歸因報表:完整系統總覽

Attribution Reporting 的連結服務概略介紹 (對象為技術決策者)。

Attribution Reporting API 可讓廣告技術和廣告主評估 點擊廣告或瀏覽會促成轉換,例如購買。這個 API 需要使用 根據應用程式的 業務需求

繼續之前,請務必詳閱 Attribution Reporting 總覽: 這有助於您瞭解 API 的用途和不同輸出報表的流程 (事件層級報表) 和摘要報表)。 如果發現陌生詞彙,請參閱 Privacy Sandbox 詞彙

這篇文章的適用對象為何?

如果您符合下列情況,不妨閱讀這篇文章:

  • 你是廣告技術或廣告客戶的技術決策者。你可能會工作 應用領域、開發運作、數據資料學、IT、行銷或其他職務 做出技術導入決策你想瞭解 API 如何用於評估隱私權。
  • 您是技術從業人員 (例如開發人員、系統操作人員、 系統架構師 (或數據資料學家) 將使用 這個 API 和匯總服務環境

本文將說明 服務才能執行 Attribution Reporting API。如果您是技術人員 可以 使用此 API 進行實驗 本機儲存空間

總覽

Attribution Reporting API 包含多項服務,需要特定的 設定、用戶端設定和伺服器部署。為了判斷 請先:

  • 做出設計決策。定義您要收集的資訊、判斷任何特定廣告活動預期會產生哪些轉換,並決定要收集的報表類型。最後的輸出內容則是事件層級報表和摘要報表 (或兩者都選)。

為了支援報表功能,我們總會同時使用兩個 (有時則是三個) 元件:

  • 網站對瀏覽器通訊。於 以 Cookie 為基礎的系統,轉換和廣告參與所需的資訊就是 供您或數據分析服務彙整 這些事件。這個 API 可讓瀏覽器將轉換連結至 廣告在放送 以便查詢及分析因此,您的廣告顯示程式碼和轉換追蹤必須:
    • 告知瀏覽器應將哪些轉換歸給哪個廣告 點擊或曝光
    • 指定任何要納入最終報表的資料。
  • 資料收集:您需要收集器端點 接收報表 (在使用者的。瀏覽器的輸出內容 事件層級報表和可匯總報表都可用來 報告 (已加密,用於產生摘要報告)。

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

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

設計決策

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

輸出報表可以是:

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

您需要收集的資料取決於您的報表選項。

最終輸出內容也是輸入工具的輸入來源 做出決策舉例來說,如果您產生摘要報表 許多轉換促成總支出價值,有助團隊決定 下一個廣告活動應該指定的目標,才能產生更高的總支出。

決定要評估的指標後,即可設定用戶端 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. 這個網址的服務 (通常是廣告客戶或廣告技術供應商) 會收到要求。由於 Floodlight 決定將這項動作歸類為轉換,因此需要指示瀏覽器記錄轉換,也就是觸發歸因。為此,廣告客戶或廣告技術供應商會在回應像素請求時,加入包含轉換相關自訂資料的特殊 HTTP 標頭。

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

  7. 瀏覽器會安排傳送報表至 attributionsrc。這份報表包含:

    1. 廣告技術供應商或廣告客戶在步驟 3 中附加至來源事件的自訂歸因設定資料。
    2. 步驟 6 中的自訂轉換資料集。
    轉換。
  8. 稍後,瀏覽器會將報表傳送至 attributionsrc 中定義的端點,但會有延遲和雜訊。可匯總報表會經過加密,事件層級報表則不會。

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

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

建議您擷取對客戶而言最重要的轉換 例如購買等多種轉換類型和中繼資料 會從摘要報表中擷取

這可確保這些事件的匯總結果準確且準確。

將來源與觸發條件進行比對

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

舉例來說,當瀏覽器從 adtech.example 上的 shoes.example/shoes123,瀏覽器會在以下位置尋找來源: 符合 adtech.exampleshoes.example 的本機儲存空間。

您可以設定篩選器 (或自訂規則),用來判斷觸發事件的時機 已傳送至特定來源舉例來說,您可以將篩選器設為只計算 特定產品類別,並忽略所有其他類別。篩選器和 優先順序模型可產生更進階的歸因報表。

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

資料收集

歸因觸發條件與對應的來源進行比對時,會以下列形式傳送: 瀏覽器向廣告技術自有伺服器上的報表端點傳送報表 (有時也稱為集合端點或集合服務)。這些 可以是事件層級報表或可匯總報表。

可匯總報表 可用來產生摘要報表可匯總報表是指 系統會從廣告 (在發布商網站上) 收集的資料和轉換資料 (來自 廣告客戶的網站) 所產生並加密的廣告 使用者裝置,再由廣告技術收集相關資料。

事件層級報表會延遲 2 到 30 天的資料。可匯總報表 在一小時內以隨機延遲傳送,而且事件必須符合 貢獻預算。 這些選擇能保護隱私權,並避免有心人士濫用任何個人動作。

您只需要查看事件層級報表 所需的基礎架構不過,如要產生摘要報表 必須以額外服務處理可匯總報表

產生摘要報表

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

可匯總報表收集及批次處理,然後傳送至廣告技術環境。
此圖表代表非同步流程 批次處理報表 廣告技術自有的匯總服務處理資料

批次處理收集到的可匯總報表之後,系統就會處理批次資料 。A 罩杯 協調員 只會將解密金鑰提供給認證的匯總版本 售後服務匯總服務接著解密資料、 並在傳回結果做為摘要報表前加入雜訊

批次匯總報表

處理可匯總報表之前,您必須先批次處理。一個批次 包含策略性分組的可匯總報表。您的策略 可能反映特定時段 (例如每天或每週)。這個 因為處理程序就是您的報告端點。

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

時間範圍越長,會產生雜訊較少的結果。
比較等待 1 天和 1 週的時間。到了 1 小時,你的摘要值就會較小,而且結果可能較為雜訊。一天過後,你的摘要值就會比較大,因此雜訊量可能會比較低。

批次計算期間可隨時變更,以確保擷取特定事件 也就是銷售量較高的地區,例如年度特賣會。批次處理期間 無須變更歸因來源或觸發條件即可進行變更。

匯總服務

匯總服務負責處理以下資料的可匯總報表: 「產生摘要報表」可匯總報表會經過加密,且只能 是由匯總服務讀取的匯總服務,該服務會在受信任的執行環境中執行 (TEE)。

匯總服務會要求協調者提供的解密金鑰 解密及匯總資料。解密及匯總後 ,以保護隱私並傳回摘要報告。

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

後續步驟

我們希望與您聊聊,確保我們建構的 API 人人都能受惠

討論 API

如同其他 Privacy Sandbox API,這個 API 也都會記錄下來 公開討論

使用 API 進行實驗

您可以進行實驗並參與