報表最佳做法
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本頁面列出擷取報表時的最佳做法。
儲存及重複使用報表
建議您為定期執行的查詢建立及儲存報表,因為多次插入及刪除相同的報表會浪費資源。使用相對日期範圍,例如 YESTERDAY
或
LAST_7_DAYS
讓報表更容易重複使用。
安排定期報表
臨時或一次性的報表可能會因為執行報表而浪費資源
也可能會針對不完整的資料集執行預定報表可充分運用報表資源,因為報表會大量執行,且系統會確保在前一天的資料處理完成前,不會執行報表。詳情請參閱可用的排程欄位。
在輪詢報表狀態時使用指數輪詢
我們無法預測報表的執行時間。長度
時間可能從幾秒到幾小時,取決於許多因素 (包括日期)
以及要處理的資料量,例如報表執行時間與報表中傳回的資料列數之間也沒有關聯。因此,你必須定期查看執行中報表的狀態,直到
判斷是否完成後這個程序稱為「輪詢」。
雖然必須進行輪詢,但效率不佳的實作方式可能會快速耗盡
提高配額。因此建議使用
採用指數輪詢策略來限制重試次數並節省配額。
執行多部分下載
報表檔案的大小可能超過數 GB。在單一要求中下載這類報表可能會導致連線問題。此外,如果單一請求
下載中斷,而且無法恢復下載以及單一請求失敗
下載作業中斷。因此,建議您使用多部分下載功能,將大型下載作業拆成較小的部分。如果
單一區塊失敗,您可以從該區塊繼續下載。
雖然區塊化有許多好處,但每個區塊會產生單獨的要求。
因此,建議您使用至少 10 MB 的片段大小,以免浪費配額。不過,如果平均報表大小非常龐大,建議您增加報表大小
區塊大小。
考慮回報配額
強制要求以負責任的方式使用 Campaign Manager 360 報表功能
共有三項產品用量配額:
臨時報表執行次數 (每日)
限制 CM 帳戶/CM 使用者設定檔在 24 小時內執行臨時報表的數量。如何避免超出配額:
- 減少重複的報表。
- 安排定期執行報表。
- 停用不必要的 API 指令碼。
啟用的定期報表
限制 CM 帳戶/CM 使用者個人資料在特定時間內可定期執行的報表數量。如何避免超出配額:
- 減少重複的報表。
- 停用不必要的定期報表。
- 停用不必要的 API 指令碼。
同時產生報表
限制 CM 帳戶 / CM 使用者個人資料可執行的報表數量
。如何避免超出配額:
- 安排定期執行報表。
- 停用不必要的 API 指令碼。
- 實作輪詢邏輯。
如果您已最佳化報表導入方式,
超過指定配額時,請與 Campaign Manager 360 支援團隊聯絡,方法是使用
聯絡表單。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-31 (世界標準時間)。
[null,null,["上次更新時間: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)."]]