おすすめのレポート方法
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このページでは、レポートの作成時に推奨される方法をいくつか紹介します。
レポートを保存、再利用する
定期的に実行するクエリのレポートを作成して保存することをおすすめします
同じレポートを何度も挿入して削除するとリソースが浪費されるためです
相対的な期間(YESTERDAY
、LAST_7_DAYS
など)を使用すると、レポートの再利用が簡単になります。
スケジュール設定されたレポート
アドホック(1 回限り)のレポートは個別に実行され、不完全なデータセットに対しても実行される可能性があるため、リソースを浪費するおそれがあります。スケジュールに基づくレポートは一括で実行され、かつその日の前のデータ処理が完了するまでは実行されないことが保証されているため、レポート リソースが最大限に活用されます。詳しくは、使用可能なスケジュール フィールドをご覧ください。
レポートのステータスをポーリングするときに指数バックオフを使用する
レポートの実行にかかる時間を予測することはできません。長さ
時間は、日付などのさまざまな要因によって、数秒から数時間の範囲になります
処理されるデータの量などに応じて
異なりますレポートの実行時間とレポートに含まれる行数との間にも相関関係はありません。そのため、実行中のレポートのステータスを定期的に確認して、
いつ終了したかを判断します。このプロセスを「ポーリング」と呼びます。
ポーリングは必要なものではありますが、実行に長時間を要するレポートに遭遇した場合、実装効率が悪いと割り当てられたリソースをすぐに使い切ってしまう可能性があります。そのためおすすめは
指数バックオフを使用して再試行回数を制限し
割り当てを節約できます
マルチパート ダウンロードを実行する
レポート ファイルは最大で数ギガバイトになる場合があります。このようなレポートを 1 回のリクエストでダウンロードすると、接続の問題が発生する可能性があります。また、1 つのリクエストが
ダウンロードが中断されて再開する方法はなく、1 回のリクエストの失敗
中断するとダウンロードを再開できません。そのため、新しい Google Chat の
マルチパート ダウンロードを使用して、大規模なダウンロードを小さなチャンクに分割します。分割された 1 回のダウンロードが失敗した場合、その時点からダウンロードを再開できます。
チャンク化には多くのメリットがありますが、各チャンクが別々のリクエストを生成します。
そのため、無駄を避けるため、最小サイズを 10 MB にすることをおすすめします。
できます。ただし、レポートサイズの平均が非常に大きい場合は、接続速度が許す限り、分割するサイズを大きくすることを検討してください。
レポートの割り当てを検討する
キャンペーン マネージャー 360 のレポート機能の責任ある使用
次の 3 つのプロダクト全体の使用量割り当てで提供されます。
アドホック レポート実行数(1 日あたり)
キャンペーン マネージャー アカウント / キャンペーン マネージャー ユーザー プロフィールが 24 時間以内に実行できるアドホック レポートの数を制限します。割り当てを超えないようにするには、次のようにします。
- 重複レポートを削減します。
- 定期的に実行されるレポートをスケジュール設定します。
- 不要な API スクリプトを無効にします。
スケジュール設定が可能なレポート数
一定期間にキャンペーン マネージャー アカウント / キャンペーン マネージャー ユーザー プロフィールがアクティブにスケジュール設定できるレポートの数を制限します。割り当てを超えないようにするには、次のようにします。
- 重複レポートを削減します。
- 不要なスケジュール設定済みレポートを無効にします。
- 不要な API スクリプトを無効にする。
同時レポート
キャンペーン マネージャー アカウント / キャンペーン マネージャーユーザー プロフィールが同時に実行できるレポートの数を制限します。割り当てを超えないようにするには、次のようにします。
- 定期的に実行するレポートをスケジュールします。
- 不要な API スクリプトを無効にします。
- バックオフ ロジックを実装します。
レポートの実装を最適化しているにもかかわらず、特定の割り当てを超えている場合は、お問い合わせフォームからキャンペーン マネージャー 360 サポートまでお問い合わせください。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-31 UTC。
[null,null,["最終更新日 2025-08-31 UTC。"],[[["\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)."]]