报表最佳实践
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本页列出了拉取报告时的一些推荐做法。
保存和重复使用报告
建议您为定期运行的查询创建并保存报表,因为多次插入和删除同一个报表会浪费资源。
使用相对日期范围(例如 YESTERDAY
或 LAST_7_DAYS
)可以使报告更便于重复使用。
定期生成报告
临时报表(即一次性报表)会浪费资源,因为它们
可以对不完整的数据集执行。定期生成的报告
充分利用报表资源,因为它们是批量生成的
保证在前一天的数据完成之前不会执行
处理。如需了解详情,请参阅在安排定期生成报表时可供使用的字段。
在轮询报告状态时使用指数退避算法
生成一个报表需要多长时间是无法预测的。生成报表所花费的时间可能从几秒到几小时不等,具体取决于许多因素,包括日期范围、要处理的数据量,等等。另外,生成报表所用的时间与报表中返回的行数之间也没有关联。因此,您需要定期检查正在生成的报表的状态
确定该任务的完成时间此过程称为“轮询”。
虽然轮询很有必要,但在遇到需要很长时间才能生成的报表时,如果编写的实现代码效率低下,可能很快就会耗尽您的配额。因此建议
可以使用指数退避算法来限制重试次数并节省配额。
分成多部分进行下载
报告文件的大小可能高达数 GB。下载此类报告
就可能会导致连接问题。此外,如果通过单个请求进行的下载操作发生中断,则完全无法恢复下载;而且这种下载操作在失败后也无法从中断处恢复下载。因此,建议您
分为多部分下载,将较大的下载内容拆分成多个较小的部分。如果
有单个数据块失败,则可以从该处继续下载。
虽然分成多部分进行下载有很多好处,但每个部分都会生成一个单独的请求。
因此,我们建议每个块的大小不小于 10 MB,以免浪费
配额。不过,如果您的报表平均大小非常大,建议您在网络连接速度允许的条件下,尽量增加每个部分的大小。
考虑报告配额
强制以负责任的方式使用 Campaign Manager 360 报告功能
通过以下三种产品级用量配额:
临时报表执行配额(每天)
旨在限制 CM 账号或 CM 用户个人资料可在 24 小时内生成的临时报表的数量。为避免超出配额,请执行以下操作:
- 减少重复的报告。
- 安排定期生成报告。
- 停用不必要的 API 脚本。
主动生成的定期报表的配额
旨在限制 CM 账号或 CM 用户个人资料可主动安排在给定时间生成的报表的数量。为避免超出配额,请采取以下措施:
- 减少重复的报告。
- 停用不必要的定期报表。
- 停用不必要的 API 脚本。
同步生成的报告的配额
限制 CM 账号或 CM 用户个人资料可同步生成的报告的数量。为避免超出配额,请采取以下措施:
- 安排定期生成报告。
- 停用不必要的 API 脚本。
- 实现退避逻辑。
如果您已优化了报告实施方式 但仍可以发现
请联系 Campaign Manager 360 支持团队,请使用
联系表单。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-31。
[null,null,["最后更新时间 (UTC):2025-08-31。"],[[["\u003cp\u003eSave and re-use reports, especially those with relative date ranges, to conserve resources.\u003c/p\u003e\n"],["\u003cp\u003eSchedule reports instead of running them ad-hoc to ensure data completeness and efficient resource usage.\u003c/p\u003e\n"],["\u003cp\u003eUtilize exponential backoff when polling for report status to avoid exhausting your quota.\u003c/p\u003e\n"],["\u003cp\u003eEmploy multipart downloads for large reports to prevent connection issues and enable resumability.\u003c/p\u003e\n"],["\u003cp\u003eBe mindful of reporting quotas (ad-hoc executions, active scheduled reports, simultaneous reports) and optimize usage accordingly.\u003c/p\u003e\n"]]],[],null,["# Reporting Best Practices\n\nThis page lists some recommended practices when pulling reports.\n\nSave and re-use reports\n-----------------------\n\nIt's recommended that you create and save reports for queries you run regularly\nbecause inserting and deleting the same report multiple times wastes resources.\nUsing [relative date ranges](/doubleclick-advertisers/current/reports#criteria.dateRange.relativeDateRange) such as `YESTERDAY` or\n`LAST_7_DAYS` makes reports more reusable.\n\nSchedule reports\n----------------\n\nAd-hoc, or one off, reports can be wasteful of resources because they are run\nindividually and may execute against an incomplete dataset. Scheduled reports\nmake the best use of reporting resources because they are run in bulk and are\nguaranteed not to execute until the previous day's data has completed\nprocessing. See the [available scheduling fields](/doubleclick-advertisers/current/reports#schedule) for details.\n\nUse exponential backoff when polling for report status\n------------------------------------------------------\n\nIt's not possible to predict how long a report will take to run. The length of\ntime can range from seconds to hours depending on many factors including date\nrange and the amount of data to be processed, for instance. There's also no\ncorrelation between report runtime and the number of rows returned in the\nreport. You therefore need to regularly check the status of a running report to\ndetermine when it has finished. This is a process known as \"polling\".\n\nWhile polling is necessary, an inefficient implementation may quickly exhaust\nyour quota when encountering a long running report. It's therefore recommended\nthat you use exponential backoff to limit retries and conserve quota.\n| **Key Point:** See [exponential backoff](/doubleclick-advertisers/upload#exp-backoff) for more information.\n\nPerform multipart downloads\n---------------------------\n\nReport files may be as large as multiple gigabytes. Downloading such reports in\na single request can lead to connection issues. Also if a single request\ndownload is interrupted, there's no way to resume it and a failed single request\ndownload cannot be resumed if interrupted. It's therefore recommended that you\nuse multipart downloads to break large downloads into smaller chunks. If a\nsingle chunk fails, the download may be resumed from that point.\n\nAlthough chunking has many benefits, each chunk generates a separate request.\nTherefore, we recommend using a minimum chunk size of 10 MB to avoid wasting\nquota. However, if your average report size is very large, consider increasing\nchunk size as much as connection speed allows.\n\nConsider reporting quotas\n-------------------------\n\nResponsible use of the Campaign Manager 360 reporting feature is enforced\nthrough the three following product-wide usage quotas:\n\n1. **Ad hoc report executions (per day)**\n\n Limits the number of ad-hoc reports a CM account / a CM user profile can run\n in a 24-hour period. To stay under quota:\n - Reduce duplicate reports.\n - Schedule reports that are run regularly.\n - Deactivate unnecessary API scripts.\n2. **Active scheduled reports**\n\n Limits the number of reports a CM account / a CM user profile can have\n actively scheduled at a given time. To stay under quota:\n - Reduce duplicate reports.\n - Deactivate unnecessary scheduled reports.\n - Deactivate unnecessary API scripts.\n3. **Simultaneous reports**\n\n Limits the number of reports a CM account / a CM user profile can run\n simultaneously. To stay under quota:\n - Schedule reports that are run regularly.\n - Deactivate unnecessary API scripts.\n - Implement [backoff logic](/doubleclick-advertisers/upload#exp-backoff).\n\nIf you've optimized your reporting implementation and you still find yourself\nexceeding your given quota, contact Campaign Manager 360 support using the\n[contact form](//support.google.com/campaignmanager/gethelp)."]]