ECサイト向け広告トラッキングコード診断（2026年）

このガイドの使い方

このガイドは、代理店、プラグイン、アプリ、または社内実装によって導入されたトラッキングを監査する必要がある、パフォーマンスマーケター、EC運営担当者、アナリスト、開発者、チーム向けです。テストはステージング環境、またはキャンセル・返金可能なテスト注文で実施してください。実際の顧客注文を使って繰り返しテストしないでください。

このガイドを完了すると、次のことができるようになります

• コードの存在、タグの発火、リクエストの送信、プラットフォームでの受信、入札対象となるコンバージョンを区別する。
• 注文ID、売上、通貨、商品ID、イベントIDなどの重要なフィールドを検証する。
• 購入の重複・欠落、値が0のコンバージョン、クロスドメインで失われたアトリビューション、同意設定の問題を診断する。
• Shopify、WordPress、WooCommerce、またはカスタムECスタックに適した診断方法を選択する。
• マーケティング、開発、分析、経営の各チーム向けに、明確な診断レポートを作成する。

トラッキングを設置済みでもデータが信頼できない理由

独立系ECストアがGoogle Ads、Meta Ads、Microsoft Ads、TikTok Adsで広告を開始すると、各プラットフォームからトラッキングタグまたはピクセルの設置を求められます。ただし、ページソースにコードが存在するだけでは、コンバージョントラッキングが正しく機能している証明にはなりません。

• 広告プラットフォームでタグが未確認、無効、または最近のアクティビティなしと表示される。
• GA4には注文が記録されているが、Google Adsにはコンバージョンが表示されない。
• ストアのバックエンドには注文が1件しかないのに、広告プラットフォームでは購入が2件報告される。
• コンバージョン数は妥当に見えるが、売上、通貨、または商品データが誤っている。
• ホームページではピクセルが検出されるが、決済途中または注文確認ページで消える。
• ブラウザとサーバーの両方からイベントが送信されているが、正しく重複排除されていない。
• 広告トラッキングが訪問者の同意選択に従っていません。マーケティング同意がdeniedになった後も、広告ストレージが読み書きされたり、広告識別子またはユーザーデータが送信されたりしています。高度な同意モードでは、Cookieを使用しない同意 pingが、ad_storageまたはanalytics_storageがdeniedでも送信される場合があります。この動作だけでは実装不良とはいえません。
• 訪問者が同意を許可した後もタグが再開しない。

完全な監査は「コードが存在するか」という確認だけで終わりません。実際の各ビジネスアクションが、正しいイベント名、パラメータ、値、通貨、注文IDとともに正しいプラットフォームへ届き、ブラウザとサーバーからの送信が重複排除後に1件の論理コンバージョンとして処理されることを確認してください。

1. 広告トラッキング診断で実際に確認すること

広告トラッキングは5つのレイヤーで評価できます。5つすべてに合格して初めて、データをパフォーマンス分析、ROAS計算、自動入札に利用できます。

GTMで「Tag Fired」と表示されても、トリガー条件を満たしたことしか証明できません。コンバージョンが正確であることの証明にはなりません。続けて、データレイヤー、ネットワークリクエスト、プラットフォームのテストツール、対応するバックエンド注文を確認してください。

2. まずECイベントのトラッキング計画を作成する

トラブルシューティングの前に、サイトで本当に計測すべき顧客アクションを定義します。一般的なEC実装では、少なくとも商品閲覧、カート追加、決済開始、購入を対象にします。

このガイドの2026年8月版では、TikTokはPurchaseを標準のEC purchaseイベントとして、Leadをリード送信に使用します。CompletePaymentとSubmitFormはPurchaseとLeadに対応する互換性のある旧イベント名です。移行計画なしに、稼働中の旧実装の名称を変更しないでください。Contactは実際の問い合わせアクションにのみ使用してください。GA4はpurchaseを使用し、transaction_id、value、currency、items配列などのパラメータを推奨しています。

purchaseイベントに必要な最小データ

3. 診断テストの準備

実際の顧客注文を主なテストに使用しないでください。キャンセルまたは返金可能なテスト注文を作成し、開始前に以下の情報を記録します。

主要な実装テストではブラウザの広告ブロック拡張機能を無効にしますが、サイトの同意バナーは無効にしないでください。広告ブロックのテストと同意のテストは別々に実施してください。そうしないと、ブラウザ拡張機能と同意設定のどちらがタグをブロックしたのか判断できません。

少なくとも3つの同意シナリオをテストする

• まだCookieの選択をしていない新規訪問者。
• 関連するCookieをすべて許可した訪問者。
• マーケティングCookieを拒否した訪問者。

Google 同意モードでは、関連タグが実行される前にデフォルトの同意状態を設定し、訪問者が選択した後、同じページですぐに更新します。ad_storage、analytics_storage、ad_user_data、ad_personalizationをそれぞれ検証してください。高度な同意モードでは、ストレージがdeniedでもCookieを使用しないpingが送信される場合があります。訪問者の選択に反して、広告ストレージ、広告識別子、ユーザーデータが送信されていないことを確認してください。

診断ツールセット

1. Google Tag AssistantとGTM Preview

Google Tag Manager Previewには、ページイベント、発火したタグ、発火しなかったタグ、トリガー条件、変数、同意状態が表示されます。これにより「サイトで何が起きたか」「なぜGTMがタグを発火した、または発火しなかったのか」という2つの重要な質問に答えられます。

2. GA4 DebugView

GA4 DebugViewでは、GA4が実際にイベントを受信したかを確認でき、パラメータも表示されます。GTMの実装問題と、送信またはGA4収集の問題を切り分けるのに役立ちます。

3. Chrome DevToolsのNetworkパネル

Networkパネルには、ブラウザが実際に送信したリクエストが表示されます。プラットフォームのドメイン、リクエストタイプ、ファイル名、タグID、測定IDで絞り込めます。「ブラウザがデータを送信したか」に答えるための重要なツールです。

4. プラットフォーム固有のテストツール

Test Eventsと診断はMeta Events Managerで使用します。TikTokではPixel Helper、Test Events、診断を、UET Tag HelperはMicrosoft Advertisingで、Shopify Pixel HelperはShopifyのカスタムピクセルで使用します。

4. 広告トラッキングの完全診断ワークフロー

ステップ1：すべてのトラッキング実装を棚卸しする

コンバージョンの重複は、1つのタグの故障ではなく、同じプラットフォームが複数の方法で設置されていることが原因の場合がよくあります。

• GTMがテーマに1回、プラグイン経由でもう1回設置されている。
• 公式Shopify Metaアプリがピクセルを設置している一方、別のカスタムMeta pixelも存在する。
• WordPressプラグインがPurchaseを送信し、GTMも同じPurchaseを再度送信する。
• ネイティブのGoogle Ads購入アクションと、インポートしたGA4購入アクションの両方が主要目標に設定されている。
• Meta PixelとConversions APIが、有効な重複排除なしに同じ購入を送信する。
• TikTokアプリ、GTM、テーマコードがそれぞれ同じピクセルを設置している。

実装の棚卸し表を作成します。読みやすくするため、設置方法、ベースタグの場所、購入イベントの送信元、サーバーイベントの状態を1つの「実装メモ」欄にまとめます。

ページソース、GTMのタグ一覧、WordPressプラグイン、テーマのカスタムコード領域、Shopify Customer Events、Shopifyアプリ、Cloudflare Zaraz、サーバー側GTM、カスタムのバックエンド連携で各IDを検索します。

ステップ2：ベースタグが正しく読み込まれることを確認する

GTMでは、注文確認ページを直接開くところから始めないでください。ホームページまたは広告のランディングページからPreviewを接続し、商品閲覧、カート、決済、支払いという実際の顧客導線をたどります。

• Previewが正しいドメインに接続されていることを確認します。
• ページ読み込み時に想定したGTMコンテナが表示されることを確認します。
• コンテナIDが有効なアカウントおよび環境と一致することを確認します。
• ベースGoogle tagが必要なすべてのページで読み込まれることを確認します。
• 支払い完了ページが同じデバッグセッション内に残るか確認します。
• リダイレクトまたはクロスドメイン遷移後にセッションが切れないか確認します。
• タグをブロックしているConsent Initializationおよび同意の状態を確認します。

同時にChrome DevToolsを開き、NetworkパネルでGTMコンテナID、GA4測定ID、Google AdsコンバージョンID、Meta pixel ID、TikTokピクセルID、Microsoft UETタグIDを検索します。リクエストパスは変わる可能性があるため、固定エンドポイントだけに頼るより実際のIDを検索する方が確実です。

リクエストがまったく表示されない場合は、まず次を確認します

• コードがない、または設定したIDが間違っている。
• GTMコンテナが未公開、または誤った環境が読み込まれている。
• 同意設定によってタグの実行が阻止されている。
• コンテンツセキュリティポリシーが外部スクリプトまたはエンドポイントをブロックしている。
• 広告ブロッカーまたはブラウザのプライバシー設定がリクエストをブロックしている。
• トラッキングコードの実行前にJavaScriptエラーが発生している。
• キャッシュまたはCDNが古いバージョンのサイトコードを配信し続けている。

ステップ3：データレイヤーまたは顧客イベントを検証する

データレイヤーは、EC上の行動と広告タグを結ぶ橋です。Google Tag Managerとgtag.jsは、この構造化レイヤーからイベントと変数を読み取ります。無関係なページ要素からタグに値を抽出させるのではなく、予測可能な構造化データを使用してください。

簡略化したGA4形式のpurchaseイベントは、次のようになります。

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-10086",
    value: 129.90,
    currency: "USD",
    tax: 8.20,
    shipping: 0,
    items: [
      {
        item_id: "SKU-001",
        item_name: "Portable Coffee Grinder",
        price: 64.95,
        quantity: 2
      }
    ]
  }
});
</script>

GA4のEC計測では、イベント単位のvalueは通常、items配列内の「price × quantity」の合計とし、文書化したレポート定義と送信先プラットフォームが別の値を明示的に求めない限り、送料や税を含めません。

初期確認にはChrome Consoleで次のコマンドを使用します。

window.dataLayer

purchaseイベントだけを表示するには、次を使用します。

window.dataLayer?.filter(item => item.event === "purchase")

次の6点を検証する

1. イベントの発生タイミングが正しい：顧客が「今すぐ支払う」または「注文を送信」をクリックした時点ではなく、注文が実際に成功した後にPurchaseが生成される必要があります。
2. 注文IDが一意である：同じ注文では再読み込み後も同じIDを維持し、異なる注文が同じIDを共有してはいけません。
3. 値が数値である：“$129.90″、”USD 129.90″、桁区切りを含む文字列ではなく、129.90を使用します。
4. 通貨が注文と一致する：多通貨ストアでは、表示通貨、決済通貨、プラットフォームへ送信した通貨を比較します。
5. items配列が完全である：商品ID、価格、数量、割引がバックエンドの注文と一致する必要があります。
6. 古い値が残っていない：シングルページアプリ、カートドロワー、AJAX決済では、前回イベントのデータが誤って再利用される場合があります。

ステップ4：GTMのトリガーと変数を確認する

GTM Previewで実際のテスト導線を完了し、purchaseイベントを選択して、Tags Fired、Tags Not Fired、Variables、Data Layer、同意を確認します。

トリガーの条件が広すぎる

「Page URLにthank-youを含む」などのルールでは、訪問者が注文確認ページを再読み込み、ブックマーク、再訪するたびに再発火する可能性があります。ECの購入計測では、実際の注文完了イベントと一意の注文IDを使用することが望まれます。

トリガーの条件が厳しすぎる

実際のURLが/en/checkout/successでも、トリガーが/checkout/successだけを許可している場合があります。言語フォルダ、クエリ文字列、別の決済パスにより、厳しすぎるルールは機能しなくなることがあります。

カスタムイベント名が一致していない

データレイヤーはevent: “checkout_completed”を送信しているのに、GTMはpurchaseを待ち受けています。大文字・小文字やアンダースコアを含め、イベント名は完全に一致する必要があります。

データ到着前にタグが発火する

ページ読み込み中にタグが実行されますが、value、currency、注文IDは数百ミリ秒後にデータレイヤーへ入ります。タグは正常に発火したように見えても、空のパラメータを送信しています。

AJAXまたはシングルページアプリで従来のページ読み込みが発生しない

カートドロワー、モーダル決済、ReactまたはVueアプリでは、通常のページビューが発生しない場合があります。ページ読み込みやURL変更だけに依存せず、ビジネスイベントを起点にトラッキングを発火してください。

ステップ5：Networkでリクエスト送信を確認する

Chrome DevTools -> Networkを開き、Preserve logを有効にして、テスト全体を再実行します。プラットフォームIDまたはドメインで絞り込み、一致するリクエストを開いてHeadersとPayloadを確認します。

• 送信先プラットフォームとタグまたはピクセルIDを確認します。
• イベント名、値、通貨、注文IDを確認します。
• 商品ID、数量、items配列が含まれていることを確認します。
• ブラウザとサーバーのイベントが、プラットフォーム固有の重複排除識別子を共有していることを確認します。MetaとTikTokでは、一致するイベント名またはタイプに加えてevent_idが必要です。GA4とGoogle Adsの購入ではtransaction_idを使用します。
• リクエストがキャンセル、ブロック、またはエラーになっていないか確認します。
• リクエストがページリダイレクトの前後どちらで発生したか確認します。

妥当に見えるペイロードのリクエストを確認できても、ブラウザが送信を試みた、またはエンドポイントがリクエストを受け付けたことしか証明できません。プラットフォームでの処理、アトリビューション、入札対象資格、ビジネスデータの正確性までは証明できません。値が0のPurchaseリクエストでも、正常に送信されることがあります。

GTMではタグが発火したと表示されるが、Networkにはリクエストが表示されない

• 同意状態と組み込み同意チェック。
• 広告ブロックまたはブラウザのプライバシー設定。
• コンテンツセキュリティポリシーの制限。
• 壊れたタグテンプレートまたはJavaScriptのランタイムエラー。
• 即時ナビゲーションによってキャンセルされたリクエスト。
• Shopify Pixel Sandboxの制限。

ステップ6：各広告プラットフォームで受信を確認する

GA4

DebugViewを開き、テストデバイスを選択して、イベントの順序が妥当であることを確認します。

page_view
view_item
add_to_cart
begin_checkout
purchase

purchaseを開き、transaction_id、value、currency、itemsを確認します。

Google Ads

Goals -> Conversions -> Summaryを開き、対象アクションのトラッキング状態を確認します。Unverified、Tag inactive、Needs attentionの場合は、コンバージョンアクションからTag Assistantを起動します。修正後、アカウントの状態更新には時間がかかることがあるため、Tag Assistantと実際のリクエストを即時の検証レイヤーとして使用します。

Meta Ads

Events Managerで正しいデータソースを選択し、Overview、Test Events、診断、Event Deduplication、Event Match Qualityを確認します。Test Eventsではブラウザとサーバーからの受信を確認でき、診断では重複イベント、無効なパラメータ、データ品質の問題を特定できます。

TikTok Ads

TikTok Pixel Helperでブラウザタグ、イベント、パラメータを確認し、リアルタイム受信はEvents Manager -> Test Events、継続的な実装エラーはEvents Manager -> 診断で確認します。

Microsoft Advertising

UET Tag Helperを使って、UETタグID、ページ読み込みイベント、カスタムイベント、変動売上、通貨、コンバージョン目標の条件を検証します。UETの状態はMicrosoft Advertising内で更新に時間がかかる場合があります。Microsoft Advertising Conversions APIも使用している場合は、そのevent_idを検証し、ブラウザとサーバーからの送信がレポートの重複を生んでいないことを確認します。変動売上では、送信先が求めるとおりrevenue_valueと通貨を正確に維持します。

5. ConversionsとEvent Deduplicationの重複を診断する

購入の重複は報告されるROASを水増しし、自動入札に誤ったシグナルを与えます。1つのレイヤーだけでなく、ブラウザ、サーバー、プラグイン、アプリ、GTM、インポートした目標をまとめて確認してください。

Google Adsの重複排除

Google Adsでは、購入ごとに一意のトランザクションIDを送信することが推奨されています。注文確認ページを再読み込みして、同じ注文が同じコンバージョンアクションへ再送信された場合、Google Adsは一致するトランザクションIDを使って重複を識別できます。ただし、トランザクションIDによって別々のPurchaseコンバージョンアクションが自動的に重複排除されるわけではありません。

• 異なる注文で同じトランザクションIDを共有してはいけません。
• トランザクションIDを空にしてはいけません。
• 顧客のメールアドレスや電話番号を注文IDとして使用しないでください。
• 同じ取引については、ブラウザタグとバックエンドアップロードで同じ注文IDを使用します。

Meta PixelとConversions APIの重複排除

同じPurchaseをMeta PixelとConversions APIから送信する場合、ブラウザとサーバーのイベントは同じevent_nameとevent_idを共有する必要があります。異なる注文には異なるevent_id値を使用してください。そうしないと、1件の注文が2件のイベントとしてカウントされる可能性があります。

• ブラウザとサーバーのイベントで同じevent_nameを使用しているか。
• 同じ注文の両方のバージョンで同じevent_idを使用しているか。
• 異なる注文ごとに別のイベントIDが割り当てられているか。
• サーバーの再試行時に新しいイベントIDが生成され、誤って2件目のイベントになっていないか。
• ShopifyアプリとカスタムCAPI実装の両方が同じ購入を送信していないか。

TikTok PixelとEvents APIの重複排除

TikTok PixelとEvents APIが同じイベントを送信する場合、TikTokが両者を対応付けて1件の論理イベントだけを残せるよう、双方で同じイベント名またはタイプと同じevent_idを使用する必要があります。

注文確認ページの再読み込み

注文確認ページのページビューだけでPurchaseを発火させる方法は高リスクです。再読み込み、ブックマーク、ページの再表示によってイベントが再発火する可能性があります。一意の注文IDを使用し、可能であれば通常のページ読み込みではなく、実際の注文完了イベントから発火してください。

6. コンバージョンGoals、クロスドメイン決済、アトリビューションを確認する

Primaryとセカンダリコンバージョンアクションの違い

Google Adsでは、プライマリコンバージョンアクションは通常Conversions列に表示され、キャンペーンが該当目標を使用している場合は入札にも使用できます。Secondaryアクションは主に観察用で、通常All conversionsに表示されます。ただし、キャンペーンが実際に使用するカスタム目標にセカンダリアクションが含まれていれば、入札に使用される場合があります。

イベントがアカウントには表示されるのにキャンペーンがそのイベントに向けて最適化されない場合は、そのアクションがプライマリで、キャンペーンが対応する目標を使用していることを確認します。

EveryとOne

Purchaseアクションでは通常、すべての取引をカウントする必要があります。Leadフォームでは、同じ広告クリックからの繰り返し送信が複数の有価値なリードを意味しない場合があるため、Oneがよく使用されます。販売では一意のトランザクションIDを使って注文の重複を除外します。

重複したプライマリ購入目標

アカウントには、ネイティブのGoogle Ads Purchase、インポートしたGA4 Purchase、Purchase（Shopifyアプリで作成）が存在する場合があります。3つすべてがプライマリでキャンペーンに使用されていると、Conversions列に1件の注文に対する複数の購入シグナルが含まれる可能性があります。

拡張Conversions

拡張Conversionsを有効にした後、対象となるファーストパーティ顧客データが必要な形式で実際に送信されていることを確認します。ベースPurchaseタグが動作していても、拡張Conversionsが正常とは限りません。

クロスドメイン決済と支払いリダイレクト

ストアによっては、訪問者をメインドメインから別の決済ドメイン、第三者決済事業者、予約システム、フォームサービス、サブドメイン、地域別サイトへ移動させます。クロスドメイン設定が誤っていると、次の問題が発生します。

• 1回の顧客セッションが複数のセッションに分割される。
• 元の広告流入元が失われる。
• 決済事業者が参照元として報告される。
• 決済前にクリックIDが失われる。
• ストアフロントではイベントが発生するが、支払い完了後はイベントが発生しない。

GA4のクロスドメイン測定は、自社で管理し、同じGA4タグを設置できるドメイン間でのみ使用します。そのタグを設置できない第三者決済ドメインでは、決済事業者が元の流入元を上書きしないようList unwanted referralsを確認してください。これはクロスドメイン測定の代替ではありません。成功ページを直接開くのではなく、ランディングページからリダイレクト全体をテストします。

7. Shopify固有のトラッキング診断

Shopify Customer Eventsピクセルはサンドボックス環境で動作します。アプリピクセルはStrict sandbox、カスタムピクセルはLax sandboxを使用し、機能は同一ではありません。どちらもShopify Customer EventsとWeb Pixels APIを利用し、従来のDOMスクレイピングに依存しないようにします。

1. Google Tag Assistantだけに頼らない

Google Tag Assistantは、GTMカスタムピクセル（Shopify内）には対応していません。Shopify Pixel Helperで顧客イベントがサンドボックスへ入ることを確認し、その結果のNetworkリクエストと送信先プラットフォームのTest Eventsまたは診断を検証してください。

Shopify Pixel Helper
-> Custom Pixel dataLayer
-> GTMタグ
-> Networkリクエスト
-> 広告プラットフォームのTest Events

2. サンドボックス内でDOMをスクレイピングしない

Shopify Web Pixelsはサンドボックス内で動作します。ストアフロントのDOMを読み取りまたは変更する実装は、失敗したり動作が不安定になったりする可能性があります。CSSセレクターで商品価格、ボタン、注文詳細をスクレイピングせず、Shopify Customer EventsとWeb Pixels APIから提供されるデータを優先してください。

• テーマのボタンを直接監視するクリックトリガー。
• 表示された商品価格をスクレイピングするDOM Element Variable。
• document.querySelectorの直接使用。
• サンドボックスURLをストアフロントURLとして扱う。
• GA4拡張計測が、サンドボックス内のすべての操作を自動検出できると想定する。

3. ピクセルが同意待ちになっていないか確認する

Shopify Settings -> Customer events -> Custom pixelsを開いてテストを開始します。Pixel Helperに「Pixel is awaiting 同意」と表示された場合は、次を確認します。

• カスタムピクセルに割り当てられた顧客プライバシー権限。
• 対象市場で有効なCookieバナー設定。
• 訪問者がAnalyticsまたはMarketingをgrantedし、同意しているか。
• 同意管理プラットフォームがShopify Customer Privacy APIと連携しているか。

4. checkout_completedを正しく使用する

Shopify checkout_completedは通常、決済ごとに1回発火し、多くの場合Thank Youページで確認されます。購入後アップセルがある場合は、Thank Youページで再度発火するのではなく、最初のアップセルページで発火することがあります。想定したページが正常に読み込まれなければ、発火しない場合もあります。

標準のカード決済、Shop Payまたは高速決済、割引注文、無料注文、購入後アップセル、多通貨注文、Thank Youページが完全には読み込まれないケースをテストします。

8. WordPressとWooCommerceでよくある診断上の問題

WordPressで最も一般的な問題は、トラッキングを設置できないことではなく、同じトラッキングを多すぎる場所に設置することです。次の場所を順番に確認します。

• GTM設置プラグイン。
• GA4または広告コンバージョンプラグイン。
• Meta、TikTok、Microsoft Advertising用の個別プラグイン。
• テーマのヘッダー／フッターにあるカスタムコード領域。
• ページビルダーのカスタムコード。
• WooCommerce Thank Youページのカスタマイズ。
• CDN、キャッシュ、スクリプト結合、JavaScript遅延設定。

WooCommerceのカート追加、決済、支払いのフローは、AJAXまたは第三者プラグインによって頻繁に変更されます。標準のボタンクリックルールや既定の注文確認ページルールが引き続き機能すると想定しないでください。実際のデータレイヤーと注文完了イベントを正しい情報源として使用します。

パフォーマンス／キャッシュプラグインの追加確認

• GTMまたはピクセルの読み込みを遅延させていないか。
• 結合したスクリプトによって実行順序が変わっていないか。
• 注文データを含む注文確認ページがキャッシュされていないか。
• 広告タグの実行後に同意の更新が行われていないか。
• 第三者のトラッキングリクエストがブロックされたり、誤ってプロキシされたりしていないか。
• 管理者がログアウトした場合にだけ問題が発生しないか。

9. トラブルシューティング一覧

10. 信頼できる実装の合格基準

テスト購入が成功したと判断するには、次の条件をすべて満たす必要があります。

• 注文が実際に成功した後にだけPurchaseが発火する。
• One件のテスト注文が、重複排除後に1件の論理コンバージョンとして処理される。
• 注文IDがECバックエンドと一致する。
• コンバージョン値が合意した定義に従い、通貨が正しい。
• 商品ID、価格、数量が正確である。
• GTM Previewにイベント全体と値が入った変数が表示される。
• 対応するリクエストがNetworkに存在する。
• 送信先プラットフォームのテストツールでイベントが認識される。
• ブラウザとサーバーのイベントが重複排除される。
• 許可および拒否した同意状態で、想定どおりの動作になる。
• Google AdsのPrimary、Secondary、Count設定が正しい。
• クロスドメイン決済で元の流入元が保持される。
• 注文確認ページを再読み込みしても、別の独立したコンバージョンが生成されない。

最終合格基準
One件の実注文 -> 重複排除後に1件の論理広告コンバージョン -> 正しい注文ID、値、通貨、商品データ -> プラットフォームで検証 -> ECバックエンドと照合可能

11. 広告トラッキング診断レポートのテンプレート

以下の構成で監査結果を記録します。テスト経路、Networkペイロード、プラットフォームのTest Events、バックエンド注文のスクリーンショットを証拠資料として保存してください。

1. ウェブサイトと環境

2. トラッキング設置一覧

3. テスト注文

4. 診断結果

5. 問題と修正

6. 回帰テスト

完全な証拠チェーン

ビジネスアクション
-> Customer Event／Data Layer
-> GTMトリガー
-> 広告タグ
-> Networkリクエスト
-> プラットフォームのテストイベント
-> コンバージョン目標
-> バックエンド照合

このチェーンの全レイヤーが正しい場合にのみ、コンバージョンデータをキャンペーン評価、ROASレポート、自動入札に使用してください。