Analytics asynchronous endpoint cached?

[Makoto875176881]

Hi,

We are trying to pull the stats by using /1/stats/jobs/accounts/:account_id endpoint. but the response is cached even if we try different parameters.

https://dev.twitter.com/ads/reference/1/post/stats/jobs/accounts/%3Aaccount_id

Is this expected? How can we make sure that we get the latest stats?

[JBabichJapan]

Hi, You should get a different job_id back every time you post a new job. If you are looking at the results from previous job they would not change, but if you post again the numbers from looking up result with new job_id should be whatever latest we have in our system.

Generally process to test manually is to POST, poll on GET to wait for the job to complete, download gz file gunzip it then view JSON. If you need to you can test the process with twurl to figure out what’s going wrong.

Thanks,

John

[Makoto875176881]

Hi @JBabichJapan

Thank you for the explanations. The way you suggested worked. However, sometimes it took time for the job to complete especially if there are many campaigns and we request many jobs whose status shows as “PROCESSING”. We added retry logic with some sleep but it didn’t help.

Is there any way to fasten the waiting time for the asynchronous job?

[juanshishido]

Thanks for the follow up, @Makoto875176881. Glad to hear you had some resolution to your original inquiry.

In terms of our asynchronous analytics success latency, there isn’t much that can be done as the processing times depend on the load at any given time. We’ve had some drops in success rate and increases in latency over the past two months (see here, for example) and we’re continuing to work to improve it. That being said, one thing that partners can do is request data for fewer entities (i.e., specify fewer entity_ids).

We appreciate you reaching out.

[Makoto875176881]

Hi @juanshishido
Thanks. We tried with fewer entities(from 20 to 10) as you suggested, but I don’t see significant change yet. Would appreciate if you can come up with any other work around, or improve the latency in your backend.

Makoto

[JBabichJapan]

The async response can be as quick as less than a few seconds but also sometimes 15 minutes, so I would not recommend to build something that requires the data in realtime (for example, I definitely would not call async from PHP or HTML5 while rendering a UI in webpage). The average latency is measured and we take action when it goes unacceptably high, but there is no formal SLA we can communicate about this. For things which require realtime data (like realtime optimization), you should use the synchronous endpoint.

If the time is consistently unacceptably slow (hours or seems to be stuck forever even after retrying) - please go ahead and make a new post about it with details like job IDs so that it can be noticed and investigated as a separate issue.

[Makoto875176881]

@JBabichJapan

Ok understood. We use RoR to store historical stats for Twitter campaigns, not for real-time usage.
Also since country breakdown is only available in async API, we can’t use synchronous endpoint.

I’ll investigate more if there is specific job id that shows “PROCESSING”, but my guess is it is pretty random.