ad-attribution-gap

アトリビューションギャップの照合

あなたはマーケティング測定アナリストです。照合レポートを作成してください。各レポートシステムが主張する数値の差を示し、その差のすべての単位を、名前の付いた原因に割り当てます。広告プラットフォーム、分析ツール、そして金額を記録するシステムの間に差があるのは、構造上当然のことです。数値が完全に一致するレポートは、誰かが数値を捏造したレポートです。

すべての手順に、次のテストを適用してください。その手順は、ギャップを数値化し、その数値を名前の付いた原因に割り当てるのに役立ちますか。そうでなければ、省略してください。

対応範囲 — 引き継ぎ、抱え込まない

• トラッキングの修正や導入（タグ、ピクセル、重複排除の設定）は対象外です。分析の結果、「タグの動作に不具合がある」または「重複排除が壊れている」と判明した場合は、その所見を示し、ギャップに占める割合を数値化し、担当者を割り当てて、mbfinotti/advertising-skills@ad-conversion-tracking に引き継いでください。
• アトリビューションモデルの選択は対象外です。モデル間の違いは、測定して差し引くべき差異の原因として扱い、選択すべき判断事項として扱わないでください。ユーザーから「どのモデルを使えばよいか」と尋ねられた場合は、アトリビューションモデル選択のリソースを案内してください。
• 広告アカウントのパフォーマンス診断、ランディングページの作業、CAC／ROAS のベンチマークは、ほかのスキルの担当です。

財務照合から取り入れた規律

財務照合では、両方の側の調整後残高を出してから比較し、照合項目をすべて分類し、差額が $0.00 になった時点でのみ完了とします。最初の二つの手順を取り入れ、三つ目は意図的に変えてください。

1. 数値を一つでも比較する前に、両方の側を共通の基準にそろえます。
2. 差異のすべての単位を、次の三つの区分のいずれか一つに分類します。タイミング、定義上の違い、未説明の残差。
3. 残差を明示し、ゼロにしようとしてはいけません。銀行照合では差額を $0.00 に合わせる必要がありますが、アトリビューション照合ではそうなりません。システムが実際に異なるものを数えているためです。目標はゼロではなく、説明のつく小さな残差です。

この判断基準を最初に示してください。アカウント規模を問わず機能するため、どのような割合のしきい値よりも有効です。

• ギャップが、期間ごとに 安定しており、想定された方向で、名前の付いた原因に分解できる 場合、そのギャップは正常です。
• ギャップの方向が 反転する、突然跳ね上がる、または 既知の仕組みに帰属できない 場合、そのギャップは不具合です。

このテストは区分に正確に対応しています。不具合とは、タイミングまたは定義上の違いとして分類できないギャップにほかなりません。

始める前に確認する5つの質問

最初にまとめて質問してください。これは戦術的な実行であり、戦略に関するヒアリングではありません。

1. どのソースを使いますか？広告プラットフォーム、分析ツール、そして正とするデータのソースを挙げてください。
2. 金額を管理しているのはどのシステムですか？CRMですか、それとも受注・請求システムですか？コンバージョン数の基準となるのはそのシステムです。ユーザーが広告プラットフォームを基準にすることを提案した場合は、異議を唱えてください。プラットフォームが報告するのはコンバージョンの申告であり、実際に受け取った金額ではありません。
3. この差異によって、どの意思決定が妨げられていますか？（予算の再配分、取締役会に報告する数値、チャネルへの信頼など。）これにより、どこまで細かく分解するかが決まります。
4. どの期間を、どの粒度で見ますか？週次または月次を推奨してください。日単位の比較では、タイムゾーンや日付記録の違いが誤った差異として増幅されます。
5. B2B、B2C／Eコマース、それとも混合型ですか？混合型の事業では、2つのファネルを別々に照合します（「B2BとB2C」のセクションを参照）。

同じタイミングで、さらに3つ質問してください。質問の回数は1回分増えるだけですが、実行の最後に提示する選択肢の順序が決まります。ユーザーに代わって、欠陥の一覧と次に行う測定方法を順位付けするには、これらの情報が必要です。

6. 回答はいつまでに必要ですか？ 期限が近い場合は、自己申告によるアトリビューションや、1時間でできるタグまたはフォームの修正など、すぐに実施できる選択肢が優先され、完全なテスト期間が必要な選択肢は除外されます。
7. 一度きりの成果ですか、それとも積み上がる資産ですか？ 一度きりの回答が必要なら、問題となっている単一チャネルでホールドアウトテストを行うのが適しています。継続的に積み上げることが目的である場合に限り、恒常的な測定作業が正当化されます。
8. 作業量の上限はどのくらいですか？ アナリストの作業時間、エンジニアリングチームとの調整、広告費を止めるために必要な社内での調整力、変更の取り消しやすさを確認してください。「今週、自分で使える時間」が上限なら、他のチームが必要な選択肢はすべて除外されます。

ユーザーがエクスポートしたレポート（CSV、スプレッドシート、データウェアハウスの抽出データ）を確認できる場合は、それを使って作業してください。そうでない場合は、各システムに表示されている次の値を貼り付けるよう、ユーザーに依頼してください。

• 合意した期間のコンバージョン数と売上。
• 日付の基準、タイムゾーン、通貨。
• システム独自の設定に表示されているアトリビューション期間とカウントルール。

ステップ 1 - 共通の基準に正規化する

正規化前の比較には意味がなく、実務担当者が見落としがちな手順が正規化です。両方のレポートが同じコンバージョンアクション、同じタイムゾーンでの同じ期間、同じ定義を対象にするだけで、報告される「不一致」の多くは小さくなります。以下の各軸を揃え、選んだ基準をレポートに記録してください：

1. 日付の基準。 広告プラットフォームは通常、コンバージョンを広告インタラクションの日付（クリックまたはインプレッション）に記録し、日付をさかのぼって計上します。分析ツールと真実の基準となるデータソースは、コンバージョンイベントの日付に記録します。月曜日のクリックから木曜日に購入が発生した場合、一方のシステムでは月曜日、もう一方では木曜日に表示されるため、短い期間でデータを取得すると、一方ではコンバージョンがあり、もう一方ではゼロになることがあります。片方の日付を調整するか、両方の基準をカバーするまで期間を広げてください。
2. タイムゾーン。 各システムは、それぞれに設定されたタイムゾーンでレポートします。深夜近くのコンバージョンは、実際には差がなくても異なる暦日に計上されます。週次／月次の粒度にすれば、その影響の大部分は解消されます。
3. 通貨。 各システムの通貨と、コンバージョン時にどちら側が適用する通貨かを確認してください。売上については、取引日の真実の基準となるデータソースの為替レートを基準にします。
4. コンバージョンの定義。 どのイベントをカウントするか、また各システムのカウントルールを揃えてください。プラットフォームによってはクリックごとにコンバージョンを_すべて_カウントし、別のプラットフォームでは_1 件_だけカウントします。1 件の注文でも、ダッシュボードによって単位が異なることがあります。
5. アトリビューション期間とモデル。 デフォルトを決めつけないでください。プラットフォームごとにデフォルトが異なり、変更されることもあります。ウェブを閲覧できる場合は、各プラットフォームで現在公開されているデフォルト期間を確認してください。そうでない場合は、ユーザーにプラットフォームの設定から確認してもらってください。設定可能な場合は、システム間で期間とモデルを一致させます。設定できない場合は、その違いをステップ 3 で数値化する定義上の要因として記録してください。
6. クリックスルーとビュースルー。 プラットフォームは、クリックベースの分析では把握できないビュースルーコンバージョンを含めています。比較前にビュースルーを除外するか、定義上の差として別項目に計上してください。
7. モデルによる推定値と実測値。 プラットフォームや分析ツールは、トラッキングがブロックされた場合にモデルによる推定コンバージョンを追加します。モデルによる推定値と、確定的な注文数を比較する場合は、どちらがどちらなのかを必ず明記してください。
8. 売上の基準。 基準を 1 つ選んでください。デフォルトとして、税金と送料を除いた純売上を推奨します。すべてのシステムに同じ基準を適用し、返金、キャンセル、割引を各側でどのように扱うか記録してください。
9. データの成熟度。 遅延が十分に反映された期間だけを比較してください。期間の一部でアトリビューションウィンドウがまだ開いている場合、データ取得後もプラットフォームの数値が増え続けるため、未成熟な割合をタイミング要因として明記します。分析側のデータも遅れて確定するため、最近のコンバージョンは、照合できないものを差として扱う前に十分な時間を置いてください。実務上の方法の一つでは、丸 4 日待ちます。早すぎる比較は見かけ上の差を生み、1 日だけの期間では最悪のケースになります。7 日以上を使用してください。

ステップ 2 - 差分を定量化する

1. コンバージョン数と売上は、信頼できる唯一の情報源を基準にします。それ以外の情報源で説明するのは、コンバージョンの「件数」ではなく「発生元」です。
2. 組み合わせごとに、各広告プラットフォームと基準値、分析ツールと基準値、プラットフォームと分析ツールの差分を、絶対値と基準値に対する割合で算出し、符号（どちらが大きいか）も示します。
3. 広告プラットフォーム間で合算してはいけません。あるプラットフォームが 100 件、別のプラットフォームが 80 件を計上し、注文システムの記録が 120 件なら、コンバージョン数は 120 件です。プラットフォームの計上は重複しています。プラットフォーム間の重複自体も、定義上の差分として定量化します。
4. ペアごとの総差分（正規化後の絶対差）が、ステップ 3 で内訳を明らかにする対象です。
5. 複合的なクロスチェックを実施します。MER ＝ 総売上 ÷ 総広告費として、信頼できる唯一の情報源と実際の請求額を使って算出します。あるアトリビューションベンダーは、業界や事業段階によって大きく異なるという但し書き付きで、5.0 以上を一般的な数値として挙げています。MER はプラットフォームごとのアトリビューションを完全に回避するクロスチェックとして扱い、目標値として扱わないでください。プラットフォームごとの数値が改善する一方で MER が悪化しているなら、正しくないのはプラットフォームの数値です。
6. 比率を確認します。プラットフォームの報告数が基準値の約 1.5 倍を超える場合、二重計上が疑われます（標準ではなく、実務者の経験則です）。バケット 2 ではなく、バケット 3 に回して調査します。

ステップ 1～4 は B2B と B2C で同じです。異なるのは基準とするシステムのみです。

ステップ 3 - すべての単位を必ず 1 つのバケットに分類する

何よりも先に方向性のルールを適用します。それぞれの原因が差分をどちら向きに広げるかは決まっています。観測された差分と逆方向に差分を広げる原因では、その符号の差分を説明できません。このルールを使って、候補となる原因をすばやく絞り込みます。以下のリストで「プラットフォーム側が多い」とは、その原因によって広告プラットフォームの報告数が基準値を上回ることを意味します。

バケット 1 - タイミング：実際に発生するが、いずれ解消する

処理が追いつけば、2 つのシステムの数値は一致します。修正は不要ですが、比較の日付を変更するか、後日再実行する必要があります。各項目の解消予定日を記録してください。

• 広告インタラクション日とイベント日のどちらに日時を記録するかの違い（方向は、集計期間のどちら側に位置するかによって異なります）。
• アトリビューション期間がまだ終了していない場合。直近のクリックによるコンバージョンがまだ反映されていません（プラットフォーム側が少なく、その後追いつきます）。
• B2B のリードから成約までの遅延：クリックの数週間後に、CRM で案件が成約します。アトリビューション期間が営業サイクルより短いプラットフォームでは、その成約を把握できません（成約売上に対してプラットフォーム側が少ない状態です）。
• オフラインコンバージョンのアップロードと処理の遅延：イベントから数時間または数日後にインポートされます（処理されるまでプラットフォーム側が少ない状態です）。
• 処理中の注文：一方のシステムでは保留中または未発送の注文を計上し、もう一方ではまだ計上していません。

バケット 2 - 定義：実際の違いであり、説明できるが、解消はしない

システムごとに、実際に異なる対象を計上しています。各項目を定量化し、記録済みの想定差分として引き継いでください。「修正」してはいけません。

• アトリビューション期間の長さの違い（期間が長いシステム側が多くなります）。
• アトリビューションモデルの違い：プラットフォームは自らのクリックに 100％のクレジットを付与し、チャネル横断の分析モデルはチャネル間でクレジットを分配します（分析ツールに対してプラットフォーム側が多くなります）。
• 片方のみでビュースルーコンバージョンを含めること（プラットフォーム側が多くなります）。
• 片方のみでモデル化または推定されたコンバージョンを含めること（含める側が多くなります）。
• 計上ルール：「すべて」のコンバージョンを数えるか、クリックごとに「1 件」のみ数えるか（「すべて」の側が多くなります）。
• プラットフォーム間の相互クレジット付与による重複：複数のプラットフォームが同じコンバージョンをそれぞれ計上します（プラットフォームの合計が基準値を上回ります。これがプラットフォームを合算してはならない理由です）。
• 売上を税金、送料、割引込みの総額で見るか、それらを差し引いた純額で見るか（総額側が多くなります）。
• 返金、キャンセル、チャージバックは信頼できる唯一の情報源には記録されますが、プラットフォームや分析ツールでは取り消されないことがよくあります（売上についてはプラットフォーム／分析ツール側が多くなります）。
• 為替換算に異なるレートや日付を適用すること。
• ボットや無効なトラフィックに対するフィルタリングルールがシステムごとに異なること。

バケット 3 - 説明のつかない残差：不具合を示す唯一のバケット

バケット 1 と 2 を定量化した後に残るものです。エスカレーションされるのはこのバケットだけで、mbfinotti/advertising-skills@ad-conversion-tracking に引き渡されるのもこれだけです。ここに隠れていることがわかっている要因は次のとおりです。

• タグの破損、欠落、または重複発火（重複の場合：プラットフォーム側が高くなることが多く、比率が約1.5倍を大きく超えることもあります）。
• ブラウザーイベントとサーバーイベントの重複排除の失敗（プラットフォーム側が高くなります）。
• 予想されるベースラインを超える、同意設定、トラッキング防止、広告ブロッカーによる損失（アナリティクス側が低くなります）。
• リダイレクト、リンク短縮サービス、アプリ内ブラウザーによってトラッキングパラメーターが削除され、トラフィックが「ダイレクト」に分類される（アナリティクスで誤分類され、合計値には差がないのにチャネル単位で差が生じます）。
• AI アシスタントからの流入：約70％の AI アシスタント経由のトラフィックはリファラーなしで到着し、「ダイレクト」に誤分類されます（ある成長マーケティングニュースレターの数値であり、傾向を示すもので監査済みではありません）。合計に変化がないまま、チャネル構成が「ダイレクト」側に移ります。
• デバイス間および ID の不一致：デバイス間またはサブドメイン間でユーザーの行動経路が途切れます（アナリティクス側が低くなり、プラットフォーム側への影響は比較的小さくなります）。
• テスト注文や社内トラフィックが、真実の基準となるデータソースを汚染します（基準値側が高くなります。はい、基準値も間違っていることがあります）。

すべてのバケットのすべての項目に、金額（件数と売上）、方向の整合性チェックの合否、根拠、担当者を記載します。金額を推定するしかない場合は、推定値であると明記し、その根拠を示してください。

ステップ 4 - 残差を判定する

1. ペアごとに残差を計算します：総差異から、定量化したタイミング要因と定義上の要因を差し引きます。件数、売上、総差異に対する割合で表します。

2. 判定テストを適用します：残差は安定していて、方向性に一貫性があり、小さいでしょうか。その場合は記録して終了します。ゼロになるまで追いかけないでください。

3. 「小さい」の判断に関する背景を、正直に記載します。正式に公開されている許容範囲は、大手アナリティクスベンダー自身のドキュメントにあるものだけです。そこでは、ページビューの差異は最大10％、ユーザー数／セッション数の差異は最大20％まで「想定内であり、懸念する必要はない」とされています。以下に示すその他の範囲はすべて、トラッキング監査を販売するベンダーや代理店に由来するため、見解が一致している方向性には意味がありますが、正確な割合は自己申告であり、監査済みではありません。これらは標準ではなく、参考となるトリアージの目安として引用し、レポートにもその旨を記載してください。

   ペア	引用されている正常範囲	引用されている調査対象の範囲
   広告プラットフォームとアナリティクス	10〜20％	範囲を大幅に超える場合。10〜30％も正常範囲として広く引用されています
   アナリティクスと注文バックエンド	約25％未満	35％超
   サーバーサイドとブラウザーイベント	最大約10％	マッチ率が50％未満で、差異が約30％の場合

4. 事前確率を調整します。代理店の監査では、ほとんどのアカウントに少なくとも1つ、重大なコンバージョントラッキングの不具合があることが報告されています。バケット3の不具合が見つかるのは例外ではなく、よくあるケースです。それでも方向性のルールに従って分類する必要があります。そうしなければ、結論にならず、残差のままです。

5. 方向が反転する、突然変化する、または既知のメカニズムでは説明できない残差は、不具合です。不具合は、売上への影響額だけでなく、修正にかかる労力あたりの売上影響額で順位付けします。調整内容を示してください。各不具合の売上への影響、次に修正にかかる労力、そして比率での実際の順位を明記します。一般的な不具合クラスの典型的な順序は次のとおりです。

   • 効率：タグの二重発火 > アンカーの汚染（テスト注文と社内注文） > クリック ID の取得漏れ > トラッキングパラメーターの削除 > タグの破損または欠落 > ブラウザーとサーバー間の重複排除の失敗 > 同意とトラッキング防止による損失 > クロスデバイスの ID ギャップ
   • 価値：クロスデバイスの ID ギャップ > 同意とトラッキング防止による損失 > ブラウザーとサーバー間の重複排除の失敗 > タグの二重発火 > タグの破損または欠落 > クリック ID の取得漏れ > トラッキングパラメーターの削除 > アンカーの汚染

   この2つの順序が逆転することこそ、分けて考える理由です。

   • ID と同意の損失は、売上への影響額が最も大きく、修正も最も困難です。エンジニアリングに4分の1人月を費やすか、定常的なジョブを設ける必要があり、どれだけ労力をかけても一部は構造的なものです。同意による損失の是正には、リリース前に法務の承認も必要となるため、売上への影響額に比べてさらに順位が下がります。
   • 非表示フォームフィールドの欠落、テスト注文のフィルター、タグの重複は、1時間の作業で完全に元に戻せます。

   1時間で対応できる4つのクラスは、所要時間が同じでも同じものではありません。

   • タグの重複が最優先です。1人の担当者が1つのタグコンテナーを修正するだけで、大幅な過剰計上を解消できます。
   • 次がアンカーの汚染です。労力はほぼゼロで、アナリストが全面的に担当できます。
   • クリック ID の取得とパラメーターの削除では、それぞれ別のチームが1時間を費やします。前者はマーケティングオペレーションがフォームフィールドを担当し、後者はリダイレクトチェーンの担当者が対応します。

   この効率重視の順序では、価値リストの上位が後回しになります。クロスデバイスの ID ギャップと同意による損失は、比率では毎回順位が下がり、1時間で対応できる修正が繰り返される一方で、期間ごとに先送りされます。

   次のいずれかの条件に当てはまる場合は、どちらも1時間で対応できるクラスより上位にします。

   • そのクラスが受け持つギャップが安定しているのではなく、期間ごとに_拡大している_。
   • 質問3で挙げた意思決定がチャネル単位の再配分であり、その ID ギャップ自体が判断をゆがめている。

   安定した構造的な損失は、後回しにできます。拡大している損失は、将来のすべての期間にわたって積み重なります。

   報告前に、このアカウントに合わせて順位を付け直してください。チームがすでに社内で修正している不具合クラスは順位を上げ、インタビューで判明した厳しい期限があれば、1時間で対応できるすべてのクラスを、4分の1人月規模のクラスより上位にします。このアカウントでまったく対応できないクラスは、順位を下げるのではなく削除します。ここでサーバー側の ID 対応を担当するチームが今後も存在しない場合は、優先修正リストからその名称を挙げて削除し、担当者不在であることを示したうえで、定量化した差分として既知の差分セクションに記載します。

   順位の最下位に置いたクラスは、次の期間には対応範囲として再び浮上します。不具合ごとに担当者を割り当て、トラッキングの不具合は mbfinotti/advertising-skills@ad-conversion-tracking に引き継ぎます。

6. すべてのメカニズムを検討しても残差が解消されない場合、または2つのプラットフォームが同じコンバージョンをそれぞれ自分の実績として主張する場合は、照合の外から答えを得る必要があります。次のセクションにある順位付きの次のステップから1つを選び、名称を挙げて担当者を割り当て、そこで止めてください。

照合で決着がつかない場合 - 次の計測、優先順位付き

次の2つの状況は、このスキルの範囲を超えます。

• 既知のメカニズムをすべて検討しても残るバケット3の残差。
• 2つのプラットフォームが同じコンバージョンをそれぞれ自分の実績として主張し、照合で証明できるのが重複の存在だけである場合。

次のステップを挙げ、担当者を割り当ててください。これらの設計や実施はこのスキルの範囲外です。また、2つのトラッキング段階は mbfinotti/advertising-skills@ad-conversion-tracking の担当範囲です。 各手段がどれだけ決定的に聞こえるかではなく、投入する労力あたりにどれだけの価値が得られるかで順位付けします。各軸の順位は一致しないため、4つすべてを確認してください。

• 効率：自己申告によるアトリビューション > ホールドアウトまたは地域テスト > イベントIDを共有するサーバーサイド収集 > 同意シグナルの設定とモデリングによるコンバージョン計測 > メディアミックスモデリング
• 価値：ホールドアウトまたは地域テスト > メディアミックスモデリング > イベントIDを共有するサーバーサイド収集 > 自己申告によるアトリビューション > 同意シグナルの設定とモデリングによるコンバージョン計測
• 労力：メディアミックスモデリング > ホールドアウトまたは地域テスト == イベントIDを共有するサーバーサイド収集 > 同意シグナルの設定とモデリングによるコンバージョン計測 > 自己申告によるアトリビューション
• コンプライアンスコスト：同意シグナルの設定とモデリングによるコンバージョン計測 > イベントIDを共有するサーバーサイド収集 > 自己申告によるアトリビューション > ホールドアウトまたは地域テスト == メディアミックスモデリング

どちらの同順位も、先送りされた判断ではなく、実際に同等であることを示しています。労力の軸では、ホールドアウトもサーバーサイドの構築も、数週間から四半期にわたって別のチームの協力が必要になります。前者は広告費を使わないことで、後者はエンジニアリングの時間でコストを支払います。どちらも1時間で済むものでも、恒常的な業務でもありません。

コンプライアンスコストでは、どちらもこの軸の最低水準にあります。どちらも新たな個人データを収集しません。開示するものも、審査するものもなく、元に戻しても新たなデータ収集は発生しません。

段階	かかるコスト	得られるもの	必要な対応
自己申告によるアトリビューション	フォーム入力に1時間と、レポート項目を1つ追加する手間。その後、データに反映されるまで一定期間かかります	同意を失っても完全に有効な、独立したチャネルシグナルです。精度は粗く、自己申告による偏りはありますが、妨げられることはありません	新しい項目についてプライバシー通知に一文追加すること
ホールドアウトテストまたは地域テスト	設計に1週間、その後テスト期間全体（B2Cでは数週間、B2Bのサイクルでは四半期単位）に加え、広告費を差し控えるための社内調整力が必要です	唯一の因果関係に関する答えであり、2つのプラットフォーム間のアトリビューション争いを完全に解決できる答えです	規制上の対応は不要です。広告費を再開すれば完全に元に戻せます
イベント ID を共有するサーバーサイド収集	2つのチームにまたがる数週間のエンジニアリング作業	推定ではなく、観測されたコンバージョンを復元し、二重計上を発生源で解消します	同意シグナルをサーバーサイドで引き継ぐことに加え、最初のイベントを送信する前にデータ所在地と契約を確認すること
同意シグナルの設定とコンバージョンのモデリング	数日間のセットアップ。その後は監査アクセスのないベンダー所有の出力になります	プラットフォーム側のボリュームを推定値として復元します。問題の解消ではなく、ステップ1のモデル値と観測値の区別を再現します	法域ごとに法務の承認が必要です。設定を誤ると、同意を再収集する必要があります
メディアミックスモデリング	継続的な業務です。パイプライン、モデリング、更新頻度を誰かが管理します	オフラインやブランドを含め、コンバージョン記録では捉えられないチャネル全体の予算配分が分かります	規制上の対応は不要です。集計された広告費と成果データを使って実施します

デフォルトの段階：既存の照合と並行して実施する、自己申告によるアトリビューションです。

効率性を優先する順序では、この選択肢のうち因果関係を明らかにするものが後回しになります。ホールドアウトとメディアミックスモデリングは、どちらも照合では得られない証拠をもたらしますが、どちらもフォーム入力にかかる1時間に効率性の評価で負けます。メディアミックスモデリングは価値で2位にランクされる一方、効率性では最下位です。

どちらも比率によって優先順位が上がることはないため、それぞれに個別のトリガーを設け、意図的に適用する必要があります。

• 2つのプラットフォームが同じコンバージョンを主張し、争点となっている予算が広告費を差し控える判断に値する時点で、ホールドアウトに切り替えます。これより安価な段階でアトリビューション争いを解決することはできません。
• オフラインやブランドを含め、コンバージョン記録では捉えられないチャネルにポートフォリオがまたがり、継続的に担当できる人がいる場合は、メディアミックスモデリングに切り替えます。

この順序はデフォルトであり、絶対的なものではありません。状況や実行する人によって変わります。このアカウントについてすでに分かっていることに基づいて、順位を付け直してください。

• すでにマーケティングデータをモデル化しているデータウェアハウスがあれば、ミックスモデリングの作業負担は大幅に軽減されます。
• 既存のサーバーサイド収集レイヤーがあれば、その段階への移行は設定変更だけで済みます。
• 厳格な同意規制のある地域では、その割合にかかわらず、同意シグナルへの対応が必須になります。

インタビューでの回答によっても順位は変わります。直近の厳しい期限がある場合、完全なテスト期間を要する段階はすべて順位が下がり、単発の義務であれば、継続的に実施する2つの段階はどちらも順位が下がります。

ユーザーの制約により実施できない段階は、最下位に回すのではなく削除し、レポート内でその削除を明記してください。どの地域やオーディエンスでも広告費を抑えることを拒む場合、ホールドアウトと地域別テストは両方とも対象外になります。残る4つを順位付けし、因果測定の段階は選択肢にないと明記してください。「後で」という見出しの下に残しておくと、次の四半期に再び対象範囲に含まれてしまいます。

• エンジニアリングリソースがない場合、サーバーサイド収集は同様に対象外になります。
• 更新の運用担当者がいない場合、ミックスモデリングは対象外になります。
• アカウントに同意規制対象のトラフィックがない場合、同意シグナルの設定は対象外になります。

成熟した最終形は、どれか1つの手法を勝者とすることではなく、複数の手法による照合です。

• 日々の入札最適化にはプラットフォームのアトリビューションを使います。
• 因果関係の実態を把握するにはインクリメンタリティ実験を使います。
• ポートフォリオの配分にはミックスモデリングを使います。
• どの手法も単独では信頼しません。

プラットフォームのレポートは構造的に自画自賛になりがちです（あるグロース系ニュースレターの言葉を借りれば、「各プラットフォームのAIは、自分自身の成果をよく見せるよう最適化されています」）。だからこそ、その偏りを正す仕組みはプラットフォームの外部に置く必要があります。

B2B と B2C

正規化の軸、3つのバケット、方向のルール、合算禁止のルール、レポートの形式、プラットフォームによる自己計上の扱いは、どちらも同じです。存在しない違いを探さないでください。

B2B（基準：CRM）。

• クローズ日ではなく、リード作成日 でコホートを分けてください。そうしないと比較に意味がありません。主なタイミングの違いはリード獲得から成約までの期間であり、クローズ日で抽出すると、プラットフォームが数か月も離れて認識したコホートが混在します。
• プラットフォームに照合するための橋渡しとなるのは、オフラインコンバージョンのインポートです。広告プラットフォームのクリック ID を非表示のフォームフィールドで取得し、リードに保存したうえで、その ID をキーとして照合します。インポート自体のアップロードの遅延と照合率も、差異の原因です。
  • 現場から報告されているクリック ID の照合率は、およそ 75～85％です。
  • 約 50％を下回る場合は、取得時の不具合を疑ってください。Cookie がブロックされている、リダイレクトで ID が削除されている、または CRM がすべての送信で ID を保存していない可能性があります。これはバケット 3 に該当します。
  • プラットフォームでは、クリック後にインポートを受け付ける期間にも上限があります。現在の公式ドキュメントに記載された期間を確認してください。
  • ブラウザーのトラッキング防止機能により、Cookie に保存されたクリック ID は数日で削除されることがあります。そのため、最初のクリック時にサーバー側で取得することが重要です。
• コンタクト単位ではなく、アカウント単位でアトリビューションを行ってください。そうしないと、複数人が関わる購買グループのうち、フォームに入力した人に功績が付与されてしまいます。
• 件数が少ないことを想定してください。分母が小さいと、割合の差は大きく変動します。すべての割合とあわせて実数も報告し、より長い期間を優先してください。
• ラストタッチでは、長いサイクルにおけるプラットフォームの貢献が過小評価されます。B2B 広告の実務家 AJ Wilcox の言葉を借りれば、「ディスカバリーが無視されます。見込み顧客が 1 回のクリックだけでコンバージョンに至ることは、ほとんどありません。」モデルの違いは定義上の違いとして記録してください。分析の途中でモデルを切り替えないでください。

B2C／eコマース（基準：注文／請求システム）。

• 定義上の主な違いは、返金、キャンセル、重複注文／テスト注文、および税、送料、割引を含む総額と、それらを差し引いた純額のどちらで売上を計上するかです。売上の基準を 1 つ（税と送料を除いた純額を推奨）定義し、すべての箇所で適用してください。
• 注文のライフサイクル（保留 → 支払い済み → 履行済み → 返金／キャンセル）によって、広告プラットフォームには反映されない取り消しが発生します。返金が注文システム自体のあるレポートには表示され、別のレポートには表示されないことさえあるため、基準データも監査してください。
• ブラウザー側とサーバー側を照合する橋渡しには、通常は注文 ID である共通のイベント ID を使用し、各購入イベントの 2 つのコピーを重複排除します。イベント ID の欠落または不一致は、バケット 3 の二重計上の原因になります。
• B2B よりもプラットフォームでの過剰なアトリビューションが顕著です。これは、ビュースルーコンバージョンやモデル化されたコンバージョンが、プラットフォームの計上件数に占める割合が大きいためです。
• サイクルが短いため、タイミングの違いは数日で解消します。期間が終了してから比較を再実行すると、バケット 1 の大部分は解消されているはずです。

レポート

次のセクションを含む照合レポートを作成します（詳細な作業例として、B2C と B2B の例が 1 つずつ記載された ./references/reconciliation-examples.md を参照してください）。

1. 概要 - 基準システム、基準となる数値、ペアごとの一行判定（「構造上の差異で説明済み」または「不具合を発見、担当者を割り当て済み」）。
2. 正規化の基準 - 日付の基準、粒度、タイムゾーン、通貨、コンバージョンの定義、計測期間／モデルの設定、収益の基準。定義には日付を付けてください。日付のないコンバージョン定義の変更は、あらゆるトレンド比較を無効にします。
3. 差異テーブル - 原因ごとに 1 行、列は次のとおりです：ソースのペア | 指標 | 金額 | 総差異に占める割合 | 区分 | 原因 | 方向の確認 | 根拠 | 担当者 | ステータス。
4. 残差の記述 - ペアごとに、総差異、説明できた割合、残差、判定テストの結果を記載します。
5. 不具合と引き継ぎ事項 - 修正作業量あたりの影響売上額の大きい順に並べ、売上額と作業量の調整値を別々の列に記載します。こうすることで、最大の数値が必ずしも最優先ではない理由を確認できます。それぞれに担当者と次のアクションを記載します。
6. 次回に引き継ぐ既知の差異 - 次の期間の照合を警告ではなく、文書化された想定から開始できるよう、次回も適用する定義上の項目を記載します。

経営陣や役員向けの数値は、財務上の正式な記録として使用するソースを基準にしてください。プラットフォームが報告する数値は、プラットフォーム内での入札最適化にのみ使用し、資料にプラットフォームの ROAS を掲載する場合は、インクリメンタルではないことを明記してください。担当者列での一般的な役割分担は次のとおりです。

役割	担当範囲
アナリスト（通常、このスキルの利用者）	正規化と照合そのもの
メディアバイヤー	プラットフォーム設定、計測期間、タグ付けパラメーター
マーケティングオペレーション／RevOps	CRM フィールド、クリック ID の取得
データ／分析エンジニアリング	データウェアハウスのモデル、重複排除キー
財務	純収益（正式な記録として使用する数値）

失敗しやすいポイント

• 正規化する前に比較すること。これは最もよくある誤検知です。クリック日別の合計とイベント日別の合計の差は、不具合ではなく定義によるものです。
• 広告プラットフォーム間でコンバージョンを合算すること、または計測期間の異なるプラットフォームを 1 つの合計にまとめること。
• 残差をゼロにすること。完全な照合は、厳密さの証拠ではなく、捏造の証拠です。
• 10～30％という俗説上の範囲を標準として扱うこと、または許容値の根拠のステータスを明記せずに引用すること。
• モデルによる推定値と決定論的な件数を、どちらも計上済みの取引であるかのように比較すること。
• 平均差異を一度測定し、固定補正値として以後ずっと差し引くこと。差異は同意率やメディアミックスの変化に伴って常に変動します。期間ごとに再計算してください。
• どちらか一方のシステムが「正しい」と決めつけること。異なるものを測定しているなら、両方のシステムが正しい場合もあります。また、基準となるシステムにテスト注文や未処理の返金が混入している可能性もあります。
• B2B のコホートを、リード作成日ではなく成約日で分類すること。
• データ量の少ない B2B で、割合だけを報告すること。
• レポートの履歴に注記せずタグを修正すること。修正によって不連続が生じ、次の期間に不具合のように見える可能性があります。

目的と合格基準

このスキルの自然なスコアは説明済み割合です。ソースペアごとに、（定量化されたタイミング要因＋定量化された定義上の要因）÷総ギャップで算出します。

• 合格：説明済み割合が80％以上であり、残差が判定基準を満たしていること（安定しており、方向性に一貫性があり、既知のメカニズムに該当する候補を未検証のまま残していない）。
• 80％とする理由：許容される残差（ギャップの20％以下）は、公式に公開されている唯一の期待範囲内に収まります（分析ベンダー自身のドキュメントによると、10～20％までの差異は正常です）。そのため、残りの5分の1を追いかけても、基礎データが裏付けられない精度を求めることになります。
• 達成するまで反復します：説明されていない単位ごとに、方向性のルールに従ってバケット1とバケット2の原因リストを確認します。ウィンドウが閉じた後に再実行し、疑われたタイミング要因が実際に解消されたことを確認します。その後に限り、残りを残差として受け入れるか、欠陥としてエスカレーションします。
• 100％は達成できません。欠陥が見つからず、反復しても80％未満で行き詰まった場合は、除外した要因とともに、その旨をレポートで明記します。除外項目を明示した正直な70％のほうが、作り上げた100％より優れています。

参考資料

• mbfinotti/advertising-skills@ad-conversion-tracking - バケット3で見つかった追跡の欠陥（タグの破損、重複排除の失敗）が確認済みの場合に引き継ぎます。
• ./references/reconciliation-examples.md - 現実的で説明用の数値を用いた、照合の詳細な例（B2CおよびB2B）。

任意の連携に関する注記（ベンダー固有の内容です。ユーザーがこれらのツールを使用している場合を除き、読み飛ばしてください）。 上記の一般化された仕組みは、特定のプラットフォームやツールに次のように対応します。

• Google Ads：広告インタラクション日の記録、「すべて／1回」のカウント方法、30日間のクリックIDウィンドウを用いたオフラインコンバージョンのインポート。
• GA4：イベント日の記録、クロスチャネルモデル。期待される差異の数値である10％／20％は、Google Analytics ヘルプ（support.google.com/analytics/answer/11986666）に基づいています。
• Meta Pixel と Conversions API：共通のイベントIDによる重複排除。
• B2Bの結合キーとしてのクリックID：gclid、wbraid／gbraid（Google）、msclkid（Microsoft）、li_fat_id（LinkedIn）。
• B2Cの基準としての Shopify／WooCommerce：Shopifyの総額と純額の「Total Sales」の計算式、および在庫を戻さない返金に注意してください。
• B2Bの基準としての Salesforce／HubSpot。

出典：MERの約5.0以上という数値はNorthbeamによるものです。リファラーのないAIトラフィックが約70％という数値はDemand Curve（ニュースレター第331号）によるものです。「自社に都合よく見えるよう最適化されている」という表現はDemand Curveによるものです。any-touchに関する引用はAJ Wilcox（B2Linked）によるものです。