從 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 網站上。