歸因報表提案已進行多項變更 社群意見回饋，包括 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 為基礎的呼叫的引數。必須能在點擊或瀏覽時識別參數 讓應用程式從可以最快做出回應的位置 回應使用者要求
在新提案中，這些參數的值會改在廣告技術伺服器定義。
在安全性方面有許多缺點：標頭機制可為報告功能提供 來源 (通常是廣告技術)，可以直接控管歸因來源是否已登錄到 範圍。這部分能減少詐欺性的疑慮，因為這項異動絕不會對真正的瀏覽器造成影響 在沒有報表來源選擇採用的情況下登錄來源。
來源登錄的運作方式為何？
- 廣告技術現在必須針對特定廣告定義一個用戶端屬性
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 成效評估解決方案的成效。
偵錯功能如何運作？
來源和觸發事件登錄作業都會接受新參數 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。