ad-conversion-tracking

コンバージョントラッキング

キャンペーン予算を1ドルも消費する前に、コンバージョントラッキングが実際の成果を正しく測定していることを確認します。

• **このスキルが防ぐアンチパターン：**チームがトラッキングをローンチ前チェックリストの項目として扱い、設定画面のスクリーンショットを見ただけでチェックを付け、消化額のレポートがつじつまの合わないものになって初めて、トラッキングの不具合に気付きます。GrowthSpreeが監査したB2B SaaS検索アカウントの70～80％に、少なくとも1つの重大なコンバージョントラッキングの問題があります。
• **基本原則：**不正確なコンバージョンデータは、単に誤った測定値を報告するだけでなく、入札アルゴリズムに誤ったユーザーを見つけるよう学習させてしまいます。「トラッキングが不正確であれば、プラットフォームが行う最適化の判断はすべて、誤ったデータに基づくことになります」（PPC Hero）。

出力はチェックごとの証拠を示す検証レポートで、最後に承認者の氏名を記した明確なGO／NO-GOの判断を提示します。

対象範囲と引き継ぎ

このスキルは検証のみを行い、実装はしません。チェックリストを作成し、証拠を確認して判定を下します。トラッキングコードの作成やインストールは、実装の担当者が行います（Interviewで特定します）。隣接する領域は、以下の関連スキルが担当します。

• ローンチ後のプラットフォーム間の数値照合 → mbfinotti/advertising-skills@ad-attribution-gap。
• アカウントレベルのパフォーマンスの根本原因診断 → mbfinotti/advertising-skills@ad-account-diagnostic（トラッキングのFAILをこのスキルに差し戻します）。
• ランディングページのコンバージョン率レビュー → mbfinotti/advertising-skills@paid-landing-page-audit。
• クリエイティブの継続的な劣化モニタリング → mbfinotti/advertising-skills@ad-creative-fatigue。

Interview

一度に1つだけ質問します。すでに分かっていることや、セットアップから確認できることは省略します。これは戦術的な確認であり、面接ではありません。簡潔に進めてください。

1. キャンペーンを実施するプラットフォームはどれですか？
2. ファネルの種類はどれですか？B2Bのリード獲得、B2CのEコマース、または両方ですか？
3. サーバーサイドイベントはブラウザのピクセル／タグと併用していますか、それともブラウザのみですか？
4. 実装の担当者は誰ですか？あなた、開発チーム、代理店のどれですか？（修正依頼の宛先になります。）
5. 同意バナーは公開されていますか？また、トラフィックに同意規制のある地域からのアクセスが含まれますか？
6. このローンチに充てる予算はいくらですか？（ゲートでどれだけの予算をリスクにさらすかを判断します。）
7. ローンチ日は確定していますか、それとも変更可能ですか？確定日であれば、ほぼ工数のかからない設定とトリガーの修正を優先し、クリック識別子の連鎖はリスクを受け入れた項目としてローンチ後に回します。変更可能であれば、不具合をまとめて1回のリリースで修正し、学習し直すことができます。
8. 今回のキャンペーンだけを対象とする一度限りの承認ですか、それとも今後数四半期にわたって信頼できるトラッキング設定を目指していますか？継続的な利用を想定する場合、クリック識別子の連鎖と共通イベントIDを優先します。これらは今後のすべてのキャンペーンで役立ちます。一度限りの場合は、今回のローンチを承認するために必要なチェックだけを優先します。
9. ローンチ前にかけられる工数の上限はどの程度ですか？タグマネージャーでの作業にかける自分の時間、開発チームやCRMとの調整、法務承認まで含みますか？開発環境にアクセスできない場合、修正項目は設定とタグマネージャーでの作業に限定します。その範囲外の項目は、測定への影響と損失を受け入れた担当者をレポートに明記したうえで、項目名を挙げてリストから削除します。黙って除外したり、優先度を最後にしたまま残したりしてはいけません。

回答7～9はDefect checklistの修正項目の順序に反映します。回答を記録してください。レポートには、どの不具合を、誰の承認のもとで後回しにしたのかを明記する必要があります。

エビデンスゲート

設定画面のスクリーンショットだけを根拠に GO 判定を出してはいけません。正しく見える設定ページや、デバッガーでタグが正常に発火していることさえも、正確に計測できている証拠にはなりません。GO 判定には、少なくとも次のすべてをエンドツーエンドで追跡した実際のテストコンバージョンが 1 件必要です。

1. アクションを実行する。
2. ペイロードを確認する。
3. 正しい値と通貨でイベントがプラットフォームの UI に届いていることを確認する。
4. 重複排除されていることを確認する。
5. テストデータが除外されていることを確認する。

例外として明示されているケースが 1 つあります。まだトラフィックのない新しいプロパティでは、検証セッション中にプラットフォームの UI でコンバージョンを確認できません（イベントの表示には数時間かかることがあり、新しいコンバージョンアクションは待機ステータスから始まります）。デバッグモードのエビデンスと正しいペイロードに基づき、暫定 PASS として明記したうえで判定してもかまいません。ただし、最初の実際のコンバージョンが発生した時点で必ず再検証してください。

検証手順

順序が固定された9つのステップです。各ステップの証拠を読み取れるのは、それより前のステップが満たされた後だけです。

• タグが実際に送信した内容がわかるまでは、プラットフォームのUIを評価できません。
• 両方のソースからイベントが届くまでは、重複排除を評価できません。
• テストデータの除外は、ソーク期間にデータが生成される前に設定する必要があります。除外フィルターは遡及適用されません。

これらのステップを効率性で順位付けしたり、手軽なものを先にするために順序を入れ替えたりしないでください。この順序は依存関係の連鎖であり、ここで費用対効果順に並べると、根拠のない精密さを装うことになります。効率性による順序付けは、この手順から作成する修正リスト（欠陥チェックリスト）に適用するものであり、手順そのものには適用しません。

作業を進めながら、各ステップの証拠を記録してください。

1. 設定とコンバージョンアクションの構成。 主要コンバージョンの指定がビジネス目標と一致していることを確認します。収益に関係するアクションを主要にし、ページビューやマイクロアクションは副次的なアクションとして入札の対象から除外します。Rawsoftは、主要なコンバージョンアクションが13件あるアカウントを発見しましたが、そのうちビジネス成果に該当するのはわずか4件で、スマート自動入札は毎月150万件以上のノイズコンバージョンに対して最適化されていました。リード獲得の場合は、クリックごとに1回のみカウントする設定（「毎回カウント」ではないこと）を確認します。 証拠：主要アクションの一覧と、各アクションに対応するビジネス成果。アクションごとのカウント方法。
2. タグのデバッグ／プレビューモードに入ります。 タグマネージャーのプレビューモードと、プラットフォームのテストイベントまたはタグ検査ツールを使用します。 証拠：コンバージョンタグがコンバージョンページで確認でき、意図したトリガーでのみ発火する状態になっていること。
3. 最初から最後まで、実際のテストコンバージョンを実行します。 有料クリックからユーザーがたどる正確な経路を進みます。クリック識別子を含むURLでランディングし、同意バナーで同意し（別途、拒否も行い）、アクションを完了します。B2Cの場合：実際に少額のテスト注文を行います（割引額がほぼゼロのクーポンコードを使うか、後で返金します）。B2Bの場合：一意のQA値を含むテストリードを送信し、CRMレコードに登録されたことを確認します。 証拠：テスト注文／リードのIDと、それに付与された識別子。
4. イベントペイロードを検査します。 ブラウザーのネットワークインスペクターまたはタグデバッグツールで、実際のリクエストを確認します。イベント名、値、通貨、コンバージョンごとのイベントID、クリック識別子、使用している場合はハッシュ化された識別子が正しいことを確認します。 証拠：ペイロードの各フィールドをレポートにコピーしたもの。
5. プラットフォームのUIでイベントを確認します。 テストイベントがプラットフォームのイベントマネージャーにブラウザーまたはサーバーのイベントとして表示され、コンバージョンアクションの記録ステータスが正常であることを確認します。主要アクションのステータスが設定ミスまたは最近のコンバージョンなしの場合は、自動的にNO-GOです。イベントが見つからないと判断する前に、レポートの反映に数時間かかることを考慮してください。 証拠：主要アクションごとのステータス。正しい値と通貨で表示されたテストイベント。
6. 重複排除を検証します（下のセクション）。ブラウザーとサーバーの両方でイベントを送信している場合は、必ず検証します。 証拠：テストアクションでカウントされたコンバージョンが1件であること。重複排除率。
7. テストデータを除外し、クリーンアップします（下のセクション）。 証拠：フィルターが有効であること。テストコンバージョンが取り消されていること。テスト注文が返金または削除されていること。
8. ソーク期間。 スケーリングの判断を下す前に、実際のシグナルが数日分蓄積するのを待ちます。実務担当者は、プラットフォームが目標を理解できるよう、コンバージョンのシグナルを数日間報告させることを推奨しています（Pearmill）。バックエンドまたはCRMとの照合は、データが安定するまで約4日待つ必要があります（Enalitica）。 証拠：日次件数の推移と、しきい値内の乖離（「目的」セクション）。
9. 文書化して承認を得ます。 出力形式のレポートに記入し、承認者を明記して日付を入れ、GO／NO-GOを発行します。明示的な承認欄のないローンチチェックリストは、ローンチのプレッシャーがかかると省略されます（Marketing Machineのテンプレートには、承認者と日付を記入するGO／NO-GO欄があります）。 証拠：完成したレポートそのもの。

重複排除の確認

ブラウザータグとサーバー側のエンドポイントの両方からコンバージョンが送信される場合、プラットフォームで1回だけカウントするには、共通キーが必要です。次の3つの条件を満たす必要があります（Analyzify）。

• 両方の送信元から同じ値で送信される、コンバージョンごとの共通イベント ID（注文 ID が適しています）。
• イベント名が一致していること（大文字と小文字の区別も含めて完全に一致）。
• タイムスタンプがプラットフォームの照合可能時間内に収まっていること（理想的には数秒以内）。

確認すべき失敗パターン：

• サーバーが別のイベント ID を生成する、またはイベント ID をまったく含めない。プラットフォームで照合できず、コンバージョンがすべて二重にカウントされます。
• コンバージョンごとではなくページ読み込みごとに新しいイベント ID を生成する。ページを更新すると「新しい」コンバージョンが作られます。
• 2つの送信元間でイベント名の大文字・小文字や命名が一致しない。
• タイムスタンプのずれによって、2つのイベントが照合可能時間の範囲外になる。

間違った対処法は、ついやってしまいがちなため、明確にしておきます。二重カウントを止めるためにサーバーイベントを削除するのは、まったく逆の対処です。より堅牢なシグナルソースを、気付かないうちに破棄してしまいます。解決策は常に、共通のイベント ID を使うことです。

確認方法は3つありますが、それぞれにかける時間を等しくする必要はありません。

efficiency (do first) : dedup rate > browser-vs-server count comparison > match-quality score
effort                : browser-vs-server count comparison > dedup rate == match-quality score
value for this goal   : dedup rate > browser-vs-server count comparison > match-quality score

照合作業の品質スコアでは、労力と価値の評価が一致しません。このスコアは、労力の軸では重複排除率と同じく最下位です。どちらもイベントマネージャーがすでに計算して1画面に表示している単一の数値で、データを取得する必要も、データを突き合わせる必要もありません。何もコストがかからないにもかかわらず効率で最下位になるのは、ここで挙げた3つの中で最も有用性が低いためです。

1. 重複排除率：プラットフォームのイベントマネージャーに表示されます。1画面で確認でき、ほとんど手間がかからず、疑問に直接答えてくれます。健全な設定では、ブラウザーイベントの約90％以上が重複排除されます（TAGGRS では、監視対象の設定でブラウザーが95.35％、サーバーが100％です）。必ずここから確認してください。
2. 同じアクションについてのブラウザーイベント数とサーバーイベント数：2つのレポートを取得して突き合わせるのに、およそ1時間かかります。重複排除率に問題がある、利用できない、またはテストアクションが二重にカウントされた場合に実施します。重複排除率が健全で、テストアクションが1回だけカウントされた場合、これは新たな問題を見つけるためではなく、確認のための作業なので、一定期間の計測が終わるまで待てます。
3. 照合作業の品質スコア：完全性の指標として捉え、正確性の指標とは見なさないでください。コンバージョンが実際に発生したかどうかではなく、イベントデータの形式がどれほど整っていて照合可能かを評価するものです（AnyTrack）。したがって、このスコアだけで重複排除を確認することはできません。記録はしておきますが、公開準備期間を使って改善する必要はありません。

プラットフォームのイベントマネージャーで重複排除率が見つからない場合や、アナリストがすでにブラウザーとサーバーの件数レポートを管理している場合は、これらの優先順位をアカウントに合わせて見直し、ステップ2を最優先にします。

不具合チェックリスト

広告費を無駄にする不具合と、それぞれを検出するための確認項目です。

影響度は、不具合が測定をどれほど損なうかを示します。

• 重大：公開を阻止します。
• 高：レポートで明示的にリスクを受け入れない限り、公開を阻止します。
• 中：修正リストに追加します。

修正工数は、対応に必要な時間、調整、元に戻せるかどうかを示します。

行は効率、つまり修正工数1単位あたりに得られる影響度の改善量に基づいて並んでいます。そのため、最初の行が最初に修正すべき項目です。最も安価な項目でも、最も重大な項目でもありません。

不具合	検出するチェック項目	影響	修正にかかる労力
ノイズとなるアクションが主要コンバージョンに指定されている	設定の確認（ステップ 1）	重大	ほぼゼロ - 指定を切り替えるだけで、ワンクリックで元に戻せます
コンテナがプレビューでは動作するが、公開されていない	プレビューモード以外でライブサイトをテストする	重大	ほぼゼロ - コンテナを公開します
リードフォームで「すべてをカウント」が設定されている	設定の確認（ステップ 1）	高	ほぼゼロ - アクションごとにカウント設定を 1 つ変更するだけです
社内／QA のトラフィックがコンバージョンとしてカウントされている	フィルター状態の確認（テストデータの除外セクション）	中	ほぼゼロ - フィルターをテスト用から有効に切り替えます
タグが完了したアクションではなく、ページ読み込み時／全ページのトリガーで発火する	デバッグモードで、コンバージョンせずにページを読み込む	重大	1 時間 - タグマネージャーでトリガーを再設定します。開発作業は不要です
成功が確認されたときではなく、ボタンのクリック時に発火する	送信を途中で中断し、何も発火しないことを確認する	高	1 時間 - 同様の作業に加えて、紐付ける成功シグナルが必要です
ボット／スパムによるフォーム送信がカウントされ、アルゴリズムにも学習されている	フォームのスパム対策を有効にし、テスト運用中にリードの質を確認する	中	1 時間 - フォーム単位の保護で対応でき、セルフサービスで設定できます
確認ページの再読み込み／戻る操作で再発火する（固有のトランザクション ID がない）	テストコンバージョン後に確認ページを再読み込みし、イベントが二重に発生しないか確認する	重大	注文 ID がすでにタグに届いていれば 1 時間。届いていなければ開発に 1～2 日かかります
シングルページアプリのルート変更でタグが再発火する	デバッグモードで仮想ページ間を移動する	高	タグマネージャーのルールで解決できれば 1 時間。アプリ側でイベントの送信が必要なら 1～2 日かかります
値がない／ハードコードされている、または通貨が間違っている／設定されていない	ペイロードの確認（ステップ 4）	値ベースの入札では重大	値がデータレイヤーにあれば 1 時間。まず値を公開する開発作業には 1～2 日かかります
ブラウザーとサーバーの両方でカウントされる（共通のイベント ID がない）	重複排除の確認	重大	数日 - 両方の送信元で開発チームの調整が必要で、元に戻すには再デプロイも必要です
同意バナーがタグを完全にブロックする、または同意状態がタグに届かない	同意する場合と拒否する場合の両方でテストコンバージョンを実行する	高	数日と法務の承認が必要です - 下記のコンプライアンスコストを参照してください
リダイレクトチェーンでクリック ID が削除される、またはブラウザーの Cookie 上限で切り詰められる	ランディング URL と、コンバージョン時に保持されている識別子を確認する	高	数日から数週間 - リダイレクト、ストレージ、すべてのファネルのステップに影響します
クロスドメインのチェックアウト中に ID が失われる	デバッグモードでクロスドメインの全行程を確認する	高	1 週間から 1 四半期 - 2 つのドメインの所有者間で調整が必要です
この順序と一致しない軸が2つあるため、個別に示します。

efficiency (fix first) : settings-class toggles > trigger corrections > refire guard
                         > value & currency > bot protection > shared event ID > consent path
                         > click-identifier chain
compliance cost        : consent path > click-identifier persistence
                         > server-side sender (shared event ID) > every other row: none

影響度だけで並べれば、共有イベント ID は上位になります。しかし6位にとどまるのは、数日かかる開発チームとの調整で得られる重要な修正が、指定の切り替えで得られる修正と同じだからです。内部トラフィックのフィルターは影響度が中程度にすぎませんが、同じ理由で順位は上位に来ます。こちらは逆のケースです。

再発火ガード、値と通貨の修正、ボット対策に優劣はありません。必要なデータがすでにタグに届いている場合、いずれもタグマネージャーでの作業は同じ1時間で済むため、影響度だけで順位が分かれます。

• 再発火ガードがないと、アカウント上のすべてのコンバージョンが誤ってカウントされます。
• 値が間違っていると、値に基づいて入札するアカウントだけで誤カウントが起きます。
• ボットによる入力の影響度は中程度です。

コンプライアンスコストとは、修正によって必要になるレビューと、修正によって失われる可逆性のことです。罰金ではありません。

• 同意経路（最も重い）：拒否経路で何を発火させるかの変更は、適法な根拠に関する判断であるため、リリース前にプライバシーまたは法務の承認が必要です。また、記録に残した後で密かに元に戻すのは困難です。
• クリック識別子の保持：保存と保持に関する判断をドメイン間、さらに CRM レコードにまで広げるため、通常はプライバシー通知の見直しが再び必要になります。
• サーバーサイド送信元：イベントデータをチームが選択するインフラに移すため、ブラウザータグでは生じなかったデータレジデンシーと処理者に関する問題が浮上します。
• それ以外のすべての行：外部のレビュー担当者が不要な設定変更です。

デフォルトの段階： リリース前に共有イベント ID までを含むすべての項目を解消し、同意経路とクリック識別子の連鎖については、リスクを受け入れる旨を書面に残します。規制対象の同意が必要なトラフィックが、オーディエンスの一部ではなく過半数を占める場合は、もう1段階進めて同意経路もリリース前に修正します。その場合、受け入れたシグナル損失はキャンペーンを削るどころか圧倒してしまうからです。

効率重視の順序で後回しになるもの： サーバーサイドへの再構築、共有イベント ID、そしてその先にあるクリック識別子の連鎖です。どちらも価値の軸と工数の軸で最上位にあるため、設定の切り替えが毎回必ず上回ります。今週安くできる修正だけを行うアカウントは、誰もシグナル損失を測定しなくなったブラウザータグのまま、何年も運用されることになります。

次のいずれかに該当する場合は、デフォルトの段階より上に引き上げてください。

• インタビューの質問8から、数四半期にわたって信頼して使うことを想定した設定だと分かった場合。
• ファネルが B2B の場合。識別子が CRM レコードに記録されることは、オフライン成果のインポートを可能にする条件そのものであり、単なる改善ではありません。
• ジャーニーがドメインをまたぐ場合。識別子は構造上失われ、下流の修正で取り戻すこともできません。

順位を下げるのではなく、削除する。 制約によって順位が下がるのではなく、ある行が対象外になる場合は、その行をこのアカウントの修正リストから削除し、それによって失われる計測内容とともに、レポートの deleted 行に記録します。リリース前にエンジニアリングリソースを割けない場合は、共有イベント ID、同意経路の再構築、クリック識別子の連鎖を削除します。その場合、レポートにはキャンペーンが何を承知のうえで導入しないのか、そして誰がその判断を受け入れたのかを記載します。

同意規制の対象地域に一切関わらないトラフィックでは、同意経路の行を該当なしとして完全に削除します。対象外の行を順位の最下位に置いたままにすると、誰かが実施する予定の作業として読めてしまい、リリース予算に含まれていない作業が再びスコープに戻ってきます。

この順序はデフォルトであり、絶対的なものではありません。状況や実行者によって変わるため、提示する前に、ユーザーについてすでに分かっていることに照らして順位を付け直してください。

• 社内のエンジニアがチームにいる場合、開発依存のすべての行が1時間程度に短縮され、共有イベント ID の順位が上がります。
• タグマネージャーがすでに導入され、データレイヤーも構築済みの場合、値と通貨、および再発火ガードの各行の作業量が減ります。

インタビューの質問7～9への回答によっても順位は変わります。厳格なリリース日がある場合、クリック識別子の連鎖の順位は下がります。一方、効果の積み上げが求められる場合は、このリリースだけを解消する項目よりも上に、クリック識別子の連鎖と共有イベント ID が引き上げられます。 ランキングでは、どの不具合を対応対象にするかを決めます。リリース順を決めるものではありません。対応対象になったものはすべて、1回のバッチでリリースし、1回だけ再学習します（学習フェーズへの影響）。ランキングが決めるのは、工数の上限に収まらない場合に、そのバッチに何を含めるかです。

クリック識別子の連鎖。 シグナル損失の不具合には、共通の根本原因があります。クリック識別子は最初のヒット時に、リダイレクトより前に取得し、その後永続化して、クロスドメインの移動を含むファネルのすべての段階で引き継ぎ、注文またはリードのレコードに付与する必要があります。

クエリ文字列を削除するリダイレクトチェーンや、数日でCookieを失効させるブラウザーのストレージ上限によって、アトリビューションは気付かないうちに失われます。識別子を落とすトラッキングリダイレクトが1つあるだけで、キャンペーン全体の測定が損なわれます。B2Bでは、CRMレコードに保存された識別子が、オフライン成果のインポートを可能にする唯一の手段です。

B2BとB2C

検証の基本部分は共通ですが、価値の扱いとタイミングは異なります。

項目	B2C eコマース	B2Bリード獲得
主なコンバージョン	購入、即時	フォーム送信／リード、その後にオフラインの各段階
価値	注文ごとの動的な値と通貨	パイプラインの段階ごとの価値。クリックIDがCRMに取り込まれていることを検証
イベント後の修正	コンバージョン調整による返金（再記録／撤回）	CRMの成果インポートによるリードの不適格化
クリックから売上までの期間	数分から数日	数週間から数か月 ―「B2Bのアトリビューションは複雑で断片化しており、完全に白黒をつけることはできません」（AJ Wilcox）
ボリューム	通常、プラットフォームの学習に必要な最低数を満たす	不足しがちです。最適化対象のイベントに十分なボリュームがあることを検証

両方に共通する項目は同じです。そのように明記し、改めて説明しないでください。タグのデバッグ／プレビュー、共通イベントIDによる重複排除の仕組み、プラットフォームUIでのステータス確認、同意の処理、ペイロードを確認するテストコンバージョンが該当します。

B2B固有の確認事項は2つあります。

• アトリビューション期間が販売サイクルをカバーしていることを確認します。クリックから40日後に発生したコンバージョンは、クリック期間が30日なら単純にカウントされません（Tucker Evans、B2Linked）。
• 主なコンバージョンが、十分なボリュームを確保できる範囲で最も深い段階であることを確認します。その段階を最適化対象にする前に、30日間でおよそ30件のコンバージョンが必要です（Jyll Saskin Galesの「30日で30件」ルール）。満たない場合は、ボリュームの多い上流イベントに最適化し、下流の成果をインポートします。

テストデータの除外

検証そのものがデータを汚染します。ソーク期間の後ではなく、前にクリーンアップしてください。

• 2段階のフィルターに潜む落とし穴。 内部トラフィックの除外には、内部として扱うIPアドレス／マーカーの定義と、有効化されたフィルターの両方が必要です。多くの分析設定では、フィルターがテスト状態で始まります。この状態では内部トラフィックにタグが付くだけで、除外されません。これは最も見落とされやすい手順です（NiceLookingData）。フィルターの状態が「テスト」ではなく「有効」になっていることを確認してください。
• フィルターは遡及適用されません。 除外はリリース前に設定する必要があります。すでに記録されたデータは汚染されたままです。
• プラットフォームのコンバージョン調整（値をゼロにする／削除する）でテストコンバージョンを取り消し、バックエンドと分析データの照合が正確になるよう、バックエンドでテスト注文を返金または削除します。B2Bの場合は、QAリードをCRMから削除してください。

学習フェーズで重要となること

件数の不具合の重大度が高い理由は、プラットフォームが最適化イベントを一定数獲得すると学習フェーズを終了するためです。

• 過剰カウント（重複、ボット、再発火）があると、誤ったシグナルで学習フェーズを終了し、アルゴリズムは実在しないイベントを発生させるユーザーに向けて最適化します（EasyInsights）。
• 過少カウント（同意の欠落、タグの破損）があると、キャンペーンはしきい値を下回ったまま、いつまでも抜け出せなくなります（Niblin）。

監査したアカウントの一例では、主要指標のコンバージョンは31件しか記録されていない一方で、実際のアクションが数百件も二次レポートにカウントされずに残っており、学習のしきい値を人為的に下回った状態になっていました（Jyll Saskin Gales）。

発見した不具合はすべて一度にまとめて修正し、その後、プラットフォームに一度だけ再学習させます。スマート自動入札は、修正からおよそ24時間以内に、改善されたデータを使って再学習を開始します（GrowthSpree）。不具合を一つずつ順番に修正すると、そのたびに学習がリセットされます。

出力形式

検証結果は、1つのレポートとして提出します。レポートには、ヘッダー（キャンペーン、日付、プラットフォーム、ファネルタイプ、サーバーサイドの有無、開始日、リスクにさらされている予算）、全9ステップを対象としたチェックごとの表（結果、影響、修正工数、エビデンス）、重複排除率と差分の概要、判定ブロック（GO／NO-GO、修正順、ブロッカー、延期事項、削除事項、再検証、承認者、日付）を含めます。詳細なNO-GOの記入例は./references/output-report-example.mdを参照してください。

各チェックの結果は、pass／fail／unknown／not applicableのいずれかで報告します。unknownはpassではありません。新規プロパティは、エビデンスのゲートに従い、通常のGOではなく、PROVISIONAL GO (new property - no traffic yet)としてのみ判定されます。

失敗パターン

• スクリーンショットでの検証 - 設定を確認しただけで、イベントを追跡していません。このためにエビデンスのゲートがあります。
• 二重カウントを修正するためにサーバーイベントを削除する - 逆効果です。イベントを復元し、共通のイベントIDを修正してください。
• 同意を受け入れる経路だけをテストする - シグナルが気付かれないまま失われるのは、拒否する経路です。両方をテストしてください。
• フィルターをテスト状態のままにする - タグが付いていても除外されているとは限りません。状態がアクティブになっていることを確認してください。
• コンバージョンのステータスが保留中、または設定ミスの状態で開始する - ステータスが正常になるまで、自動的にNO-GOとなります。
• プレビューだけで検証する - コンテナが公開されていません。公開中のサイトでテストしてください。
• 修正を一つずつ行う - 修正のたびに学習がリセットされます。すべての不具合を1回のリリースにまとめ、再学習も1回だけにしてください。
• マッチ品質を正確性と見なす - マッチ品質が測るのはペイロードの完全性です。重複があっても高いスコアになることがあります。
• 差分ゼロを目指す - プラットフォームとアナリティクスの間に10～20％の差が生じるのは構造上、通常のことです（Ruler Analytics）。ローンチ前の期間を差分解消に費やすと、何も得られないままローンチが遅れます。

目的と測定

次の条件がすべて満たされた場合に限り、ゲートがクリアされ、GOが発行されます。条件を満たすまで修正と再検証を繰り返してください。

• 実際のテストコンバージョンを1件、エンドツーエンドで追跡でき、プラットフォームのUIに正しい金額と通貨で表示されていること。
• すべての主要コンバージョンアクションの記録ステータスが正常であること。主要アクションに設定ミスがある場合、または最近のコンバージョンが表示されない場合は、自動的にNO-GOとなります。
• ブラウザー／サーバー間の重複排除率が約90％以上であり、テストアクションごとにカウントされるコンバージョンが正確に1件であること。
• プラットフォームとアナリティクスの差が、通常の10～20％の範囲内であること（Ruler Analytics）。
• Eコマースのアナリティクスとバックエンドの差が25％未満であること。35％を超える場合はローンチ前に調査が必要です（Enalitica）。
• サーバーとブラウザーの差は最大10％まで通常の範囲です。一方、マッチ率が50％未満で差が30％ある場合は、ローンチを阻む要因となります。この状態で規模を拡大するのは、「壊れたモデルの最適化を加速するために、さらに費用を投じる」ことになります（Journify）。
• テストデータが除外され、フィルターがアクティブになっており、テストコンバージョンが取り消され、テスト注文が返金されていること。

ローンチ後は、プラットフォームとバックエンドの比率を毎週追跡してください。比率がゼロでなくても安定していれば健全です。週ごとに変動する場合は、パイプラインでイベントが欠落しています。mbfinotti/advertising-skills@ad-attribution-gapに引き継いでください。

プラットフォームに関する補足（任意）

ユーザーがプラットフォームを指定した場合にのみ読み込みます。上記の基本チェックリストは引き続きベンダー中立です。

重複排除キーと期間：

• Meta は、48 時間の期間内で event_id とイベント名に基づいて重複を排除します。
• TikTok は、event_id とイベント名に基づいて重複を排除します。5 分後以降かつ最初のイベントから 48 時間以内に届いたイベントを統合し、最初に受信したイベントを保持します。
• LinkedIn は、コンバージョンルールごとに共通の eventId に基づいて重複を排除し、Insight Tag のイベントを保持して、Conversions API の重複イベントを破棄します（Meta のモデルとは逆です）。
• Google Ads は、クリックの照合に gclid を使い、transaction_id に基づいて重複を排除します。

ベンダーごとのクリック識別子： gclid（Google、および wbraid／gbraid）、fbclid（Meta）、li_fat_id（LinkedIn）、ttclid（TikTok）、msclkid（Microsoft）。

学習フェーズの最低条件：

• Meta の広告セットが学習フェーズを終了するには、7 日間でおよそ 50 件の最適化イベントが必要です。
• Google Target CPA のドキュメントでは、30 日間で 15 件のコンバージョンを最低条件とし、評価には 30 件を推奨しています。

正確な数値は目安として扱ってください。プラットフォームによって改定される場合があります。