歸因報表提案已進行多項變更 社群意見回饋,包括 API 機制變更和新功能等。
變更記錄
- 2022 年 2 月 7 日:新增標頭觸發條件重新導向一節。
- 2022 年 1 月 27 日:首次發布文章。
這則訊息的適用對像是誰?
為你推薦:
- 如果您已瞭解這個 API (例如,您已觀察或 參與 WICG 儲存庫的相關討論,並想瞭解 2022 年 1 月提案中的變更內容
- 如果您是在示範版或正式版實驗中使用 Attribution Reporting API,
如果您才剛開始使用這個 API,且/或尚未進行實驗,請直接 加入 API 簡介 。
即將遷移
在 Chrome 中導入這些變更後:如果您在試用版或正式版 (來源試用) 中使用 Attribution Reporting API 的事件層級報表,就需要編輯 API 程式碼才能繼續運作。您也可以考慮使用新功能。
此外,本文也會列出可匯總報表的異動。不過,如果執行這些變更,您不必採取任何行動或進行遷移,因為在撰寫這封信時,尚未針對可匯總報表實作瀏覽器。
名稱變更
摘要報表和可匯總報表
「匯總報表」現在稱為「匯總報表」 做為摘要報表。
摘要報表是多個可匯總報表匯總資料後的最終輸出結果。 舊稱「捐款」或直方圖貢獻。
API 機制異動
以標頭為基礎的來源登錄 (事件層級報表)
異動內容與原因
使用者查看或點擊廣告時,瀏覽器 (位於使用者裝置本機上) 就會記錄這個事件。
以及歸因報表專用參數 (例如
attributionsourceeventid
、attributiondestination
、attributionexpiry
和其他參數)。
這些參數值是由廣告技術人員設定
這些參數的設定方式將有異動。
在上一提案中,參數必須包含在用戶端位置:無論是在錨點標記中 做為 HTML 屬性,或以 JS 為基礎的呼叫的引數。必須能在點擊或瀏覽時識別參數 讓應用程式從可以最快做出回應的位置 回應使用者要求
在新提案中,這些參數的值會改在廣告技術伺服器定義。
![標頭式來源登錄的圖表](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/blog/diagram-header-based-sou-5d15e921f96f3.png?authuser=9&hl=zh-tw)
在安全性方面有許多缺點:標頭機制可為報告功能提供 來源 (通常是廣告技術),可以直接控管歸因來源是否已登錄到 範圍。這部分能減少詐欺性的疑慮,因為這項異動絕不會對真正的瀏覽器造成影響 在沒有報表來源選擇採用的情況下登錄來源。
來源登錄的運作方式為何?
- 廣告技術現在必須針對特定廣告定義一個用戶端屬性
attributionsrc
。這個屬性的值是瀏覽器會將 要求;這項要求會包含新的 HTTP 標頭Attribution-Reporting-Source-Info
,且這個標頭navigation
的值或event,
值,分別指定來源是點擊或觀看。 - 收到這項要求後,點擊/觀看追蹤伺服器應以 HTTP
包含所需出處的標頭
Attribution-Reporting-Register-Source
參數。 傳回這個標頭的來源現已改稱報表來源 (先前定義為
attributionreportto
)。HTTP 回應標頭
Attribution-Reporting-Register-Source
:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
詳情請參閱技術說明
加入公開討論
以標頭為準的歸因觸發條件 (事件層級報表)
異動內容與原因
就像點擊或觀看註冊一樣,新提案會變更歸因觸發條件,
廣告技術會指示瀏覽器記錄以標頭為基礎的轉換。
這項機制符合以標頭為基礎的來源登錄,
不像以往使用的重新導向機制。
此外,新提案的轉換頁也需要使用 attributionsrc
屬性。
原因在於權限的重要性:在先前的提案中,也就是觸發端網站 (通常是
廣告客戶網站 - 可以透過 Permissions-Policy
標頭大致控管這項功能,但
沒有精細的元素層級控制項,無法決定元素是否可向第三方傳送要求
這最終會觸發歸因程序attributionsrc
會變更這個欄位:這個必要標記
讓廣告客戶能夠監控並控制哪些元素可以
出處。
請注意,在來源端 (通常是發布商網站) 中,您可以透過
具有 Permissions-Policy
以及透過 attributionsrc
進行整個元素的控制項。
歸因觸發條件的運作方式為何?
收到像素請求並決定應分類為轉換時,廣告技術公司
應以新的 HTTP
回應
標頭 Attribution-Reporting-Register-Event-Trigger
。
此標頭的值會指定如何將觸發事件視為 JSON 物件處理。原來是 先前的提案已定義為查詢參數的資訊
HTTP 回應標頭 Attribution-Reporting-Register-Event-Trigger
:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
重新導向 (選擇性)
您也可以選擇讓廣告技術伺服器發出包含 Attribution-Reporting-Register-Event-Trigger
的回應。
如此一來,第三方就能觀察轉換事件,並指示瀏覽器進行歸因。
您可以選擇是否重新導向;如果廣告技術和第三方都在網頁上有像素,則不需要。
詳情請參閱第三方報表。
詳情請參閱技術說明
加入公開討論
沒有工作資料夾 (可匯總報表)
異動內容與原因
在先前的提案中,需要具備 JavaScript 存取權才能叫用 Worklet 是以 JavaScript 為基礎的機制,會產生這些報告。
在新提案中不需要使用工作程式。廣告技術會改為透過 HTTP 標題:瀏覽器產生可匯總報表時應使用的規則。
新提案提供以下幾個好處:
- 瀏覽器實作:新設計與 Worklet 設計不同, 因為這項介面不需要在瀏覽器中建立新的執行環境。
- 開發人員體驗:新版設計必須仰賴標頭, 這與程式小程式不同也會與 來源登錄,讓 API 更容易瞭解和使用。
- 採用:新版設計讓更多現有評估系統能夠使用可匯總 報表。許多成效評估解決方案都只適用於 HTTP:這類解決方案仰賴圖片請求,也就是像素 不需要 JavaScript 存取權。但由於 Worklet 做法需要 JavaScript 存取權,可能很難從某些現有的評估系統遷出。
- 穩定性:這項新設計更容易整合,降低資料遺失的風險
與
keepalive
語意合作,例如在使用者離開時登錄點擊或觀看 網頁。
無 Worklet 機制的運作方式為何?
這個宣告式機制是以 HTTP 標頭為基礎,就像事件層級來源登錄一樣 和歸因觸發條件標題詳情請參閱下一節。
加入公開討論
以標頭為基礎的來源登錄 (可匯總報表)
我們提議採用新機制來登錄可匯總報表的來源;也就是 與事件層級來源登錄相同。
只有標頭名稱不同:Attribution-Reporting-Register-Aggregatable-Source
。
詳情請參閱技術說明
以標頭為準的歸因觸發條件 (可匯總報表)
我們提議採用新機制來登錄可匯總報表的來源;也就是 與事件層級歸因觸發條件相同。
只有標頭名稱不同:Attribution-Reporting-Register-Aggregatable-Trigger-Data
。
詳情請參閱技術說明
新功能
第三方報表 (事件層級報表和可匯總報表)
異動內容與原因
新提案的兩個面向有助於進一步支援第三方報表使用案例:
- 廣告技術人員也可以將網路請求重新導向至其他廣告技術伺服器,讓 廣告技術以自行登錄來源和觸發事件這是第三常見的 這讓 API 更容易採用,以及其他現有 API 以及第三方報表系統
- 報表來源 (通常是廣告技術) 將不再共享大部分的隱私權限制。這項功能支援使用 因為多個廣告技術都與相同的發布商或廣告客戶合作的情況。
第三方報表如何運作?
在新提案中,回應型來源登錄和觸發條件必須仰賴 HTTP 標頭。廣告技術可針對這些請求利用 HTTP 重新導向。
如果發布商網站的點擊/瀏覽請求 (來源登錄) 隨後會重新導向到
這些方,全都可以登錄這個檢視或點擊 (來源事件)。
同樣地,廣告技術也可以重新導向來自律師網站的特定歸因要求。
允許多個方記錄一次轉換 (歸因觸發條件)。
各方可存取個別報表,並以個別資料來設定報表,
登錄多個不含重新導向的觸發條件
您也可以登錄多個歸因觸發事件,而不使用重新導向,方法是在轉換端加入多個像素元素 (每個觸發條件一個)。
加入公開討論
瀏覽後轉換評估 (事件層級報表和可匯總報表)
異動內容與原因
在新提案中,瀏覽後轉換評估與點閱評估是以統一的方式運作:
registerattributionsrc
,用來指示瀏覽器執行此動作的檢視畫面專屬屬性 記錄觀看次數和點擊次數,並不再以此提案的一部分。- 點擊和瀏覽隱私機制現已統合。在這個情境中,請參閱噪音 資訊公開和資訊
這項變更是為了配合新的標頭式註冊機制。 預期同時支援點閱和瀏覽後轉換時,也能簡化開發人員體驗 成效評估方式
瀏覽後轉換評估的運作方式為何?
瀏覽後轉換評估和點閱評估方法都需仰賴以標頭登錄,
詳情請參閱技術說明
加入公開討論
偵錯 / 成效分析 (事件層級報表和可匯總報表)
異動內容與原因
提案中新增了偵錯機制,可協助開發人員偵測錯誤,以及 比較歸因報表與現有 Cookie 成效評估解決方案的成效。
![新的 Cookie 式偵錯系統圖表](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/blog/diagram-the-cookie-base-60490ad30c9e9.png?authuser=9&hl=zh-tw)
偵錯功能如何運作?
來源和觸發事件登錄作業都會接受新參數 debug_key
,即 64 位元的未簽署參數
整數值 (也就是較大的數字)。
如果使用來源和觸發偵錯金鑰建立報表,且報表有 Samesite=None ar_debug=1
Cookie
都出現在報表來源的 Cookie jar 檔案 (來源和觸發事件登錄時間)
系統會將報表 (JSON) 傳送至 .well-known/attribution-reporting/debug
端點:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
此外,事件層級和可匯總報表也會包含這兩個新參數, 與正確的偵錯報表建立關聯
詳情請參閱技術說明
加入公開討論
篩選功能 (事件層級報表和可匯總報表)
異動內容與原因
這類 Cookie 支援現今廣告生態系統的重要用途,因此有許多用途。 將可支援事件層級和可匯總報表:
- 轉換篩選:根據來源資訊篩選轉換。適用對象 比如說,為廣告點擊和觀看選取不同的觸發事件資料 (轉換資料)。
- 歸因不符:篩選歸因錯誤的轉換。這是 特定類型的轉換篩選。例如,濾除對應至 因 API 中的 etld+1 目的地範圍導致的廣告點擊/瀏覽錯誤。
篩選功能如何運作?(適用於事件層級報表)
來源端 JSON 物件中的選用 source_data
欄位,可定義將要
瀏覽器隨後會在轉換時用來套用篩選邏輯。
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
觸發事件登錄作業現在接受選用標頭 Attribution-Reporting-Filters
。
HTTP 回應標頭 Attribution-Reporting-Filters
:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
或者,Attribution-Reporting-Register-Event-Trigger
標頭也可以使用
使用 filters
欄位執行選擇性篩選,以便根據 source_data
設定 trigger_data
。
如果 source_data
篩選器中的鍵使用 JSON 比對鍵,則觸發事件為
如果十字路口為空白,則完全忽略。
詳情請參閱技術說明
加入公開討論
隱私保護服務異動
雜訊和透明 (事件層級報表和可匯總報表)
異動內容與原因
在新版提案中,報表採用了一種隱私權保護機制:報表是
收到隨機回應。
也就是說,部分實際轉換會正確記錄。以及
在這段時間內,部分真正的轉換會遭到抑製或新增。
這項新技巧有幾個優點:
- 能統合點擊和觀看次數的隱私權機制。
- 與其區分觸發事件資料 (轉換資料) 和觸發事件來源連結雜訊,其實更簡易。
- 因此制定了隱私權架構,透過適當的雜訊設定,確保任一方都無法利用 API 得知個別使用者已轉換 (或不瞭解) 特定廣告。
新機制取代了舊機制,在 5% 的時間都觸發資料 (轉換資料) 已由隨機值取代。
此外,報表主體也加入了隨機回應機率值
(randomized_trigger_rate
欄位)。這個欄位可用來指定來源為
分別收到隨機回應
這麼做有兩大優點:
- 這麼做會將基礎瀏覽器行為透明給接收報表的各方 (通常是廣告技術)
- 對於未來我們全面支援這個 API,將會提供許多支援 不同瀏覽器:不同瀏覽器可能會根據使用情況,套用不同程度的雜訊 隱私權目標,以及處理報表的各方必須深入瞭解這項資訊。
噪音如何運作?
在新提案中,登錄來源時 (記錄廣告點擊或觀看), 瀏覽器就會隨機判斷是否要正確進行轉換歸因,並傳送相關報表 或是否改為產生假的輸出內容。
假輸出內容可以是:
- 一律不產生報表:無論使用者是否完成轉換。
- 一或多份偽造報表:不論使用者是否完成轉換。
在假報表中,觸發事件資料 (轉換資料) 會隨機呈現:點擊 (任一種) 的隨機 3 位元值 介於 0 到 7 之間的數字) 和隨機的 1 位元值 (0 或 1)。
如同真正的報表,系統不會在使用者完成轉換後立即傳送假報表,這類訊息的傳送時間為 隨機報表回溯期的結尾處。
點擊有三個報表回溯期 (2 天、7 天或點擊後 30 天)。每張假貨 系統就會隨機將報表指派給其中一個報表回溯期。
此外,如先前的提案所述,系統會在「內」內隨機排序報表。
詳情請參閱技術說明
加入公開討論
報表限制 (事件層級報表和可匯總報表)
異動內容與原因
新的提案會明確限制兩個網站之間可評估事件的單位數量。
- 可登錄的不重複報表來源 (通常是廣告技術) 數量上限 每個 {publisher, advertiser} 的範圍建議上限為每 30 天 100 個。這個 每次廣告點擊或觀看 (來源事件) 的次數,都會增加 歸因。
- 每個可傳送報表的不重複報表來源 (通常是廣告技術) 數量上限 {publisher, advertiser}建議將上限設為每 30 天 10 天。這個計數器會是 增量轉換。
這些限制的下限是,以便不限制任何發動者的衡量能力 因這類攻擊可減少某些形式的 API 濫用問題。
報表等待期 / 頻率限制
異動內容與原因
回報緩和功能是一種隱私機制,可限制傳送的資訊總量 使用者在特定時間範圍內透過這個 API
在新提案中,每個 {source site、destination、report origin} 回報 100 份報表 (通常是 {publisher, advertiser, adtech}) 安排在 30 天內。
如果超過此限制,瀏覽器就會停止為符合此上限的報表 ({source site, destination, report origin} (通常是 {publisher, advertiser, adtech}),直到 30 天滾動週期為止 在該 {source site, destination, reporting origin} 的報表中,數目低於 100。
詳情請參閱技術說明
目的地上限 (僅限事件層級報表)
異動內容與原因
修改目的地上限,將報表來源 (通常是廣告技術) 納入範圍:100 個不重複 待審核的到達網頁 (通常是廣告客戶網站或預期會發生轉換的網站 地點) 是每個 {publisher, adtech} 的許可請求數量。
這項隱私保護措施可限制瀏覽記錄重建作業。
詳情請參閱技術說明
所有資源
標題圖片來自 Diana Polekhina,位於 Unsplash。