在服务器端跟踪前面放一个 Cookie 横幅：什么变了，什么没变

第一方主机名是请求的一个技术属性。它不是许可。如果你昨天设置分析 Cookie 需要同意，今天同样需要，Cookie 现在由 metrics.yoursite.com 而不是 google-analytics.com 设置，与此毫无关系。监管机构的问题是你收集什么、为什么收集，而不是数据包在路上经过了哪台服务器。

真正改变的是被拦截的请求去了哪里。广告拦截器和浏览器隐私功能按主机名和 URL 模式拦截，它们拦截 googletagmanager.com。它们不拦截你自己的域名。所以一个已经同意、却被过滤列表悄悄丢弃的访客，现在会被统计到。这就是全部的收益，而且只对已同意的访客才是收益。

Google 的代码读取一个由几个命名权限组成的同意状态——analytics_storage、ad_storage、ad_user_data、ad_personalization——并据此调整发送的内容。在访客做出决定之前，同意管理工具推送一个默认的 denied；访客选择后，它推送一次更新。在 denied 状态下，Google 代码仍会触发，但只发送一个无 Cookie 的 ping：没有客户端 ID，没有 Cookie，只是一个「页面被看到了」的信号，仅此而已。一旦 analytics_storage 变为 granted，它就发送完整命中。服务器容器收到的就是被发送的那一种，同意信号随命中一起传输，所以服务器端的 GA4 代码行为一致。

同意管理工具必须在 Google 代码之前加载，这样当代码首次评估时，它的默认值已经就位。大多数同意管理工具正是为此提供了 wait_for_update 值——代码在假定 denied 之前等待同意状态的几百毫秒。

SignalHost 在你的容器中创建的实体不带任何同意条件。这是有意为之。Google 自己的代码会遵守 Consent Mode；在 Google 代码上手动添加同意检查、而它下面的 GA4 事件代码却没有，就是下面两个错误中的第一个。

Google 代码负责把衡量数据经由服务器容器转发。而一个 GA4 事件代码——比如购买代码——可以自行发送。如果 Google 代码等待同意而事件代码不等，事件代码就会在同意之前触发并直接发送给 Google，而且是从一个横幅还开着的页面发送的。容器页面看不出任何异常，因为这些命中根本没有经过容器。

要么手动什么都不限制，让 Consent Mode 处理；要么限制每一个能够发送的代码。没有自洽的中间路线。

有些同意管理工具的工作方式是在获得同意前拦截脚本——它们按 URL 截住 script 标签并扣住。它们的列表认识 googletagmanager.com。它们不认识 exxz2gdaz1jz.yoursite.com，因为任何人的列表都不可能认识：加载器的主机名和文件名是你的容器独有的。所以在拦截模式下，加载器可能被无条件放行，如果你依赖的是拦截而不是 Consent Mode，那就是一个在同意之前触发的代码。

两条出路。手动把加载器的 URL 加入同意管理工具的拦截规则，归入你的分析所属的类别。或者——更好，因为它也能正确处理无 Cookie 的 ping——对 Google 的代码依赖 Consent Mode，只对不支持它的脚本使用拦截。我们自己的网站在自动拦截模式下运行同意管理工具，同时启用 Consent Mode；Google 代码放在同意管理工具脚本之后，仓库里有一个测试，谁把顺序调换了它就会失败。

同意状态包含在每一次命中里到达服务器容器，服务器端的 GA4 代码像浏览器端一样读取它。我们这边不会授予或升级任何同意；无 Cookie 的 ping 仍然是无 Cookie 的 ping。

如果你连接了 Meta 或 TikTok 目标，同样的命中也会送往它们。访客拒绝营销同意时是否应该停止这些转发，是由你的同意管理工具来表达的决定——通过加载器所在的类别，以及你的配置是否遵守 Consent Mode 的 ad_storage。用检查这里其他一切的方法来检查它：在横幅未作答的状态下打开网站，看网络面板，看看有什么发出去了。

• 同意管理工具的脚本在页面中位于 Google 代码之上。
• 在代码加载之前推送了默认的 denied 同意状态，并带有 wait_for_update。
• 容器中没有任何代码带有手动添加的同意条件——或者每一个能够发送的代码都带有。
• 横幅未作答时，网络面板显示一个无 Cookie 的 ping（请求中有 gcs=G100），没有完整命中。
• 接受之后，同一页面显示一次完整命中，容器页面把它计入。
• 如果同意管理工具按 URL 拦截，加载器的 URL 在它的规则里。