広告費用の収益率におけるデータ品質の問題の隠れたコスト
The hidden cost of data quality issues in the return on advertising spend.
あなたのデータには、どの顧客が利益を生み出し、どの顧客がそうでなかったかについて多くの情報があります。あなたがB2B企業のライフサイクルマーケティングマネージャーとして、無料トライアルから有料顧客に変換するために最適化する場合や、B2Cのeコマースで初回ユーザーが製品を購入するために最適化するデータサイエンティストとして働く場合でも、各ユーザーはあなたにとって価値があります。
主要企業は、ウェブサイトや製品との相互作用に基づいて顧客のライフタイムバリューを予測することに長けてきました。このデータを武器に、彼らは入札を調整し、ライフタイムで50ドルの追加収益が見込めるユーザーに追加の5ドルを支払うことができます。
言い換えれば、あなたは直接GoogleやMetaに予測データを入力し、各顧客に適切な価格を支払うことで市場で勝利するための入札戦略を調整するためのゴールドマインを手にしています。
顧客のライフタイムバリュー（CLTV）計算に影響を与えるデータの問題により、価値に基づく入札が誤った仮定に基づいて行われることがあります。
しかし、広告費用対効果は顧客のライフタイムバリューの計算によるものです。
平均的な250〜500人規模の企業は、何百ものテーブルにわたって数十のデータソースを使用し、使用するデータの正確性についての適切なレベルの可視性を常に持っているわけではありません。これは、彼らが予算を誤ったユーザーに割り当て、数十万ドルを無駄にすることを意味します。
この投稿では、生データが変換され、広告プラットフォームで価値に基づく入札に使用される際に、データ駆動型マーケティングチームが直面するデータ品質の問題について掘り下げます。具体的には、以下の領域について詳しく説明します。
- 360度の概要 – マーケティングデータスタック全体の概要を持つことの重要性
- モニタリング – マーケティングパイプラインで注意すべき一般的な問題
- 人とツール – 信頼性のあるマーケティングデータパイプラインを構築するための人とツールの調整の重要性
マーケティングパイプラインの360度概要が必要な理由
各顧客の価値を理解するためには、ユーザーの行動や強力な指標となるデータポイントを分析することができます。これにより、数十の異なるシステムから導かれた予測要因のリストが明らかになることがよくあります。これらの要因を組み合わせることで、顧客の完全なビューを得て、顧客の価値が高いことを示す行動やアクションの背後の主な要因を理解することができます。
たとえば、B2B企業のマーケターであれば、無料ユーザーから有料ユーザーに移行させる要因を理解しているかもしれません。
- 2回ログインすることで、顧客のコンバージョン率が50％向上する（Stripe）
- 7日以内に他のユーザーを紹介すると、顧客の価値が70％向上する（Segment）
- 企業のメールアドレスを持ち、250人以上の従業員がいるユーザーは、支払い顧客になる可能性が30％高い（Clearbit）
- モバイルのみのログインは、顧客の価値を30％減少させる（Amplitude）
数十の上流ソースがデータウェアハウスに入る前に、GoogleとFacebookに送信される
包括的な概要がないと、入札システムに入力されたデータの正確性を誤って想定し、後に以下のような重要な問題が発生する可能性があります：
- Clearbit/Segmentの統合の問題により、メールドメインから企業のサイズが正しく抽出されない。
- Amplitudeのチェックアウトフローの重要なアクションのデータが欠落するためのイベントトラッキングの競合。
- Stripeの統合からのデータ同期の不正確さにより、顧客の購入に関する情報が不完全になる。
「第三者データソースの問題により、CLTVの計算が壊れました。その日にGoogleに費やした100,000ポンドの一部を失っただけでなく、CLTVモデルが再キャリブレーションするまで数日間待たなければなりませんでした」- 500人のフィンテック企業
オンライン小売業者ASOSの顧客生涯価値（CLTV）を予測するための複数の要素の重要性が、研究論文で強調されています。この研究では、注文行動（注文数、最近の注文履歴など）、人口統計情報（国、年齢など）、ウェブ/アプリのセッションログ（最後のセッションからの日数など）、および購買データ（総注文金額など）など、主要な要素が含まれています。これらの洞察は、数百のデータ変換と数十の第三者ソースの統合の結果です。
ASOS — CLTVを決定する要素
データの問題 — 既知の未知と未知の未知
包括的なデータの概要を持つことは十分ではありません。CLTVの計算に影響を与える可能性のある問題を積極的に特定することが重要です。これらの問題は、次の2つのタイプに分類できます：
既知の未知：発見された問題であり、認識されている問題です。たとえば、パイプラインの障害によりGoogle APIがデータを12時間同期しないことがあります。
未知の未知：気付かれないかもしれない問題です。たとえば、製品の分析イベントデータがデータウェアハウスに正しく同期されていないことにより、ユーザーの行動に関する不正確な仮定が行われることがあります。
「私たちはFacebookマーケティングに1日5万ドルを費やしており、上流のパイプラインの1つが3日間同期していなかったため、予算の半分を無駄にしました。彼らが私たちに通知するまで、このことに気づきませんでした」— 250人のECサイト企業
CLTVの計算に影響を与えるデータの問題を積極的に特定し、対処するために、次の領域全体でモニタリングを行うことを検討してください：
論理テスト：dbtのようなツールを使用して、異なる列やテーブルに仮定を適用します。たとえば、user_id列が一意であり、order_id列に空の値が含まれないことを確認します。電話番号フィールドが整数のみを含み、平均注文サイズが合理的な制限を超えていないことなど、追加の論理チェックを実装します。
ボリューム：異常なデータのボリュームをモニタリングします。たとえば、注文テーブルに新しい行が急増している場合、誤ったデータ変換からの重複を示す場合や、新製品の成功を反映している場合があります。
新鮮さ：すべてのデータテーブルの最新の更新時刻を把握してください。データパイプラインの障害は、より細かい領域では気付かれない場合があります。たとえば、Clearbitからの企業サイズデータの収集を一時停止する統合の問題は、即座に検出されない場合があります。
セグメント：特定のセグメント内の問題を特定します。特定の製品カテゴリの誤ったラベリングなどは、適切なチェックがないと検出が難しい場合があります。
責任と所有権の確立
データとモニタリングシステムの包括的な概要を持ったら、監視の異なる側面に対する責任を定義することが重要です。先に述べた例では、データの所有権は製品の使用状況、人口統計情報、請求、注文に及びます。関連するソースやテーブルの所有者を割り当てることで、問題の迅速なトライアージと解決を確保します。
「重要なテストのアラートが数週間放置され、受信していた担当者が会社を辞めてしまった」— イギリスのFintech Unicorn
さらに、データ製品の最も重要なコンポーネントを優先し、サービスレベル契約（SLA）を確立してください。アップタイムとパフォーマンスを定期的に評価し、体系的な方法で注意を要する領域に対処します。
まとめ
先進的な企業は、多くのソースからのデータを使用して、各顧客の顧客生涯価値（CLTV）を正確に予測しています。これにより、広告入札を最適化し、最も利益の上がる顧客をターゲットにすることができます。ただし、広告費の成功は、CLTVの計算の正確性に最終的に依存するため、未発見のデータの問題は重大なリスクです。
バリューベースの広告入札のための高品質なデータを確保するために、以下の2つの重要な領域に焦点を当てることをお勧めします：
- 360°概観：包括的な概観を持たないと、入札システムでのデータの正確性を当然のことと思い込んでしまい、後に重大な問題が発覚する可能性があります。これらの問題には、Amplitudeのようなプラットフォームでの古いデータやClearbitとの統合の問題が含まれることがあります。
- モニタリング：CLTVの計算に影響を与えるデータの問題を積極的に特定し、対処することが重要です。論理的なテスト、データの新鮮さ、ボリュームの追跡、セグメントの分析を含むモニタリングプロセスを実装してください。
包括的な概観と積極的なモニタリングを優先することで、企業はCLTV計算の誤りに関連するリスクを軽減し、バリューベースの広告入札戦略の効果を向上させることができます。
もしマーケティングデータを扱っており、信頼性のあるデータを構築する方法について考えている場合は、ぜひお話ししましょう。[email protected]までご連絡ください。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
