归因报告调试实战宝典

关于调试归因报告的第 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 的转化衡量结果与 Attribution Reporting 报告进行比较,请使用调试密钥,并将 Cookie 转化与调试报告相关联。请注意,调试报告会立即发送到您的端点。

概览

损失分析的步骤
损失分析的步骤

使用调试键(<source_debug_key, trigger_debug_key> 对)将 Cookie 转化映射到成功调试报告。 对于每次 Cookie 转化,您是否在转化时收到了相应的成功调试报告?

如果为“是”:对于所有这些成功调试报告,您都可以期待稍后收到归因报告,但有少数例外情况。如需了解详情,请查看成功调试报告方案

如果不是:这意味着转化未在 Attribution Reporting 中注册。使用 <source_debug_key, trigger_debug_key> 对(如果缺少触发调试键,则使用来源调试键)将 Cookie 转化映射到详细的调试报告。对于每项转化,您是否在某个时间点(来源时间或触发时间)收到了相应的详细调试报告?

  • 如果您未收到详细的调试报告,可能是因为用户行为或集成问题。如需了解详情,请参阅无调试报告情景

  • 如果您确实收到了详细的调试报告,请查看其 type 字段。

    • 如果其 typesource-success:这表示来源已成功注册,但触发器未成功注册。如需缩小成功调试报告缺失的原因,请查找任何其他类型的相应详细调试报告,该报告将指示触发器方面存在问题。

    • 如果其 type 是其他任何值:表示来源或触发器尚未注册。type会告诉您原因。相应的归因报告(以及成功调试报告)将丢失。根据详细调试报告的 type,您可能只想将此信息视为损失分析数据点(换句话说,您无需采取任何行动),也可能想要提交 bug 或排查实现方面的问题。如需了解详情,请参阅详细调试报告方案

可能的情形

成功调试报告

如果针对给定的 Cookie 转化,您收到了成功调试报告,则表示此转化已成功注册到 Attribution Reporting。

您之后会收到相应转化的归因报告,但有以下几种例外情况:

  • 用户行为:在转化后和归因报告发送之前清除数据、关闭浏览器等。如果用户在转化后关闭浏览器,并且在一周内未打开浏览器,则报告将在一周或更长时间内不会发送。您可能会将此延迟视为损失。
  • 仅适用于事件级报告:事件级报告被另一个优先级更高的报告取代。
  • 可能存在的网络问题。

类型为 source-success 的详细调试报告

如果针对给定 Cookie 转化的来源,您收到了类型为 source-success 的详细调试报告,则表示来源注册成功。根据触发器注册是否在稍后也成功,您可能会收到或不会收到相应转化的报告。

不过,需要注意以下一点:

任何其他类型的详细调试报告

如果针对给定的 Cookie 转化,您收到了任何其他类型的详细调试报告,则不会收到成功调试报告,因此之后也不会收到归因报告,因为详细报告意味着发生了可报告的失败。某些因素导致来源注册、触发注册、报告生成或报告发送失败。可能的原因:

  • 隐私权限制
  • 存储空间上限
  • 自定义规则
  • 代码中的实现问题
  • 浏览器 bug

其中一些是预期情况!具体采取哪种操作取决于每个详细报告的 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
这可能不是您希望代码具有的行为。仔细检查您的触发注册代码,确保所有贡献的总和不超过贡献预算。 详细信息和报告正文

意外错误(可能存在浏览器 bug)

这些报告出乎意料。这可能是浏览器 bug 导致的!提交 bug,并在说明中指定重现步骤。

source-unknown-error
详细信息和报告正文
trigger-unknown-error
详细信息和报告正文

流失分析示例

第 1 步:设置和 Cookie 映射

按照第 2 部分:设置调试报告中的说明设置系统,以生成成功调试报告详细调试报告

这样一来,您就可以使用基于 Cookie 的转化信息来查找相应的调试报告或归因报告。

第 2 步:确定成功注册的商品和缺失的报告

在此示例中,我们假设您已通过基于 Cookie 的系统跟踪了 100 次转化。

每次记录基于 Cookie 的转化时,请查找与该基于 Cookie 的转化具有相同 <source_debug_key, trigger_debug_key> 对的成功调试报告(立即发送)。

假设您已收到其中 70 次 Cookie 转化成功的调试报告。

  • 成功报告表示归因已成功记录,因此您可以放心地假设,您将获得与每个成功报告对应的归因报告,但也有一些例外情况。
  • 您可以决定是否监控这些异常。为此,在接下来的几天或几周内(具体取决于过期时间),当归因报告发送到您的端点时,请查找与每个成功调试报告具有相同调试键对的归因报告。请务必稍等片刻:报告可能不会在每个时间段结束时立即发送。假设您只找到了 60 份归因报告。缺少 10 份归因报告可能是因为用户行为。

第 3 步:简短的损失评估

100-70 = 30 个归因成功调试报告缺失。这意味着,在基于 Cookie 的实现中跟踪到的这 30 次转化未通过归因报告记录。您将不会收到这些广告系列的归因报告。

由于您有 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 报告。