Ad Account Stats Metrics in Time Series

[theKetsuN]

The problem

I have a use case where I need to retrieve time series data (by day) for ad accounts over extended time periods (3+ months at a time).

There are a few issues with this type of request:

• Sometimes the metrics I need (e.g. spend) are accessed through campaigns or line items.
• It seems I’m not capable of retrieving this data through the synchronous API since it buckets by 7 day periods.
• Using the asynchronous job calls may be delayed too much and are overly complex for real-time requests from the user (plus this seems against best practices).

So I have a few questions:

• Is it possible to determine overall ad account spend directly instead of through campaigns or line items?
• Is there a better way to retrieve stat metrics in time series in a synchronous way in buckets larger than 7 days?

Example usage

A user wants to retrieve real-time ad account metrics (e.g. spend or impressions) in time series over the course of 3 months.

Current attempts

Sync

1. Query for campaigns within an account
2. For each chunk of 20 campaigns…
   a. Query for a single week of /stats/ data for the 20 campaigns. (this is too many queries)
   b. For each day in the returned result metric, append it to the account-wide total for that day

Async

1. Query for campaigns within an account
2. For each chunk of 20 campaigns…
   a. Schedule a 90-day stats job for the 20 campaigns
   b. Poll for status of each job
   c. Once job is completed, pull the .gz file, unzip
   d. For each day in the returned result metric, append it to the account-wide total for that day

[JBabichJapan]

Thanks for posting with lots of details.

We do have a reference page related to best practices for analytics: https://dev.twitter.com/ads/analytics/best-practices

For cases where you are primarily concerned with back filling total spend, it might be appropriate to focus on using async (for the wide windows), or even with granularity=TOTAL as a special call. However generally our standard advice is to maintain lowest granularity bucket that you would need to reference later on your end so that you don’t have to re-request for same data over and over.

Backfilling data will be somewhat complicated process with the sync endpoint so it’s strongly recommending to use Async, and for something like ‘realtime stats’ or the equivalent of data you would see when looking at the campaign performance page on ads.twitter.com, it should be appropriate to fetch the latest stats with Sync endpoint. That’s basically the intention we have, to fill data in your DB with async but be able to either do realtime optimization or UI rendering with the sync endpoint (and the rate limit is low so very difficult to do much more than that).

If your data is not matching up for async you may need to work from a smaller example and just go step by step to make sure the smaller chunks of data are adding up to the correct total (even 1 second overlapping can make it off in aggregate).