关于调试归因报告的第 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.exampleas 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
typefield 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.
方法：实时检查您的集成
- 设置您的系统以生成成功调试报告。如需了解具体方法，请参阅第 2 部分：设置调试报告。
- 部署归因报告代码时，请实时检查是否在您的端点上收到一些成功调试报告。如果是，则说明您的归因报告设置正常。
- 成功调试报告仅在发生转化时发送。不过，您可能需要检查集成的设置是否正确，而与转化无关，也就是说，您需要检查来源是否已成功注册。为此，您可以依赖来源注册成功 详细调试报告。如需了解如何设置，请参阅第 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，您可能只想将这些信息用作损失分析数据（换言之，您无需采取任何行动），也可以提交 bug 或排查实现问题。如需了解详情，请参阅详细调试报告场景。
可能出现的情况
成功调试报告
对于指定的 Cookie 转化，如果您收到了成功调试报告，则表示该转化已成功通过 Attribution Reporting 注册。
您应该稍后会收到此转化的归因报告⏤，但有以下几种情况：
- 用户行为：转化发生后、归因报告发送之前清除数据、关闭浏览器等。如果用户在转化后关闭浏览器，且在一周或更长时间内未打开浏览器，则应用至少在一周或更长时间内才会发送报告。您可以将这种延迟视为损失。
- 仅适用于事件级报告：事件级报告已被其他优先级更高的报告取代。
- 可能存在网络问题。
source-success 类型的详细调试报告
对于指定 Cookie 转化的来源，如果您收到了 source-success 类型的详细调试报告，则意味着来源注册已成功完成。您不一定会收到该转化的报告，具体取决于触发器注册之后是否也成功。
有一点需要注意：
任何其他类型的详细调试报告
对于指定的 Cookie 转化，如果您收到了其他类型的详细调试报告，则不会收到成功调试报告，之后也就不会有归因报告⏤，因为详细报告意味着发生了可报告的失败。某些操作阻止了来源注册、触发器注册、报告生成或报告发送。可能的原因：
- 隐私保护方面的限制
- 存储空间上限
- 自定义规则
- 代码中的实现问题
- 浏览器错误
其中一些符合预期！要执行的操作取决于每份详细报告的 type。查看详细报告参考文档。
没有调试报告
如果对于指定的 Cookie 转化，您只收到归因报告（没有成功调试报告或详细调试报告），则意味着无法生成调试报告。可能的原因：
- 用户偏好设置（用户已关闭第三方 Cookie）
- 缺少 Cookie，或缺少调试密钥（由于缺少 Cookie，调试密钥被清除）。在
chrome://attribution-internals中，打开 Logs（日志）标签页，然后检查该标签页中是否出现任何问题。 - 在来源或触发时（但未发送归因报告时）发生的网络问题。
您是否收到了归因报告？
这就是没有收到调试报告的一个子情况：如果对于某个指定的 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- 这可能不是您期望的代码具备的行为。仔细检查您的触发器注册代码，确保所有贡献的总和不超过贡献预算。 详细信息和报告正文
意外错误（潜在的浏览器错误）
这些报告是非预期的。这可能是由浏览器错误造成的！提交 bug，并在说明中指明重现 bug 的步骤。
source-unknown-error- 详细信息和报告正文
trigger-unknown-error- 详细信息和报告正文
损失分析示例
第 1 步：设置 Cookie 并使用 Cookie 进行映射
按照第 2 部分：设置调试报告中的说明来设置系统，以生成成功调试报告和详细调试报告。
这样一来，您就可以使用基于 Cookie 的转化信息来查询相应的调试报告或归因报告。
第 2 步：确定成功注册和缺失的报告
在本示例中，假设您已使用基于 Cookie 的系统跟踪了 100 次转化。
每次记录基于 Cookie 的转化时，请查找包含与此基于 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字段。例如，您可能会发现：- 由于
pending destination limit，缺少 10 份报告（在我们的示例中为 10% 份） - 由于
trigger-aggregate-no-contributions，缺少 5 个 (= 5%) 报告。 - 由于
unknown-error，缺少 5 个 (= 5%) 报告。
- 由于
第 5 步：采取措施并排查问题
现在您已经了解了报告缺失的原因，接下来可以根据这些数据分析采取措施。
要执行的操作取决于每份详细报告的 type。如需了解详情，请参阅详细报告参考。例如：
pending-destination-limit是一项隐私保护措施。无需执行任何操作。使用此编号作为数据点，方便您查看和监控。trigger-aggregate-no-contributions可能是您这边出现实现问题的迹象。进一步分析。如有必要，请使用详细报告正文中的详细信息排查问题和修复此问题。unknown-error可能是浏览器 bug 或网络错误的迹象。如果您反复遇到此问题，请向浏览器开发者报告 bug。