由 Chrome 協助進行測試

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

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

實驗群組：一組會啟用、停用或設定特定功能的 Chrome 瀏覽器。在 Chrome 輔助的測試中，一組已設定標籤的瀏覽器。

標籤：這裡是針對屬於實驗群組的瀏覽器設定的要求標頭值。在由 Chrome 協助執行的測試期間，實驗組中的每個瀏覽器都會保留在該群組中，確保每位測試人員使用的瀏覽器標籤都保持一致。

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

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

如果第三方 Cookie 在模式 B 中停用，則系統會在全面淘汰第三方 Cookie 的整個階段繼續停用 Cookie。

我們與 CMA 合作，確保這些測試模式符合第三方的測試架構和時程，如產業測試指南所述。因此，CMA 預期在這些模式下的測試結果中，可以用來評估 Privacy Sandbox。CMA 表示，他們可能會增加實驗設計 2 結果的權重，因為實驗性設計 2 使用模式 B 標籤和模式 A 控制項 1 標籤。如要進一步瞭解實驗設計 2，請參閱 CMA 的 10 月 26 日指南。

您可以使用 HTTP 標頭或 JavaScript API 提供的臨時 Cookie-Deprecation 值來存取標籤。如需詳細實作資訊，請參閱下一節的「使用 Cookie 淘汰值存取標籤」一節。

我們也會透過一般的 Blink 開發程序傳送這份提案，在技術設計和 Chrome 發布里程碑定案。雖然這是我們要發布的實作項目，但其他討論和核准仍表示這些細節可能隨時變動。我們會隨著計畫進度持續更新本頁面，您也可以繼續提供意見或提出問題。

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

參與測試的機構可以選擇對部分 Chrome 瀏覽器接收一組永久性的標籤，這樣就能使用同一組瀏覽器，跨不同廣告技術進行協調實驗。例如，如果瀏覽器屬於 label_only_3 實驗群組 (如下表所示)，則參與的所有廣告技術都能看到相同的 label_only_3 標籤，並據此協調：使用 PSR&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 業界測試指南所述的「控制組 1」，因此測試參與者不應使用 Topics API，或針對這類流量執行 Protected Audience 競價。由於標籤不會影響瀏覽器行為，因此參與者不應在偵測到 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

模式 label_only_ 瀏覽器群組已於 2023 年 11 月推出，模式 A control_1_* 群組自 2024 年 1 月 4 日起可供使用。

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

自 2024 年 1 月 4 日起，Chrome 已為 Chrome 穩定版瀏覽器停用約 1% 的第三方 Cookie (在 2023 年第 4 季期間，也在開發版、Canary 版和 Beta 版瀏覽器中也同樣停用)。測試 PS R&M API 的機構無須選擇啟用這個模式，因為系統會在整個瀏覽器填入中統一套用該模式。當然，如果網站尚未採用替代解決方案 (例如 CHIPS 或相關網站集)，有些網站功能可能會受到影響。

此外，我們計劃在停用 PS R&M API 的模式 B 中，提供一小部分流量。系統不會停用相關網站集、CHIPS 和 FedCM 等其他 API。我們預期這個組合有助於針對沒有第三方 Cookie 和未使用 PS R&M API 的瀏覽器建立效能基準。

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

為協助對 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。同樣地，由於使用者可能會存取瀏覽器 UI，允許網站使用第三方 Cookie，因此我們也不保證 control_2 群組中所有成員都會停用第三方 Cookie。

實驗監控

請務必監控每個實驗組和控制組標籤的相對流量。treatment_1.1 的流量應與 treatment_1.2 和 treatment_1.3 差不多。

如果流量包含來自 Chrome 120 以下版本的 Chrome，建議您自行斟酌。如果您的團隊通常會處理無效流量，找出出現無效流量特性的使用者代理程式，就可以從測試結果中篩除這類使用者代理程式。

放送前期間標籤

在 2024 年 1 月之前，我們針對多個實驗組進行了實驗前的測試，也就是讓 Chrome 準確調整大小並選取不具統計顯著性的群組。系統會對 1 月排定開始的所有實驗組執行這些前期：模式 B 實驗組和 Control_1.* 實驗組。您不需要針對開發人員或網站採取行動，這些前期實驗組不會影響行為或 API 可用性，但請注意，在某些情況下，系統可能會傳回 preperiod 標籤。雖然收到 preperiod 標籤的瀏覽器可能會轉換為實驗群組，但這並非保證變更，因此建議您假定有此標籤的瀏覽器一定會出現在實驗中。

「實驗組」是受研究對象的子集，在本例中是其中一個已加上標籤的群組。

使用 Cookie 淘汰值存取標籤

在模式 A 和模式 B 中，我們推出可透過選用 HTTP 標頭和 JavaScript API 存取的臨時 Cookie-Deprecation 值，如果屬於上述模式的某個模式 A 或 B 實驗群組，則可為瀏覽器適用的模式 A 或 B 實驗群組提供標籤 (如上方百分比定義)。

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

存取 Sec-Cookie-Deprecation HTTP 標頭

如要接收 Sec-Cookie-Deprecation 要求標頭，網站必須先設定 receive-cookie-deprecation Cookie。這個 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」的項目主要是對測試人員感興趣，因為這些措施可確保無論其他裝置設定為何，都會啟用實驗行為。

如果只要測試實驗群組標籤，請選取「Enabled Force Control 1」或「Enabled Force LabelOnly」。這些會導致瀏覽器傳送「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。我們正在設法修正這個問題，與此同時，您可以啟動 Chrome 並加上 --user-data-dir=<new dir> 指令列標記，在個別 Chrome 資料目錄中測試這些標記值。

意見回饋：

在 GitHub 上的開發人員支援存放區中，我們會使用 chrome-testing 標籤來管理問題。歡迎您針對初始問題提供意見和討論：

• 要使用模式 A 和/或模式 B 進行測試嗎？
• 為 Chrome 輔助測試選擇標籤大小
• 使用用戶端提示進行 Chrome 輔助的測試

您也可以利用「由 Chrome 協助執行的測試」範本，在存放區中提出新問題或討論。