Consent Mode v2 与 2026 年 6 月 Google Signals 的终结
2026 年 6 月 15 日起，ad_storage 成为 Google 体系中对广告数据的唯一控制。本文讲解 Google Signals 终结对开发者意味着什么——以及为什么这整套机制是无 cookie 分析从来不必构建的。
2026 年 6 月 15 日，Google 将移除作为广告数据独立控制的 Google Signals。此后，你的同意管理平台（CMP）发送的 ad_storage 同意信号将成为决定访客级数据是否到达 Google Ads 的唯一关口。如果你的 CMP 配置错误，Analytics 中将不再有服务端设置来兜住这个错误。
这是一个安静却重大的变化。它把同意正确性的全部负担转移到运行于访客浏览器、在采集任何数据之前执行的 JavaScript 层上。值得准确理解这一层做了什么，因为这正是无 cookie 设计从不引入的复杂度。
Consent Mode v2 究竟是什么
Consent Mode v2 是 Google 用来告诉它的代码标签是否被允许使用存储的框架。它不是一个同意横幅——它是你的横幅与 Google 标签之间的接线。你的 CMP 设置四个信号：
gtag('consent', 'default', {
ad_storage: 'denied',
analytics_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
});
ad_storage控制广告 cookie、设备标识符以及发送到 Google Ads 的访客级数据。analytics_storage管理分配 client ID 的 Analytics cookie。ad_user_data允许对电子邮件等 first-party 数据进行哈希处理，用于 Enhanced Conversions。ad_personalization决定 Analytics 数据是否用于个性化广告定向。
当访客同意时，你的 CMP 会触发第二次调用，将相关信号更新为 granted。下游的一切都取决于这次更新是否正确送达。
basic 与 advanced，以及 advanced 为何存在
有两种实现模式，区别在法律上很重要。
在 basic 模式下，在获得同意之前，Google 的标签根本不会加载。拒绝则什么都不发送。
在 advanced 模式下，标签会立即加载，所有信号默认为 denied，但仍然向 Google 发送 cookieless pings——一个没有标识符、没有 client ID、没有存储状态的请求。Google 利用这些 ping 的数量，加上同意的少数人的行为，来建模它无法直接观测的转化。
advanced 模式之所以存在，是因为同意率很低，而广告主想拿回他们的数字。但在同意之前发送的 cookieless ping 仍然是向第三方传输数据，EDPB 对 ePrivacy 第 5(3) 条技术中立的解读并不会仅因请求省略了 cookie 就予以豁免。建模转化还需要一个最低限度的已同意会话池才能产出可靠结果，因此小型站点得到的只是噪声。
6 月 15 日的终结移除了什么
至今，Google Signals 充当第二道关口。你可以在 Analytics 中将其关闭，从而无论 Consent Mode 如何报告都限制广告数据共享。那道兜底防线已经消失。
终结之后：
- Google Ads 不再读取 Analytics 侧的设置，完全依赖你的 CMP 发送的 Consent Mode 信号。
- Google Signals 被收窄为仅用于 Analytics——在 GA4 内部将会话与已登录用户关联。
- IP 地址仍会被采集，并在转发到关联的 Ads 账户之前加密，之后由目标账户的设置接管。
实际效果是：一次失败的 gtag('consent', 'update', ...) 调用——一个竞态条件、一个在第一个标签之后才加载的 CMP、一次丢掉默认状态的部署——现在会悄无声息地发送你本打算拦截的数据。在 GDPR 下，这是没有合法依据的处理，而服务端安全网的移除让"暴露已被控制"的辩解更难成立。
根据近期指引，这也是广告数据共享方式的一次重大变更。对于有欧盟访客的站点，这可能触发向用户告知的义务——这是一项应在截止日期之前而非之后完成的审查。
本不必存在的复杂度
退一步看看一个合规的 Consent Mode v2 配置需要什么：一个 CMP、四个同意信号、默认状态、相对于标签加载顺序正确排列的更新调用、一个具有法律后果的 advanced 与 basic 之间的抉择、只有在流量阈值之上才有效的建模转化，以及现在没有兜底的单点故障。
这整套机制存在的目的，是在保持站在同意法律正确一侧的同时继续使用标识符——client ID、广告 cookie、哈希后的电子邮件。移除标识符，整个装置便坍缩为无。
无 cookie 的 tracker 没有要拦截的 ad_storage，因为它根本不设置任何广告存储。它没有要拒绝的 client ID，因为身份是一个单向哈希 SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)，在边缘的内存中计算且永不还原。原始 IP 与 User-Agent 仅用于计算该哈希；D1 存储哈希，而非输入。没有任何同意信号会失败，因为在第 5(3) 条之下没有任何需要同意的东西——访问访客设备对交付页面是严格必要的，而那个发送到 /collect、不到 2 KB 的脚本根本不读取任何存储。
6 月 15 日的终结是一个好时机，去问一个比"我的 Consent Mode 配置对了吗"更尖锐的问题。问问自己：你究竟为什么要为了衡量页面浏览而运行一台同意状态机。Google 从 cookieless pings 建模出的转化，是对你从未被允许采集的数据的一种估计。在没有标识符的情况下，统计真正发生的事，一直都是更简单的系统。
Comments
Loading comments…