归因报告调试实战宝典

关于调试归因报告的第 3 部分(共 3 部分)。查看有关如何使用调试报告的说明。

在本实战宝典中,您将获得有关如何针对各种用例使用调试报告的说明,详见第 1 部分:调试报告简介

术语库

  • 报告来源是 [设置归因报告来源触发器标头的来源。浏览器生成的所有报告都会发送到此来源。在本指南中,我们使用 https://adtech.example 作为示例报告来源。
  • 归因报告(简称报告)是包含您请求的衡量数据的最终报告(事件级报告或可汇总报告)。
  • 调试报告包含与归因报告或者来源或触发器事件相关的其他数据。收到调试报告并不一定意味着应用无法正常运行!调试报告有两种
  • 过渡调试报告是一种调试报告,需要设置 Cookie 才能生成和发送。如果未设置 Cookie,并且第三方 Cookie 被弃用,他们将无法提供过渡性调试报告。本指南中描述的所有调试报告均为过渡性调试报告
  • 成功调试报告会跟踪成功生成的归因报告。它们与归因报告直接相关。自 Chrome 101(2022 年 4 月)起,我们便开始提供成功调试报告。
  • 详细调试报告可以跟踪缺失的报告,并帮助您确定缺失报告的原因。它们指出浏览器未记录来源或触发器事件(这意味着浏览器不会生成归因报告)的情况,以及由于某种原因无法生成或发送归因报告的情况。详细调试报告包含一个 type 字段,用于说明未生成来源事件、触发器事件或归因报告的原因。从 Chrome 109(在 2023 年 1 月推出稳定版)开始提供详细调试报告。
  • 调试键是您可以在来源端和触发器端设置的唯一标识符。借助调试键,您可以映射基于 Cookie 的转化和基于归因的转化。将系统设置为生成调试报告并设置调试键后,浏览器会将这些调试键包含在所有归因报告和调试报告中

如需了解通篇文档使用的更多概念和关键术语,请参阅 Privacy Sandbox 术语表

方法:实时检查您的集成

  1. 设置您的系统以生成成功调试报告。如需了解具体方法,请参阅第 2 部分:设置调试报告
  2. 部署归因报告代码时,请实时检查是否在您的端点上收到一些成功调试报告。如果是,则说明您的归因报告设置正常。
  3. 成功调试报告仅在发生转化时发送。不过,您可能需要检查集成的设置是否正确,而与转化无关,也就是说,您需要检查来源是否已成功注册。为此,您可以依赖来源注册成功 详细调试报告。如需了解如何设置,请参阅第 2 部分:设置调试报告

方法:分析损失并对集成进行问题排查

若要比较基于 Cookie 的转化衡量结果与归因报告报告,请使用调试键,并将 Cookie 转化数据与调试报告对应起来。请注意,调试报告会立即发送到您的端点。

概览

损失分析的步骤

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

如果是:对于所有这些成功调试报告,您应该稍后会收到归因报告,但有一些例外情况。如需了解详情,请参阅成功调试报告场景

如果不是:则意味着该转化未向归因报告注册。使用 <source_debug_key, trigger_debug_key> 对(如果没有触发器调试键,则使用来源调试键)将 Cookie 转化映射到详细调试报告。对于每种转化,您是否在某个时间点(来源或触发时间)收到了相应的详细调试报告?

  • 如果您没收到详细调试报告:这可能是由于用户行为或集成问题造成的。如需了解详情,请参阅“无调试”报告场景

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

    • 如果其 typesource-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。