2026 年的第一方 Cookie 与联盟追踪

2026 年，依赖第三方 Cookie 的联盟追踪在 Safari 和 Firefox 里不可靠，在 Chrome 里还能用，只是因为谷歌在 2025 年 4 月决定保留现有的第三方 Cookie 选择权，而不是逐步淘汰。Safari 默认屏蔽所有第三方 Cookie，并会在用户 7 天没有与网站交互后删除 JavaScript 写的 Cookie；Firefox 默认给每个网站一个独立的 Cookie 罐。能跨浏览器站得住的做法，是基于第一方 Cookie 的联盟追踪：把推荐信息存在品牌自己的域名下，在结账时作为 Stripe 的 client_reference_id 带进去，之后由付款记录保存归因。本文按 2026 年 10 月的情况逐一说明各浏览器的规则、它们会弄坏什么，以及仍然有效的四种技术。

第三方与第一方 Cookie：真正要紧的区别

当 Cookie 属于地址栏里那个网站时，它是第一方的。访客在 yourbrand.com 上，Cookie 也存给 yourbrand.com，那就是第一方。当 Cookie 属于嵌入页面或被页面调用的另一个网站，比如联盟网络域名下的追踪像素，它就是第三方的。浏览器判断的依据是 Cookie 所属的网站和顶层网站是否相同，而不是代码是谁写的。

传统联盟追踪建立在第三方 Cookie 之上。伙伴链接指向网络的域名，网络在跳转时把 Cookie 写在自己的域名下；之后商家感谢页上的像素，同样从网络域名加载，再把这个 Cookie 读回来。读和写都发生在网络的域名上，而访客当时在别人的网站上。这正是浏览器隐私功能要阻止的模式，因为同样的机制能让广告网络在所有嵌入它的网站上跟踪一个人。

第一方追踪改变的是推荐信息存放的位置。伙伴链接仍然带着一个标识，但由品牌自己的网站读取，并存进品牌域名下的 Cookie。不需要任何跨站读取。网络得知这次推荐，是品牌网站或服务器告诉它的，而不是在别人的页面上读自己的 Cookie。

2026 年 10 月各浏览器的现状

决定大多数流量的三个引擎立场各不相同。下表汇总了影响联盟追踪的部分，后面几节给出细节和来源。

Safari：智能防追踪（ITP）

WebKit 的追踪防护页面写明，它默认屏蔽所有第三方 Cookie，只能通过 Storage Access API 或临时兼容修复获得访问 [1]。对第一方 Cookie，关键规则是 7 天上限：JavaScript 创建的 Cookie 和其他脚本可写存储，在用户 7 天没有与网站交互后被删除 [1]。针对链接装饰还有更严的规则：当一个被判定具有跨站追踪能力的域名把用户导航到某页面、且最终网址带查询参数或片段时，该落地页上 JavaScript 创建的 Cookie 被限制在 24 小时 [2]。而当 ITP 检测到第三方 CNAME 伪装或第三方 IP 地址伪装时，它会把 HTTP 响应里设置的 Cookie 限制在 7 天 [1]。

实际意味着：你网站追踪脚本写的推荐 Cookie，在 Safari 里能活一周，而不是 60 天，除非访客在这一周内回来并与网站交互。如果伙伴自己的网站被判定为追踪者，从那里来的装饰链接可能把它缩短到一天。这些都不是你的配置出了错，而是浏览器在做它声明要做的事。

Firefox：全面 Cookie 保护

Mozilla 在 2022 年 6 月把全面 Cookie 保护（Total Cookie Protection）设为全球所有 Firefox 桌面用户的默认功能，相关文章在 2024 年 8 月更新过 [5]。它的做法是给用户访问的每个网站创建一个独立的 Cookie 罐。访客在伙伴博客上时，联盟网络设置的第三方 Cookie 存进这个博客的罐里，当同一个网络从商家网站被调用时就看不到它。因此传统的跨站像素追踪在 Firefox 里会失败，而商家域名下的第一方 Cookie 表现正常。

Chrome：第三方 Cookie 留下，替代 API 退场

2025 年 4 月 22 日，谷歌表示将维持目前在 Chrome 中向用户提供第三方 Cookie 选择权的做法，不再推出新的独立提示；用户仍在 Chrome 的隐私和安全设置里做选择 [3]。2025 年 10 月 17 日，谷歌宣布因采用率低，退役大部分 Privacy Sandbox 技术，包括 Attribution Reporting API、Topics、Protected Audience、IP Protection 和 Related Website Sets，同时继续支持 CHIPS、FedCM 和 Private State Tokens [4]。对联盟追踪来说，这意味着第三方 Cookie 对没有屏蔽它的 Chrome 用户仍然有效，而一些厂商在准备接入的浏览器原生归因 API，不会以现在的形式到来。

把 Chrome 的决定当作继续依赖第三方 Cookie 的理由，是一个错误。Safari 和 Firefox 仍在屏蔽或分区它们，一部分 Chrome 用户也会主动屏蔽。一种在一个引擎里有效、在两个引擎里失效的追踪方法，不能拿来向伙伴承诺佣金。

传统联盟追踪在哪里断掉

用老办法走一遍推荐流程，标出失败的地方。访客在博客上读了伙伴的测评，点击指向 network.example/click?aff=123 的链接，在跳转时拿到 network.example 的 Cookie，落到 yourbrand.com，三天后注册。你的感谢页从 network.example 加载一个像素，本该读出那个 Cookie。

• Safari：像素请求在 yourbrand.com 上是第三方请求，它的 Cookie 被屏蔽。转化丢失。
• Firefox：跳转时 Cookie 存在以 network.example 为顶层网站的罐里；yourbrand.com 上的像素看到的是 yourbrand.com 的罐。转化丢失。
• 默认设置的 Chrome：像素能读到 Cookie。转化被记录。
• 用户屏蔽了第三方 Cookie 的 Chrome：转化丢失。

纯粹为了示例，假设你的伙伴流量中 30% 用 Safari、5% 用 Firefox、65% 用 Chrome，而 Chrome 用户中每十人有一人屏蔽了第三方 Cookie，那么基于像素的方案只能记录 0.65 × 0.9 ≈ 58.5% 的转化。剩下 41.5% 不管 Cookie 窗口多长都看不见。用你分析工具里的浏览器分布算出自己的数字；要点是这种损失是结构性的，不是调参能解决的。

仍然有效的四种技术

2026 年稳健的联盟追踪由四种技术组合而成。它们都不新，也都不依赖跨站 Cookie。

1. 用普通参数做链接装饰

伙伴链接直接指向品牌页面，查询参数里带一个标识，比如 yourbrand.com/?via=anna。标识是可见的，品牌自己的代码能读到，不需要经过第三方域名跳转。参数要短、人能读懂，比如伙伴别名，而不是一长串不透明的点击 ID；可读的别名更容易让伙伴和客户信任，也方便核对。即便如此，也请在 Safari 无痕浏览里实际测试你的链接，因为那里对参数的处理最严格。

2. 品牌域名下的第一方 Cookie

品牌网站上的一段小脚本读取参数，把 Cookie 写在品牌自己的域名下。因为是第一方 Cookie，网站每个页面都能读到，包括结账页。在 Safari 里它受上面说的 7 天上限约束，所以应该把它当作从点击到结账之间的桥，而不是长期存储。

3. 通过结账做服务端归因

这一步让其余部分变得持久。客户开始结账时，品牌的服务器从 Cookie 里读出推荐 ID，在创建 Checkout Session 时把它放进 client_reference_id 字段传给 Stripe。Stripe 文档把这个字段描述为用于和内部系统对账的唯一字符串，最长 200 个字符 [6]。从那一刻起，推荐信息就成了付款记录的一部分。之后的每张续费发票都属于同一位客户和同一份订阅，所以续费佣金是从发票匹配的，与浏览器记得什么无关。

换句话说，浏览器只需要从点击记到结账。对一周内就结账的大量客户，Safari 的 7 天上限根本不起作用。对花更久的客户，下一种技术才是关键。

4. 专属优惠码

结账时输入的码不需要任何 Cookie，在任何设备、任何时间都能完成归因。在 Stripe 里这就是促销码，一个映射到优惠券、面向客户的字符串。优惠码填补了浏览器制造的空缺，而且对那些在播客或视频里听说产品、几天后手动输入网址的受众，它是唯一有效的技术。

品牌追踪域名有用吗

品牌追踪域名是 go.yourbrand.com 这样的子域名，用 CNAME 记录指向追踪服务商。它在两个具体方面有用。第一，短链接看起来是品牌自己的链接，这对正在犹豫要不要点的人很重要。第二，当 go.yourbrand.com 上的短链接跳转到 yourbrand.com 时，追踪服务器可以直接在跳转响应里把推荐 Cookie 写在品牌的主域名下，即使页面上没装追踪脚本，推荐信息也能存下来。

它不是绕过浏览器隐私的办法，把它这样宣传的服务商是在夸大。WebKit 说，检测到第三方 CNAME 伪装时，它会把 HTTP 响应中设置的 Cookie 限制在 7 天，和 JavaScript Cookie 一样 [1]。所以在 Safari 里，通过品牌域名设置的 Cookie 也应预期只活一周左右，和脚本 Cookie 一样。品牌域名的价值在于信任和覆盖面，而不是更长的 Cookie。持久的部分仍然是结账归因和优惠码。

RelayWonder 怎么处理这些

RelayWonder 从一开始就按第一方模式构建。追踪脚本读取 ?via= 参数，在品牌自己的域名下写入第一方 Cookie rw_ref。品牌的结账流程把推荐 ID 作为 client_reference_id 传给 Stripe，之后通过 Stripe Connect 按每张 Stripe 发票计算佣金，所以续费、退款和争议都从付款数据归因。伙伴专属码就是 Stripe 促销码，不需要点击也能归因。品牌还可以添加 go.yourbrand.com 这样的自定义追踪域名；生效后，短链接、活动链接和脚本都使用它，推荐 Cookie 写在品牌的主域名下。

第一方联盟追踪检查清单

1. 确保伙伴链接落在你自己的域名上并带可读参数，而不是落在第三方点击域名上。
2. 在伙伴可能链接到的每个页面都装上追踪脚本，而不只是首页。
3. 在服务器上从第一方 Cookie 读出推荐 ID，作为 client_reference_id 传给 Stripe Checkout。
4. 给每位伙伴一个专属促销码，并在条款页写明用码购买无需点击也会记到他名下。
5. 移除依赖第三方 Cookie 的感谢页像素，或者只把它当作次要信号。
6. 在 Safari、Firefox 和 Chrome 里完整测试一遍，包括 Safari 无痕浏览，记录每种情况下是哪一步承载了推荐信息。
7. 如实告诉伙伴归因是怎么运作的，包括浏览器可能缩短一次点击被记住的时间。