Stats API metrics changed over time

[minh.pham]

Hi all,

Recently our system has reported a strange behavior of Twitter stats data.

Could someone help us with below questions?

• 1. What type of metrics will be changed after 24 hours?
• 2. What is the time range window till the change be finalized?

Based on what documented in
https://developer.twitter.com/en/docs/ads/analytics/overview/best-practices
https://developer.twitter.com/en/docs/ads/analytics/overview

Except from billing metrics all other metrics should not be changed after 24 hours

All analytics metrics are locked and will not change after 24 hours, with the exception of billed_charge_local_micro

Value will be finalized after 3 days or at last 14 days

All billing stats are generally final within 3 days of the event (~99%), however we do process some spam filtering for up to 14 days from the date of the event.

But our system has recorded a different behavior. Please find the detail information below

Our collection system has a rolling window to collect data of the pass few days.
For example: data of 2017-11-15 will be collected on 2017-11-15 till 2017-11-20 and the latest record will override the previous one

Because of a big discrepancy in our report stats recently, we re-run the backward collecting job to collect data of the pass and notice the differences between each collecting run.
Take below for example

• data of 2017-11-15 collected on 2017-11-20 have impressions=192650
• data of 2017-11-15 collected on 2017-12-13 have impressions=192658

This kind of discrepancy impact other metrics as well like mobile_conversion_installs and other conversions
This is one of the url that we’ve used to collect data
https://ads-api.twitter.com/2/stats/accounts/<account_id>?entity=CAMPAIGN&entity_ids=<entity_id>&metric_groups=ENGAGEMENT,BILLING,VIDEO,MEDIA,WEB_CONVERSION,MOBILE_CONVERSION,LIFE_TIME_VALUE_MOBILE_CONVERSION&placement=ALL_ON_TWITTER&with_deleted=true&granularity=DAY&start_time=2017-11-15T23%3A00%3A00Z&end_time=2017-20-25T23%3A00%3A00Z

[goforbrent]

Hi @minh.pham,

I’ve tried to answer all of your questions below, please let me know if I missed anything.

Because of a big discrepancy in our report stats recently, we re-run the backward collecting job to collect data of the pass and notice the differences between each collecting run.
Take below for example
data of 2017-11-15 collected on 2017-11-20 have impressions=192650
data of 2017-11-15 collected on 2017-12-13 have impressions=192658

Depending on how the data is pulled, its very possible that impressions changed due to timezone of data pull or prior impressions being reviewed as fraud were added later once legitimized.

With regard to mobile or web conversion data, these numbers can change throughout the duration of the attribution window. For instance the example you provided, mobile app events have click window of 7 days and our non real time attribution job could connect conversions days later as processing finishes. The web conversion data also goes through our identity network processing to match the users cookie to a Twitter profile. There are cases where we matched a cookie to a user later and then updated attribution reporting appropriately.

[minh.pham]

Hi goforbrent

its very possible that impressions changed due to timezone of data pull

You can see in my example that the collection run after 5 days, it should not be affected by timezone.

prior impressions being reviewed as fraud were added later once legitimized

Do you have any information regarding the fraud detection mechanism cause I see quite a large number of line_items affected by this discrepancy

• How is it determine a fraud?
• How often does it occur?

mobile app events have click window of 7 days and our non real time attribution job could connect conversions days later as processing finishes

Could you help us with the links to document that mentions attribution window?

[goforbrent]

Do you have any information regarding the fraud detection mechanism cause I see quite a large number of line_items affected by this discrepancy

How is it determine a fraud?
How often does it occur?

I will have to track this information down, but more importantly. If you are seeing this happen often, can you provide us recent examples using twurl commands? Although I’m not aware of any issues, I’d rather be safe and dig into a legitimate example.

Could you help us with the links to document that mentions attribution window?

Here is a quick glossary that touches on attribution windows. I also found the first two points from Adjust’s description of attribution windows to be very descriptive (Adjust is one of Twitter’s mobile measurement partners).

[minh.pham]

Hi @goforbrent, thanks for the information

mobile app events have click window of 7 days and our non real time attribution job could connect conversions days later as processing finishes

I could not find any document that point out the impact of attribution window on statistics of analytic API. Could you explain where the mobile app events have click window of 7 come from? So far, I have checked below document, it states that the default click_window are 14 days for a conversion event

• https://developer.twitter.com/en/docs/ads/measurement/overview/mact-overview
• https://developer.twitter.com/en/docs/ads/measurement/api-reference/conversion-attribution
• https://developer.twitter.com/en/docs/ads/measurement/api-reference/conversion-event#post-conversion-event

does analytic API support collecting data by attribution window? I could not find it mention anywhere in the document.
Suppose we use below url to collect data, I’ve tried to use click_window, view_through_window param but it has no affect

https://ads-api.twitter.com/2/stats/accounts/1<account_id>?entity=CAMPAIGN&entity_ids=<entity_id>&metric_groups=ENGAGEMENT,BILLING,VIDEO,MEDIA,WEB_CONVERSION,MOBILE_CONVERSION,LIFE_TIME_VALUE_MOBILE_CONVERSION&placement=ALL_ON_TWITTER&with_deleted=true&granularity=DAY&start_time=2017-11-15T23%3A00%3A00Z&end_time=2017-20-25T23%3A00%3A00Z&click_window=1&view_through_window=1

Are there any best practice when working with attribution window?
Let say we have a campaign that has a variety of conversion events and they also have a variety of attribution window. So do we have to follow the max possible supported day (which is 30).
Ex: campaign stats on date 2018-01-01 will be finalized on date 2018-01-31 (because some conversion event have click_window=30). Is that correct?

[goforbrent]

We don’t specifically call out attribution windows because those are known terms in the marketing world. As I said above if user x gets an promoted app install tweet and clicks on it. But decides to bounce and not install at that time. If the client set an attribution of 7 days post engagement, that user has up to 7 days after engaging with the promoted tweet to install that app. If the install happens within that timeframe, Twitter would attributed with the install on the day of the conversion. We have both an online and offline job that is processing attributed app events. Sometimes the online job is not able to attribute an action back to a promoted tweet in real time. Our offline job could potentially find that user x saw an impression and installed, correcting for the real time that was unable connect those two actions as to the same user. I would suggest reading about attribution windows in terms general marketing since Facebook, Google, whomever uses them.

Let say we have a campaign that has a variety of conversion events and they also have a variety of attribution window. So do we have to follow the max possible supported day (which is 30).

Ex: campaign stats on date 2018-01-01 will be finalized on date 2018-01-31 (because some conversion event have click_window=30). Is that correct?

Yes, what you said above is the general idea. It is always good to re-pull attributed MOBILE_CONVERSION or WEB_CONVERSION throughout the length of the attribution window to make sure your database and Twitter’s align.