博客
方法

联盟 Cookie 应该保留多久?30、60 还是 90 天

用一个算出来的模型看 30、60、90 天的联盟 Cookie 各能记到多少注册,B2B 与 B2C 的差别,Safari 的上限,优惠码的作用,以及更长窗口的成本。

Sep 28, 2026 · 11 分钟读完 · RelayWonder
clickday 30day 60day 90referral window: a signup here is creditedoutside the window

对大多数 SaaS 产品,60 天是一个稳妥的联盟 Cookie 时长:在我们的示例模型里,它能为一款决策快的自助产品记到约 94% 由伙伴带来的注册,为一款决策慢的 B2B 产品记到约 78%;换成 30 天窗口,这两个数字是 87% 和 60%。从 60 天延长到 90 天,快产品只多 4 个百分点,慢产品却多 12 个,所以答案取决于你的买家要多久才做决定。你承诺的窗口也不等于每个浏览器都会保留的窗口:Safari 会在用户 7 天没有与网站交互后删除 JavaScript 写的 Cookie,这就是为什么专属优惠码和天数一样重要。本文一步步搭出这个模型,你可以换上自己的数据重算。

联盟 Cookie 时长到底管的是什么

Cookie 窗口也叫推荐窗口,是访客点击伙伴链接到注册或付款之间允许的最长时间,在这个时间内的注册才记给伙伴。第 0 天点击、60 天窗口,第 59 天的注册算,第 61 天的不算。这是一条关于归属的规则,而不是一种追踪技术:Cookie 只是记住这次点击最常用的方式。

有两个细节会影响规则的实际效果。第一,多数计划在同一伙伴的每次新点击时重新计时,访客第 40 天再点一次,就重新获得 60 天。第二,在末次触点归因下,另一位伙伴的点击会替换掉前一位。这两点都不改变本文要回答的基本问题:在给定天数下,伙伴真正促成的注册里,有多大比例会被记到他名下?

作为参照,Google Ads 默认使用 30 天的点击转化窗口,并允许广告主根据转化来源把它设到最多 30、60 或 90 天 [1]。联盟计划通常比广告平台更宽松,因为伙伴的内容往往开启的是比一次广告点击更长的评估过程。

clickday 30day 60day 90referral window: a signup here is creditedoutside the window
一条从第 0 天伙伴点击开始、经过第 30、60、90 天的时间线,注册画成圆点,各窗口画成括号,显示每个窗口能覆盖哪些圆点。

为"从点击到注册的时间"建模

被记到的注册占比,完全取决于一个分布:在伙伴点击后最终注册的访客中,点击和注册之间隔了多少天?等你有了几百个已归因注册,就能从自己的数据里量出来。在那之前,一个合理的示例分布足以推演取舍。我们用两个分布,一个代表决策快的自助产品,一个代表决策慢的团队或 B2B 产品。这些不是行业统计,而是为了展示决策形状而选的假设。

示例:假设的伙伴带来注册按点击后天数的分布。请换成你自己测得的分布。
从点击到注册的天数快速自助产品较慢的 B2B 产品
0–150%20%
2–720%15%
8–3017%25%
31–607%18%
61–904%12%
超过 902%10%
合计100%100%

这样读这张表:快产品里,一半的最终注册发生在点击当天或第二天,只有 2% 超过三个月。B2B 产品里,只有五分之一这么快,十分之一要超过 90 天。需要试用、团队讨论或预算审批才会付款的产品,通常就是这个样子。

30、60、90 天 Cookie 窗口各能记到多少

N 天窗口下被记到的占比,就是 N 天内发生的注册的累计占比。把窗口以内的各行加起来即可。

  • 快产品,30 天:50% + 20% + 17% = 87%。60 天:87% + 7% = 94%。90 天:94% + 4% = 98%。
  • B2B 产品,30 天:20% + 15% + 25% = 60%。60 天:60% + 18% = 78%。90 天:78% + 12% = 90%。

窗口越长,边际收益越小,但缩小的速度因产品而异。快产品从 30 天到 60 天多 7 个点,从 60 到 90 天多 4 个点。B2B 产品同样的两步多 18 和 12 个点。用 30 天窗口的 B2B 伙伴,有 40% 自己促成的客户拿不到归属。当伙伴说你的窗口太短时,要看的就是这个数字。

这也解释了为什么同样的窗口,对一个品牌算慷慨,对另一个品牌却算小气。在大多数人一天内就做决定的消费类应用上,30 天的联盟 Cookie 时长几乎就是完整覆盖。同样的 30 天放在卖给团队的工具上,会让伙伴相当一部分工作得不到报酬,有经验的 B2B 伙伴心里清楚。

浏览器会对一个 60 天的 Cookie 做什么

到目前为止,模型假设 Cookie 能活满整个窗口,但并非总是如此。Safari 的追踪防护把通过 document.cookie 创建的持久 Cookie 有效期限制在 7 天 [2],WebKit 的说法是:用户 7 天没有与网站交互,脚本写入的 Cookie 和其他脚本可写存储就会被删除。它还可以更严:当一个被判定具有跨站追踪能力的网站把用户导航到你的页面、且网址带查询参数或片段时,落地页上由 JavaScript 创建的 Cookie 会被限制在 24 小时 [3]。Chrome 也有上限,但长得多:自 2022 年 8 月的 Chrome 104 起,任何 Cookie 的过期时间都不能设在 400 天之后 [4]。

所以,一个在你网站上用 JavaScript 写推荐 Cookie 的追踪脚本,在 Safari 里会受 7 天上限约束。为了看清它对模型的影响,我们纯粹为了示例假设:来自伙伴链接的访客中 30% 用 Safari,对他们来说,只有 7 天内的注册能被 Cookie 记到。你的真实比例会不同,请在自己的分析工具里查。

示例:30% 访客的 Cookie 只保留 7 天时被记到的占比。7 天内注册占比:快产品 70%、B2B 35%,来自上面的分布表。
窗口快产品,无上限快产品,30% SafariB2B,无上限B2B,30% Safari
30 天87%0.7 × 87 + 0.3 × 70 ≈ 81.9%60%0.7 × 60 + 0.3 × 35 = 52.5%
60 天94%0.7 × 94 + 0.3 × 70 ≈ 86.8%78%0.7 × 78 + 0.3 × 35 ≈ 65.1%
90 天98%0.7 × 98 + 0.3 × 70 ≈ 89.6%90%0.7 × 90 + 0.3 × 35 = 73.5%

有两点很明显。上限对 B2B 产品伤害大得多,因为它的注册来得晚。上限还削弱了延长窗口的好处:B2B 情形下,从 60 天到 90 天只多 8.4 个点而不是 12 个点,因为多出的天数对 Safari 那部分访客是看不见的。承诺更长的窗口,修不好一个一周后就被浏览器删掉的 Cookie。

public information only · dated
B2B 产品每个窗口两根柱子:一根是所有浏览器都保留 Cookie 时的记到占比,一根是 30% 访客只保留 7 天时的占比。

为什么优惠码比多给几天更管用

专属优惠码不需要任何 Cookie 就能完成归因。伙伴的受众在结账时输入伙伴的码,不论注册发生在什么时候、用的什么浏览器、中间换过几台设备,都会记到伙伴名下。在 Stripe 里,促销码是包在优惠券外面、面向客户的字符串,多个码可以指向同一张优惠券 [5],所以给每位伙伴一个专属码,在折扣设计上没有额外成本。

为了给出一个数字,我们同样为示例假设:Cookie 没能记到的伙伴带来注册中,有 40% 改用了伙伴的码。这既包括窗口过后的注册,也包括 Cookie 被 Safari 删掉的注册。B2B 产品、30% Safari、60 天窗口时,没记到的占比是 100% − 65.1% = 34.9%,其中 40% 约 14.0 个点,于是记到占比升到约 79.1%。30 天时:52.5% + 0.4 × 47.5% = 71.5%。90 天时:73.5% + 0.4 × 26.5% = 84.1%。

对比这两个杠杆。在这个例子里,30 天加优惠码(71.5%)胜过不带码的 60 天(65.1%),60 天加优惠码(79.1%)胜过不带码的 90 天(73.5%)。真实使用码的买家比例很大程度上取决于伙伴类型:在受众能"听到"码的播客和视频里往往更高,在读者习惯点击的对比文章里更低。但方向是一致的:优惠码能找回再多天数也找不回的注册。

SARAH10attributes the sale with no click and no cookievideo → memory → Google → checkout
一个结账表单,促销码一栏里填着伙伴的专属码,不需要点击就把这次注册记到该伙伴名下。

更长的 Cookie 窗口要花多少钱

窗口越长,你要付佣金的客户就越多。这是成本还是公平的报酬,取决于这些晚来的客户是不是真的由伙伴带来。先算账。取 B2B 产品的 100 个最终由伙伴带来的注册,不考虑浏览器上限,每位被记到的客户按约 $90 预期佣金计,即 $49 月付套餐、20%、12 个月、月流失 5%:(1 − 0.95¹²) ÷ 0.05 ≈ 9.2 张发票 × $9.80。

示例:上面的 B2B 分布,无浏览器上限,每位被记到客户预期佣金 $90($49 的 20%,12 个月,月流失 5%)。
窗口被记到的客户(100 位中)预期佣金比上一档增加
30 天6060 × $90 = $5,400—
60 天7878 × $90 = $7,020+$1,620
90 天9090 × $90 = $8,100+$1,080

每多记到一位客户,同样的 12 个月里也给你带来约 9.2 × $49 ≈ $450 收入,所以佣金始终是这些客户收入的 20%。更长的窗口不改变你每位客户的利润率,改变的是你要和伙伴分享的客户数量。真正要问的是重叠:点击和注册隔得越久,就越可能有别的渠道——搜索广告、销售电话、展会——也碰过这位客户。在伙伴之间的末次触点归因下,第 1 天的伙伴点击依然会赢下第 80 天经你自己付费搜索广告进来的注册,除非你的设置允许后来的非伙伴触点覆盖它。

所以更长窗口的成本不是佣金本身,而是为那些本来就会来的客户付的佣金。这无法精确测量,但可以估一个范围:看 30 天之后的晚到注册,查查其中有多少在注册前也经过了其他付费渠道。如果这个比例很小,更长的窗口基本上是在为伙伴的真实工作付钱。

EPCcommission ÷ clicksConversioncustomers ÷ clicksPayout ratiocommission ÷ revenueActive rateactive ÷ approved
一组指标卡片,显示一个伙伴计划的已记到注册数、从点击到注册的平均天数,以及通过优惠码归因的注册占比。

B2B 与 B2C:怎样选你的联盟 Cookie 时长

把模型收拢成一条决策规则。目标是选一个窗口,既能记到伙伴促成的大部分注册,又不为他们没有影响的客户付钱。

  1. 如果大多数客户在首次访问后一周内注册,比如低价消费类应用,模型里 30 天已经能记到接近 90%。60 天是一个友好的默认值,额外成本很小。
  2. 如果你卖给团队、试用期超过一周,或者需要首位访客以外的人批准,至少用 60 天。在 B2B 模型里,30 天会让 40% 由伙伴促成的注册拿不到归属。
  3. 如果你的销售周期经常超过两个月,90 天是合理的,但要配上优惠码,因为浏览器上限会吃掉多出天数的大部分好处。
  4. 不论选哪个,都给每位伙伴一个专属码,并在条款页写明"用码购买无需点击也会记到你名下"。
  5. 三到六个月后,用已归因客户测出你真实的点击到注册分布,按上面的方法重算。如果数据这么说,就调整窗口,并提前通知伙伴。

RelayWonder 的计划默认 60 天推荐窗口、末次触点归因,品牌可以按计划修改。伙伴专属码就是 Stripe 促销码,所以即使没有 Cookie,用码购买也会被归因。追踪脚本在你自己的域名下写推荐 Cookie,并把推荐 ID 作为 client_reference_id 传给 Stripe Checkout;Stripe 文档把这个字段描述为用于和你内部系统对账的引用,最长 200 个字符 [6]。这样一来,客户一旦结账,归因信息就和付款本身存在一起。

怎样测量你自己的"点击到注册"时间

每位已归因客户你需要两个时间戳:点击和注册。大多数追踪工具两者都存。导出来,算出相差的天数,按上表同样的区间分桶。几百位客户就足以得到稳定的形状。

  • 如果你的窗口会在新点击时重新计时,用赢得归因的那次点击,而不是有史以来的第一次点击。
  • 把通过优惠码归因(没有点击)的注册和通过链接归因的分开。前者的占比就是优惠码的效果。
  • 能的话按伙伴类型拆分。视频和播客受众的行为常常和搜索来的读者不同。
  • 记住:当前窗口之后的注册在数据里是看不见的。如果你的窗口是 30 天,就无法从已归因数据里看到 31–60 天那一桶;可以用引导流程里"从哪里知道我们"问题中填了伙伴的客户来估算。

FAQ

SaaS 的联盟 Cookie 时长设多少合适?

对大多数 SaaS 产品,60 天是稳妥的默认值。在示例模型里,它为快速自助产品记到约 94% 的伙伴注册,为较慢的 B2B 产品记到约 78%,而 30 天分别是 87% 和 60%。销售周期长的产品可以用 90 天。

90 天 Cookie 窗口一定比 60 天好吗?

不一定。对大多数买家一周内就做决定的产品,模型里 90 天只比 60 天多约 4 个点。浏览器上限也会削弱收益,因为 Safari 会在 7 天无交互后删除 JavaScript Cookie。

Safari 真的会在 7 天后删除联盟 Cookie 吗?

Safari 把通过 document.cookie 创建的 Cookie 有效期限制在 7 天;当已知追踪网站带着装饰过的网址把访客送来时,还可能限制在 24 小时。这适用于追踪脚本写的推荐 Cookie。优惠码以及把推荐 ID 传进结账可以减轻影响。

优惠码怎样弥补 Cookie 窗口太短?

专属码在结账时完成归因,不需要 Cookie,所以窗口结束后、跨浏览器和跨设备都有效。在示例 B2B 模型里,假设 40% 本会丢失的注册用了码,60 天窗口的记到占比从约 65% 升到约 79%。

更长的 Cookie 窗口会增加佣金成本吗?

它增加的是要分享的客户数,不是每位客户的比例。在 100 个注册、每位预期佣金 $90 的 B2B 例子里,从 30 天到 60 天多付约 $1,620 佣金,这 18 位客户在 12 个月内带来约 $8,100 收入。真正的成本是为别的渠道本来就会带来的客户付钱。

浏览器允许的最长 Cookie 时长是多少?

自 2022 年 8 月的 Chrome 104 起,Chrome 把任何 Cookie 的过期时间限制在设置后 400 天以内。Safari 对 JavaScript 写的 Cookie 限制短得多。实际上 30 到 90 天的窗口远低于 Chrome 的上限。

Sources

  1. Google Ads 帮助:关于转化窗口 · 默认点击转化窗口 30 天,可设到最多 30、60 或 90 天。2026 年 10 月核对。
  2. WebKit:Intelligent Tracking Prevention 2.1 · 通过 document.cookie 创建的持久 Cookie 有效期限制为 7 天(2019 年 2 月)。2026 年 10 月核对。
  3. WebKit:Intelligent Tracking Prevention 2.2 · 被判定的域名导航用户且网址带查询参数或片段时限制为 1 天(2019 年 4 月)。2026 年 10 月核对。
  4. Chrome for Developers:Cookie 过期时间上限 · 自 Chrome M104(2022 年 8 月)起 Cookie 最长 400 天。2026 年 10 月核对。
  5. Stripe 文档:优惠券与促销码 · 促销码是面向客户的码,多个码可指向同一张优惠券。2026 年 10 月核对。
  6. Stripe API:创建 Checkout Session · client_reference_id 用于与内部系统对账,最长 200 个字符。2026 年 10 月核对。
话题联盟 Cookie 时长30/60/90 天 Cookie 窗口推荐窗口从点击到注册的时间B2B 与 B2C 联盟优惠码归因Safari Cookie 上限