為了回應社群意見，Attribution Reporting 提案經過多項變更，包括 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 為基礎的呼叫的引數。參數必須在點擊或觀看時提供。
在新提案中，這些參數的值會改為在 adtech 伺服器上定義。
這項做法有許多優點，特別是在安全性方面：標頭機制可讓報表來源 (通常是廣告技術) 直接控制歸因來源是否在其範圍內登錄。這項變更可部分緩解詐欺問題，因為在這種情況下，即使是真實的瀏覽器，也不會在未經報表來源選擇加入的情況下註冊來源。
來源註冊的運作方式為何？
- 針對特定廣告，廣告技術現在需要定義特定的用戶端屬性
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 標頭，以宣告方式定義瀏覽器應使用的產生可匯總報表的規則。
新提案有幾項優點：
- 瀏覽器實作：與工作區設計不同，新設計不需要在瀏覽器中建立新的執行環境，因此整體來說更為簡單。
- 開發人員體驗：新設計仰賴開發人員常用且廣為人知的標頭，這與工作項不同。它也與 API 介面緊密配合，可用於來源註冊，讓 API 更容易學習及使用。
- 採用率：新設計可讓更多現有評估系統使用可匯總的報表。許多成效評估解決方案僅限 HTTP：它們依賴圖片要求 (像素要求)，而這類要求不需要 JavaScript 存取權。但由於工作區塊方法確實需要 JavaScript 存取權，因此可能難以從某些現有評估系統遷移。
- 穩健性：新設計可更輕鬆地與
keepalive語意整合，因此有助於減少資料遺失，例如在使用者離開網頁時註冊點擊或觀看次數。
無工作區機制的運作方式為何？
這個宣告式機制以 HTTP 標頭為基礎，就像事件層級來源登錄和歸因觸發事件標頭一樣。詳情請參閱後續章節。
加入公開討論
以標頭為依據的來源登錄 (可匯總報表)
我們建議採用新機制，為可匯總報表登錄來源；這項機制與事件層級來源登錄相同。
只有標頭名稱不同：Attribution-Reporting-Register-Aggregatable-Source。
請參閱技術說明，進一步瞭解
以標頭為依據的歸因觸發條件 (可匯總報表)
我們建議採用新機制，為可匯總報表登錄來源；這個機制與事件層級歸因觸發事件相同。
只有標頭名稱不同：Attribution-Reporting-Register-Aggregatable-Trigger-Data。
請參閱技術說明，進一步瞭解
新功能
第三方報表 (事件層級報表和可匯總報表)
異動內容和原因
新提案的兩個方面有助於更好地支援第三方報表使用情境：
- 廣告技術可以視需要將網路要求重新導向至其他廣告技術伺服器，讓其他廣告技術執行自己的來源和觸發事件登錄。這是目前第三方設定的常見方式。這麼做可讓 API 更容易採用，並與現有第三方報表系統中的其他 API 整合。
- 報表來源 (通常是廣告技術) 不再分享大部分的隱私權限制。這項功能可支援多個廣告技術與相同發布商或廣告客戶合作的用途。
第三方報表的運作方式為何？
在新提案中，以回應為基礎的來源登錄和觸發條件會依賴 HTTP 標頭。廣告技術可以利用 HTTP 重新導向這些要求。
如果發布商網站上的點擊/觀看要求 (來源登錄) 之後重新導向至多個對象，這些對象中的每個對象都可以登錄這項觀看或點擊 (來源事件)。
同樣地，廣告技術可以重新導向廣告客戶網站提出的特定歸因要求，讓多個其他方登錄轉換 (歸因觸發事件)。
每個使用者都能存取各自的報表，並使用各自的資料設定報表。
註冊不含重新導向的多個觸發條件
您也可以在轉換端新增多個像素元素 (每個觸發事件一個)，藉此登錄多個歸因觸發事件，而無須使用重新導向。
加入公開討論
看見後成效評估 (事件層級報表和可匯總報表)
異動內容和原因
在新的提案中，曝光後評估和點閱後評估會以統一的方式運作：
registerattributionsrc是專屬於觀看次數的屬性，可指示瀏覽器記錄觀看次數和點擊次數，但不再是提案的一部分。- 隱私權機制現在已在點擊和觀看之間統一。詳情請參閱「噪音和透明度」。
這項變更是為了配合新的以標頭為基礎的註冊機制。此外，如果您想同時支援點擊和觀看轉換評估，這項功能也能簡化開發人員的操作體驗。
瀏覽後評估的運作方式
瀏覽後轉換評估和點閱轉換評估都需要使用以標頭為基礎的註冊。
請參閱技術說明，進一步瞭解
加入公開討論
偵錯 / 效能分析 (事件層級報表和可匯總報表)
異動內容和原因
我們已在提案中加入偵錯機制，協助開發人員偵測錯誤，並比較歸因報表與現有 Cookie 評估解決方案的成效。
偵錯功能的運作方式為何？
來源和觸發事件登錄都會接受新的參數 debug_key，這是 64 位元未簽署的整數 (也就是大數字)。
如果同時透過來源和觸發偵錯金鑰建立報表，且在來源和觸發事件註冊期間，報表來源的 Cookie jar 中存在 Samesite=None ar_debug=1 Cookie，系統會將偵錯報表 (JSON) 傳送至 .well-known/attribution-reporting/debug 端點：
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
事件層級和可匯總報表也會納入這兩個新參數，以便與正確的偵錯報表建立關聯。
請參閱技術說明，進一步瞭解
加入公開討論
篩選功能 (事件層級報表和可匯總報表)
異動內容和原因
由於這類事件可支援當今廣告生態中的重要用途，因此現在事件層級和可匯總的報表都會支援以下用途：
- 轉換篩選：根據來源端資訊篩選轉換。舉例來說，請為廣告點擊和瀏覽選取不同的觸發資料 (轉換資料)。
- 歸因不符：篩除歸因錯誤的轉換，這是一種特定類型的轉換篩選。舉例來說，篩除因 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"
}
或者，您也可以使用 filters 欄位擴充 Attribution-Reporting-Register-Event-Trigger 標頭，藉此進行選擇性篩選，根據 source_data 設定 trigger_data。
如果篩選器 JSON 中的鍵與 source_data 中的鍵相符，且交集為空，系統會完全忽略觸發條件。
請參閱技術說明，進一步瞭解
加入公開討論
隱私權防護服務異動
雜訊和透明度 (事件層級報表和可匯總報表)
異動內容和原因
在新的提案中，我們改善了報表的其中一個隱私權機制：報表會採用隨機回應機制。
這表示系統會正確記錄部分實際轉換，但在某些情況下，部分實際轉換會遭到抑制，或系統會新增部分假轉換。
這項新技術有幾個優點：
- 統一點擊和觀看的隱私權機制。
- 與分離觸發資料 (轉換資料) 和觸發來源連結雜訊的機制相比，這項機制更容易進行推論。
- 這項功能會設定隱私權架構，並透過適當的雜訊設定，確保任何一方都無法透過 API 得知個別使用者是否因特定廣告而轉換。
這項新機制取代了先前的機制，在該機制中，觸發資料 (轉換資料) 會在 5% 的時間內替換為隨機值。
此外，隨機回應機率值已新增至報表主體 (randomized_trigger_rate 欄位)。這個欄位會指定來源受隨機回應影響的機率 (0 到 1)。
這有兩個主要優點：
- 這項功能可讓基礎瀏覽器行為對收取報表的各方 (通常是廣告技術) 保持透明。
- 這項功能對於未來支援 API 的瀏覽器來說非常實用：不同瀏覽器可能會根據隱私權目標，決定套用不同程度的雜訊，而處理報表的各方需要瞭解這項資訊。
噪音的運作方式為何？
在新提案中，在來源登錄 (即記錄廣告點擊或瀏覽) 時，瀏覽器會隨機決定是否要誠實歸因轉換並傳送這次廣告點擊/瀏覽的報表，或是產生假輸出內容。
假輸出內容可以是：
- 完全沒有報表：無論使用者是否轉換，都不會產生報表。
- 一或多則假報表 (無論使用者是否轉換)。
在假報表中，觸發事件資料 (轉換資料) 是隨機產生的：點擊的隨機 3 位元值 (0 到 7 之間的任何數字)，以及觀看的隨機 1 位元值 (0 或 1)。
與真實報表一樣，假報表不會在使用者完成轉換後立即傳送。這些報表會在隨機報表時段結束時傳送。
點擊有三個報表回溯期 (點擊後 2 天、7 天或 30 天)。每份假報表都會隨機指派至其中一個報表回溯期。
另外，如先前提案所述，在某個時間範圍內，報表的排序是隨機的。
請參閱技術說明，進一步瞭解
加入公開討論
報表限制 (事件層級報表和可匯總報表)
異動內容和原因
新提案明確限制兩個網站之間的事件可由多少個實體進行評估。
- 建議每個 {發布商、廣告客戶} 的報表來源 (通常為廣告技術) 最多可登錄 每 30 天 100 個。每個廣告點擊或觀看 (來源事件) 都會增加這個計數器，即使未歸因也一樣。
- 建議每個 {發布商、廣告客戶} 的報表來源 (通常是廣告技術) 數量上限為 每 30 天 10 個。系統會針對每次歸因轉換遞增這個計數器。
這些限制的目的在於讓任何參與者都能評估轉換，但限制的程度不至於造成 API 濫用行為。
回報冷卻 / 頻率限制
異動內容和原因
報表冷卻時間是一種隱私權機制，可限制在指定時間範圍內，透過此 API 傳送的使用者資訊總量。
在新提案中，每個 {來源網站、目的地、報表來源} (通常是 {發布商、廣告主、廣告技術}) 可排程 100 份報表，時間範圍為 30 天。
超過這個限制後，瀏覽器就會停止排定符合此特定 {來源網站、目的地、報表來源} (通常是 {發布商、廣告客戶、廣告技術}) 的報表，直到該 {來源網站、目的地、報表來源} 的 30 天滾動報表計數低於 100 為止。
請參閱技術說明，進一步瞭解
目的地上限 (僅限事件層級報表)
異動內容和原因
修改目的地上限，在範圍中加入報表來源 (通常是廣告技術)：每個 {publisher, adtech} 允許有 100 個獨特的待處理目的地 (通常是廣告主網站，或預期會發生轉換的網站)。
這是為了保護隱私權，限制瀏覽記錄重建功能。
請參閱技術說明，進一步瞭解
所有資源
- 請參閱「歸因報表」。
- 請參閱「API 相關注意事項」。
標題圖片出自 Unsplash 上的 Diana Polekhina。