Consent ModeとCMP

GDPRとePrivacyの下では、通常、必須ではないCookieを設定したり、広告目的でデータを共有したりする前に、明示的な同意が必要です。しかし、同意が拒否されたときにすべてのタグをブロックすると、計測を完全に失うことになります。

Google Consent Modeは、その橋渡しをします。タグがユーザーの同意設定を読み取り、完全なデータ、プライバシーを保護したシグナル、または何も送信しないという形で動作を調整します。

Consent Mode v2では、4つの主要な状態が定義されています。以前から存在していたのはanalytics_storageとad_storageです。v2で追加されたのはad_user_dataとad_personalizationです。

それぞれの状態は「granted」または「denied」のいずれかです。ad_user_dataは広告目的でユーザーデータをGoogleに送信できるかどうかを管理し、ad_personalizationはパーソナライズド広告やリマーケティングに利用できるかどうかを管理します。

このフローには2つのステップがあります。まず、どのタグよりも先にデフォルトコマンドが実行され、通常はEUユーザーに対してすべてをdeniedに設定します。次に、ユーザーがバナーをクリックすると、更新コマンドが実際の選択内容を反映します。

タグが読み込まれる前にデフォルトを設定することが重要です。そうしないと、同意を取得する前にタグが完全なトラッキング状態で発火し、規制違反になる可能性があります。

Basic Consent Modeでは、同意が得られるまでGoogleタグを完全にブロックするため、それ以前にpingは送信されません。Advanced Consent Modeではタグをすぐに読み込みますが、同意が拒否された場合は、識別子を含まない匿名の信号である、Cookieを使用しない「ping」を送信します。

Advanced modeはGoogleのコンバージョンモデリングにデータを提供し、直接観測できないコンバージョンを推定します。通常はより多くのデータを回収できますが、コンプライアンス上の検討事項も増えます。

Advanced modeで同意が拒否された場合でも、Googleは最小限のCookieを使用しないpingを受け取ります。そこにはタイムスタンプ、ページURL、同意状態そのもの、そして保存されないランダム識別子が含まれます。

これらのpingには個人データが含まれず、Cookieも設定されないため、正当性を説明できる場合があります。集計された十分な信号をGoogleのモデルに提供し、観測できないコンバージョンを推定できるようにします。

Consent Management Platform（CMP）は、バナーを表示し、ユーザーの選択を記録し、同意の証拠を保存して、その選択内容をタグに提供するツールです。

例としてCookiebot、OneTrust、Usercentrics、Didomiなどがあります。CMPは同意に関する唯一の正確な情報源であり、Consent ModeはGoogleのタグがその同意に応じて動作する仕組みです。

Consent Mode v2では、Google AdsのリマーケティングやEEAのトラフィックなどの用途で、Google認定CMPが必要です。認定CMPはv2の信号を正しく統合し、Googleの承認リストに掲載されています。

CMPは4つの同意パラメータを渡し、該当する場合はIAB Transparency and Consent Framework（TCF）と統合する必要があります。未認定のバナーや独自実装のバナーを使用すると、機能が無効化されるリスクがあります。

IAB Transparency and Consent Frameworkは、同意を「TC string」にエンコードする業界標準です。TC stringは、ユーザーが許可した目的とベンダーを一覧にした、コンパクトなトークンです。

アドテクノロジーのパートナーはTC stringを読み取り、データを処理してよいかを判断します。多くのCMPはこれを自動的に生成しますが、仕組みが大がかりなため、小規模なサイトではTCF全体を導入せず、より軽量なGoogle認定の構成を使うことがよくあります。

基本的な統合パターンは、まずCMPを読み込み、Consent Modeのデフォルトをdeniedに設定するというものです。ユーザーが選択すると、CMPが同意の更新を実行し、dataLayerイベントを発火します。

その後、GTMタグはConsent Modeに自動的に反応するか（組み込みの同意チェック）、同意イベントを条件とするトリガーを使用します。順序が重要です。CMPをGTMより先に、デフォルトを更新より先に設定します。

同意情報はイベントとともにタグ付けサーバーへ渡されます。各サーバーサイドタグは、送信先へ転送する前にペイロード内の同意状態を確認できます。

つまり、ブラウザを通過した後でも、ad_user_data信号がdeniedなら、Meta CAPIやGoogle Adsタグによる送信を停止する必要があります。同意の適用はクライアントとサーバーの両方に存在しなければなりません。

正しく実装すれば、Consent Modeと認定CMPの組み合わせにより、許可されていないCookieを設定せず、モデリングを通じて測定を続けながら、ユーザーの選択を尊重できます。誤った実装では、違法なトラッキングを覆い隠すだけの見せかけになってしまいます。

定期的に監査してください。デフォルトがdeniedになっていること、バナーに実質的な拒否の選択肢があること、同意の証拠が記録されていること、そして同意前に識別情報を扱うタグが発火していないことを確認します。

Consent ModeとCMPについての理解度を確認しましょう。

Consent Mode v2では、4つの信号（analytics_storage、ad_storage、ad_user_data、ad_personalization）をgrantedまたはdeniedに設定します。デフォルトをdeniedにしてから更新するフローが基本です。Advanced modeでは、拒否された場合にCookieを使用しないpingを送信し、モデリングに役立てます。

Google認定CMPは、バナーを表示し、同意を記録し、これらの信号（およびIAB TC string）に反映する唯一の正確な情報源です。同意をクライアントとサーバーの両方で適用し、タグが発火する前にデフォルトがdeniedになっていることを監査してください。