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
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 appears in the top right-hand corner of the page for daily reports.
Time zones
In the 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 and 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 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.
- 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:
- 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:
- 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
| Rate | 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 |
|
|
Intraday (during the day) |
Every 4 hours on average | Data is collected six times a day but, on average, collected every four hours. Data is processed on receipt. |
|
Ad revenue |
Data is available 40 hours after the end of day UTC on which the ad displays. |
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. Note: Aggregate-level data is reported under Day 1. User-level data in Cohorts is reported under Day 0.
|
|
PBA Daily |
Data is available 8 hours after midnight UTC on the day of the event |
|
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 | Real-time | ✓ |
|
Sessions, clicks, impressions, loyal users |
KPI |
|
✓ |
|
Revenue in-app events |
KPI |
Real-time |
✓ |
|
Ad revenue |
KPI |
Ad revenue |
✓ |
|
Ad spend (cost) |
KPI |
|
✓ |
|
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 | Real-time | ✓ |
|
Protect360 dashboard |
Page |
|
✓(1)
|
|
Activity page |
Page |
|
✓ Exception: MAU data is UTC |
|
Events page |
Page | Real-time |
✓ |
|
Retargeting page |
Page | Real-time | ✓ |
|
Retention |
Page |
Retention KPIs are available having daily and weekly granularity. The data freshness for each is different.
|
Daily: ✓ Weekly: x |
|
Cohort |
Page |
Daily |
✓(1) |
|
Custom dashboard |
Page | Real-time. Exception: KPIs that are calculated otherwise |
✓(1) |
|
Audiences |
Page |
|
✓ |
|
SDK information page |
Page |
Daily |
x |
|
Live alerts |
Page |
|
✓ |
|
Export data |
Page |
The data freshness rate is the same as the dashboard that contains the data. In most cases this means Real-time.
Some exceptions to note:
|
✓ |
|
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 |
|
✓ |
|
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 |
|
x UTC |
|
Postbacks |
API |
Real-time |
N/A |
|
Push API |
API | Real-time. UTC and app-specific timezone are supported simultaneously |
✓ Both |
|
Server-to-server in-app events |
API |
|
N/A |
|
Notes: (1) All apps need to use the same app-specific time zone. If not, time zone reverts to UTC. |
|||