歸因報表：完整系統總覽

Attribution Reporting 已連結服務的概要總覽，專為技術決策者設計。

透過 Attribution Reporting API，廣告技術和廣告客戶可評估廣告點擊或觀看促成轉換 (例如購買) 的時機。視您的業務需求而定，這個 API 需要同時採用用戶端和伺服器端整合。

繼續操作前，請務必參閱「歸因報表總覽」一文。這將協助您瞭解 API 的用途，以及不同輸出報表 (事件層級報表和摘要報表) 的流程。如果看到不熟悉的術語，請參閱 Privacy Sandbox 詞彙。

本文適用對象

遇到以下情形時，建議您閱讀這篇文章：

• 您是廣告技術或廣告客戶的技術決策者。您的職務可能包括營運、開發運作、數據資料學、IT、行銷，或由您擔任技術實作決策的其他角色。您想知道 API 如何運作，以保護隱私權的評估方式。
• 您是這個 API 和匯總服務環境的技術從業人員 (例如開發人員、系統操作人員、系統架構師或數據資料學家)，

在本文中，您將參閱 Attribution Reporting API 服務運作方式的概略端對端說明。如果您是技術人員，可在本機使用這個 API 進行實驗。

總覽

Attribution Reporting API 包含許多服務，需要特定設定、用戶端設定和伺服器部署作業。如要判斷需要的項目，請先：

• 決定設計。定義要收集的資訊、識別您希望特定廣告活動帶來哪些轉換，並決定要收集哪種報表類型。最終輸出是其中一種或兩種報表類型：事件層級報表和摘要報表。

共有兩個 (有時是三個) 元件可搭配運作來支援報表：

• 網站與瀏覽器通訊：在 Cookie 型系統中，轉換和廣告互動的資訊會附加至 ID，方便您或數據分析服務之後加入這些事件。有了這個 API，瀏覽器在傳送進行分析前，就會按照您的指示，將轉換與廣告點擊/觀看建立關聯。因此，您的廣告顯示程式碼和轉換追蹤必須：
  • 告知瀏覽器應將哪些轉換歸因於哪些廣告點擊或曝光。
  • 指出要納入最終報表的任何其他資料。
• 資料收集：您必須有收集器端點，才能接收在使用者瀏覽器中產生的報表。瀏覽器的輸出內容可能是以下兩種報表之一：事件層級報表和可匯總報表 (已加密，用於產生摘要報表)。

如果您收集了可匯總報表，則需要第三個元件：

• 產生摘要報表：批次可匯總報表，並使用匯總服務處理報表來產生摘要報表。

設計決策

歸因報表的一大原則是早期設計決策。您可以決定要收集哪些類別的資料，以及處理這些資料的頻率。輸出報表提供廣告活動或業務的深入分析。

輸出報表可以是：

• 事件層級報表會將特定廣告點擊或瀏覽 (廣告端) 與轉換端的資料建立關聯。為限制使用者跨網站身分的結合，藉此限制使用者隱私，轉換端資料非常有限，而且資料會很雜訊 (意即在少數情況下，系統會傳送隨機資料，而不是實際報表)。
• 摘要報表不會與廣告端的特定事件建立關聯，這些報表提供更詳盡的轉換資料，並能讓您更靈活地彙整點擊和查看資料與轉換資料。

您選擇的報表會決定您要收集的資料。

您也可以將最終輸出內容視為用於決策的工具輸入。舉例來說，如果您產生摘要報表來判斷有多少轉換帶來部分總支出，有助團隊決定下一個廣告活動應指定什麼目標，以便提高總支出。

決定要評估的項目後，您就可以在用戶端設定 Attribution Reporting API。

網站對瀏覽器通訊

注意：這個 API 處於測試階段時，您的程式碼必須確認 API 可用，並設定適當的 Permissions-Policy。

發布商網站上的歸因來源，會與廣告客戶網站上的觸發條件建立關聯。

歸因事件流程

假設有一個顯示廣告的發布商網站，每個廣告客戶或廣告技術供應商，都想瞭解廣告的互動情形，並將轉換歸因於正確的廣告。報表 (事件層級和可匯總) 的產生方式如下：

1. 在發布商網站上，廣告元素 (<a> 或 <img> 代碼) 設定了特殊屬性 attributionsrc。其值為網址 (例如 https://adtech.example/register-source/ad_id=...)。

   下列連結範例會在使用者點擊後登錄來源：

   <a href="https://shoes.example/landing" 
     attributionsrc="http://adtech.example/register-source?..."
     target="_blank">
   Click me</a>
   

   以下範例圖片會在使用者查看時登錄來源：

   <img href="https://advertiser.example/landing" 
     attributionsrc="https://adtech.example/register-source?..."/>
   

   此外，也可以使用 JavaScript 呼叫取代 HTML 元素。

   以下是使用 window.open() 的 JavaScript 範例。請注意，網址會經過編碼，以免出現特殊字元。

   const encodedUrl = encodeURIComponent(
     'https://adtech.example/attribution_source?ad_id=...');
   window.open(
     "https://shoes.example/landing",
     "_blank",
     attributionsrc=${encodedUrl});
   

1. 當使用者點擊或觀看廣告時，瀏覽器會將 GET 要求傳送至 attributionsrc，通常是廣告客戶或廣告技術供應商的端點。

2. 收到這項要求後，廣告客戶或廣告技術供應商決定指示瀏覽器登錄來源事件，以便記錄廣告的互動，系統稍後就會將轉換歸因於這個廣告。為了進行這項作業，廣告客戶或廣告技術供應商會在回應中加入特殊 HTTP 標頭。這項標題自訂資料會附加至這項標題自訂資料，提供來源事件 (廣告點擊或觀看) 相關資訊。如果這則廣告最後發生轉換，這項自訂資料最終會顯示在歸因報表中。

   

3. 後來使用者造訪廣告客戶的網站。

4. 在廣告客戶網站的每個相關網頁上 (例如購買確認頁或產品網頁)，轉換像素 (<img> 元素) 或 JavaScript 呼叫向 https://adtech.example/conversion?param1=...&param2=... 發出要求。

5. 這個網址中的服務 (通常為廣告客戶或廣告技術供應商) 會收到請求。於是，該關鍵字將該轉換分類為轉換，因此必須指示瀏覽器記錄轉換 (也就是觸發歸因)。為此，廣告客戶或廣告技術供應商會在回應像素請求時，加入內含轉換相關自訂資料的特殊 HTTP 標頭。

6. 使用者本機裝置上的瀏覽器會收到這則回應，並將轉換資料與原始來源事件 (廣告點擊或觀看) 進行比對。詳情請參閱「比對來源與觸發條件」一文

7. 瀏覽器會排定傳送報表給 attributionsrc。這份報表包含：

   1. 由廣告技術供應商或廣告客戶附加至步驟 3 中來源事件的自訂歸因設定資料。
   2. 步驟 6 的自訂轉換資料設定。

   

8. 之後，瀏覽器會將報表傳送到 attributionsrc 中定義的端點，但有些延遲和雜訊。可匯總報表會經過加密，但事件層級報表則不會。

歸因觸發條件 (廣告客戶的網站)

歸因觸發條件是指示瀏覽器擷取轉換的事件。

建議您擷取對廣告客戶最重要的轉換 (例如購買)。摘要報表可以擷取多種轉換類型和中繼資料。

如此可確保這些事件的匯總結果都十分詳細正確。

比對來源與觸發條件

瀏覽器收到歸因觸發事件回應時，瀏覽器會存取本機儲存空間，找出同時符合歸因觸發條件來源和該網頁網址的 eTLD+1 來源。

舉例來說，當瀏覽器在 shoes.example/shoes123 上收到來自 adtech.example 的歸因觸發事件時，瀏覽器會在本機儲存空間中尋找同時符合 adtech.example 和 shoes.example 的來源。

您可以設定篩選器 (或自訂規則)，決定觸發事件與特定來源的比對結果。舉例來說，您可以設定篩選器，只計算特定產品類別的轉換次數，並忽略所有其他類別。篩選器和優先順序模型可用於製作更進階的歸因報表。

如果在本機儲存空間中找到多個歸因來源，瀏覽器會選用最近儲存的歸因來源。在某些情況下，如果歸因來源具有優先順序，瀏覽器會選擇優先順序最高的來源。

資料收集

比對到對應來源的歸因觸發條件會由瀏覽器以報表形式傳送至廣告技術自有伺服器上的報表端點 (有時稱為收集端點或收集服務)。這些報表可以是事件層級報表或可匯總報表。

可匯總報表可用來產生摘要報表。可匯總報表是由系統從廣告 (在發布商網站上) 收集到的資料與轉換資料 (來自廣告客戶網站) 所組成，這類資料是由瀏覽器在廣告技術收集前，由瀏覽器產生並加密。

事件層級報表會延遲 2 到 30 天。可匯總報表會在一小時內隨機延遲傳送，且事件必須符合貢獻預算。這些選擇可保護隱私權，並防止個別使用者行為遭到濫用。

如果只想查看事件層級報表，這是所需的最後一個基礎架構。不過，如要產生摘要報表，則需要透過額外服務處理可匯總報表。

產生摘要報表

如要產生摘要報表，您需要使用廣告技術執行的 匯總服務 (由廣告技術執行) 處理可匯總報表。匯總服務會加入雜訊來保護使用者隱私，並傳回最終摘要報表。

這張圖表代表透過廣告技術自有匯總服務上的處理，從收集端點產生的資料非同步資料流。

批次處理收集到的可匯總報表後，該批次就會由匯總服務處理。協調者只會將解密金鑰提供給匯總服務的認證版本。匯總服務會解密資料、匯總資料並加入雜訊，然後再將結果傳回為摘要報表。

批次可匯總報表

必須先批次處理，才能處理可匯總報表。批次包含策略性可匯總報表。您的策略最有可能反映特定時間範圍 (例如每天或每週)。此程序可在做為報告端點的同一伺服器上進行。

批次中應包含許多報表，以確保信號雜訊比率偏高。

比較等待 1 天和 1 週的等候時間。1 小時後，您的摘要值會更小，結果可能會更雜亂。一天的摘要值較大，因此雜訊較少。

批次週期隨時可能變更，以確保您擷取到預期可獲得較高的特定事件，例如一年的特賣活動。批次處理期間無需變更歸因來源或觸發條件即可變更。

匯總服務

匯總服務會負責處理可匯總報表，以產生摘要報表。可匯總報表會經過加密，而且只能由在受信任的執行環境 (TEE) 上執行的匯總服務讀取。

匯總服務會要求協調工具提供解密金鑰，以解密及匯總資料。解密及匯總結果後，系統會將結果套用雜訊來保護隱私，並以摘要報表的形式傳回。

從業人員可以產生可匯總的明文報告，在本機測試匯總服務。您也可以使用 Nitro Enclaves 對 AWS 上的加密報告進行測試。

後續步驟

我們希望與您交流，確保我們建構的 API 適合所有人使用。

討論 API

如同其他 Privacy Sandbox API，這項 API 也記載於公開討論。

透過 API 進行實驗

您可以實驗及參與 Attribution Reporting API。