歸因報表偵錯教戰手冊

這是「偵錯 Attribution Reporting」的第 3 部分 (共 3 部分)。請參閱操作說明，瞭解如何使用偵錯報表。

本教戰手冊提供操作說明，說明如何針對第 1 部分：偵錯報告簡介中列出的各種用途，使用偵錯報告。

詞彙

  • The reporting origin is the origin that sets the Attribution Reporting source and trigger headers. All reports generated by the browser are sent to this origin. In this guidance, we use https://adtech.example as the example reporting origin.
  • An attribution report (report for short) is the final report (event-level or aggregatable) that contains the measurement data you've requested.
  • A debug report contains additional data about an attribution report, or about a source or trigger event. Receiving a debug report does not necessarily mean that something is working incorrectly! There are two types of debug reports
  • A transitional debug report is a debug report that requires a cookie to be set in order to be generated and sent. Transitional debug reports will be unavailable if a cookie is not set, and once third-party cookies are deprecated. All debug reports described in this guide are transitional debug reports.
  • Success debug reports track successful generation of an attribution report. They relate directly to an attribution report. Success debug reports have been available since Chrome 101 (April 2022).
  • Verbose debug reports can track missing reports and help you determine why they're missing. They indicate cases where the browser did not record a source or trigger event, (which means it will not generate an attribution report), and cases where an attribution report can't be generated or sent for some reason. Verbose debug reports include a type field that describes the reason why a source event, trigger event or attribution report was not generated. Verbose debug reports are available starting in Chrome 109 (Stable in January 2023).
  • Debug keys are unique identifiers you can set on both the source side and the trigger side. Debug keys enable you to map cookie-based conversions and attribution-based conversions. When you've set up your system to generate debug reports and set debug keys, the browser will include these debug keys in all attribution reports and debug reports.

For more concepts and key terms used throughout our documentation, refer to the Privacy Sandbox glossary.

操作說明：即時檢查整合狀態

  1. 設定系統，產生成功偵錯報告。請參閱第 2 部分：設定偵錯報告。
  2. 每當您部署歸因報表程式碼時，請即時檢查端點是否收到一些成功偵錯報表。如果是，表示 Attribution Reporting 設定運作正常。
  3. 只有在發生轉換時，系統才會傳送成功偵錯報表。建議您檢查整合設定是否正確，不論是否有轉換，都要確認來源是否已成功註冊。如要達成這個目標，您可以依據來源註冊成功 詳細偵錯報表。請參閱第 2 部分：設定偵錯報表，瞭解如何設定。

操作說明：分析損失並排解整合問題

如要比較以 Cookie 為準的轉換評估結果與歸因報表，請使用偵錯金鑰，並透過偵錯報表對應 Cookie 轉換。請注意，系統會立即將偵錯報表傳送至端點。

總覽

損失分析步驟
損失分析步驟

使用偵錯金鑰 (<source_debug_key, trigger_debug_key> 配對) 將 Cookie 轉換對應至成功偵錯報表。 針對每個 Cookie 轉換，您是否在轉換時收到相應的成功偵錯報表？

如果符合：您稍後會收到所有這些成功偵錯報表的歸因報表，但有幾種情況除外。如需詳細資料，請參閱成功偵錯報告情境。

如果不是：表示歸因報表未登錄轉換。使用 <source_debug_key, trigger_debug_key> 配對 (或來源偵錯金鑰，如果沒有觸發偵錯金鑰) 將 Cookie 轉換對應至詳細的偵錯報表。針對這些轉換，您是否在某個時間點 (來源或觸發時間) 收到相應的詳細偵錯報表？

  • 如果沒有收到詳細的偵錯報告，可能是因為使用者行為或整合問題。如需詳細資訊，請參閱沒有偵錯報告的情況。

  • 如果收到詳細的偵錯報表，請查看 type 欄位。

    • 如果 type 為 source-success，表示來源已成功註冊，但觸發事件未註冊。如要縮小範圍，找出缺少成功偵錯報表的原因，請尋找任何其他類型的對應詳細偵錯報表，該報表會指出觸發端的相關問題。

    • 如果 type 是其他值：表示來源或觸發事件尚未登錄。type會說明原因。對應的歸因報表 (和成功偵錯報表) 將會遺失。視詳細偵錯報告的 type 而定，您可能只想將這項資訊視為損失分析資料點 (換句話說，您不必採取任何行動)，或是想提出錯誤報告或排解實作問題。如需詳細資訊，請參閱詳細偵錯報告情境。

可能的情境

成功偵錯報表

如果特定 Cookie 轉換的偵錯報表顯示成功，表示轉換已成功登錄至 Attribution Reporting。

您稍後應會收到這項轉換的歸因報表，但有幾種例外情況：

  • 使用者行為：在轉換後和傳送歸因報表前清除資料、關閉瀏覽器等。如果使用者在轉換後關閉瀏覽器，且一週內未開啟瀏覽器，系統就不會傳送報表，時間可能長達一週以上。這類延遲可能會造成損失。
  • 僅適用於事件層級：事件層級報表遭優先順序較高的報表取代。
  • 網路可能發生問題。

類型為 source-success 的詳細偵錯報表

如果特定 Cookie 轉換的來源收到 source-success 類型的詳細偵錯報表，表示來源登錄成功。視觸發事件登錄是否成功而定，您可能會收到或不會收到該轉換的報表。

但請注意以下事項：

任何其他類型的詳細偵錯報表

如果針對特定 Cookie 轉換收到任何其他類型的詳細偵錯報表，您就不會收到成功偵錯報表，因此稍後也不會收到歸因報表，因為詳細報表表示發生可回報的失敗情況。發生錯誤，無法登錄來源、登錄觸發、產生或傳送報表。可能原因：

  • 隱私權限制
  • 儲存空間上限
  • 自訂規則
  • 程式碼中的導入問題
  • 瀏覽器錯誤

其中有些是預期會發生的情況！應採取哪項動作，取決於各詳細報表的 type。請參閱詳細報表參考資料。

沒有偵錯報表

如果特定 Cookie 轉換只收到歸因報表，而沒有收到成功偵錯報表或詳細偵錯報表，表示系統無法產生偵錯報表。可能原因：

  • 使用者偏好設定 (使用者已關閉第三方 Cookie)
  • 缺少 Cookie 或偵錯鍵 (偵錯鍵因缺少 Cookie 而清除)。在 chrome://attribution-internals 中，開啟「記錄」分頁，檢查是否有任何問題。
  • 來源或觸發時間發生網路問題，但傳送歸因報表時沒有問題。

您是否收到歸因報表？

這是未收到偵錯報表的子情況：如果特定 Cookie 轉換未產生任何報表 (沒有任何偵錯報表，也沒有歸因報表)，表示發生無法回報的失敗。可能原因：

  • 基本整合問題。如要瞭解如何排解這些問題，請參閱「修正基本整合問題」。
  • 網路可能發生問題。
  • 瀏覽器設定中的使用者偏好設定 (例如 Privacy Sandbox) 已關閉。

詳細偵錯報表參考資料

每份詳細偵錯報表都有 type 欄位，可擷取對應歸因報表遭捨棄的原因。請參閱參考資料，瞭解針對每個詳細報表 type 應採取的動作。

來源登錄成功

來源已成功註冊。

source-success
詳細資料和報表主體

隱私權限制報表

這是預期情況。這些限制會減少跨網站使用者身分識別資訊外洩。

source-destination-limit
詳細資料和報表主體
source-noised
詳細資料和報表主體
trigger-attributions-per-source-destination-limit
詳細資料和報表主體
trigger-reporting-origin-limit
詳細資料和報表主體
trigger-event-noise
詳細資料和報表主體
trigger-event-excessive-reports
如果報表計數超過上限，系統就會產生這項錯誤。您最多可為瀏覽次數登錄一次轉換，為點擊次數登錄三次轉換。請注意，您可以設定優先順序，決定要接收哪些報表。 詳細資料和報表內文

儲存空間限制報表

這是預期情況。這些限制可避免資源用量過高。

source-storage-limit
詳細資料和報表主體
trigger-event-storage-limit
詳細資料和報表主體
trigger-aggregate-storage-limit
詳細資料和報表主體

自訂規則報表

如果您使用篩選、重複資料刪除、優先順序或以時間範圍為準的篩選功能，這些報表是預期結果。為求保險，請再次檢查對應的自訂規則，確認與詳細報表相應的報表確實是您要捨棄的報表。如果這項資訊正確無誤，您就不必採取任何行動。

trigger-no-matching-filter-data
詳細資料和報表主體
trigger-event-no-matching-configuration
詳細資料和報表主體
trigger-event-deduplicated
詳細資料和報表主體
trigger-aggregate-deduplicated
詳細資料和報表主體
trigger-event-low-priority
詳細資料和報表主體
trigger-event-report-window-passed
詳細資料和報表主體
trigger-aggregate-report-window-passed
詳細資料和報表主體

其他詳細報表

這些報表可能會指出程式碼中潛在的導入問題。

trigger-no-matching-source
這可能是導入問題。請檢查 <reporting origin, destination> 設定是否正確無誤。這也可能是預期的 API 行為。舉例來說，使用者在與廣告互動後到完成轉換前，曾清除資料；或是使用者完成轉換，但從未看過相關聯的廣告。 詳細資料和報表內文
trigger-aggregate-no-contributions
這可能不是您預期程式碼會有的行為。排解觸發條件註冊程式碼的問題，並確認貢獻設定正確無誤。 詳細資料和報表內文
trigger-aggregate-insufficient-budget
這可能不是您預期程式碼會有的行為。請仔細檢查觸發條件註冊程式碼，確認所有貢獻值的總和未超過貢獻預算。詳細資料和報表內文

發生非預期的錯誤 (可能是瀏覽器錯誤)

這些報告並非預期結果。這可能是瀏覽器錯誤所致！回報錯誤，並在說明中指定重現錯誤的步驟。

source-unknown-error
詳細資料和報表主體
trigger-unknown-error
詳細資料和報表主體

損失分析範例

步驟 1：使用 Cookie 設定及對應

按照「第 2 部分：設定偵錯報表」中的操作說明，設定系統產生成功偵錯報表和詳細偵錯報表。

這樣一來，您就能使用以 Cookie 為準的轉換資訊，查詢相應的偵錯報表或歸因報表。

步驟 2：找出註冊成功的項目和缺少的報告

在這個例子中，假設您已透過 Cookie 型系統追蹤 100 次轉換。

每次記錄以 Cookie 為準的轉換時，請尋找與該轉換具有相同 <source_debug_key, trigger_debug_key> 配對的成功偵錯報表 (系統會立即傳送)。

假設您收到 70 個這類 Cookie 轉換的成功偵錯報表。

  • 成功報表表示系統已成功記錄歸因，因此您可以放心，系統會提供與每份成功報表相應的歸因報表 (少數情況除外)。
  • 您可以決定是否要監控這些例外狀況。如要這麼做，請在歸因報表於接下來幾天或幾週 (視到期日而定) 傳送至端點時，找出與各項成功偵錯報表具有相同偵錯金鑰配對的歸因報表。請稍待片刻，報表可能不會在每個時間範圍結束時立即傳送。假設您只找到 60 份歸因報表，這 10 份歸因報表可能因使用者行為而遺失。

步驟 3：簡要評估損失

100 - 70 = 30 份成功偵錯報表遺失。也就是說，這 30 個轉換 (透過以 Cookie 為基礎的導入方式追蹤) 並未透過歸因報表記錄。您不會收到這些轉換的歸因報表。

由於您有 100 個以 Cookie 為準的轉換，但只有 70 個以歸因為準的轉換，因此損失為 30%。您現在可以進行簡短的損失評估。

步驟 4：分析原因

如要調查缺少這些報表的原因，請在轉換 (觸發事件登錄) 時間或更早的來源登錄時間，尋找相應的詳細偵錯報表。使用以 Cookie 為準的轉換金鑰，將這些轉換對應至詳細的偵錯報表。

  • 假設有 10 個金鑰沒有詳細的偵錯報表。檢查是否有任何整合問題。如果不是，可能是因為使用者行為。
  • 您有 20 份詳細偵錯報表。現在可以進一步分析損失。分析每份詳細報表的 type 欄位。舉例來說，你可能會發現：
    • 有 10 份報告 (在本例中為 10%) 遺失，原因是 pending destination limit
    • 由於trigger-aggregate-no-contributions，有 5 份 (5%) 報表遺失。
    • 由於unknown-error，有 5 份 (5%) 報表遺失。

步驟 5：採取行動並排解問題

現在您已瞭解報表遺失的原因，可以根據這些洞察資料採取行動。

應採取哪項動作，取決於各詳細報表的 type。詳情請參閱詳細報表參考資料。例如：

  • pending-destination-limit 是一種隱私權保護措施。您不需要採取任何行動。您可以將這個數字做為資料點，用於瞭解及監控自己的曝光率。
  • trigger-aggregate-no-contributions 可能代表您導入時發生問題。請進一步分析。如要排解及修正這個問題，請使用詳細報表內文中的詳細資料。
  • unknown-error可能是瀏覽器錯誤或網路錯誤的徵兆。如果反覆遇到這個問題，請向瀏覽器開發人員回報錯誤。