歸因報表:完整系統總覽

這份總覽旨在向技術決策者介紹歸因報表的相關服務。

Attribution Reporting API 可讓廣告技術和廣告主評估廣告點擊或瀏覽促成轉換 (例如購買) 的時間。這個 API 會根據您的業務需求,結合用戶端和伺服器端整合。

繼續操作前,請務必詳閱歸因報表總覽。這有助於您瞭解 API 的用途,以及各種輸出報表 (事件層級報表摘要報表) 的流程。如果您看到不熟悉的術語,請參閱 Privacy Sandbox 術語彙

這篇文章適用對象

您應該閱讀本文,如果:

  • 您是廣告技術或廣告客戶的技術決策者。您可能從事營運、開發運作、資料科學、IT、行銷或其他需要做出技術導入決策的職務。您想瞭解 API 如何在隱私權保護評估中運作。
  • 您是技術實務人員 (例如開發人員、系統操作人員、系統架構師或資料科學家),將使用這個 API 和匯總服務環境設定實驗。

本文將概略說明 Attribution Reporting API 的服務如何運作。如果您是技術專家,可以在本機端測試這個 API

總覽

Attribution Reporting API 包含許多服務,需要特定設定、用戶端設定和伺服器部署。如要判斷您需要哪些內容,請先:

  • 決定設計。定義要收集的資訊、找出您期望從任何特定廣告活動獲得的轉換,並決定要收集哪種報表類型。最終輸出內容為事件層級報表和摘要報表這兩種報表類型之一或兩者皆有。

報表功能需要兩個 (有時是三個) 元件搭配運作:

  • 網站與瀏覽器之間的通訊。在 Cookie 為基礎的系統中,轉換和廣告互動資訊會附加至 ID,方便您或分析服務日後加入這些事件。透過這個 API,瀏覽器會根據您的指示,在轉換送交進行分析前,將轉換與廣告點擊/瀏覽次數建立關聯。因此,您的廣告算繪程式碼和轉換追蹤功能必須符合下列條件:
    • 告訴瀏覽器,哪些轉換應歸因於哪些廣告點擊或曝光。
    • 指出要納入最終報表的其他資料。
  • 資料收集。您需要收集器端點,才能接收使用者瀏覽器產生的報表。瀏覽器的輸出內容可能為以下兩種報表之一:事件層級報表和可匯總報表 (經過加密,用於產生摘要報表)。

如果您收集可匯總報表,就需要第三個元件:

  • 產生摘要報表:匯總可匯總報表,並使用匯總服務處理報表,產生摘要報表。

設計決策

歸因報表的一項重要原則,就是及早做出設計決策。您可以決定收集哪些資料、收集哪些類別的資料,以及處理資料的頻率。輸出報表會提供廣告活動或業務的洞察資料。

輸出報表可以是:

  • 事件層級報表:將特定廣告點擊或瀏覽 (廣告端) 與轉換端的資料建立關聯。為保護使用者隱私,我們限制在不同網站上彙整使用者身分資料,因此轉換資料非常有限,而且雜訊較多 (也就是說,在少數情況下,系統會傳送隨機資料,而非實際報表)。
  • 摘要報表與廣告端的特定事件無關,這些報表提供更詳細的轉換資料,並可靈活地將點擊和觀看資料與轉換資料彙整。

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

您也可以將最終輸出結果視為用於決策的工具輸入內容。舉例來說,如果您產生摘要報表來判斷有多少轉換會產生某些總支出價值,這可能有助於您的團隊決定下一個廣告活動應指定哪些目標,以產生更高的總支出。

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

網站與瀏覽器之間的通訊

發布商網站上的歸因來源會連結至廣告主網站上的觸發事件。
發布商網站上的歸因來源會連結廣告主網站上的觸發事件。

歸因事件流程

假設發布商網站顯示廣告。每位廣告主或廣告技術供應商都想瞭解廣告的互動情形,並將轉換歸因給正確的廣告。報表 (包括事件層級和可匯總報表) 的產生方式如下:

  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/shoes123adtech.example 歸因觸發事件時,瀏覽器會在本機儲存空間中尋找與 adtech.exampleshoes.example 相符的來源。

您可以設定篩選器 (或自訂規則),決定觸發條件何時與特定來源相符。舉例來說,您可以設定篩選器,只計算特定產品類別的轉換,並忽略所有其他類別。篩選器和優先順序模式可提供更進階的歸因報表。

如果本機儲存空間中有多個歸因來源,瀏覽器會選擇最近儲存的來源。在某些情況下,如果歸因來源已指派優先順序,瀏覽器會選取優先順序最高的來源。

資料收集

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

可匯總報表可用於產生摘要報表。可匯總報表是從廣告 (在發布商網站上) 和轉換資料 (在廣告主網站上) 收集到的資料組合而成,這些資料是在使用者裝置上的瀏覽器產生並加密,然後才由廣告技術收集。

事件層級報表的產生時間會延遲 2 到 30 天。匯總報表會在 1 小時內隨機延遲傳送,且事件必須符合貢獻預算。這些選項可保護隱私,並防止任何個別使用者的動作遭到濫用。

如果您只想查看事件層級報表,這就是最後一項基礎架構。不過,如果您想產生摘要報表,就必須使用其他服務處理可匯總的報表。

產生摘要報表

如要產生摘要報表,您必須使用匯總服務 (由廣告技術平台營運) 處理可匯總的報表。匯總服務會加入干擾因子來保護使用者隱私,並傳回最終摘要報表。

系統會收集可匯總報表、匯總報表,然後傳送至廣告技術環境。
這張圖表代表從收集端點收集資料的非同步流程,匯總報表,以及在廣告技術擁有的匯總服務上處理。

匯總服務會處理匯總報表批次,協調器只會將解密金鑰提供給匯總服務的認證版本。匯總服務接著會解密資料、匯總資料,並加入雜訊,然後以摘要報表的形式傳回結果。

可匯總報表的批次

可匯總報表必須先分批,才能進行處理。批次包含按策略分組的可匯總報表。您的策略最有可能反映特定時間範圍 (例如每日或每週)。這項程序可在做為報表端點的相同伺服器上執行。

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

時間範圍越長,結果就越不受雜訊影響。
比較等待 1 天和 1 週的差異。在 1 小時內,您會得到較小的摘要值,且結果可能會出現較多雜訊。在一天內,您會獲得較大的摘要值,因此雜訊可能會減少。

您隨時可以變更批次期間,確保系統能擷取預期流量較高的特定事件,例如年度特賣活動。您可以變更批次期間,而無須變更歸因來源或觸發條件。

匯總服務

匯總服務負責處理可匯總報表,產生摘要報表。可匯總報表會加密處理,且只能由匯總服務讀取,該服務會在受信任的執行環境 (TEE) 中運作。

匯總服務會向協調器要求解密金鑰,以便解密及匯總資料。解密並匯總後,系統會加入雜訊來保護隱私權,並以摘要報表的形式傳回。

實務人員可以產生可匯總的明文報表,在本機測試匯總服務。或者,您也可以使用 AWS 上的加密報表,搭配 Nitro Enclaves 進行測試

後續步驟

我們希望與您對話,確保我們建構的 API 適用於所有人。

討論 API

如同其他 Privacy Sandbox API,這個 API 已編寫說明文件,並公開討論

試用 API

您可以進行實驗並參與討論,瞭解 Attribution Reporting API。