為因應第三方 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
![chrome://flags/#tpc-phase-out-facilitated-testing](https://developers.google.cn/static/privacy-sandbox/assets/images/cft-flag.png?authuser=5&hl=zh-tw)
旗標下拉式選單中包含多個選項。標記為「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 標籤來管理問題。歡迎您針對初始問題提供意見和討論:
您也可以利用「由 Chrome 協助執行的測試」範本,在存放區中提出新問題或討論。