用户同意模式与 CMP

根据 GDPR 和 ePrivacy，通常需要先取得明确同意，才能设置非必要 Cookie 或为了广告共享数据。但如果用户拒绝同意后就阻止所有标签，衡量工作也会完全丢失。

Google Consent Mode 是一种桥梁：标签会读取用户的同意选择并调整行为，发送完整数据、保护隐私的信号，或者完全不发送任何数据。

Consent Mode v2 定义了四种关键状态。其中两种此前就已存在：analytics_storage 和 ad_storage。另外两种是在 v2 中新增的：ad_user_data 和 ad_personalization。

每种状态要么是“granted”，要么是“denied”。ad_user_data 控制是否可以将用户数据发送给 Google 用于广告；ad_personalization 控制这些数据是否可以用于个性化广告和再营销。

该流程分为两个步骤。首先，在任何标签触发之前运行默认命令，通常会将 EU 用户的所有设置设为拒绝。然后，用户点击横幅后，更新命令会反映其实际选择。

在标签加载前设置默认值至关重要，否则标签可能会在获取同意之前以完整跟踪状态触发，这将构成违规。

基础同意模式会完全阻止 Google 标签，直到获得同意；在此之前不会发送任何信号。高级同意模式会立即加载标签，但在同意被拒绝时，会发送不使用 Cookie 的“信号”，也就是不含标识符的匿名信号。

高级模式会为 Google 的转化建模提供数据，用于估算您无法直接观测到的转化。它通常能恢复更多数据，但合规方面需要进行更深入的讨论。

在高级模式下，如果同意被拒绝，Google 仍会收到一个最小化的无 Cookie 信号：时间戳、页面 URL、同意状态本身，以及一个不会被存储的随机标识符。

这些信号不携带个人数据，也不会设置 Cookie，因此具有一定的合规依据。它们为 Google 的模型提供了足够的汇总信号，用于估算未被观测到的转化。

同意管理平台（CMP）是一种工具，用于显示横幅、记录用户的选择、存储同意证明，并将该选择提供给您的标签。

示例包括 Cookiebot、OneTrust、Usercentrics 和 Didomi。CMP 是同意状态的事实来源；同意模式则规定 Google 标签如何响应这一状态。

对于同意模式 v2，Google 要求 Google Ads 再营销和 EEA 流量等产品使用经过认证的 CMP。经过认证的 CMP 能正确集成 v2 信号，并且位于 Google 的批准列表中。

CMP 必须传递四个同意参数，并在适用时与 IAB 透明度与同意框架（TCF）集成。使用未经认证的横幅或自行开发的横幅，可能导致相关功能被停用。

IAB 透明度与同意框架是一项行业标准，它会将同意编码为“TC 字符串”——一种紧凑的令牌，用于列出用户允许的用途和供应商。

广告技术合作伙伴会读取 TC 字符串，以确定自己是否可以处理数据。许多 CMP 会自动生成该字符串；这套机制较为复杂，因此规模较小的网站通常会使用更轻量的 Google 认证方案，而不采用完整的 TCF。

集成模式如下：CMP 先加载，并将同意模式的默认值设为拒绝。用户做出选择后，CMP 触发同意更新，并触发一个 dataLayer 事件。

然后，您的 GTM 标签会自动响应同意模式（使用内置同意检查），或使用由同意事件控制的触发器。顺序很重要：CMP 在 GTM 之前，默认值在更新之前。

同意状态会随事件一起传输到您的标签服务器。每个服务器端标签都可以在转发到目标平台之前，检查有效负载中的同意状态。

因此，即使数据已经离开浏览器，被拒绝的 ad_user_data 信号也应阻止 Meta CAPI 或 Google Ads 标签发送数据。同意控制必须同时存在于客户端和服务器端。

如果实施得当，同意模式加上经过认证的 CMP，就能尊重用户选择，并通过建模继续进行测量，同时不设置未经授权的 Cookie。实施不当时，它就会变成非法跟踪的遮羞布。

请定期进行审计：确认默认值为拒绝，横幅提供真正的拒绝选项，同意证明已被记录，并且任何用于识别用户的标签都不会在获得同意前触发。

测试您对同意模式和 CMP 的理解。

同意模式 v2 使用四个信号（analytics_storage、ad_storage、ad_user_data、ad_personalization），将其设置为已授予或已拒绝，并采用默认拒绝、随后更新的流程。高级模式会在拒绝同意时发送无 Cookie 信号，为建模提供支持。

经过 Google 认证的 CMP 是同意状态的事实来源：它显示横幅、记录同意，并传递这些信号以及 IAB TC 字符串。在客户端和服务器端都执行同意控制，并审计确保默认值在任何标签触发前已设为拒绝。