タグ設定の前にビジネスイベントを定義する
コンバージョンは、タグ化しやすいインタラクションではなく、ビジネスにとって完了した行為です。ECでは一般に受理された注文がこれに当たり、カート追加や支払ボタンクリックは該当しません。リード獲得では、定義済み基準を満たす送信済み問合せ、予約確定、または営業的に有効と判定されたリードが該当します。まずビジネス言語で書いてからイベントに翻訳してください。
各コンバージョンアクションについて、トリガー、含める／除外するルール、価値、カウントルール、識別子、責任者、および記録システムを記録します。例：「受理済み有料注文；注文IDごとに1イベント；会社の規定に基づく注文収益；コマースデータベースで突合する。」
主要アクションと二次アクションを意図的に使う
Google Adsは、主要（Primary）コンバージョンはConversions列に表示され、該当する標準目標が入札に使われるときに入札学習に用いられると説明します。二次（Secondary）アクションはAll conversionsで観察用に使われ、通常は入札に使われません。したがって主要設定は品質のバッジではなく、最適化が学習するシグナルを制御するものです。
直接的で繰り返し発生するキャンペーンの成果のみを主要にしてください。フォーム開始、資料ダウンロード、アカウント作成、チャット開始、電話クリックは、意図的な最適化成果でない限り二次に留めます。キャンペーンが異なる目的を持つ場合は、汎用のデフォルトに任せずキャンペーンごとにゴールを管理してください。ゴールを変更したら日付と旧設定を記録し、報告を文脈で解釈できるようにしてください。
計測設計に同意（コンセント）を組み込む
同意はタグを稼働させた後で追加するバナーではありません。Googleのconsent-modeガイダンスは、測定データを送るコマンドの前にデフォルトの同意状態を設定し、その後に利用者の選択後で更新することを示します。例は広告ストレージ、アナリティクスストレージ、広告ユーザーデータ、広告パーソナライズをカバーします。consent modeは法的根拠や社内方針を決めるものではありません。組織が承認した同意状態を実装してください。
要件は地域や事実関係で異なります。英国ICOのガイダンスは、利用者にクッキーについて伝え、何をしなぜ必要かを明確にし、アクティブで明確な同意を得ることを求めており、限定的な必須サービス例外を除きます。EUの事業者向けガイダンスは、同意が必要なクッキーは初回ロードで設定できず、同意は目的別であり撤回が容易であるべきだと示します。市場・ベンダー・データフローについては適格なプライバシーレビューを受けてください。メールや電話番号、注文メモ、不必要な顧客データをURL、イベントパラメータ、トランザクションIDに生のまま入れないでください。
基礎となるビジネスイベントを重複排除する
確認ページはリロードされたり、履歴から再訪されたり、失敗状態の後に到達されることがあります。Google Adsは各購入に一意のトランザクションIDを推奨しており、同じコンバージョンアクションとIDでの2回目のコンバージョンを重複として扱います。IDは動的に生成され、取引ごとに一意でなければなりません。異なる注文での再利用は逆に過少計上を招きます。顧客を特定するデータではなく、不透明な注文識別子を使ってください。
またアーキテクチャを図示してください。ブラウザタグ、サーバーイベント、CRMインポート、決済ウェブフックが同じ売上を報告しうるなら、どの経路が権威的（オーソリティ）で、どの共有IDで重複排除するかを決めます。IDはカウント設定に替わるものではありません：カウントは広告クリックに続くコンバージョンの数を制御し、IDは同じ注文が二度送られることを防ぎます。返金、キャンセル、無効リードについては運用チームと調整した制御された調整／除外プロセスを定義してください。
帰属は“クレジット”として報告し、運用数と突合する
帰属は選んだルールの下でクレジットを割り当てるものであり、すべての影響を観測したり因果を証明したりするものではありません。Google Adsはラストクリックを最後にクリックされた広告に全てのクレジットを与えると説明し、データドリブン帰属はそのアクションのためにアカウントデータを使ってクレジットを分配します。選んだモデルはConversions列とAll conversions列に影響を与え、入札にも影響を与え得ます。したがってモデル変更は分析上の変更であると同時に本番での最適化変更でもあります。
二つのビューを維持してください。プラットフォームビューはキャンペーン判断を支えるもので：支出、帰属された主要コンバージョン、帰属された価値、モデル、計測ウィンドウ、日付基準を含みます。運用ビューは受理済み注文、事業ルールに基づく収益、有資格リード、キャンセル、返金を含みます。方向性の突合を行い、重大で継続する差分があれば許可された識別子を使って調査してください。完全一致は期待されません：同意、ブラウザ制限、クロスデバイス経路、タイミング、適格性、モデル化が異なることがあります。
リリースをコンバージョン経路の信頼性作業としてQAする
可能なら本番外でテストし、その後運用が識別して元に戻せる制御されたライブテストを使ってください。Google Tag Managerのプレビューとデバッグモードは、プレビュー中のサイトをTag Assistantに接続し、発火したタグ、順序、処理されたデータを表示します。トリガー、価値、通貨、ID、同意状態、送信先を検査し、次に注文やリード記録を検査してください。タグのステータスが緑でも、それが正しいビジネスイベントをカウントした証拠ではありません。
有料ランディングURL、リダイレクト、フォーム検証、クロスドメインのチェックアウト、決済リターン、確認、CRM引き渡し、返金処理を網羅してテストしてください。Googleはクリック識別子がトラッカーやリダイレクトで失われることがあると指摘し、ランディングとコンバージョンのドメインが異なる場合のクロスドメインガイダンスを提供しています。プレフライトを行い、タグ・同意・チェックアウト・リダイレクトの変更にバージョンを付けてください。経路やシグナルが失敗した場合は、検証済み構成を復元し、ダッシュボードからの推測ではなく影響を受けた期間を突合してください。