报表最佳实践

先在界面中创建新报告

报告需要遵守与报告类型、过滤条件、维度和指标相关的许多限制和要求。这些限制是在 API 中强制执行的，会返回 HTTP 400 错误。为避免在构建报表时出错，我们建议您先在 Display & Video 360 界面中构建新报表。

构建报告后，点击参考文档页面上的“试用此 API”功能即可对 Query 资源执行 queries.get。您可以使用返回的 JSON 来构建未来的报告。

使用特定于报告类型的指标和过滤条件

某些指标和过滤条件值特定于某些报告类型。除了先在界面中生成报告之外，您还可以按 Bid Manager API 值来识别属于特定 ReportType 值的指标和过滤条件。

下面介绍了一些方法来确定相关的 Bid Manager API 过滤条件和指标值。下表并未详尽列出这些类型的报告可以使用的过滤条件和指标。并非所有值都能在同一个报告中结合使用。

`ReportType`	相关过滤条件和指标
`INVENTORY_AVAILABILITY`	前缀为 `FILTER_TRUEVIEW_IAR` 的过滤器。
`YOUTUBE`	前缀为 `FILTER_TRUEVIEW` 的过滤器，不包括前缀为 `FILTER_TRUEVIEW_IAR` 的过滤器。带有 `METRIC_TRUEVIEW` 前缀的指标。
`GRP`	带有 `METRIC_GRP` 前缀的指标。
`YOUTUBE_PROGRAMMATIC_GUARANTEED`	前缀为 `FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED` 的过滤器。带有 `METRIC_PROGRAMMATIC_GUARANTEED` 前缀的指标。
`REACH`	带有 `METRIC_UNIQUE_REACH` 前缀的指标。
`UNIQUE_REACH_AUDIENCE`	带有 `METRIC_UNIQUE_REACH` 前缀的指标。

保存和重复使用报告

我们建议您为定期运行的查询创建并保存报告，因为多次插入和删除同一个报告会浪费资源。在 dataRange 字段中使用设置的 Range 值（例如 PREVIOUS_DAY 或 LAST_7_DAYS）可以提高报告的可重用性。

定期生成报告

临时或一次性报告会浪费资源，因为它们是单独生成的，并且可能针对不完整的数据集执行。定期生成的报告充分利用了报告资源，因为它们是批量生成的，并且保证在前一天的数据处理完毕后才执行。如需了解详情，请参阅在安排定期生成报表时可供使用的字段。

合并类似的报告

如果您定期为不同的广告客户或合作伙伴生成具有相同指标和日期范围的报告，我们建议您合并这些报告，以优化其报告量。

您可以通过附加所有报告的过滤条件并将所有过滤条件类型添加为维度，来合并类似的报告。生成后，您可以按原始过滤条件值拆分所生成报告的各行，以生成原始报告。

考虑报告配额

您必须负责任地使用 Display & Video 360 报告功能，具体可通过以下产品级用量配额实现。

每天临时报表执行次数

限制用户在 24 小时内可生成的临时报表的数量。为确保不超出此配额，请执行以下操作：

合并类似的报告，以减少报告量。
安排定期生成临时报告，以专门减少临时报告量。
停用不必要的 API 脚本。

有效的定期报告

限制用户在指定时间可主动安排的报告数量。为确保不超出此配额，请执行以下操作：

合并类似的定期生成的报表，以减少定期生成的报表的总数。
停用不必要的定期报表。
停用不必要的 API 脚本。

并发报告

限制用户可以同时生成的报表数量。为确保不超出此配额，请执行以下操作：

安排定期生成报表。
停用不必要的 API 脚本。
使用指数退避算法逻辑进行轮询，以便跟踪报告何时完成。

如果您已优化报表实现，但发现仍超出了给定配额，请使用联系表单与 Display & Video 360 支持团队联系。

轮询报告状态时使用指数退避算法

无法预测生成报表需要多长时间。时长可能从几秒到几小时不等，具体取决于许多因素，包括日期范围和要处理的数据量，例如。此外，运行时间与报告中返回的行数之间也没有关联。因此，您需要使用 queries.reports.get 方法定期检索报告资源，并检查资源的 metadata.status.state 字段是否已更新为 DONE 或 FAILED，以确定它是否已完成运行。此过程称为“轮询”过程。

虽然轮询很有必要，但在遇到需要很长时间才能生成的报告时，如果实现效率低下，可能很快就会耗尽您的配额。因此，我们建议您使用指数退避算法来限制重试次数，从而节省配额。

指数退避算法

指数退避算法是网络应用的标准错误处理策略，在此策略中，客户端按照不断增加的时间间隔定期重试请求。如果使用得当，指数退避算法还能提高带宽使用效率、减少获得成功响应所需的请求数，并最大程度地提高并发环境中的请求吞吐量。

实现简单指数退避算法的流程如下：

向 API 发出 queries.reports.get 请求。
检索报表对象。如果 metadata.status.state 字段不是 DONE 或 FAILED，则表示报告尚未运行完毕，应继续轮询。
等待 5 秒 + 随机的毫秒数，然后重试请求。
检索报表对象。如果 metadata.status.state 字段不是 DONE 或 FAILED，则表示报告尚未运行完毕，应继续轮询。
等待 10 秒 + 随机毫秒数，然后重试请求。
检索报表对象。如果 metadata.status.state 字段不是 DONE 或 FAILED，则表示报告尚未运行完毕，应继续轮询。
等待 20 秒 + 随机毫秒数，然后重试请求。
检索报表对象。如果 metadata.status.state 字段不是 DONE 或 FAILED，则表示报告尚未运行完毕，应继续轮询。
等待 40 秒 + 随机毫秒数，然后重试请求。
检索报表对象。如果 metadata.status.state 字段不是 DONE 或 FAILED，则表示报告尚未运行完毕，应继续轮询。
等待 80 秒 + 随机毫秒数，然后重试请求。
继续使用此模式，直到报告对象更新或达到最长时间。

如果报告运行完毕且以 DONE 状态结束，您可以从 Google Cloud Storage 的 metadata.googleCloudStoragePath 字段中指定的路径检索生成的报告文件。