Tray 處理第三方 Cookie 異動的方式

Tray 是電子商務內容管理系統 (CMS) 供應商，在巴西零售市場擁有 20 多年的服務經驗。商家可在 Tray's 基礎架構上經營網路商店，該基礎架構也提供服務和整合功能，可用於管理業務物流、付款、促銷活動和報表。

Tray 是 LWSA 群組的成員，也是電子商務領域的推手。Tray 深受超過 180,000 名客戶信賴，這些客戶在 2024 年第一季的 GMV 總額達 30 億美元。

tray.com.br 網站首頁

依賴第三方 Cookie

Tray's 技術架構會使用第三方 Cookie (3PC)，為商家網站提供第三方功能，尤其是商家用於商店管理的後台管理面板。這些 Cookie 對於從第三方應用程式提供的內容 (這些內容託管於商家網域以外的網域) 而言，是呈現內容的必要條件。Tray's 研究顯示，瀏覽器處理 3PC 的方式若有變更，可能會影響這項功能。Tray 是許多線上零售商的重要基礎架構，因此必須確保商家能照常運作，即使 Chrome 和其他瀏覽器處理 3PC 的方式有重大變更也一樣。

本個案研究將介紹 Tray's 發現潛在中斷情形、評估潛在解決方案，以及導入的成功解決方案，確保網站能因應 3PC 的變更。

技術架構

微服務

Tray 會在其網域 tray.com.br 上代管所有商店和後端應用程式，商家可以使用 CNAME 從自訂網域提供這些應用程式。如此一來，購物者只會看到商店的網域，例如 merchant.example。Tray 會運用微服務架構提供功能和能力。這種方法會使用獨立的獨立應用程式，每個應用程式都專注於特定功能。接著，這些微服務會根據功能能力分組為範圍：

  • Store：包含負責商店功能的應用程式，例如產品顯示、搜尋和主題管理。
  • 購買流程：管理購物車、結帳程序，以及購物歷程中的客戶互動。
  • 商店管理：提供後端應用程式，用於處理管理、報表和資料匯入等工作。
  • 整合：協助與外部平台建立連線，以便跨市集刊登商品、管理物流等。

後端應用程式

後勤是商店管理中的核心應用程式，可做為 Tray 上賣家虛擬商店的中央管理控制台。賣家可透過這個面板執行以下操作：

  • 註冊產品
  • 設定運送和付款方式
  • 舉辦宣傳活動
  • 管理直播
  • 監控訂單流程
  • 監控銷售報表

由於 Backoffice 會將許多微服務 (部分由 Tray 營運，部分由第三方營運) 整合至單一介面，因此特別容易受到第三方 Cookie 處理方式變更所造成的服務中斷。

商家自訂的 CNAME

Tray 會使用 CNAME 記錄，讓商店能無縫整合。

設定新商店時，商家可以設定 CNAME，將要求直接導向代管在 Tray's 網域 (Tray's) 上的應用程式，也就是 tray.com.br。也就是說，當顧客造訪商家網站 (例如 example.com) 時，CNAME 記錄會將他們重新導向至 Tray's 網域，同時保留地址列中的商家網址。這樣一來，使用者就能享有流暢的體驗，因為內容會直接從商家網站提供。

瞭解 CNAME

CNAME 記錄的運作方式與電話上的轉接功能類似。假設你撥打 555-0199 給朋友，但對方沒有接聽。系統可能會將來電轉接至其他號碼的語音信箱，例如 555-0100。不過，您 (也就是來電者) 完全不會察覺到這項重新導向。手機會順利連線，語音信箱問候語仍會顯示朋友的原始號碼 (555-0199)。

CNAME 的運作方式與網站相同。當使用者造訪商家的網站 (例如 example.com) 時，CNAME 記錄可能會將使用者的要求重新導向至不同的伺服器 (例如 assets.example.com)。但從使用者和瀏覽器的角度來看，所有動作都會在 example.com 上執行。地址列會顯示商家的網址，使用者與網站互動時，內容會直接來自該網域。

評估潛在中斷情形

Tray's對 3PC 處理方式的變更計畫進行分析後，發現後端辦公室應用程式出現中斷情形。當 3PC 遭到封鎖時，在後端網頁內嵌入的 iframe 中載入不同網域的網頁時，就會發生問題。這項規定適用於屬於公司自有服務的內部網域，以及使用 API 將應用程式整合至 Tray 的協力廠商。

舉例來說，假設 backoffice.merchant.example 上的網頁嵌入由 tray.com.br 和其他第三方代管的內容。由於網域不同，瀏覽器會將這項嵌入內容視為第三方，因此可能會根據任何 3PC 限制限制這項內容。

這種設定可能會導致以下問題：

  • 工作階段中斷：封鎖的 3PC 可能會導致受影響的工作階段中斷，要求使用者多次登入，進而造成使用者體驗不連貫，或是因 iframe 故障而導致後台網頁中斷或出現不一致的情形。
  • 整合挑戰：使用 API 與 Tray's 後端整合的合作夥伴應用程式和內部服務，可能會因 3PC 限制而面臨類似的困難。

下圖說明此情況：

  • 使用者存取 merchant.example 上代管的 Backoffice 應用程式。
  • 嵌入式應用程式位於不同的網域，有些位於 Tray 擁有的 tray.com.br，有些位於第三方供應商網域 (third-party.example)。
  • 這個網域差異會觸發 3PC 限制，可能導致嵌入式應用程式發生問題。
圖表顯示 CNAME 範例：backoffice.merchant.example 的動態小工具會繼承 CNAME，因此所有動態小工具都會與商家網站保持 SameSite

測試關鍵使用者歷程

Tray's 測試和分析的目的在於改善網站效能和使用者體驗，並著重於第三方整合，為未來許多使用者不使用 3PC 瀏覽網站做好準備。

Tray 使用 Privacy Sandbox 分析工具 (PSAT) 和 Chrome 開發人員工具，分析客戶和商家的關鍵使用者流程。這項測試包括在 iframe 中測試網頁載入情形、檢查使用者工作階段是否仍有效，以及確保第三方應用程式繼續正常運作。測試涵蓋各種使用者角色、裝置和瀏覽器 (包括 Chrome、Firefox 和 Safari)，以找出潛在的跨瀏覽器相容性問題。Tray 使用 PSAT 和 Chrome 開發人員工具，將 Cookie 分類並評估其對使用者體驗的影響。

這項分析是確保順暢一致的使用者體驗，並適應第三方 Cookie 可能受限或無法使用的未來環境的重要步驟。

分析 Privacy Sandbox 解決方案

儲存空間存取權 API

雖然 Storage Access API (SAA) 可能可以解決 Tray's 中斷問題，且所有主要瀏覽器都支援這項 API，但這項 API 不適合用於商家，主要有兩個原因：

  1. 嵌入內容只需要存取嵌入來源的 Cookie，而不需要跨多個網站存取相同的 Cookie。
  2. 與 SAA 相關的瀏覽器提示並不理想，尤其是因為 Cookie 並未用於追蹤不同網站的使用者。

CHIPS

CHIPS 提供了強大的解決方案，為跨網站嵌入提供優異的使用者體驗。Partitioned 屬性實作起來相當簡單，對 Chrome 使用者的使用者互動並未造成明顯影響。Tray 在調整服務時，其他主要瀏覽器不支援 CHIPS，因此他們選擇將自有嵌入內容移至與頂層應用程式相同的網站，以便在各瀏覽器中提供一致的體驗。第三方嵌入內容會依賴 Chrome 中的 CHIPS，並在其他瀏覽器中開啟新視窗 (第一方內容)。不過，自 Tray's 初始實作以來，Firefox 已確認即將推出 CHIPS 的計畫，而 Safari 也已開始新增對 Partitioned 屬性的支援，從技術預覽版開始。

我們認為 CHIPS 是個完美的解決方案，很高興看到它在多個瀏覽器中採用。除了將內容移至第一方網站，我們也決定保留 CHIPS 解決方案，這樣一來，即使瀏覽器尚未採用 CHIPS，我們也能支援所有瀏覽器。

— Tray 技術長 Takashi Tanaka

瀏覽器相容性、W3C 和標準

Chrome 在標準社群中扮演著關鍵角色。積極參與 W3C 工作小組和社群小組 (例如 PrivacyCG)，對於影響更廣泛的瀏覽器生態系統採用新網路技術至關重要。

Privacy Sandbox 與網路生態系統合作，根據業界意見回饋和參與度，持續改進 CHIPS 等 API。這種透明且以標準為導向的方法，對於推動其他主要瀏覽器採用 CHIPS 至關重要。

Tray 支援所有類型的裝置和瀏覽器，為商家和其客戶提供服務。我們原本偏好採用完全以 CHIPS 為基礎的方法，但也做出了其他變更，以便支援當時不支援 CHIPS 的其他瀏覽器。

Tray's 解決方案可解決 3PC 無法使用時造成的服務中斷問題，其中涉及兩項主要策略。

1. 內部應用程式

我們更新了全代管的 Tray 微服務 (包括直播商店、直購服務和發票核發者)，讓嵌入內容的來源繼承商家設定的 CNAME。簡單來說，嵌入內容已更新為第一方，並嵌入該網頁，確保不會因第三方 Cookie 變更而中斷。

2. 第三方應用程式

針對透過後端辦公室存取的第三方應用程式，Tray導入了更具彈性的做法。運作方式如下：

  • 分割屬性實作：Partitioned Cookie 屬性實作已為信任的供應商維護，讓第三方應用程式可在支援 CHIPS 的瀏覽器上有效設定 Cookie。
  • 第三方 Cookie 遭封鎖時：如果使用者的瀏覽器封鎖 3PC，第三方應用程式會在新 (第一方) 視窗中開啟。這樣一來，即使有 3PC 限制，也能避免發生開啟問題，並確保持續運作。
  • 允許第三方 Cookie 時：如果使用者的瀏覽器允許 3PC，應用程式會繼續在 iframe 內開啟，就像先前一樣。

將解決方案視覺化

下圖說明瞭解決方案。繼承商店的主要網域 (merchant.example) 後，所有嵌入式應用程式都會顯示為來自相同來源。這樣一來，所有小工具都會彼此視為第一方，也就是說，3PC 限制不會是影響因素。由於所有這些框架都會彼此成為第一方，隱私權原則會採用其他第一方 Cookie 的原則：這些 Cookie 只能在第一方內容中存取，並限制跨網站追蹤的可能性。

任何非 Tray 擁有的第三方服務都會使用 Partitioned 屬性設定 CHIPS Cookie，也就是說，這些 Cookie 只能在設定 Cookie 的環境中存取，並限制跨網站追蹤的可能性。

圖表顯示 CHIPS 範例：移至第一方網域的小工具可以存取第一方 Cookie 罐；第三方小工具則使用分割的 Cookie 罐。

結論

  • 網路上的隱私權解決方案並沒有一體適用的解決方案，但您可以透過許多方式，在保護隱私權的同時，提供流暢的使用者體驗。
  • 將資源整合至相同的頂層網域，即使有第三方 Cookie 限制，Cookie 也能正常運作。
  • 與將所有資源遷移至同一個頂層網站相比，CHIPS 可能更容易實作。
  • Tray's 解決方案可靠且可跨瀏覽器運作。隨著更多瀏覽器實作對 CHIPS 的支援，在 Tray's 等情境中，這可以視為可靠的跨瀏覽器解決方案。