Save and re-use reports
It's recommended that you create and save reports for queries you run regularly because
inserting and deleting the same report multiple times wastes resources. Using
ranges such as
LAST_7_DAYS makes reports more reusable.
Ad-hoc, or one off, reports can be wasteful of resources because they are run individually and may execute against an incomplete dataset. Scheduled reports make the best use of reporting resources because they are run in bulk and are guaranteed not to execute until the previous day's data has completed processing. See the available scheduling fields for details.
Use exponential backoff when polling for report status
It's not possible to predict how long a report will take to run. The length of time can range from seconds to hours depending on many factors including date range and the amount of data to be processed, for instance. There's also no correlation between report run-time and the number of rows returned in the report. You therefore need to regularly check the status of a running report to determine when it has finished. This is a process known as "polling".
While polling is necessary, an inefficient implementation may quickly exhaust your quota when encountering a long running report. It's therefore recommended that you use exponential backoff to limit retries and conserve quota.
See exponential backoff for more information.
Perform multipart downloads
Report files may be as large as multiple gigabytes. Downloading such reports in a single request can lead to connection issues. Also if a single request download is interrupted there's no way to resume it and a failed single request download cannot be resumed if interrupted. It's therefore recommended that you use multipart downloads to break large downloads into smaller chunks. If a single chunk fails, the download may be resumed from that point.
Although chunking has many benefits, each chunk generates a separate request. Therefore, we recommend using a minimum chunk size of 10MB to avoid wasting quota. However, if your average report size is very large, consider increasing chunk size as much as connection speed allows.
Limit the number of concurrent running reports
If you run more than 10 reports concurrently, any additional run requests will be throttled. Throttling causes reports to take longer to run and may lead to timeouts or errors in extreme cases. It's recommended you limit concurrent reports to 5 to stay below the limit comfortably.