第三方 Cookie 可能会因浏览器限制、用户设置、开发者标志或企业政策而被屏蔽。
您需要确保您的网站或服务无论是否使用第三方 Cookie，都能为所有用户提供出色的体验。
此页面包含有关在第三方 Cookie 被屏蔽的情况下可能会受到影响的常见用户历程的信息。
常见用户体验历程
许多付款和购物工作流程都依赖于第三方 Cookie。下表列出了一些在停用第三方 Cookie 后可能会受到影响的用户历程，并建议了开发者可以使用的替代 API，以避免出现中断。此列表可能并不详尽，并且可能会随着更多 Privacy Sandbox 解决方案的推出而更新。
测试与付款相关的用户历程
测试用户流程是否会受到第三方 Cookie 限制的最佳方法是，在启用第三方 Cookie 测试标志的情况下完成这些流程。
为确保您的网站按预期运行，请在限制第三方 Cookie 的情况下测试以下流程：
- 跨网站结账：测试依赖于第三方付款服务提供商（例如使用 <example-provider> 付款）的付款流程。确保：
- 重定向成功。
- 支付网关已正确加载。
- 付款流程可以顺利完成。
- 用户会按预期重定向回您的网站。
- 付款信息中心：测试交易信息中心 widget 在第三方 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嵌入在五个以上相关网站中。
FedCM 的主要优势在于，界面可以为用户提供更多有关其选择的背景信息。在获得用户许可后，FedCM 允许在信赖方 (merchant.example) 和身份提供方 (payment-provider.example) 之间共享自定义数据。信赖方可以选择支持一个或多个身份提供方，并且 FedCM 界面仅在有条件的情况下显示。
开发者可以根据需要选择 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 以获得更自定义的体验。
减少少量相关网站上的用户摩擦
如果商家网站和付款服务提供商都属于同一家公司，您可以使用 Related Website Sets (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 个网站，即 1 个主要网站和 5 个关联网站。
大规模分发信息中心
- 您为第三方网站分发信息中心解决方案。
- 有超过 5 个网站嵌入了您的信息中心 widget。
在这种情况下，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 目前正处于积极开发阶段，您可以参与塑造其未来。 欢迎亲自试用并提供反馈。
帮助和反馈
如果您对本指南中介绍的用户体验历程或 API 有任何疑问或反馈，可以分享您的反馈。