Googleタグを使うサイトで利用者の同意選択を計測へ反映するとき、同意バナーと同意モードの役割を分けて設計します。同意モードを入れるだけで、同意取得の画面や法的要件が自動で整うわけではありません。
Google同意モードは、Cookieやアプリ識別子の利用についての同意状態をGoogleへ伝え、Google広告やGoogle Analyticsなどのタグ動作を選択に合わせる仕組みです。本稿は技術的な確認順を扱い、法令への適合や同意文言の妥当性を判断するものではありません。
同意バナーとタグ制御を別々に設計する
最初に、同意バナーが取得する選択肢と、Googleタグへ渡す同意タイプの対応表を作ります。利用者へ何を説明し、どの操作を許可・拒否として扱い、その結果をどのタグへ渡すかを分けます。同意バナーは選択を取得し、同意モードはその状態に応じて対応タグの動作を調整します。
実装表には、対象地域、同意項目、既定状態、更新条件、タグの読込時点、不同意時の通信、確認端末、確認日を記録します。画面上のボタン名だけでなく、初回訪問、再訪問、選択変更、別ページへの移動で状態がどう維持されるかを書きます。
同意文言、必須Cookie、広告、分析などの区分は、事業者の方針と適用法令に基づいて決めます。媒体担当者だけで法的判断を行わず、必要に応じて社内のプライバシー担当や専門家へ確認します。ハッシュ化やcookieless pingを、同意不要と読み替えないでください。
基本実装と高度な実装の違いを理解する
基本実装では、利用者が同意バナーを操作するまでGoogleタグを読み込みません。利用者が同意しない場合は、同意状態を含めてGoogleへデータを送らず、タグは完全にブロックされます。Google広告のコンバージョンモデリングは一般的なモデルに基づきます。
高度な実装ではGoogleタグが読み込まれ、既定の同意状態を設定したうえで選択を待ちます。不同意時はCookieを保存せず、同意状態やcookieless pingを送る場合があります。完全な計測データは利用者が同意した場合だけ送られます。基本と高度では、同意前の通信とモデリングに使える情報が異なります。
高度な実装を選んでも、利用者の選択を無視してよいわけではありません。既定状態、更新命令、タグの発火順が誤ると、選択前に許可状態で動いたり、拒否後も状態が更新されなかったりします。タグ管理画面の設定済み表示だけでなく、実際のブラウザー通信を確認します。
実機で四つの状態を検証する
同意取得の方針が決まり、既定状態と更新状態を全ページで正しく渡し、利用者の選択どおりにタグが動くことを確認できたら公開候補にします。確認は同意前、許可、拒否、許可後の変更という少なくとも四つの状態で行います。
タグアシスタントやブラウザーの開発者機能を使い、同意状態、Cookie、ネットワーク通信、イベント発火を確認します。ページ遷移、フォーム完了、外部決済、埋め込みコンテンツなど、計測経路が変わる地点もテストします。テスト用の値に実利用者データを使いません。
法的要件、適用地域、同意文言、既定状態、不同意時の通信のいずれかを確認できない場合は公開を保留します。特定地域だけ動作を変える場合は、地域判定の失敗時にどの状態へ倒すかも決めます。
モデリングと運用後の制約を記録する
同意モードのモデリングにはデータ量のしきい値があります。導入すれば必ず欠損が補われる、実測値と同じ精度になる、すぐにレポートへ効果が出るとは限りません。Google広告・Google Analyticsの影響結果は、少なくとも7日間の実装後でも条件を満たした区分にだけ表示される場合があります。
公開後は、同意前、許可、拒否、選択変更の各状態でタグと通信を再確認し、サイト更新時にも同じテストを行います。バナーやタグマネージャーの変更履歴、確認端末、ブラウザー、確認日を残し、計測値の増減だけで正否を判断しません。
複数ドメイン、サブドメイン、外部フォームを使う場合は、同意状態がどこまで引き継がれるかを個別に確認します。トップページで許可した状態が申込画面で失われる、拒否状態が別ドメインで初期化されるなど、画面単体のテストでは分からない問題があります。実際の導線を最初から最後まで操作します。
タグやバナーを提供する事業者が更新された場合も再検証します。管理画面の設定名や既定値が変わる可能性があるため、実装日だけで完了にせず、サイト改修とタグ公開のたびに確認責任者を決めます。異常時には一時停止できる変更手順も残します。
成果計測の発火地点も同時に整理する場合は、コンバージョンタグの確認範囲も参照してください。Google広告の拡張コンバージョン導入前確認と組み合わせる場合も、同意取得、通常タグ、ユーザー提供データを別々に検証します。