关于调试归因报告的第 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 转化的成功调试报告，则表示此转化已成功注册到归因报告中。
您应该会稍后收到一份有关此转化的归因报告，但有以下几种例外情况：
- 用户行为：在转化后和发送归因报告之前清除数据、关闭浏览器等。如果用户在转化后关闭浏览器，并且一周内都没有打开浏览器，则系统将在一周或更长时间后才会发送报告。您可能会将这笔延迟视为损失。
- 仅适用于事件级报告：事件级报告会被其他优先级更高的报告取代。
- 可能存在网络问题。
类型为 source-success 的详细调试报告
如果您收到了给定 Cookie 转化的类型为 source-success 的详细调试报告，则表示来源注册成功。您可能或可能不会收到相应转化的报告，具体取决于触发器注册是否在稍后成功。
但有一个注意事项：
任何其他类型的详细调试报告
如果您针对给定 Cookie 转化收到任何其他类型的详细调试报告，则不会收到成功调试报告，因此日后也不会收到归因报告，因为详细报告表示发生了可报告的失败情况。某些问题阻止了来源注册、触发器注册、报告生成或报告发送。可能的原因：
- 隐私权限制
- 存储空间上限
- 自定义规则
- 代码中的实现问题
- 浏览器 bug
其中一些是正常现象！要执行哪项操作取决于每个详细报告的 type。查看详细报告参考文档。
没有调试报告
如果您针对给定 Cookie 转化仅收到归因报告（没有成功调试报告或详细调试报告），则表示某些因素阻止了调试报告的生成。可能的原因：
- 用户偏好设置（用户已关闭第三方 Cookie）
- 缺少 Cookie 或缺少调试密钥（由于缺少 Cookie 而清除了调试密钥）。在
chrome://attribution-internals中，打开日志标签页，然后检查其中是否显示了任何问题。 - 在来源或触发器时间点发生的网络问题，但不是在发送归因报告时发生的。
您是否在接收归因报告？
这是未收到调试报告的一个子情况：如果您未收到任何类型的报告（无任何类型的调试报告，无归因报告），则表示发生了无法报告的失败情况。可能的原因：
- 基本集成问题。如需了解如何排查这些问题，请参阅解决基本集成问题。
- 可能存在网络问题。
- 浏览器设置中的用户偏好设置（例如 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 导致的！提交 bug，并在说明中指定重现 bug 的步骤。
流量损失分析示例
第 1 步：使用 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。