Chrome 提出了一种可让用户选择使用第三方 Cookie 的新体验。您需要为选择在不使用第三方 Cookie 的情况下浏览的用户做好准备。
本页面包含有关即将发生的变更可能影响哪些方面的信息。
常见用户体验历程
许多付款和购物工作流程都依赖于第三方 Cookie。下表列出了停用第三方 Cookie 后可能会受到影响的一些用户体验历程,并建议了开发者可用来避免服务中断的替代 API。此列表可能并不详尽,可能会随着更多 Privacy Sandbox 解决方案的推出而更新。如果您遇到任何其他受影响的情况,建议您分享反馈。
测试与付款相关的用户历程
如需测试您的用户流程是否受到第三方 Cookie 限制的影响,最佳方式是启用第三方 Cookie 测试标志,然后在启用该标志的情况下完成用户流程。
为确保您的网站能按预期运行,请在限制第三方 Cookie 的情况下测试以下流程:
- 跨网站结账:测试依赖于第三方付款服务提供商(例如使用 <example-provider> 付款)的付款流程。确保:
- 重定向成功完成。
- 支付网关已正确加载。
- 付款流程可以毫无错误地完成。
- 系统会按预期将用户重定向回您的网站。
- 付款信息中心:测试在限制第三方 Cookie 的情况下,交易信息中心微件能否正常运行。验证用户是否可以:
- 访问信息中心。
- 按预期查看所有付款。
- 能够在信息中心的不同部分(例如交易记录、付款详情)之间无误导航。
- 管理付款方式:测试付款方式管理 widget 是否按预期运行。屏蔽第三方 Cookie 后,请测试:
- 添加或删除付款方式可正常运行。
- 使用之前保存的付款方式付款不会受到影响。
- 欺诈检测:比较在使用和不使用第三方 Cookie 时欺诈检测解决方案的运作方式。
- 阻止第三方 Cookie 是否会增加额外的步骤,给用户带来额外的不便?
- 在浏览器中屏蔽第三方 Cookie 后,该工具是否仍能检测到可疑模式?
- 个性化结账按钮:测试在限制第三方 Cookie 的情况下,付款按钮能否正确呈现。
- 即使个性化按钮未显示用户的首选付款方式,用户是否仍能完成购买交易?
跨网站结账
某些付款服务提供商可能会依赖第三方 Cookie,让用户无需重新进行身份验证,即可在多个商家网站上访问其账号。如果用户选择不使用第三方 Cookie 来浏览网页,此用户体验可能会受到影响。
嵌入式结账表单
请考虑以下网域:
payment-provider.example
为商家网站提供付款服务,并存储用户付款和会话数据。merchant.example
是一个网站,其中嵌入了payment-provider.example
提供的结账表单。
用户刚刚登录 payment-provider.example
(例如,在另一个网站上完成结账时)。用户在 merchant.example
上发起结账流程。
使用第三方 Cookie 后,嵌入在 merchant.example
上的 payment-provider.example
结账表单将能够访问在顶级上下文中在 payment-provider.example
上设置的自己的顶级会话 Cookie。不过,如果第三方 Cookie 被屏蔽,嵌入内容将无法访问自己的顶级 Cookie。

可自定义的 FedCM 解决方案
payment-provider.example
应考虑实现 FedCM 以用作身份提供方。在以下情况下,此方法非常适用:
payment-provider.example
嵌入在无关的第三方网站上。payment-provider.example
已嵌入到 5 个以上的相关网站中。
FedCM 的主要优势在于,界面可以为用户提供更多选择背景信息。在用户授权的情况下,FedCM 允许在依赖方 (merchant.example
) 和身份提供方 (payment-provider.example
) 之间共享自定义数据。依赖方可以选择支持一个或多个身份提供方,并且 FedCM 界面将仅在满足条件时显示。
根据需要,开发者可以选择以下两种模式:在用户使用身份提供程序登录时自动显示 FedCM 提示的“被动”模式,或在用户执行操作(例如点击结账按钮)后触发登录流程的“主动”模式。
FedCM 还可用作 Storage Access API (SAA) 的信任信号,让嵌入内容在用户同意使用嵌入内容提供商的账号登录后,无需额外向用户显示提示即可访问其顶级未分区的 Cookie。
侧重于存储空间访问权限的解决方案
另一个值得考虑的 API 是 Storage Access API (SAA)。使用 SAA 时,系统会提示用户允许 payment-provider.example
嵌入访问其自己的顶级 Cookie。如果用户批准访问,表单的呈现方式将与第三方 Cookie 可用时一样。
与 FedCM 一样,用户必须在嵌入 payment-provider.example
的每个新网站上批准请求。查看 SAA 演示,了解该 API 的运作方式。如果默认的 SAA 提示不符合您的需求,不妨考虑实现 FedCM,以获得更个性化的体验。
减少少数相关网站上的用户体验阻碍
如果商家网站和付款服务提供商都属于同一家公司,您可以使用相关网站集 (RWS) API 声明网域之间的关系。这有助于减少用户摩擦:例如,如果 insurance.example
和 payment-portal-insurance.example
位于同一 RWS 中,当 payment-portal-insurance.example
嵌入中请求存储空间访问权限时,payment-portal-insurance.example
将自动获得对其自己的顶级 Cookie 的访问权限。
其他实验性解决方案
在这种情况下,另一个可能有用的实验性 API 是分区弹出式窗口。该 API 目前处于积极开发阶段。
借助分屏弹出式窗口,系统可以要求用户输入凭据,以便在 merchant.example
打开的弹出式窗口中登录 payment-provider.example
。存储空间将由打开器 merchant.example
分区。在本例中,payment-provider.example
嵌入内容将能够访问在弹出式窗口中设置的存储值。采用此解决方案时,用户必须在每个网站上登录支付服务提供商。
付款链接结账
某些付款服务提供商提供生成付款链接的服务,该服务会为商家网站呈现自定义结账页。付款链接服务和付款服务提供商的用户门户通常在不同的网域(例如 payment-provider.example
和 payment-link.example
)上实现。
payment-link.example
会嵌入 payment-provider.example
提供的结账表单。这是嵌入式结账表单模式的变体。在这种情况下,FedCM、SAA 和 RWS 也是不错的选择。
付款信息中心
某些应用会向用户显示跨多个网站的交易信息中心,以便用户集中查看其金融活动。这需要信息中心能够访问多个网域中的用户专用数据。
请考虑以下网域:
earnings.example
提供一个可嵌入各种 Web 应用中的付款信息中心。此服务会存储用户收入数据和会话信息。catsitting.example
和dogsitting.example
是两个单独的网站,都嵌入了earnings.example
信息中心。
用户登录其 earnings.example
账号。当他们访问 catsitting.example
或 dogsitting.example
时,可以查看自己的收入。嵌入的 earnings.example
信息中心依赖于顶级 Cookie,并显示用户的个性化收入信息。
与其他示例一样,在停用第三方 Cookie 的情况下,嵌入的 earnings.example
将无法访问其顶级 Cookie。

第一方信息中心
如果这三个网域都属于同一方,请考虑将 SAA 与 RWS 搭配使用。借助 SAA,earnings.example
可以通过用户权限访问其顶级 Cookie。如果此方在 4 个或更少的网域中使用 earnings.example
,则使用 RWS 声明这些网域之间的关系可以提供更顺畅的用户体验。
如果同一方在超过 5 个网域中嵌入了该 widget,则无法声明所有嵌入网站与 widget 的网域之间的关系,因为 RWS 仅支持一组中最多 6 个网站(一个主要网站和 5 个关联网站)。
信息中心分发规模
- 您分发了适用于第三方网站的控制台解决方案。
- 您有超过 5 个网站嵌入了信息中心微件。
在这种情况下,earnings.example
应考虑实现 FedCM 以充当身份提供程序。这意味着,用户需要使用由 earnings.example
管理的账号登录 dogsitting.example
。
FedCM 提供了可自定义的界面,可帮助您向用户明确说明要共享哪些信息。借助 FedCM,dogsitting.example
可以请求 earnings.example
共享自定义权限,例如访问交易数据。
FedCM 还可用作 Storage Access API 的信任信号,并且系统会向嵌入的 earnings.example
授予对其自身顶级 Cookie 的存储访问权限,而无需在 SAA API 调用时额外提示用户。
特定于网站的信息中心设置
如果数据不需要跨多个网站共享,请考虑使用 CHIPS 对 Cookie 进行分区。CHIPS 非常适合存储网站专用偏好设置,例如信息中心布局或过滤条件。
管理付款方式
另一种常见流程是,用户无需离开托管网站,即可在嵌入式页面中查看和修改其付款方式。
请考虑以下流程:
payments.example
提供可嵌入网站上的付款管理工具。此服务会存储用户付款数据和会话信息。shop.example
是一个嵌入了payments.example
工具的网站,可让用户查看、修改或选择与其shop.example
账号关联的首选付款方式。
实现付款方式管理的付款服务提供商还应考虑成为 FedCM 身份提供方。借助 FedCM,用户将能够使用由身份提供方 (payments.example
) 管理的账号登录依赖方 (shop.example
)。
在用户授权的情况下,FedCM 允许在依赖方和身份提供程序之间共享自定义数据。使用 FedCM 的主要优势在于,界面可以为用户提供更多背景信息,帮助他们做出选择。它还充当 Storage Access API 的信任信号,允许嵌入内容访问其顶级 Cookie。
停用第三方 Cookie 后,payments.example
嵌入内容将无法访问其顶级 Cookie。在这种情况下,SAA 可以通过请求存储空间访问权限来帮助确保正常运行。
有时,嵌入内容中设置的信息不需要在其他嵌入网站中共享。payments.example
可能只需针对每个特定嵌入网站存储不同的用户偏好设置。在这种情况下,请考虑使用 CHIPS 对 Cookie 进行分区。使用 CHIPS 时,嵌入在 shop.example
上的 payments.example
中设置的 Cookie 将无法被嵌入在 another-shop.example
上的 payments.example
访问。
另一个可能在此用户体验流程中使用的实验性 API 是分区弹出式窗口。当用户在由 shop.example
打开的弹出式窗口中登录 payments.example
时,存储空间将由打开者分区,并且 payments.example
嵌入内容将能够访问在弹出式窗口中设置的存储空间值。不过,这种方法要求用户在每个网站上输入凭据才能登录付款服务提供商。
欺诈检测
风险分析系统可以分析存储在 Cookie 中的数据,以识别偏离常规的模式。例如,如果用户突然更改送货地址,并使用新设备进行多次大额购买交易,则潜在欺诈得分可能会增加。欺诈检测 Cookie 通常是第三方 Cookie,由付款服务提供商或欺诈防范服务 widget 在商家网站上设置。
虽然第三方 Cookie 限制不应破坏欺诈检测系统,但可能会给用户带来额外的麻烦。如果系统因 Cookie 被屏蔽而无法确信用户是否合法,则可能需要进行额外检查,例如完成身份验证。
如需在第三方 Cookie 被屏蔽后支持欺诈检测,不妨考虑将 Private State Tokens (PST) API 集成到您的欺诈检测解决方案中。借助 PST,付款服务提供商可以注册为令牌颁发方,并向用户授予不依赖于第三方 Cookie 的令牌。然后,这些令牌可在商家网站上兑换,以便检查用户是否可信。如需了解实现详情,请参阅 PST 开发者文档。
Privacy Sandbox 正在尝试使用其他反欺诈 API。
个性化结账按钮
商家网站上嵌入的付款按钮(例如使用 <首选付款方式> 付款)通常依赖于付款服务提供商设置的跨网站信息。这样一来,系统便可实现个性化设置,用户可以使用首选付款方式畅享顺畅的结账体验。如果用户的浏览器中屏蔽了第三方 Cookie,这可能会影响个性化付款按钮的呈现。
虽然 SAA 可以允许存储空间访问权限,但所需的提示可能无法带来理想的用户体验。
我们正在探索专门针对此用例的潜在解决方案:具有本地未分区数据访问权限的围栏帧。该 API 目前处于积极开发阶段,您可以参与其未来发展。亲自试用并提供反馈。
获取帮助
请通过 goo.gle/report-3pc-broken 报告您遇到的所有故障。您还可以提交反馈表单,或在 GitHub Privacy Sandbox 开发者支持代码库中提交问题。