Reporting Best Practices

This page lists some recommended practices when pulling reports.

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 relative date ranges such as YESTERDAY or LAST_7_DAYS makes reports more reusable.

Schedule reports

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 runtime 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.

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 10 MB to avoid wasting quota. However, if your average report size is very large, consider increasing chunk size as much as connection speed allows.

Consider reporting quotas

Responsible use of the Campaign Manager 360 reporting feature is enforced through the three following product-wide usage quotas:

  1. Ad hoc report executions (per day)

    Limits the number of ad-hoc reports a CM account / a CM user profile can run in a 24-hour period. To stay under quota:

    • Reduce duplicate reports.
    • Schedule reports that are run regularly.
    • Deactivate unnecessary API scripts.
  2. Active scheduled reports

    Limits the number of reports a CM account / a CM user profile can have actively scheduled at a given time. To stay under quota:

    • Reduce duplicate reports.
    • Deactivate unnecessary scheduled reports.
    • Deactivate unnecessary API scripts.
  3. Simultaneous reports

    Limits the number of reports a CM account / a CM user profile can run simultaneously. To stay under quota:

    • Schedule reports that are run regularly.
    • Deactivate unnecessary API scripts.
    • Implement backoff logic.

If you've optimized your reporting implementation and you still find yourself exceeding your given quota, contact Campaign Manager 360 support using the contact form.