從 API 機制變更到新功能，Attribution Reporting 提案進行了數項變更以解決社群意見回饋。
變更記錄
- 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 呼叫的引數。參數必須在點擊或瀏覽時得知。
在新提案中，這些參數值會改由廣告技術伺服器定義。
但這樣做也有不少優點，尤其是在安全性方面：標頭機制會提供報表來源 (通常是廣告技術)，直接控制歸因來源是否已在範圍內登錄。這部分可降低詐欺疑慮，因為這項變更後，正版瀏覽器在未選擇加入報表來源的情況下，絕對不會登錄來源。
來源登錄作業的運作方式為何？
- 現在，廣告技術必須定義特定用戶端屬性
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 重新導向回應的回應。這樣一來，第三方就能觀察轉換事件，並指示瀏覽器進行歸因。
您不一定要重新導向；如果廣告技術和第三方網頁上都有像素，則不需要進行重新導向。
詳情請參閱第三方報表。
詳情請參閱技術說明
加入公開討論
無 Worklet (可匯總報表)
異動內容與原因
之前的可匯總報表提案中，必須具備 JavaScript 存取權，才能叫用一項以 JavaScript 為基礎的機制 (一種以 JavaScript 為基礎的機制)，才能產生這些報表。
在新的提案中，您完全不需要動手操作。相反地，廣告技術需要透過 HTTP 標頭以宣告方式定義瀏覽器用於產生可匯總報表的規則。
新提案具備以下幾項優點：
- 瀏覽器實作：與 Worklet 設計不同的是，全新設計將大幅簡化，因為不需要在瀏覽器中新增執行環境。
- 開發人員體驗：新版設計仰賴標頭，這是開發人員常用且廣為人知的標頭，這與 Worklet 不同。這個級別也與來源註冊的 API 介面保持一致，方便開發人員學習及使用 API。
- 採用率：新版設計可讓更多現有評估系統使用可匯總報表。許多成效評估解決方案都僅限 HTTP，也就是仰賴圖片要求 (像素要求)，不需要 JavaScript 存取權。不過，由於這個演練的方法確實需要 JavaScript 存取權，因此很難從一些現有的評估系統遷出。
- 健全性：新設計有助於減少資料遺失，因為這樣更易於與
keepalive語意整合，例如在使用者離開頁面時登錄點擊或檢視區塊。
免手持機制的運作方式為何？
這項宣告式機制是以 HTTP 標頭為基礎，與事件層級來源登錄和歸因觸發條件標頭一樣。詳情請參閱下一節。
加入公開討論
標題式來源登錄 (可匯總報表)
建議您採用新的機制來註冊可匯總報表的來源；這個機制與事件層級來源登錄相同。
只有標頭名稱不同：Attribution-Reporting-Register-Aggregatable-Source。
詳情請參閱技術說明
標題式歸因觸發事件 (可匯總報表)
建議您採用新的機制來登錄可匯總報表的來源；這個機制與事件層級歸因觸發條件相同。
只有標頭名稱不同：Attribution-Reporting-Register-Aggregatable-Trigger-Data。
詳情請參閱技術說明
新功能
第三方報表 (事件層級報表和可匯總報表)
異動內容與原因
這項新提案有兩個方面，能為第三方報表用途提供更完善的支援：
- 您可以視需要將網路要求重新導向其他廣告技術伺服器，讓其他廣告技術自行執行來源和觸發條件登錄作業。這是第三方目前常見的設定方式。這樣一來，您就能在現有的第三方報表系統中採用 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)。
這麼做有兩大優點：
- 這可讓接收報表方 (通常是廣告技術) 「公開」transparent基礎瀏覽器行為。
- 在日後跨瀏覽器支援這個 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}) 的報表，直到該 {source site, destination, reporting origin} 的 30 天累計報表計數低於 100。
詳情請參閱技術說明
目的地上限 (僅限事件層級報表)
異動內容與原因
已修改目的地上限，使其根據範圍 (通常為廣告技術) 納入範圍內的報表來源：每個{publisher, adtech}可允許 100 個不重複的待處理目的地 (通常是廣告客戶網站或預計發生轉換的網站)。
這是一項隱私保護服務，目的是限制他人重建瀏覽記錄。
詳情請參閱技術說明
所有資源
頁首圖片來源為 Diana Polekhina，位於 Unsplash 網站上。