第三方 Cookie 可能會因瀏覽器限制、使用者設定、開發人員標記或企業政策而遭到封鎖。
無論是否使用第三方 Cookie，您都必須確保網站或服務能為所有使用者提供良好的體驗。
本頁面提供資訊，說明在封鎖第三方 Cookie 時，可能會受到影響的常見使用者歷程。
常見的使用者歷程
許多付款和購物工作流程都需要第三方 Cookie。下表列出在停用第三方 Cookie 後可能受到影響的部分使用者歷程，並建議開發人員可使用的其他 API，以免造成服務中斷。這份清單並未包含完整內容，我們會在推出更多 Privacy Sandbox 解決方案時加以更新。如果您遇到其他受影響的情況，歡迎提供意見回饋。
測試付款相關使用者歷程
如要測試您的使用者流程是否受到第三方 Cookie 限制的影響，最好的方法就是啟用第三方 Cookie 測試標記，並在啟用後進行測試。
為確保網站能正常運作，請在限制第三方 Cookie 的情況下測試下列流程：
- 跨網站結帳：測試仰賴第三方付款供應商 (例如「Pay with <example-provider>」) 的付款流程。請確認：
- 重新導向成功。
- 付款閘道載入正確。
- 付款程序可順利完成，且不會發生任何錯誤。
- 使用者會如預期重新導向至您的網站。
- 付款資訊主頁：測試交易資訊主頁小工具在限制第三方 Cookie 的情況下是否能正常運作。確認使用者可以：
- 前往資訊主頁。
- 查看所有預期的付款。
- 在資訊主頁的不同部分 (例如交易記錄、付款詳細資料) 之間瀏覽時，不會發生錯誤。
- 管理付款方式：測試付款方式管理小工具是否正常運作。在封鎖第三方 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 UI 只會依條件顯示。
視需求而定，開發人員可以選擇使用被動模式，讓 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 時要求儲存空間存取權，payment-portal-insurance.example 就會自動取得自身頂層 Cookie 的存取權。
其他實驗性質的解決方案
在這種情況下，分區彈出式視窗是另一個可能有用的實驗性 API。這個 API 目前處於開發階段。
使用 Partitioned Popins 時，系統會要求使用者輸入憑證，以便在 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提供可嵌入各種網路應用程式的付款資訊主頁。這項服務會儲存使用者收益資料和工作階段資訊。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。如果此方在四個或更少的網域中使用 earnings.example，則透過 RWS 宣告這些網域之間的關係，可提供更順暢的使用者體驗。
如果同一個使用者在五個以上網域上嵌入小工具，就無法宣告所有嵌入網站與小工具網域之間的關係，因為 RWS 最多只支援集合中的六個網站，包括一個主要網站和五個相關網站。
可調式資訊主頁分發
- 您為第三方網站發布資訊主頁解決方案。
- 您有超過五個嵌入資訊主頁小工具的網站。
在這種情況下，earnings.example 應考慮實作 FedCM，以便擔任身分識別資訊提供者的角色。也就是說，使用者必須使用由 earnings.example 管理的帳戶登入 dogsitting.example。
FedCM 提供可自訂的 UI，可清楚向使用者說明要共用哪些資訊。透過 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，使用者就能使用由 Identity Provider (payments.example) 管理的帳戶登入依賴方 (shop.example)。
在取得使用者同意後，FedCM 可讓依賴方和 ID 提供者之間共用自訂資料。使用 FedCM 的主要優點是，使用者介面可為使用者提供更多選擇的背景資訊。這也能做為 Storage Access API 的信任訊號，讓內嵌內容存取頂層 Cookie。
停用第三方 Cookie 後，payments.example 嵌入項目就無法存取頂層 Cookie。在這種情況下，SAA 可要求存取儲存空間，確保應用程式正常運作。
有時嵌入內容中的資訊不需要與其他嵌入網站共用。payments.example 可能只需要為每個特定嵌入網站儲存不同的使用者偏好設定。在這種情況下，建議您使用 CHIPS 分割 Cookie。使用 CHIPS 時，payments.example 在 shop.example 上嵌入的 Cookie 設定無法由 payments.example 在 another-shop.example 上嵌入。
另一個可在這個使用者流程中使用的實驗 API 是分割式彈出式視窗。當使用者在 shop.example 開啟的彈出式視窗中登入 payments.example 時，儲存空間會由開啟者分割，payments.example 嵌入項目將可存取彈出式視窗中設定的儲存空間值。不過，這種做法會要求使用者在每個網站上輸入憑證，才能登入付款服務供應商。
詐欺偵測
風險分析系統可分析儲存在 Cookie 中的資料，找出與常態不同的模式。舉例來說，如果使用者突然變更運送地址，並使用新裝置進行多筆大額購物，潛在詐欺分數就可能會提高。詐欺偵測 Cookie 通常是第三方 Cookie，由付款服務供應商或防詐欺服務小工具在商家網站上設定。
雖然第三方 Cookie 限制不會破壞詐欺偵測系統，但可能會造成額外的使用者摩擦。如果系統因 Cookie 遭到封鎖而無法確實驗證使用者是否合法，可能就需要進行額外檢查，例如完成身分驗證。
如要在封鎖第三方 Cookie 時支援詐欺偵測，請考慮將 Private State Tokens (PST) API 整合至詐欺偵測解決方案。透過 PST，付款服務供應商可以註冊為權杖發行者，並授予不仰賴第三方 Cookie 的使用者權杖。這些權杖可在商家網站上兌換，以便檢查使用者是否可信。如需導入詳細資訊，請參閱 PST 開發人員說明文件。
Privacy Sandbox 正在測試其他防詐 API。
個人化結帳按鈕
商家網站上嵌入的付款按鈕 (例如「使用 <偏好付款方式> 付款」) 通常會依賴付款供應商設定的跨網站資訊。這麼做可實現個人化服務，使用者也能透過偏好的付款方式順利結帳。如果使用者的瀏覽器封鎖第三方 Cookie，可能會影響個人化付款按鈕的顯示方式。
雖然 SAA 可允許存取儲存空間，但必要提示可能無法提供理想的使用者體驗。
我們正在探索專門針對此用途的潛在解決方案：具有本機未分割資料存取權的區隔式 Frame。這個 API 目前處於積極開發階段，您可以塑造其未來。親自試用並提供意見回饋。
取得說明
請將遇到的任何中斷情形回報至 goo.gle/report-3pc-broken。您也可以提交意見回饋表單，或是在 GitHub Privacy Sandbox 開發人員支援存放區中回報問題。