Attribution Reporting API：整合指南

詳閱 Android 版 Privacy Sandbox 說明文件時，請利用「開發人員預覽版」或「Beta 版」按鈕選取您要使用的計畫版本，因為兩者的操作說明可能不盡相同。

Attribution Reporting API 的設計旨在不仰賴跨方使用者 ID 的情況下，在重要用途上支援應用程式和網頁的歸因與轉換評估功能。相較於現今常見的設計，Attribution Reporting API 實作人員應考量一些整體層面的重要考量：

  • 事件層級報表提供低精確度的轉換資料。只要少量的轉換價值就能順利運作。
  • 可匯總報表提供高精確度的轉換資料。您的解決方案應該依據業務需求和 128 位元限制來設計匯總鍵。
  • 解決方案的資料模型和處理作業應將可用觸發條件的頻率限制、傳送觸發事件的延遲時間，以及 API 所套用的雜訊納入考量。

為協助您規劃整合作業，本指南提供了全面性的總覽，其中可能包含尚未在 Privacy Sandbox 當前 Android 開發人員預覽階段中實作的功能。在這類情況下，我們會提供時間軸指引。

本頁面使用「來源」代表點擊或瀏覽，並以「觸發條件」代表轉換。

以下圖表顯示歸因整合的不同工作流程選項。同一欄中列出的各個部分 (用綠色圈起) 可以並行處理，例如合作夥伴互動與應用程式對應用程式事件層級歸因作業可同時完成。

歸因整合工作流程圖表

圖 1. 歸因整合工作流程。

事前準備和設定

只要完成本節所述的步驟，就能進一步瞭解 Attribution Reporting API。這些步驟將為您說明如何在廣告技術生態系統中，使用這個 API 收集有意義的結果。

熟悉 API

  1. 詳閱設計提案，熟悉 Attribution Reporting API 和相關功能。
  2. 詳閱開發人員指南，瞭解如何整合您的用途需要的程式碼和 API 呼叫。
  3. 針對說明文件提交任何意見回饋，特別是對沒有定論的問題提供意見回饋。
  4. 註冊即可接收 Attribution Reporting API 的最新消息，有助於隨時掌握日後版本推出的新功能。

設定並測試範例應用程式

  1. 準備好開始進行整合時，請自行設定最新的 Android Studio 開發人員預覽版。
  2. 設定模擬伺服器端點，進行事件登錄及報表提交作業。 我們提供了模擬內容，方便您與線上工具搭配使用。
  3. 下載並執行範例應用程式中的程式碼，瞭解如何登錄來源和觸發條件。
    1. 設定報表的傳送期。這個 API 支援 2 天、7 天的傳送期，或是介於 2 至 30 天之間的自訂週期。
    2. 執行及使用範例應用程式登錄來源和觸發條件，且設定的傳送期過後，請確認您有收到事件層級報表和經過加密的可匯總報表。如果需要對報表進行偵錯，可以強制執行報表工作，提早產生報表。
    3. 查看應用程式對應用程式歸因的結果。確認這些結果中的資料，就是上次接觸和安裝後情況預期會顯示的資料。

  4. 熟悉用戶端 API 和伺服器搭配運作的方式後，請使用範例應用程式做為例子，引導您進行整合。設定自己的實際執行伺服器，並在應用程式中新增事件登錄呼叫。

整合前置作業

為貴機構註冊 Android 版 Privacy Sandbox。這項註冊旨在避免廣告技術平台出現不必要的重複情形，這樣會讓系統允許存取更多有關使用者活動的資訊。

合作夥伴參與

廣告技術合作夥伴 (MMP/SSP/DSP) 通常會建立整合式歸因解決方案。本節所述步驟可協助您做好準備，以便與廣告技術合作夥伴互動。

  1. 安排時間與頂尖的評估合作夥伴討論如何測試及採用 Attribution Reporting API。評估合作夥伴包括廣告技術聯播網、SSP、DSP、廣告客戶，或您目前合作中或想合作的任何其他合作夥伴。
  2. 與評估合作夥伴共同定義整合作業的時程，包括初始測試和採用情形。
  3. 與評估合作夥伴釐清各自負責的歸因設計面向。
  4. 建立評估合作夥伴之間的通訊管道，以便同步時程和端對端測試。
  5. 為所有評估合作夥伴設計高階資料流。重要注意事項包括：
    • 評估合作夥伴如何透過 Attribution Reporting API 登錄歸因來源？
    • 廣告技術聯播網如何透過 Attribution Reporting API 登錄觸發條件？
    • 各項廣告技術如何驗證 API 要求，並傳回回應以完成來源和觸發條件的登錄程序？
    • 除 Attribution Reporting API 以外，是否需要在所有合作夥伴之間分享任何報表？
    • 合作夥伴之間是否需要任何其他整合點或調整方式？舉例來說，您和合作夥伴是否需要進行簡化轉換作業，或是使用相同的匯總鍵？
  6. 如果適用應用程式至網頁歸因功能，請安排時間與網頁評估合作夥伴討論如何設計、測試及採用 Attribution Reporting API。開始與網頁評估合作夥伴對話時，請參考上一個步驟中的問題。

設計應用程式對應用程式事件層級歸因作業的原型

本章節可協助您在應用程式或 SDK 中，設定基本的應用程式對應用程式歸因作業與事件層級報表。您必須先完成本節所述的步驟，才能開始設計匯總伺服器歸因作業的原型。

  1. 設定事件記錄專用的收集伺服器，方法是利用系統提供的規格產生模擬伺服器，或是使用伺服器程式碼範例自行設定伺服器。
  2. 在 SDK 或應用程式中，加入要在廣告顯示時登錄來源事件的呼叫。
    • 重要注意事項包括：
      • 確認來源事件 ID 可用，並正確傳遞至來源登錄 API 呼叫。
      • 確認您也可以傳入「InputEvent」來登錄點擊來源。
      • 決定如何為不同事件類型設定來源優先順序。舉例來說，視為具有高價值的事件應指派高優先順序，例如點擊的優先順序高於瀏覽。
      • 預設的效期可用於測試，但您也可以設定不同的效期。
      • 篩選器和歸屬期可保留預設值，用來進行測試。
    • 選擇性注意事項包括：
      • 準備就緒後，即可設計匯總鍵。
      • 規劃與其他評估服務合作夥伴的合作方式時，請將重新導向策略納入考量。
  3. 在 SDK 或應用程式中新增登錄觸發條件事件，藉此記錄轉換事件。
    • 重要注意事項包括：
    • 選擇性注意事項包括：
      • 在進行準確率測試之前，請略過建立簡化鍵的程序。
      • 在模擬測試支援準備就緒之前，請略過建立匯總鍵和值的程序。
      • 在建立與其他評估服務合作夥伴的合作方式之前，請略過重新導向作業。
      • 進行測試時，不一定需要設定觸發條件優先順序。
      • 初始測試可能可以忽略篩選器。
  4. 測試系統是否能為廣告產生來源事件，以及測試觸發條件能否引發事件報表的建立程序。

模擬測試

本節將逐步說明如何測試將目前轉換移至事件報表和可匯總報表，對報表和最佳化系統可能造成的影響。這樣您就可以在完成整合作業前，開始進行影響測試。

測試方法是透過模擬以下程序完成：根據您擁有的歷來轉換記錄產生事件報表和可匯總報表，然後從模擬匯總伺服器取得匯總結果。您可以將這些結果與歷來轉換數據進行比較，觀察報表準確率的變化。

您可以透過這些報表訓練最佳化模型 (例如預測轉換率的計算方式)，將這些模型的準確率與根據目前資料建構的模型相比較。此外，您還可以藉此實驗不同的匯總鍵結構，以及這些結構對結果的影響。

  1. 在本機電腦上設定測量模擬資料庫。
  2. 詳閱spec，瞭解如何設定轉換資料格式，以便與模擬報表產生器相容。
  3. 根據業務需求設計匯總鍵。
    • 重要注意事項包括：
      • 思考客戶或合作夥伴需要匯總的重要維度，並重點評估這些維度。
      • 決定滿足您需求的匯總維度與基數下限。
      • 確保來源端和觸發條件端的鍵長度不超過 128 位元。
      • 如果您的解決方案會導致單一觸發事件產生多個值，請務必根據最大貢獻預算 L1 進行調整。這麼做可盡量減少雜訊影響。
      • 這裡的範例會詳細說明如何設定鍵，用來收集廣告活動層級的匯總轉換次數，以及另一個用來收集地理區域層級匯總購物價值的鍵。
  4. 執行報表產生器，建立事件報表和可匯總報表。
  5. 透過模擬匯總伺服器執行可匯總報表，取得摘要報表。
  6. 執行公用程式實驗：
    • 將事件層級報表和摘要報表中的轉換總數與歷來資料轉換資料相比較，判斷轉換報表準確率。為獲得最佳成果，請針對具有廣泛代表性的廣告客戶群執行報表測試及比較。
    • 根據事件層級報表資料 (可能還要加上摘要報表資料) 重新訓練模型。比較以歷來訓練資料為基礎建構的模型的準確率。
    • 嘗試不同的批次處理策略，觀察這些策略如何影響結果。
      • 重要注意事項包括：
      • 摘要報表的時效性 (用於調整出價)。
      • 裝置上可歸因事件的平均頻率。例如，根據歷來購買事件資料的已流失使用者回流。
      • 雜訊等級。批次數越多表示匯總結果越小，而匯總結果越小就代表套用的雜訊越多。

設計匯總伺服器歸因作業的原型：設定

以下步驟可確保您能收到來源和觸發事件的可匯總報表。

  1. 設定匯總伺服器：
    • 設定 AWS 帳戶。
    • 使用協調工具註冊匯總服務。
    • 透過所提供的二進位檔，在 AWS 設定匯總伺服器。
  2. 根據業務需求設計匯總鍵。如果您已在應用程式對應用程式事件層級章節中完成這項工作，可以略過這個步驟。
  3. 設定可匯總報表專用的收集伺服器。如果您已在應用程式對應用程式事件層級章節中建立此伺服器，可以重複使用。

設計匯總伺服器歸因作業的原型：整合

如要繼續操作，您必須完成「設計匯總伺服器歸因作業的原型：設定」或「設計應用程式對應用程式事件層級歸因作業的原型」章節所述步驟**。

  1. 在來源和觸發事件中加入匯總鍵資料。這可能需要將更多有關廣告事件的資料 (例如廣告活動 ID) 傳送到 SDK 或應用程式，以便加入匯總鍵中。
  2. 從使用匯總鍵資料登錄的來源和觸發事件，收集應用程式對應用程式可匯總報表。
  3. 透過匯總伺服器執行這些可匯總報表時，測試不同的批次處理策略，觀察這些策略如何影響結果。

運用選用功能反覆改進設計

以下是可納入成效評估解決方案的其他功能。

  1. 設定偵錯金鑰可用於接收未經修改的來源或觸發事件報表，以及由 Attribution Reporting API 產生的報表。您可以使用偵錯金鑰，在整合期間比較報表並找出錯誤。

自訂歸因行為

  1. 安裝後觸發條件的歸因功能
    • 只有在需要將安裝後觸發條件歸因至促成安裝的同一歸因來源時，才能使用這項功能，就算在更近的時間點有其他符合資格的歸因來源也一樣。
    • 舉例來說，假設使用者點選一個廣告，而該廣告促成安裝。使用者在安裝後又點選其他廣告並完成購物。在此情況下，廣告技術公司可能會希望將購買功勞歸給最初點擊，而非回訪點擊。
  2. 運用篩選器精細調整事件層級報表中的資料
    • 您可以設定轉換篩選器，忽略所選觸發條件並將其從事件報表中排除。每個歸因來源的觸發條件有數量上限，因此可利用篩選器，只將提供最實用資訊的觸發條件納入事件報表。
    • 此外，使用篩選器過濾部分觸發條件，可以有效忽略這些觸發條件。舉例來說，如果廣告活動以應用程式安裝為指定目標，建議您濾除安裝後觸發條件，避免將其歸因至該廣告活動的來源。
    • 篩選器也可用於依據來源資料自訂觸發條件資料。舉例來說，來源可以指定 "product" : ["1234"]，其中「product」是篩選器索引鍵，而「1234」則是值。如果觸發條件含有「product」篩選器索引鍵，且其值不是「1234」，系統就會予以忽略。
  3. 自訂來源與觸發條件優先順序
    • 如果有多個歸因來源可與特定觸發條件建立關聯，或者有多個觸發條件可歸因至同一來源，您可以使用經過簽署的 64 位元整數，設定特定來源/觸發條件的歸因優先順序高於其他項目。

與 MMP 等服務供應商合作

  1. 將來源和觸發條件重新導向至其他第三方
    • 您可以設定重新導向網址，讓多個廣告技術平台登錄單一要求。這可用於在歸因作業中啟用跨聯播網簡化資料。
  2. 簡化鍵
    • 如果廣告客戶使用多個廣告技術平台登錄同一觸發事件，可以使用簡化鍵來區分這類重複的報表。如未提供簡化鍵，系統可能會將重複的觸發事件當做不重複事件回報給各項廣告技術平台。

使用跨平台評估服務

  1. 跨應用程式和網頁歸因功能 (將於第 4 季末推出)
    • 支援使用者在應用程式中看到廣告，然後在行動瀏覽器或應用程式瀏覽器中完成轉換的情況；反之亦然。