Difference in results from v0 to v1



I’m getting different results from the v0 stats endpoint for funding instruments compared to v1.


{u’request’: {u’params’: {u’account_id’: u’rbbo3w’, u’start_time’: u’2016-06-26T00:00:00Z’, u’funding_instrument_id’: u’kh2kt’, u’metrics’: [u’billed_charge_local_micro’], u’end_time’: u’2016-06-27T00:00:00Z’, u’granularity’: u’HOUR’}}, u’data’: {u’id’: u’kh2kt’, u’start_time’: u’2016-06-26T00:00:00Z’, u’granularity’: u’HOUR’, u’end_time’: u’2016-06-27T00:00:00Z’, u’billed_charge_local_micro’: [16830000, 15650000, 18890000, 14070000, 14660000, 11980000, 3420000, 4950000, 5080000, 5450000, 4400000, 4920000, 5820000, 5880000, 7130000, 23740000, 29850000, 10700000, 9460000, 32690000, 31950000, 13430000, 38210000, 63240000]}, u’data_type’: u’stats’}

Sum of spend = 392400000


{u’request’: {u’params’: {u’placement’: u’ALL_ON_TWITTER’, u’metric_groups’: [u’BILLING’], u’country’: None, u’start_time’: u’2016-06-26T00:00:00Z’, u’entity’: u’FUNDING_INSTRUMENT’, u’platform’: None, u’end_time’: u’2016-06-27T00:00:00Z’, u’granularity’: u’HOUR’, u’entity_ids’: [u’kh2kt’], u’segmentation_type’: None}}, u’time_series_length’: 24, u’data’: [{u’id’: u’kh2kt’, u’id_data’: [{u’metrics’: {u’billed_engagements’: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 3, 1, 0, 1, 2], u’billed_charge_local_micro’: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 15000000, 15000000, 0, 0, 21160000, 15000000, 0, 15000000, 30000000]}, u’segment’: None}]}], u’data_type’: u’stats’}

Sum of spend = 111160000

Statistics differ from the values you can see in ads.twitter.com

We are seeing a similar issue with our client:
For the TW Ads Account pfh7r, here’s an example Promoted Tweet rp75x - On some days, the data for promoted_tweet_timeline_impressions matches exactly for v0 and v1. On other days, we’re getting back a zero value, while the v0 data had a non-zero value.
For example, v1 returns zeros for 06/01, 06/06, 06/10, 06/12; but v0 provided non-zero values for those dates. For all of the other dates between 06/01-06/12, the data matches exactly.


@jillblaz @jaakkosf @rchoi - Can you provide an update on this issue?


Thanks for alerting us to this difference, Mike. Our engineering team is taking a closer look. We’ll update you when we know more.


@mikenaux and @TaliDolev: We’ve confirmed that this is an issues and the engineering team is working on a fix. We’ll let you know once it’s resolved. Thanks!


@juanshishido Do you have an update on the fix? ETA?


@TaliDolev: Thanks for following up! We’ve reached out to team working on this and will update you once we get additional details.


Can I please ask for an update once again? It’s been a week, and already two weeks since the problem was acknowledged.


Is there any update to give here? This has been causing us problems for nearly a month now.


@PuttingOnAires, @alonamit, @TaliDolev, and @mikenaux: We understand the importance of getting this issue resolved and our engineering team is currently working on a fix. We’ll pass information along as soon as we get it. Thanks again for bringing this issue to our attention and for following up!


@juanshishido 17 more days gone by, and nothing. Any update?


@alonamit: We’ve been working to resolve this. Apologies for the delay. No update just yet, but stay tuned. Thanks!


@mikenaux: Thank you for your patience while we worked to resolve this. A fix has been deployed.

Please note that in v1:

placement takes in a single value, so separate queries are required to fetch analytics data for placement on Twitter and placement on the Twitter Audience Platform.

See Migration Guide: v0 => v1.

Using twurl, the requests would be:

# for v0
$ twurl -H ads-api.twitter.com "/0/stats/accounts/rbbo3w/funding_instruments/kh2kt?metrics=billed_charge_local_micro&start_time=2016-06-26T00:00:00Z&end_time=2016-06-27T00:00:00Z&granularity=HOUR" | jq .
# for v1
$ twurl -H ads-api.twitter.com "/1/stats/accounts/rbbo3w?placement=ALL_ON_TWITTER&metric_groups=BILLING&start_time=2016-06-26T00:00:00Z&entity=FUNDING_INSTRUMENT&end_time=2016-06-27T00:00:00Z&granularity=HOUR&entity_ids=kh2kt" | jq .
$ twurl -H ads-api.twitter.com "/1/stats/accounts/rbbo3w?placement=PUBLISHER_NETWORK&metric_groups=BILLING&start_time=2016-06-26T00:00:00Z&entity=FUNDING_INSTRUMENT&end_time=2016-06-27T00:00:00Z&granularity=HOUR&entity_ids=kh2kt" | jq .

@mikenaux: Please confirm that you are seeing the same values for v0 and v1. Thanks!

@TaliDolev, @alonamit, @PuttingOnAires: Please let us know whether the issues you were experiencing have been resolved. Thank you.

Campaign data mismatch for same account id

@juanshishido We are already specifying the placement, from the moment we switched to v1.
In v0, were the placements aggregated into a single metric? If so, that could account for the discrepancy we are seeing, since we are now receiving these values separately.




Hi, @TaliDolev. That’s correct. billed_charge_local_micro, the v0 metric, included data from both Twitter and its publisher network.

The issue we were seeing with v1 was that the publisher network data was not returning the correct results. So, even if you had been making the individual calls for ALL_ON_TWITTER and for PUBLISHER_NETWORK, the aggregated results would have been incorrect.

Could you please confirm that any issues you were seeing previously have been resolved?


Statistics differ from the values you can see in ads.twitter.com

@juanshishido I understand now that we need to compare the aggregate of v1 metrics with the v0 metrics (which were built-in aggregated).
So then, what was the fix that you referred to in your earlier comment?


@TaliDolev: The issue was that the publisher network stats were incorrect. The fix that we deployed two days ago corrected this.

Could you please confirm that you’re seeing the correct values?