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.

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.

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.

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.

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.

Example

Let'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.

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.

Example

Let'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.

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 status

Raw 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.

• Features affected by EPC

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 policy

According 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.

• Raw data export - Meta privacy policy

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 policy

According 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.

• FAQ - TikTok For Business - Data sharing policy

Raw data export timing

If you export raw data immediately after an event occurs, that event may not be included. Try again after 10 minutes.

The Installs (App) data in the Retention Report does not include duplicate installs based on Airbridge Device ID.

If 2 Installs (App) occur with the same Airbridge Device ID on the same date, the retention metric is measured only for the last app install. If 2 Installs (App) occur with the same Airbridge Device ID on different dates, the retention metric is measured for each install date.

The Installs (App) data in the Actuals Report does not exclude duplicate installs. Therefore, the Installs (App) count in the Retention Report may be smaller than in the Actuals Report. For more details about the identifiers in Airbridge, refer to this article.

The following reasons could be the cause of the discrepancy.

• Difference in the negative number conversion rules

• Difference in the attribution rules

• Event duplication

Note that the Revenue Events used in the Revenue Report correspond to different events in the Actuals Report that can be configured as metrics, as shown in the table below.

The Revenue Report converts negative numbers to 0, whereas the Actuals Report doesn't convert them to 0 and aggregates them as is.

• Actuals Report: The revenue-related events that occurred within the attribution window are measured. Events outside the attribution window are not aggregated.

• Revenue Report: The Revenue Event is attributed to the touchpoint that is the winning touchpoint for the Start Event. The attribution window does not apply.

In the Revenue Report, you can also view the revenue that has been generated outside the attribution window. When the attribution window is smaller, the discrepancy between the measurements may become larger.

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

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.

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.

The Airbridge Device ID is selected based on Airbridge’s internal logic, choosing the most suitable identifier collected from different platforms. Depending on the nature of each Airbridge feature and whether sufficient identifiers are available per device, different identifiers may be used as the Airbridge Device ID across features. As a result, the user count shown in Airbridge reports may differ from the count of identifiers extracted using the 'Airbridge Device ID' property in 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.

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

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.

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.

Example

Reports 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.