這是「偵錯 Attribution Reporting」的第 3 部分 (共 3 部分)。請參閱操作說明，瞭解如何使用偵錯報表。
本教戰手冊提供操作說明，說明如何針對第 1 部分：偵錯報告簡介中列出的各種用途，使用偵錯報告。
詞彙
- 報表來源是設定歸因報表來源和觸發條件標頭的來源。瀏覽器產生的所有報表都會傳送至這個來源。在本指南中，我們使用
https://adtech.example做為報表來源範例。 - 「歸因報表」 (簡稱「報表」) 是最終報表 (事件層級或可匯總)，內含您要求的評估資料。
- 偵錯報表包含歸因報表或來源/觸發事件的其他相關資料。收到偵錯報表不一定代表有運作錯誤！偵錯報表分為兩種類型
- 「轉換偵錯報表」是一種偵錯報表，需要設定 Cookie 才能產生及傳送。假如沒有設定 Cookie 且第三方 Cookie 淘汰，轉換偵錯報表將一併停止提供。本指南介紹的所有偵錯報表都是轉換偵錯報表。
- 成功偵錯報表會追蹤成功產生歸因報表。這類指標與歸因報表直接相關。成功偵錯報表自 Chrome 101 版 (2022 年 4 月) 起提供。
- 詳細偵錯報表可追蹤缺漏報表，協助您判斷為何缺少這些報表。指出瀏覽器未記錄來源或觸發事件的情況 (這表示系統不會產生歸因報表)，以及因故無法產生或傳送歸因報表的情況。詳細偵錯報表包含
type欄位，說明來源事件、觸發事件或歸因報表未產生的原因。自 Chrome 109 版開始提供詳細偵錯報表 (2023 年 1 月推出穩定版)。 - 偵錯金鑰是可在來源端和觸發端設定的專屬 ID。偵錯金鑰可讓您對應 Cookie 型轉換和歸因型轉換。設定系統產生偵錯報表並設定偵錯金鑰後，瀏覽器會將這些偵錯金鑰納入所有歸因報表和偵錯報表。
如要進一步瞭解我們說明文件中使用的更多概念和重要詞彙，請參閱「Privacy Sandbox 詞彙」。
操作說明：即時檢查整合狀態
- 設定系統，產生成功偵錯報告。請參閱第 2 部分：設定偵錯報告。
- 每當您部署歸因報表程式碼時，請即時檢查端點是否收到一些成功偵錯報表。如果是，表示 Attribution Reporting 設定運作正常。
- 只有在發生轉換時，系統才會傳送成功偵錯報表。建議您檢查整合設定是否正確，不論是否有轉換，都要確認來源是否已成功註冊。如要達成這個目標，您可以依據來源註冊成功 詳細偵錯報表。請參閱第 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- 這可能不是您預期程式碼會有的行為。請仔細檢查觸發條件註冊程式碼，確認所有貢獻值的總和未超過貢獻預算。詳細資料和報表內文
發生非預期的錯誤 (可能是瀏覽器錯誤)
這些報告並非預期結果。這可能是瀏覽器錯誤所致！回報錯誤，並在說明中指定重現錯誤的步驟。
損失分析範例
步驟 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%) 報表遺失。
- 有 10 份報告 (在本例中為 10%) 遺失，原因是
步驟 5：採取行動並排解問題
現在您已瞭解報表遺失的原因，可以根據這些洞察資料採取行動。
應採取哪項動作，取決於各詳細報表的 type。詳情請參閱詳細報表參考資料。例如：
pending-destination-limit是一種隱私權保護措施。您不需要採取任何行動。您可以將這個數字做為資料點，用於瞭解及監控自己的曝光率。trigger-aggregate-no-contributions可能代表您導入時發生問題。請進一步分析。如要排解及修正這個問題，請使用詳細報表內文中的詳細資料。unknown-error可能是瀏覽器錯誤或網路錯誤的徵兆。如果反覆遇到這個問題，請向瀏覽器開發人員回報錯誤。