Data freshness and time zone support

At a glance: Data freshness is the period of time between event occurrence and data availability in the platform.

Time zones

TimeZoneMap.jpg

Data freshness and support for app-specific time zones

Data freshness

The AppsFlyer platform utilizes different 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

For daily reports, the last update time appears in the top right-hand corner of the page. 

tIME.jpg

Time zones

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

Date and time-zone principles

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

Hemispheres

  • Eastern: Time zones 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 instead of 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's time zone setting, go to Configuration > App Settings. 
  • Most reports and data extraction tools 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 and pull-down lists 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.
  • Daily processing of the closed bucket begins two hours after midnight UTC irrespective of the app-specific time zone. For the sake of simplicity, 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 waiting time. 
  • 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 pass 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
  • Depending on the report type the processed data is available 8-20 hours after the start of the processing begins. 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
 Rate Availability Description 

Continuous (AKA real-time)

Several minutes after the occurrence and subsequent processing of the event Data processing is continuous or in near real-time. This term distinguishes it from batch processing which takes place, for example, daily or hourly. In most cases, continuous data is updated within several minutes of the occurrence of an event. Expect some variation in lag times from event occurrence until it reflects in reports and dashboards. 

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 can vary from day-to-day or as indicated in specific articles

EOD

Daily at the end of the day app-specific timezone At the end of the calendar day. Meaning 00:01 of the following day. Example: Data recorded on Monday is available starting from Tuesday at 00:01 irrespective of the app-specific timezone.

Intraday (during the day)

Every 4 hours on average
  • Data is collected six times a day, on average every four hours.
  • SRN click and impression data for customers without Xpend is collected 3 times a day.

Ad revenue

Data is available ~40 hours after the end of day UTC on which the ad displays.
  • 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 on Day 0. The revenue data is pulled from the ad networks on Day 1 at 1400 UTC and processing begins Day 2 at 00:01 UTC. The data is available in the Dashboard on Day 2 from ~16:00 UTC. Data is reported under Day 0.

 

Ad_revenue_display_timeline_3_en-us.jpg

PBA Daily

Data is available 8-10 hours after the end of the day UTC.
  • PBA dashboard and reports update Daily using the UTC timezone.
  • Daily processing includes events received during the previous day. 
  • During the first seven days after conversion, PBA may identify additional events relating to a conversion. This can change KPIs and media source attribution retroactively. 
  • After seven days, the paths are frozen, and no more changes take place.
  • Raw data reports include the field final_data. When true data is final.
  • Detailed example

SKAdNetwork

Updated data displays approx. 68 hours after install. Range 32-104 hours.

Postbacks received on a given day are processed at the end of the day UTC. Data is available by 08:00 UTC of the following day. Meaning iOS postbacks received Monday are available in reports and dashboards on Tuesday morning. Similarly, postbacks to partners are sent on Tuesday morning. 

The install date in reports and dashboards is derived from the postback arrival time as follows:

  • Install date = postback arrival time - 24 hours - measurment window. 
  • The measurement window default is 24 hours.
  • If you use custom conversion then the measurement window is set using hours_from_install.

Detailed explanation of timing.

Data Locker Daily

Data is available 8–10 hours after the end of the day UTC 
  • Data is processed daily.
  • Data is contained in the h=23 folder on the event date. For example, Monday's data is available in Monday's h=23 folder on Tuesday 08:00–10:00 UTC.

Data freshness rates and time-zone support

Data freshness rates and time-zone support
Related data  How presented  Data freshness rate
(See the preceding section for the key to the rates)
Data displays using app-specific time zone

Installs

KPI Continuous

Sessions, clicks, impressions, loyal users

KPI
  • Attribution links: Continuous
  • SRNs: Intraday

Revenue in-app events

KPI

Continuous

Ad revenue

KPI

Ad revenue

Ad spend (cost)

KPI
  • Attribution link: Continuous (maximum up to 2 hours after click)
  • API: Intraday
  • Ad Spend Ingestion: Up to 4 hours after ingestion

Uninstalls

KPI

AppsFlyer pings 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. This is not the actual time of the uninstall.

x

In-app events in the interface

Pull-down list

In-app event names that display in pull-down lists update Daily. 

This does not impact the data freshness rate of the data itself. 

Examples: Pull-down in-app event lists in Push API, dashboards, and audiences.

Overview dashboard 

Page Continuous

Protect360 dashboard

Page  The dashboard updates daily. (1)

Activity page 

Page
  • KPIs: Continuous
  • Averages: At midnight app-specific time zone. 

Exception: MAU data is UTC

Events page 

Page Continuous

Retargeting page 

Page Continuous

Retention

Page

Retention KPIs are available having daily and weekly granularity. The data freshness for each is different. 

  • Daily retention KPIs: Daily
  • Weekly retention KPIs: The week begins on Monday and ends on Sunday. Retention is calculated on Monday 12:00 UTC. The lack of app-specific timezone support for the weekly KPI results in a negligible difference. 

Daily:

Weekly: x

Cohort

Page

Continuous

(1)

Custom dashboard

Page Continuous. Exception: KPIs that are calculated otherwise

(1)

Audiences

Page
  • Updates are pushed to partners every 24 hours.
  • User-base is updated daily and holds up to 90 days of device data

SDK information page

Page

Daily

 x

Live alerts

Page
  • Regular KPIs:
    • use app-specific time zone
    • processed at Midnight
    • and are sent at local time 07:00.
  • Protect360 alerts are updated Daily UTC time. 

Export data

Page

The data freshness rate is the same as the dashboard that contains the data. In most cases this means Continuous. 

 

Some exceptions to note:

  • Ad revenue raw data: Daily 
  • Organic installs
  • Protect360:
    • Aggregate reports: Daily
    • Blocked raw data: Continuous
    • Post-attribution raw data: Daily

Pull API

API  Pull API data freshness is the same as the Export data page described in the row above.

Default UTC

 

Scheduled reports

Scheduled reports
  • Emails are sent during the morning.

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

Pivot page 

Page

Daily

Weekly retention KPIs: x

Master API

 API

Daily. Default time zone is UTC. You can change this in the API call. 

(1)

Data Locker

API
  • Hourly data: updated hourly with data freshness of approx six hours.
  • For Daily reports: On completion of daily processing. 

x

UTC

Postbacks

API

Continuous

N/A

Push API

API Continuous. UTC and app-specific timezone are supported simultaneously


Both

Server-to-server in-app events

API
  • Configurable. Send server-to-server events in real-time or batch mode
  • Batch mode, for events to be recorded with the original timestamps, they must be received by AppsFlyer by 02:00 UTC of the following day
  • Events received after 02:00 UTC are recorded under the time that they were sent
N/A

Notes:

(1) All apps must use the same app-specific time zone. If not, the time zone reverts to UTC.

Was this article helpful?