Get promoted tweet stats of specific campaign

[Tianape]

Hi guys,

I want to have statistics of all promoted tweets of a specific campaign, but I don’t see any filter on Campaign Ids in the GET stats/accounts/:account_id/promoted_tweets endpoint.
The ability to filter on campaigns in all /stats endpoints would make the API so much more feasible and easy to use…

Line items aren’t known to Twitter Ads users as these are only internal, so to filter on a specific campaign you’d have to fetch all line items of the campaign the user wants to filter on, then you’d be able to fetch all promoted tweets of the campaign using the line item ids and only THEN you could fetch the stats as you can (finally) fill in the promoted_tweet_ids property.

Not having the option to filter on campaigns is really is keeping me from using the API to its full potential, as the above-mentioned is definitely not a viable solution…

[brandonmblack]

@Tianape promoted tweets are associated with a line item, line items are associated with the promoted tweet. If you need to filter this way you’ll have to look farther up the object hierarchy and filter your list of promoted_tweet_ids down to what you want based on the associated campaigns and line items.

To reduce your API calls and avoid getting rate limited, you should store some of the relevant hierarchical data in your own database and sync / refresh as needed with a small background job.

[Tianape]

Hi @brandonmblack,

Thanks for your reply!

I understand that you can go up the hierarchy, and I know you can store data, but in my opinion it’s pretty odd to ask API users to do this for filtering purposes. Storing data should be an option, not something you’re somewhat forcing your users to do because the API would otherwise become difficult to work with…

I would really like to advice the API developers to take a good look at the other APIs such as the Google AdWords API and the newest versions of Facebook’s Ads API. Facebook for example has created a single endpoint from which you can fetch anything you want, filtered by anything, segmented by anything… It allows you to be free in your ways to fetch the data, but still has relatively tight rate limits which allows you to choose to store data in some cases instead.

Absolutely loving the Twitter Ads API documentation and the base of the API, however there really are some things in it that I believe could use another iteration… Pretty frustrating after a while.

Thanks for your help anyway!

Best,

Tiana

[majoritasdev]

@brandonmblack: I agree with @Tianape. I would add that the documentation for Ads API has many errors, like copying the page from POST (create) to PUT (edit) with no modification, missing endpoints documented (like GET accounts/:account_id/promoted_tweets/:tweet_id), possible values undocumented or wrong (like the account features), etc.

[brandonmblack]

Storing data should be an option, not something you’re somewhat forcing your users to do because the API would otherwise become difficult to work with

@Tianape storing data or not, I’m not sure it would ever make sense to ever allow filtering from any level in higher up the hierarchy on lower level objects like promoted tweets.

Storing is just a proposed solution, at a minimum your implementation just need to be aware of the objects up the hierarchy you’re currently working within the context of and have an understanding of their relationship to each other. This may involve nothing more than a few extra API reads requests but at a certain threshold it will benefit you to persist some of this data yourself and reduce / eliminate extraneous API calls for data you asked for before.

Promoted tweets are associated with the ad group (line item) and what you’re asking for is effectively that we allow you to filter those up the chain at the campaign two hops away. It might be useful in your specific use case but at this level if you’re using the API as intended you should already be working with a known set of line items associated with that campaign.

How you keep track of those line items (stored, read from the API, carrier pigeons, etc) is entirely up to you.