Data freshness and time zone supported features

At a glance: Data freshness indicates the period of time between an event occurrence until the data is available in the AppsFlyer platform.  

Time zones

This article describes when platform data is updated, displayed, and available, as well as the support in app-specific time zones.

TimeZoneMap.jpg

Data freshness and supporting app-specific time zones

Data freshness

The AppsFlyer platform has several types of types of data freshness such as daily and real time. They are used to present and make data available. Each has its own data freshness rate

Example: Data freshness rates on the Events dashboard:

  • Metric KPI: real time
  • Average KPI: daily

The last update time normally appears in the top right-hand corner of a page.

Timeupdate.png

Time zones

In the AppsFlyer platform, a day starts at 00:01 and ends at 24:00. AppsFlyer uses UTC (GMT) as the default time zone. You can change this by setting an app-specific time zone. 

Date & time-zone principles

UTC time is constant and doesn't have summer/winter times. 

Hemispheres

  • Eastern: Time zones are designated as UTC+ are those located to the east of UTC. 
  • Western: Time zones designated as UTC - are those located to the west of UTC.

App-specific time zone

You can set an app-specific time zone. This means that the data is grouped into days using local time rather than UTC.

Example: 

Beijing: If the app-specific time zone is set to Beijing (UTC +8 ) then the day starts at 16:01 UTC and ends at 16:00 UTC the following day. 

Los Angeles: If the app-specific time zone is set to Los Angeles (UTC -8) then the day starts at 08:01 UTC and ends at 08:00 UTC the following day.

Time-zone guidelines

  • Align your app-specific time zone with the time zone you set for other attribution service providers such as Google and Facebook.
  • If you have more than one app, the best practice is to set all apps to the same time zone. To view an app time zone, go to Configuration > App setting. 
  • Most reports and data extraction-features support app-specific time zones. This includes multi-app reports if all apps are set to the same app-specific time zone.

Daily processing 

Some reports are processed once a day, this is referred to as daily freshness or daily processing. These are the principles of daily processing:

  • Data belonging to a specific day, for example, Monday, is collected in a bucket. The day begins at 00:01 and ends at 24:00 using the app-specific time. 
  • Data received up to two hours after midnight is included in the day's bucket. Data received up to 02:00 on Tuesday is included in Monday's bucket.
  • At 02:00 local time, the bucket is closed, and no more data can be added to it.
  • Data received after 0200 is placed in the next available bucket, irrespective of the event date.
  • Now it is time to process the data in the Monday bucket that was closed at 0200 Tuesday local time. Data in the closed bucket undergoes daily processing.
  • Now Daily processing of the closed bucket begins two hours after midnight UTC irrespective of the app-specific time zone. For simplicities sake, we state that processing starts at midnight UTC. This means that depending on the local time zone the bucket needs to wait, until midnight UTC, before processing begins.

Eastern hemisphere and UTC time zone:

mceclip9.png

  • Up to 11 hours can pass from the time the day ends (local time) until processing begins. For example:
    • Beijing UTC+8: Need to wait eight hours before processing begins.
    • Berlin (UTC +1): Need to wait one hour before processing begins.
    • UTC: No time elapses. 
  • Depending on the report type the data is available 8-20 hours after the start of the processing For example, Beijing data is available from 16:00 local time. Berlin data is available from 09:00.

Western hemisphere:

mceclip7.png

  • Up to 23 hours can elapse from the time the day ends until processing begins. For example:
    • Los Angeles UTC -8: Need to wait 16 hours before processing begins.
    • New York UTC -5: Need to wait 19 hours before processing begins.
  • The processed data is available 8-20 hours after the start of the processing depending on the report type. For example,  Los Angeles, data is available from  00:01 local time two days after the event. New York data is available from 03:01 local time two days after the event.
  • Example:
    • Events take place on Monday Los Angeles time (UTC -8), the daily processing begins at midnight UTC Tuesday. This is Los Angeles Tuesday 16:01.
    • Eight hours later, on Wednesday 00:01 Los Angeles time the data processing is complete.  In practical terms, data from Monday is available to advertisers in Los Angeles when they begin work on Wednesday morning.

Data freshness types

Data freshness types
Data freshness type Data availability Description 
Real-time 1-2 minutes after the occurrence of the event  
Real-time ingestion Few minutes after submission Ingestion of data uploaded to the platform
Real-time report  Few minutes after requesting a report

The data freshness is in real-time until the request is made

Daily

UTC zone: 8 hours after midnight UTC on the day of the event

Eastern hemisphere: 9-20 hours after midnight UTC on the day of the event

Western hemisphere: 21-32 hours after midnight UTC on the day of the event

  • Data is processed daily
  • The availability of this data differs depending on the app-specific time zone
  • Data types that don't support app-specific time zones use UTC time
  • Data availability times may vary from day to day
Intraday Eery 4 hours on average Data is collected six times a day but, on average, collected every four hours. Data is processed on receipt. 

Data freshness rates and time zone support

The different data/presentation types have different data freshness types

Data freshness rate and support for app-specific time zone
Presentation type Data type Data freshness type Data displays using app-specific time zone 
KPI Installs Real-time Yes
KPI Sessions, clicks, impressions, loyal users
  • Attribution links: Real-time
  • SRNs: Intraday
Yes
KPI Revenue in-app events

Real-time

Yes

KPI Ad revenue
  • AppsFlyer collects ad revenue at 1400 UTC for the previous day.
  • The data displays in the dashboard on the next day. (Processing begins at midnight UTC) 

Example: An ad displays Monday. The revenue data is pulled from the ad networks on Tuesday at 1400 UTC and processing begins Tuesday midnight UTC. The data is available in the Dashboard on Wednesday from 16:00 UTC. Note: The revenue displays under Tuesday. 

 
KPI Ad spend (cost)
  • Attribution link: Real-time
  • API: Intraday
  • Ad Spend Ingestion: Real-time ingestion
Yes
KPI Uninstalls

AppsFlyer pings the app stores every 24 hours. The event time of the uninstall represents the time AppsFlyer pinged the silent push notification and discovered the app was uninstalled. It is not the actual time of the uninstall.

No

Pull down list  In-app events pull down list

List of in-app events names used for filtering in dashboards: Daily. Note: The data freshness rate of the events themselves is Real-time

Yes
Page Overview dashboard  Real-time  Yes
Page  Protect360 dashboard
  • Protect360 dashboard:
    • Processing begins at midnight UTC.
    • During processing only the data of complete days in included. 
    • Data is available in 15 hours later.
  • Fraud blocking and postbacks: Real-time

Yes

All apps need to be set to the same time zone

 

Page Activity page 
  • KPIs: Real-time
  • Averages: At midnight app-specific time zone. 
  • Yes
  • Exception: MAU data is calculated using UTC
Page Events page  Real-time

Yes

Page Retargeting page  Real-time Yes

Page

 Retention

  • Daily: Real-time
  • Weekly: Weekly retention is calculated every Monday at midday UTC+0, and spans from Monday to Sunday. The difference is negligible.
  • Daily: Yes
  • Weekly: No

Page

 Cohort

Daily

  • Yes
  • All apps need to be set to the same time zone
Page  Custom dashboard Real-time except for KPIs that are calculated otherwise
  • Yes
  • All apps need to be set to the same time zone
Page Audiences
  • The push of an audience update to the partner is performed once every 24 hours.
  • The Audience user-base updates once a day and contains device data up to 90 days backward
  • When an account configures Audiences for the first time, for example on Monday, then until the following Sunday, AppsFlyer provides the customer with data for the first few days only (Monday to Saturday.)
  • On Sunday, 6 days later, AppsFlyer loads the historical data of the previous 90 days including the previous 6 days.
 Yes
Page SDK information page

Daily

 No
Page Live alerts
  • Alerts are sent once a day at 07:00 app-specific time.
  • Regular KPIs (alerts not based on Protect360 KPIs) are checked daily at Midnight, spanning the previous day. 
  • Protect360 alerts are updated Daily UTC time. 
Yes

Page

Export data 

  • Performance 
  • Retargeting
  • Blocked fraud
  • Targeting validation
  • Raw data 

Real-time report

 Yes

API 

Pull API

  • Performance 
  • Retargeting
  • Blocked fraud
  • Targeting validation
  • Raw data 
 Real-time report 

Yes 

  • Raw data: Any time zone can be selected
  • Aggregate: Preferred time zone can be selected

 

Scheduled reports

 

  • Emails are sent during the morning.

  • Only available for Installs and In-app event raw data reports

 Yes

Page

Pivot page 

Daily

  • Yes
  • Weekly retention KPIs: No

 API

 Master API

 Daily

  • Yes
  • UTC is default the default time zone use 
  • Provided all apps have the same time zone

API

 Data Locker

Files are updated hourly with data freshness of about six hours

 No

API

Postbacks

Real-time

Not applicable

API Push API Real-time Not applicable
API Server-to-server in-app events

Configurable. You can send the server-to-server events in real-time or in batch mode.

  • In batch mode, for events to be recorded with their real-time stamps, they must be received by AppsFlyer by 02:00 UTC of the following day
  • Events received after UTC 02:00 which are not sent by 2:00 AM, are recorded under the time that they were sent
 Not applicable
Was this article helpful?
1 out of 1 found this helpful