ウェブサイトの連携監査：タグの検出はコンバージョンの確認ではない

期待する構成を先に整理する

まず、分析、広告、同意管理、サポート、必要ならサーバー側処理など、サイトに本当に必要なツールを列挙します。それぞれの目的と責任者を記録してください。情報提供サイトに広告ピクセルがないことは、自動的に欠陥にはなりません。放置されたタグを多数持つより、少数でも役割を把握できる構成の方が役立つことがあります。

次に、公開ページと事業上重要なイベントを選びます。ページ閲覧、フォーム送信、購入確定はそれぞれ別の事実です。期待するプロパティとイベントを記録しつつ、非公開の識別情報や顧客データを共有レポートへコピーしないでください。この期待状態があれば、提供元のロゴが検出されないだけで問題と判断することを防げます。

公開情報から分かる範囲を理解する

現在のエンジンは静的HTMLとヘッダーを読み、JavaScriptは実行しません。指定ページを調べ、必要に応じて同一オリジンのリンク先をもう1ページ追加します。レポートに実際に記載されたページを基準にし、すべてのテンプレート、下層ページ、外部決済フローへ結論を広げないでください。

検出パターンは、分析ツール、広告ピクセル、行動計測、同意管理、タグマネージャーなどを示す場合があります。HTML、ヘッダー、DNSの公開確認トークンは別種の根拠です。トークンがあっても、誰がSearch Consoleへアクセスできるかは分かりません。トークンが見つからなくても、別の確認方法を使っている可能性があります。方法の違いはGoogleのプロパティ所有権確認の説明で確認できます。

ステータスだけでなく根拠を追う

「検出」は、対応するパターンが見えたことを意味します。実行、同意、ネットワーク送信、提供元での受理までは証明しません。「未検出」は、後から実行される、サーバーで動く、別ページに存在する、といった連携でも起こります。どちらの状態も、実際の実装と照合してください。

ページが取得できない場合や確認画面に置き換わる場合は、測定の土台がありません。すべての連携が欠けている証拠ではありません。DNSのタイムアウトと、正常に問い合わせた結果として該当レコードがなかった状態も区別します。安全でない追跡URLが見つかったら、まず実際に使われているのか、未使用コードに残っているだけかを確認し、その後ブラウザーの通信を調べます。

イベントを意図した送信先まで確認する

1. クリーンなブラウザーセッションを開きます。選択した同意状態や、検証に影響する拡張機能を考慮します。
2. テストデータを使って対象の操作を1回行います。通信と、閲覧権限のある提供元の診断画面を確認します。
3. イベント名、送信先、必要な値を比較します。「購入」を押したことと、取引が確定したことは同じではありません。
4. 再読み込み、リダイレクト、再試行をテストします。ブラウザーとサーバーの両方から送る場合は、想定した重複排除を確認します。

Googleのデータレイヤーを使う実装では、イベントの内容とタイミングが重要です。dataLayerが存在するだけでは、値が正しいとは言えません。原因を確認せず別のタグを足すのではなく、該当する発火条件や連携を修正します。

同意とデータの手掛かりを慎重に解釈する

同意管理プラットフォームの検出は、選択が尊重される証拠ではありません。新しいセッションで、選択前、拒否後、同意後、後から変更した後を調べます。観測した挙動と想定した設計を比較してください。Googleは同意管理を選択の取得、伝達、尊重として説明し、実装ガイドでは処理順序の重要性を示しています。

個人情報を含む可能性のある追跡パターンや一部のCookieは、調査のきっかけであり、自動的な法的判定ではありません。変更前に送信先と製品ルールを確認してください。ハッシュ化すれば、あらゆる送信が許可されるわけではありません。フォームのプライバシー文言や必須チェック欄の指摘も手動で確認します。静的HTMLだけで、適用される法的義務を確定することはできません。

再検査し、確認した主張だけを完了にする

同じページで公開情報の検査を再実行し、変わったパターンを記録します。ブラウザーでの検証と、権限のある提供元での受信確認も加えます。操作、同意状態、期待イベント、観測イベント、重複の確認を短く記録するだけでも役立ちます。共有する証拠では個人情報、トークン、支払い情報を伏せてください。

実際に検証した主張だけを完了にします。不要なスクリプトを削除した場合も、重要なイベントが届き続けるか確認します。点数の改善は、正しい帰属、配信成功、法的適合性の証拠ではありません。同意管理、キャンペーンタグ、購入フローを変えた後には、関係する検証を繰り返します。