由 Chrome 協助進行測試

為因應第三方 Cookie 的淘汰情況，我們將提供 Chrome 輔助測試模式，讓網站可預覽網站行為和功能在沒有第三方 Cookie 的情況下的運作方式。本指南概略說明 Chrome 計畫提供的測試模式，以及如何存取實驗群組標籤。

在此情況下，Chrome 瀏覽器是指 Chrome 用戶端：裝置上安裝的 Chrome。每個個別使用者的資料目錄都會構成一個不同的用戶端。

實驗群組：一組啟用、停用或設定特定功能的 Chrome 瀏覽器。在透過 Chrome 協助測試的情況下，一組已設定標籤的瀏覽器。

標籤：在這個情境中，為屬於實驗群組的瀏覽器設定的要求標頭值。在 Chrome 協助進行測試期間，實驗群組中的每個瀏覽器都會保留在該群組中，以確保所有測試人員的瀏覽器標籤都會保持一致。

注意： 這項測試著重於評估 Privacy Sandbox 關聯性和評估 API (PS R&M API) 的成效：Attribution Reporting、Protected Audience、Topics、私密匯總、Shared Storage 和 Fenced Frames。

我們提供兩種不同的模式：

• 模式 A：自 2023 年 11 月起，測試 PS R&M API 的機構可以選擇在部分 Chrome 瀏覽器中接收一致的標籤，以便協調不同的測試人員進行測試。
• 模式 B：自 2024 年 1 月 4 日起，Chrome 已全面停用 Chrome 瀏覽器的一部分第三方 Cookie。

這兩種模式至少會持續到 2025 年初。第三方 Cookie 在模式 B 中停用的情況下，在整個逐步淘汰第三方 Cookie 之前，都會維持停用狀態。

我們與 CMA 合作，確保這些測試模式符合第三方的測試架構 (和時間表)，如業界測試指南所述。因此，CMA 預期這些模式的測試結果可用於評估 Privacy Sandbox。CMA 指出他們可能在實驗性設計 2 上更加投入結果，後者使用模式 B 標籤和模式 A 控制項 1 標籤。如要進一步瞭解實驗性設計 2，請參閱 CMA 的 10 月 26 日指南。

注意： 您可透過暫時 Cookie 淘汰值取得標籤，您可以透過 HTTP 標頭或 JavaScript API 存取該值。如需導入詳細資料，請參閱後續章節「透過 Cookie 淘汰值存取標籤」。

我們也會透過一般的 Blink 開發程序傳送這項提案，最終將確定技術設計和 Chrome 發布里程碑。雖然這是我們要發布的實作內容，但經過額外討論和核准之後，這些細節仍可能會有所異動。隨著計畫的進行，我們會持續更新這個頁面。您也可以繼續提供意見回饋或問題。

模式 A：已加上標籤的瀏覽器群組

參與測試的機構可以選擇接收部分 Chrome 瀏覽器的永久標籤組合，以便針對同一組瀏覽器上不同廣告技術人員進行實驗。舉例來說，如果瀏覽器屬於 label_only_3 實驗群組 (如下表所示)，所有參與的廣告技術都能看到相同的 label_only_3 標籤，並據此進行協調：使用 PS R&M API，但避免使用第三方 Cookie。我們預期網頁上的參與者會確保標籤轉寄給其他參與者，以便在廣告選擇和評估的整個過程中進行一致的實驗。

舉例來說，這可讓多個參與者在一致的瀏覽器群組中，不必使用第三方 Cookie 就能執行 Protected Audience 競價。競價賣方參與者會將觀察到的標籤轉寄給買方，以便協調測試。

標籤不會影響這些 Chrome 執行個體中的任何功能，包括第三方 Cookie 的可用性。標籤可為獨立且共同的實驗提供分組，但必須由參與方強制執行實驗的相關參數。如果您要測試移除第三方 Cookie 的影響，則每個參與者都必須負責為具有該標籤的瀏覽器排除第三方 Cookie 資料。

目的是建立代表正常 Chrome 流量的群組。也就是說，您應能使用第三方 Cookie 和 PS R&M API，不過部分使用者可能會透過設定或擴充功能變更或停用功能。

標籤在 Chrome 的瀏覽工作階段和跨工作階段通常會保持不變。不過在極少數的情況下，如果完全重設瀏覽器，目前的標籤也可能會重設，因此不保證會發生這種情況。

我們計劃在模式 A 納入 8.5% 的 Chrome 穩定版瀏覽器，而且最初的提案將人口分成 9 個群組。較小的子群組可讓廣告技術靈活組合標籤，建立不同大小的實驗。群組不會重疊。

請注意，control_1.* 標籤會依照 CMA 產業測試指南中所述的「Control 1」，因此測試參與者不得使用 Topics API，或針對此流量執行 Protected Audiences 競價。由於標籤不會影響功能，因此參與者在偵測到 control_1.* 群組標籤時，不應傳遞觀察到的主題或執行 Protected Audience 競價。

歡迎您向意見回饋，確認所選群組是否符合參與機構的需求。

標籤	穩定流量百分比
control_1.1	0.25
control_1.2	0.25
control_1.3	0.25
control_1.4	0.25
label_only_1	1.5
label_only_2	1.5
label_only_3	1.5
label_only_4	1.5
label_only_5	1.5

模式 A label_only_ 瀏覽器群組自 2023 年 11 月起開放使用，模式 A control_1_* 群組也從 2024 年 1 月 4 日起開放使用。我們將繼續傳送所有模式 A 和模式 B 標籤，直到 2025 年初第三方 Cookie 逐步淘汰為止。

模式 B：停用 1% 的第三方 Cookie

自 2024 年 1 月 4 日起，Chrome 已為大約 1% 的 Chrome 穩定版瀏覽器停用第三方 Cookie (以及 2023 年第 4 季的開發人員版、Canary 及 Beta 版瀏覽器)。測試 PS R&M API 的機構不需要選擇採用這個模式，因為這個模式會統一套用到整個瀏覽器人口。當然，如果網站尚未採用替代解決方案 (例如 CHIPS 或相關網站集)，也可能會對某些網站功能造成影響。

注意： 如果您的網站功能需要使用第三方 Cookie 資料，請參閱這份指南來做好逐步淘汰第三方 Cookie 的準備，瞭解 CHIPS 或相關網站集是否能夠滿足您的需求。我們已推出公開 Issue Tracker，方便您回報淘汰第三方 Cookie 造成的網站問題。我們正努力解決各種問題，以便偵測及處理影響使用者體驗的問題，並主動通知網站擁有者。

此外，我們計畫在模式 B 中只提供一小部分的流量，而該模式已停用 PS R&M API。其他 API (例如相關網站集、CHIPS 和 FedCM) 不會停用。我們預期這個組合有助於在沒有第三方 Cookie 和沒有 PS R&M API 的瀏覽器下，確立效能基準。

在模式 B 中，我們也會為受影響的瀏覽器提供標籤。標籤在 API 停用後即可一併使用。建議您將人口分成三個停用第三方 Cookie (但可使用 PS R&M API) 的 treatment_1.* 群組，以及一個停用第三方 Cookie 和 PS R&M API 的 control_2 群組。

為協助對 Attribution Reporting API 和 Private Aggregation API 整合進行偵錯，並協助測試參與者進一步瞭解雜訊影響，只要使用者未明確封鎖第三方 Cookie，那麼處於模式 B 的瀏覽器上仍可使用 ARA 偵錯報表和私人匯總偵錯報表。control_2 中不會提供偵錯報表，因為該片段中不提供 PS R&M API。但隨著第三方 Cookie 逐步淘汰，偵錯報表仍會逐步淘汰。

• 對於 Attribution Reporting API，由於第三方 Cookie 已停用，報表來源將無法設定 ar_debug Cookie，且應依據設定 debug_key 欄位 (用於歸因成功報表) 和 debug_reporting 欄位 (適用於詳細報表) 選擇是否啟用/停用偵錯報表。
• 針對 Private Aggregation API，報表來源應透過呼叫 enableDebugMode() 來控制選擇接收偵錯報表。公司應持續考量在使用 Attribution Reporting API 和 Private Aggregation API 時可能出現的法規義務，包括偵錯報表。

模式 A 會持續執行，且這些群組與模式 A 的群組不同，因為使用者在模式 A、模式 B 或兩者皆非。測試參與者應使用 control_1.* 流量做為控制組，透過第三方 Cookie 表示狀態。

標籤	穩定流量百分比
treatment_1.1	0.25
treatment_1.2	0.25
treatment_1.3	0.25
control_2	0.25

Chrome 也限制了 20% Chrome Canary、開發人員和 Beta 版用戶端的 Cookie。

標籤	預先穩定流量百分比
prestable_treatment_1	10%
prestable_control_2	10%

將其中一個實驗組納入實驗，效果與對等組合的效果相同。

與模式 A 一樣，無法保證 PS R&M API 可供使用，因為使用者可以在 Chrome 的「隱私權和安全性」設定中停用 API。同樣地，我們也不保證會為 control_2 群組中的所有成員停用第三方 Cookie，因為使用者可能會存取瀏覽器 UI，允許網站的第三方 Cookie。

實驗監控

請務必監控每個實驗組和控制項標籤的相對流量。treatment_1.1 的流量應與 treatment_1.2 和 treatment_1.3 大致相同。

對於含有標籤的流量 (來自 120 以下版本的 Chrome 版本)，建議您自行斟酌。如果您的團隊通常會處理無效流量，並發現含有無效流量特性的使用者代理程式，您就可以將這類代理程式從測試結果中排除。

前期標籤

直到 2024 年 1 月為止，我們針對多個實驗組執行了前置期，也就是讓 Chrome 能夠準確調整大小，並選取統計上的不偏誤群組。排定在 1 月開始的所有分支，都會執行這些前置期：模式 B 和 Control_1* 實驗組。您不需要在這裡執行任何開發人員或網站操作 (這些前期實驗組不會受到任何行為或 API 可用性變更)，但在某些情況下，您可能會看到系統傳回的 preperiod 標籤。雖然收到 preperiod 標籤的瀏覽器可能會改用其中一個實驗群組，但不保證一定能轉換，因此建議您不要假設具備此標籤的瀏覽器一定會參與實驗。

實驗組是受研究的人口子集：在此案例中，就是其中一個加上標籤的群組。

透過 Cookie 淘汰值存取標籤

在模式 A 和模式 B 的期間，我們將推出透過選擇採用的 HTTP 標頭和 JavaScript API 存取的暫時 Cookie-Deprecation 值，後者可為瀏覽器適用的模式 A 或 B 實驗群組提供標籤 (如上方百分比所定義)。

存取標籤涉及存取使用者裝置上儲存的資訊。在部分管轄區 (例如歐盟和英國)，我們瞭解這類活動與 Cookie 使用相似，因此存取標籤可能需要取得使用者同意。開始要求標籤前，建議您先尋求法律建議，瞭解這項同意聲明義務是否適用於您。

注意： 如同 Chromium 中搭載的所有功能，我們已在 Blink 開發程序中將 Intent 傳送至 Prototype (I2P)。以下實作詳情是我們建議的實作方式，但在 Chrome 穩定版推出這項功能之前，這些細節可能會有所變動。我們也會持續更新這份說明文件。您也可以在 Intent 發布至 blink-dev 郵寄清單中，追蹤公開討論內容。

存取 Sec-Cookie-Deprecation HTTP 標頭

網站必須先設定 receive-cookie-deprecation Cookie，才能接收 Sec-Cookie-Deprecation 要求標頭。此 Cookie 必須使用 Partitioned 屬性，這表示您必須根據個別頂層網站選擇加入，才能接收標頭。

舉例來說，如果 3p-example.site 想要接收 example.com 中內嵌資源的 Sec-Cookie-Deprecation 標頭，則 3p-example.site 必須在該結構定義中設定下列 Cookie。

Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned;  Max-Age=15552000

Secure、HttpOnly、SameSite 和 Partitioned Cookie 屬性為必要屬性。其他屬性：Domain、Path、Expires 和 Max-Age 可能會符合您的需求，但 Path=/ 是不錯的預設值。此處的範例會設定 Max-Age=15552000，讓 Cookie 不會在 180 天後過期。

建議您在 Chrome 帶領的測試期開始前，開始設定 receive-cookie-deprecation=1 Cookie，確保實驗群組中的瀏覽器在取得 Sec-Cookie-Deprecation 要求標頭時可立即納入。

舉例來說，假設瀏覽器在 example_label_1 群組中，則包含此 Cookie 的後續要求也會納入 Sec-Cookie-Deprecation 標頭。

Sec-Cookie-Deprecation: example_label_1

如果瀏覽器不屬於任何群組，系統就不會傳送標頭。 標籤與 Cookie 有關聯，因此如果特定網站的 Cookie 遭到刪除、遭封鎖或封鎖，系統不會傳送標籤。由於 Partitioned 屬性會在第三方 Cookie 完全淘汰後繼續使用，這表示在第三方 Cookie 遭封鎖的情況下，系統可能會設定 Partitioned Cookie。

存取 cookieDeprecationLabel JavaScript API

您也可以透過 navigator.cookieDeprecationLabel.getValue() JavaScript API 存取 Cookie-Deprecation 值。這會傳回承諾，可解析為包含適用群組標籤的字串。舉例來說，如果瀏覽器位於 example_label_1 群組：

// Feature detect temporary API first
if ('cookieDeprecationLabel' in navigator) {
 // Request value and resolve promise
 navigator.cookieDeprecationLabel.getValue().then((label) => {
   console.log(label);
   // Expected output: "example_label_1"
 });
}

如果瀏覽器不屬於任何群組，則該 API 將無法使用，或者值為空白字串，因此請務必執行功能偵測。

無論是否有 receive-cookie-deprecation Cookie，都有可能呼叫 JavaScript API。不過，如果 Cookie 完全遭到封鎖或專門針對網站遭到封鎖，API 就會再次無法使用或傳回空白字串。

和用戶端提供的值一樣，使用前請務必先清理及驗證標頭或 JavaScript API 中的值。

示範與測試

從 Chrome 120 以上版本開始，就能使用標記讓本機開發人員測試要求及讀取標籤。

chrome://flags/#tpc-phase-out-facilitated-testing 標記可讓您啟用一組測試標籤。這些標籤前面會加上 fake_，以便與實際標籤區分。啟用旗標不會讓瀏覽器加入任何實驗群組。

您可以透過 goo.gle/cft-demo 查看標籤的實際運作情形。

由於系統會強制註冊 Privacy Sandbox 關聯性和評估 API，因此您可能需要使用 chrome://flags/#privacy-sandbox-enrollment-overrides 並提供示範來源，覆寫本機測試的強制執行。如果您是透過終端機執行 Chrome，也可以加入以下指令列標記： --args --disable-features=EnforcePrivacySandboxAttestations

旗標下拉式選單包含多個選項。測試人員會特別關注標示為「Force」的項目，確保無論其他裝置設定為何，系統都會啟用實驗行為。

如果只要測試實驗群組標籤，請選取「已啟用的強制控制 1」或「已啟用的強制標籤僅限模式」。這樣瀏覽器就會傳送「fake_control_1.1」或「fake_label_only_1.1」標籤。

在 Chrome M120 以上版本中，您也可以使用下列項目。

如要測試第三方 Cookie 封鎖功能，請選取「啟用強制處理方式」。這項操作會傳送「fake_treatment_1.1」實驗群組標籤，但也會修改 Cookie 設定頁面和目前的 Cookie 設定來封鎖第三方 Cookie。

如要測試沒有私人廣告 API 的第三方 Cookie 封鎖，請選取「Force Control 2」。這項操作會傳送「fake_control_2」實驗群組標籤、更新 Cookie 設定頁面、封鎖第三方 Cookie，並封鎖新的私密廣告 API。

請注意，目前瀏覽器會一直顯示新的 Cookie 設定頁面，而即使停用這個標記，瀏覽器仍會顯示封鎖第三方 Cookie 的設定。我們正在修正這個問題，但在此期間，您可以使用 --user-data-dir=<new dir> 指令列標記啟動 Chrome，即可在獨立的 Chrome 資料目錄中測試這些旗標值。

意見回饋：

我們在 GitHub 上，使用開發人員支援存放區中的「chrome-testing"」標籤來管理問題。歡迎您針對以下初期問題提供意見回饋並討論：

• 您打算使用模式 A 和/或模式 B 進行測試嗎？
• 選擇標籤大小，用於 Chrome 協助的測試
• 使用用戶端提示進行 Chrome 協助測試

此外，您也可以使用「由 Chrome 輔助測試」範本，在存放區中提出新的問題或討論。