为什么跟踪失效了

十年来，营销衡量一直依赖一个简单的做法：从广告平台的域名写入第三方 Cookie，然后在数百万个网站上读取它。这样一来，广告主就能将用户在不同网站上的行为拼接成一个统一的跨网站画像。

客户端 JavaScript 直接从浏览器向 Google、Meta 等平台发送像素请求。这种方式易于部署且功能强大，但几乎不受用户控制地将所有信息泄露给第三方。

2017 年，Apple 在 Safari 中推出了智能跟踪防护（ITP）。它利用设备端机器学习将域名分类为跟踪器，然后阻止或分区存储这些跟踪器的 Cookie。

后续版本的 ITP 将客户端（document.cookie / JavaScript 设置的）Cookie 的有效期限制为 7 天；如果用户是通过已知跟踪器的链接进入，期限则只有 24 小时。长期归因窗口就这样悄然缩短了。

Firefox 默认启用增强型跟踪保护（ETP），使用 Disconnect 列表阻止已知的第三方跟踪 Cookie。Brave 则开箱即用地提供了激进的拦截功能。

在这些浏览器中，第三方 Cookie 早在 Chrome 宣布任何变化之前数年就已经基本失效。衡量团队发现，广告平台报告的转化与后端实际情况之间的差异不断扩大。

Chrome 占据全球浏览器市场份额的大部分，因此它的计划最为重要。Google 多次推迟全面弃用第三方 Cookie，随后在 2024 年转而采用用户选择提示，而不是强制移除。

无论具体时间表如何，战略信号都很明确：不要围绕第三方 Cookie 来设计衡量体系。它们是正在被弃用的资产。

当 Cookie 提前过期或被阻止时，回访用户看起来就像新用户。转化无法再关联到最初的广告点击，因此平台会少报转化。

与此同时，模型估算和推算的转化又会抬高其他数字。结果是两个事实来源不再一致，削弱了人们对每个信息面板的信任。

除了 Cookie，浏览器现在还会按照顶级网站对存储进行分区。跟踪器在网站 A 上的 localStorage 与同一跟踪器在网站 B 上的 localStorage 彼此隔离。

这会彻底破坏在 Cookie 被阻止后仍然存在的共享标识符技巧。即使是指纹识别也正受到积极抑制：Safari 和 Firefox 会加入噪声，而 Chrome 的隐私沙盒则提出使用聚合 API。

在移动设备上，Apple 的应用跟踪透明度（ATT）要求应用在访问 IDFA 广告标识符之前先征得许可。大多数用户都拒绝了。

这严重破坏了移动应用安装归因和受众定向，促使行业转向 SKAdNetwork 等聚合式隐私保护框架，以及基于用户同意的服务端数据。

很大一部分用户会运行广告拦截器或隐私 DNS，阻止向已知分析和广告域名发送请求。向 google-analytics.com 或 facebook.com 发送的客户端像素请求很容易被过滤。

这意味着，即使用户已经同意，即使衡量行为完全合法，也可能因为请求根本没有离开浏览器而丢失数据。通过自有域名进行路由不仅是隐私措施，也是提高可靠性的修复方案。

GDPR、ePrivacy 及类似法律要求具备合法依据；对于大多数跟踪行为，还要求事先取得同意。针对 Google Analytics 的执法行动在多个 EU 国家质疑了将数据传输到 US 服务器的做法。

因此，问题来自两个方面：浏览器进行技术拦截，同时法律要求取得同意、减少数据收集并提供控制权。您无法只解决其中一个问题。

浏览器仍然信任一样东西：由用户实际访问的网站（第一方）设置的 Cookie 和存储。仅限 HTTP、由服务器设置的第一方 Cookie 可以避开 ITP 最严格的限制。

这构成了现代技术栈的基础。请将身份信息和事件收集迁移到自有域名和服务器，然后将获得同意的数据转发给各个平台。这就是服务端跟踪。

关键结论不是寻找某个单一的变通方案，而是改变架构。不要再依赖浏览器充当向第三方传输数据的数据管道。

相反，您应当收集第一方数据，获取明确同意，从服务器发送信号，并接受部分衡量结果将通过模型估算而非确定性方式得出。接下来的课程将准确构建这套技术栈。

请测试您对跟踪为何失效的理解。

跟踪从两个方向失效：浏览器通过 ITP、ETP、存储分区和 ATT 阻止并缩短第三方标识符，而广告拦截器则完全阻止客户端像素发送请求。监管又在此基础上增加了同意要求。

持久的应对方式是收集第一方数据，在取得同意的前提下进行服务端数据收集。第三方 Cookie 是正在被弃用的资产，因此本课程其余部分将构建现代且能抵御隐私变化的技术栈。