Skip to main content

​
Actuals Report - Basic metrics, Cohort metrics, and Date option

Metrics use different data ranges when aggregating in reports. Differences in numbers are normal even when the attribution window and Day N aggregation period match. Let’s see how these metrics differ when viewing revenue generated up to Day 7 after app installation.
  1. Assume the Actuals report has these settings:
    • Date range: April 20, 2025 to April 30, 2025
    • Date option: Event Date
    • Attribution window for Installs: 7 days
    • Attribution window for Deeplink Opens: 1 day
  2. Assume the cohort metric has these settings:
    • Cohort metric: D7_Purchase
    • Aggregation period (Day N): 7 days
    • Start Event: Install (App)
    • Revenue Event: Order Complete (App)
    • Revenue Event metric: Revenue
This configuration shows cumulative revenue from users who installed the app during the date range up to Day 7.Under these conditions, normal differences between basic and cohort metrics can occur in the following scenarios.
A user installs the app through an ad on April 18 and completes a purchase on April 23.Both events are aggregated in basic metrics but not in cohort metrics because the app install occurred before the date range.
The two metrics use different data ranges and attribution window scopes when aggregating in reports. Differences in numbers are normal.
  • Cohort metrics aggregate only events that occurred during the aggregation period (Day N) after the Start Event, regardless of attribution.
  • Basic metrics with Target Event Date as the date option aggregate only events attributed to each target event.
Let’s see how these metrics differ when viewing revenue generated up to Day 3 after app installation.
  1. Assume the Actuals report has these settings:
    • Date range: April 20, 2025 to April 30, 2025
    • Attribution window for Installs: 3 days
    • Attribution window for Deeplink Opens: 1 day
  2. Assume the basic metric has this setting:
    • Date option: Target Event Date
  3. Assume the cohort metric has these settings:
    • Cohort metric: D3_Purchase
    • Aggregation period (Day N): 3 days
    • Start Event: Install (App)
    • Revenue Events: Order Complete (App), Ad Impression (App)
    • Metric: Revenue
    • Date option: Event Date (cannot be changed)
This configuration shows cumulative revenue from users who installed the app during the date range up to Day 3.Under these conditions, normal differences between basic and cohort metrics can occur in the following scenario. For example, a user installs the app through an ad on April 22 and generates multiple Revenue Events.
Basic metrics
For basic metrics, Revenue Events and revenue are aggregated based on the Target Event Date.
  • The revenue of April 22 is USD 25. This is the total revenue from Purchase A and Ad impression attributed to the App install.
  • The revenue of April 25 is USD 15. This is the total revenue from Deeplink open and Purchase B attributed to the App install.
Cohort metrics
For cohort metrics, Revenue Events and revenue are aggregated based on the Event Date with the View Type of Cumulative, which cannot be changed. All Revenue Events and revenue that occurred within 3 days (Day N) of the April 22 App install Start Event are aggregated.
  • The revenue of April 22 is USD 40. This is the total revenue from Purchase A, Ad Impression, and Purchase B that occurred through April 25.
  • The Deeplink openevent is not used in cohort metric aggregation because it’s not a Start Event.
The data in the Actuals Report may be updated due to the following reasons.
  • Data correction to fix missing data issues
  • Varying query results based on Date Option settings
Read on for more details.

​
Data correction to fix missing data issues

The major causes for missing data issues are as follows.
  • Unstable user network environments: This can lead to delays in event aggregation.
  • App backgrounded or closed shortly after event occurrence: The event may be sent to the Airbridge server before the app is sent to the background or closed.
Airbridge performs daily data correction at 9:00 PM UTC to prevent missing data. This correction process adds any missing events from the previous two days (24 hours). As a result, some metrics in the Actuals Report may increase due to data correction.Therefore, most data will stay unchanged for the query data, while data from two days prior (D-2) may be adjusted.ExampleLet’s say you are querying data in the Actuals Report on January 3rd, 11:00 PM (UTC).
  • The data from January 1, 3:00 PM (UTC) to January 2, 11:00 PM (UTC) is not finalized yet.
  • The data collected before January 1, 3:00 PM is finalized.

​
Varying query results based on Date Option settings

The time it takes for the Actuals Report query results to be finalized can vary depending on the Date Option settings. If the Date Option is set to the Target Event Date or Touchpoint Date, the event will be aggregated on the date the Target Event occurred or the Touchpoint occurred, even if it happened in the past.As a result, the Actuals Report metrics may change based on the query time until the attribution window ends.ExampleLet’s say the Date Option is set to Touchpoint Date in the Actuals Report you queried today, which is February 10.
  • If the report shows 10 installs for February 1, it means that the touchpoints that occurred on February 1 contributed to 10 installs.
  • The report may show 11 installs for February 1 on the next day, February 11, because if the attribution window is still open, more installs can be collected as a result of the touchpoints that occurred on February 1.

​
Actuals Report and Raw Data

These factors can cause differences between the Actuals report and raw data numbers, which is normal:
  • Extended Privacy Control (EPC) status
  • Meta privacy policy
  • TikTok For Business data sharing policy
  • Raw data export timing
EPC statusRaw data is affected by EPC, but the Actuals report is not. When EPC is enabled, data from users who declined the App Tracking Transparency (ATT) prompt is processed as unattributed in raw data. However, the Actuals report provides aggregated numbers regardless of EPC status.Below is an example of data from users who declined the ATT prompt.In the above example, EPC affects ad channel data displayed in reports, specifically 15 Installs (App), 20 Order Complete (App), and revenue of 3,000 generated by Order Complete (App) events. Since EPC-affected data is processed as unattributed in raw data, it is aggregated into “unattributed” instead of specific ad channels. As a result, raw data displays 45 Installs (App), 50 Order Complete (App), and revenue of 7,000 generated by Order Complete (App) events as unattributed.Meta privacy policyAccording to Meta privacy policy, for apps that have not accepted the Advanced Mobile Measurement (AMM) terms, Meta Ads is displayed as “restricted” in the Channel column in raw data, and the relevant data cells are left empty. However, the Actuals report displays “facebook.business” in the Channel column regardless of the AMM status. This policy affects Meta Ads data received through Channel Integration and Cost Integration.Below is an example of Meta Ads data with Meta privacy policy applied when the AMM terms were not accepted.According to Meta privacy policy, for apps that have not accepted the AMM terms, Meta Ads is displayed as “facebook.business” in reports while being displayed as “restricted” in raw data. Additionally, Airbridge leaves data cells empty for “restricted” ad channels. Therefore, differences occur between numbers you aggregate in raw data and those displayed in reports, since some numbers affected by Meta privacy policy are excluded from raw data.TikTok For Business data sharing policyAccording to TikTok For Business data sharing policy, some view-through campaign data from TikTok For Business is not provided in raw data. However, aggregated numbers are provided in the Actuals report.Raw data export timingIf you export raw data immediately after an event occurs, that event may not be included. Try again after 10 minutes.

​
Actuals Report and Cohort Report

This is expected. The Retention report excludes duplicate installs, but the Actuals report does not, so the Retention report’s Installs (App) is usually lower than the Actuals report’s. The Retention report deduplicates based on the [Identifier] setting. It uses the Airbridge Device ID (User Count) for Device, the Airbridge ID for User. Installs (App) for the same identifier on the same date count as one. Installs on different dates are counted separately. For more details about the identifiers in Airbridge, refer to this article.
The Revenue report and the Actuals report aggregate revenue from different sets of users, so their totals don’t match. The Revenue report aggregates revenue only from users who generated a Start Event, while the Actuals report aggregates revenue from all users. The factors below can widen the difference even further:
  • Difference in how ad performance is measured
  • Event duplication
  • Difference in how negative values are counted
  • Difference in update frequency
Difference in how ad performance is measured
  • The Actuals report counts revenue-related events that occur within the attribution window as ad performance. Events outside the attribution window aren’t included in the metrics.
  • The Revenue report counts each revenue event as ad performance of the most recent Start Event. The attribution window does not apply.
Event duplication
When a user performs multiple Start Events in a day, the Revenue Event may be duplicated in the Revenue report.Let’s say a user interacted with your app as described below.
  1. 2 PM, Day 0: Installed app after viewing a video ad
  2. 7 PM, Day 0: Opened the app via a deep link after viewing a search ad
  3. 11 AM, Day 1: Completed an order in the app
The Revenue report will report as the following:
  • Number of Revenue Events attributed to the video ad on Day 1: 1
  • Number of Revenue Events attributed to the search ad on Day 1: 1
Difference in how negative values are counted
The Revenue report counts negative values as 0. The Actuals report counts negative values as they are.
Difference in update frequency
The Actuals report updates in real time, while the Revenue report updates once an hour.
Check whether “Is First Event per Device ID” has been set as a GroupBy. When this option is set, the report identifies the first event based on the Airbridge Device ID. Since the Airbridge Device ID is determined by selecting the most suitable identifier collected from various platforms based on Airbridge’s logic, the data visualized in the reports may vary.
The numbers differ because each report applies groupby differently based on its purpose:When applying touchpoint-related groupbys like Channel or Campaign in Retention, Revenue, or Funnel report, note the following:
  • Retention and Revenue reports group all data by the property of the winning touchpoint credited for the Start Event. For example, if you select Install (App) as the Start Event and Channel as the groupby, all data is grouped by the channel credited for the Install (App) event, regardless of the channels credited for the Return or Revenue Events.
  • Funnel report groups all data by the property of the winning touchpoint credited for the Step 1 event. For example, if you select Channel as the groupby, all data is grouped by the channel credited for the Step 1 event, regardless of the channels credited for Step 2, Step 3, and later step events.

​
Airbridge Identifier

This is normal. Airbridge uses different identifiers for each feature based on the feature’s characteristics and whether sufficient identifiers have been collected per device. As a result, numbers for similar concepts across features won’t be identical, and no single feature will consistently show higher or lower numbers than others. For example, the Actuals report and other reports won’t show identical numbers, and neither will consistently show higher or lower values. Please refer to the identifiers used by each Airbridge feature.
Some Airbridge reports count unique users by the Airbridge Device ID (User Count), not the Airbridge Device ID. Because the Airbridge Device ID (User Count) and the Airbridge Device ID prioritize different identifiers, the same device can be identified by different identifiers. For example, on an iOS device where both IDFA and IDFV are collected, the Airbridge Device ID (User Count) counts the user by IDFV while the Airbridge Device ID counts them by IDFA. But if only IDFA is collected, both count the user by IDFA. As a result, the number of unique users shown in Airbridge reports may differ from the number of “Airbridge Device ID” values extracted from App Raw Data.
The identifiers used to determine whether an event is the first event differ by GroupBys. For more details, refer to this article.When selecting Is First Event per User ID as GroupBy, the first event is aggregated for the platform based on User ID. For example, if Event A first occurred in the web environment and the same event occurred in the app environment, the event that occurred in the web environment is aggregated as the first event.

​
Actuals Report and Touchpoint Report

The app install counts in the Touchpoints Analysis Report and the Touchpoints Overlap Report may not be displayed the same due to the following reasons.
  • Timezone difference
  • Aggregation difference

​
Timezone difference

The reports are based on different time zones.The timezones for the Touchpoints Analysis Report and the Touchpoints Overlap Report are fixed to KST. The timezone for the Actuals Report, however, is based on the App timezone by default and can be changed to a different timezone by report view.Therefore, unless the timezone for the Actuals Report is set to KST, the app install count may differ between the Touchpoints Analysis Report or the Touchpoints Overlap Report and the Actuals Report.

​
Aggregation difference

When selecting Installs as the analysis target in the Touchpoints Analysis Report and Touchpoints Overlap Report, the Total or Total Conversions shows the number of total installs, which is the first install a unique user has performed during the set date range.In the Actuals Report, however, when selecting the Installs (App) as a metric, you can view the total number of installs performed during the set date range. Therefore, install count may include multiple installs performed by a single user.Refer to the example below.ExampleReports may show a single user’s app install count differently. For example, let’s say a user performed the following events.
  1. App installed on January 1
  2. App deleted on January 2
  3. App installed on January 3
When the date range is set for January 1 to January 3, the app install count will appear in the respective reports as in the following table.