At a glance: Row-level data (aka raw data) describes events relating to users like installs, in-app events, website visits, Protect360 blocked installs, ad revenue generated, and user-associated postbacks sent to partners. Raw data reports are available via download, API, and Data Locker.
Raw data reporting—tools and reports
Related reading: Aggregate reports and analytics
Raw data reports enable you to analyze user behavior and journeys, reconcile ad network accounts, and enrich your CRM and BI systems. By using raw data, you increase your ability to analyze, optimize, and improve app performance.
Reports are made available via reporting tools. The tools have different characteristics suited to different use cases. For example, to reconcile a given ad network account, download the report as needed via the Export data page. To get user performance data to load into your BI systems, get the data programmatically using Data Locker or Pull API.
Reporting tools—characteristics and features
Reports are made available using the reporting tools listed in this section.
- The report date range relates to the activity (actual) date the event took place. This is in contrast to aggregated reports where the date range is LTV-based.
- Fields descriptions—see the data field dictionary.
|Tool||Description||Multiple /single app (1)||Data freshness capability (2)||Embed in scripts||Time zone||Currency|
|Raw data export page||
|Data Locker P||
||Multiple||Hourly. With a lag of several hours||✓||UTC||USD|
|Push API P||
||Can use the same endpoint||Minutes after the event is recorded in AppsFlyer||✓||UTC + app-specific||USD + app-specific|
|SDK Conversion data (3)||
||N/A||Real-time <5 seconds||✓||UTC||N/A|
|Limitation||Pull API (1)||Push API||Data Locker||SDK
|Data limit||1M rows per call||N/A||N/A||N/A|
|Data selection options||Select data types. Limited field selection options||Select data types, fields, and in-apps||Select data types, fields, and in-apps||No|
|Data retention||90 days||N/A||30 days||Lifetime (available in the SDK)|
|(1) The number of API calls is limited|
|Consideration||Pull API||Push API||Data Locker||SDK
|Requires data processing||Optional||Required||Optional||Optional|
|Risk of data loss||No||Yes, if receiving servers are down||No||Small, if there are delays in ad network response|
|Client-server processing costs||None||High||Low||None (unless sending the data to the servers)|
|Client-server maintenance||None||High||Low||None (unless sending the data to the servers)|
|Data format||CSV file||JSON or query params||GZ compressed CSV file||JSON|
Raw data records occurring in a given context are grouped together in reports. For example, non-organic installs, organic in-app events. For ease of explanation, reports are grouped as follows:
- User journey: Use to trace the journey and engagement of a user with the app.
For example: click > install > in-app event > uninstall.
- Feature: Relate to a given AppsFlyer feature but aren't part of the main user journey. For example, postbacks to ad networks, fraud and Validation Rules reports, and user-level ad revenue reports.
The raw data field dictionary contains fields relevant to user journey reports and some feature report fields. The principles are as follows:
- User journey:
- Have a common set of fields.
- Field population depends on the journey context. For example, non-organic reports contain the media source credited with bringing the user. Attribution fields in organic reports aren't populated because there is no media source.
- Feature: Have a unique set of fields or contain user journey fields and additional fields relevant to the feature. For example, SKAdNetwork reports have a unique list of fields, whereas postback reports contain the user journey fields and additional fields relating to postback sending to partners.
Tip! The best way to become familiar with the reports is to view reports. You can download your reports via the Export data page.
For ease of understanding, user journey fields are divided into groups based on context.
|Field group||Relevant to organic users||Example fields|
|App||Yes||App ID, app name, app version, SDK version, ATT|
No, except for install time
Install time, attributed touch time, media source, campaign, adset, ad, partner, retargeting conversion type
|Contributors attribution||No||Contributor partner, match type|
|Device info||Yes||Advertising ID, GAID, OAID, device type, customer user ID|
|Device location||Yes||IP address, city, country|
Populated in in-app event reports:
Event name, event value, event revenue
User journey reports
User journey basics
User journey reports contain data collected for events occurring during a user's lifetime. The data is divided into reports according to:
- User source: organic or non-organic
- Journey context:
- Engagement with ads before app install (impressions and clicks)
User acquisition (UA) reports contain:
- The impressions and clicks occurring before install by any potential user engaging with an ad.
- Install event.
- Subsequent in-app events performed by the user.
Retargeting reports contain:
- The impressions and clicks occurring when the user is retargeted.
- Conversion events: Either a re-engagement or re-attribution.
- Subsequent in-app events performed as part of the re-engagement. Consider:
- Retargeting data is always non-organic.
- Retargeting in-app events are in both the UA and retargeting in-app event reports. See retargeting double-attribution methodology.
To follow a user journey, combine the reports that relate to the part of the journey that interests you, for example, installs and in-app events. Having done so, sort the report using AppsFlyer ID, event time, and report type. The result is the events of a given user over time, meaning the user journey.
User journey report availability
- Report availability depends on your subscription plan.
- Reports can include either organic users, non-organic users, or both, as indicated.
- Retention policies apply to historical raw data reports depending on the reporting tool and the origin of the raw data. In general, data is available for the previous 90 days. Note! Retention policies don't apply to aggregated data.
|Category||Unique to Data Locker||Report topic||Organic||Non-organic|
|Retargeting||✓||Clicks from retargeting campaigns||Retargeting always non-organic|
|Retargeting||✓||Impressions from retargeting campaigns||Retargeting always non-organic|
|User acquisition||In-app events||✓||✓|
|User acquisition||Attributed ad revenue||-||✓|
|User acquisition||Organic ad revenue||✓||-|
|Retargeting||Retargeting ad revenue||Retargeting always non-organic|
|Retargeting||Retargeting conversions (re-engagements and re-attributions)||Retargeting always non-organic|
|Retargeting||Retargeting in-app events (re-engagements and re-attributions)||Retargeting always non-organic|
|Retargeting||✓||Retargeting sessions (re-engagements and re-attributions)||Retargeting always non-organic|
|User acquisition||Non-organic uninstalls||-||✓|
|User acquisition||Organic uninstalls||✓||-|
User journey report descriptions
|Context||A user engages with a campaign and clicks or views an ad.|
|Characteristics||The reports contain a record of the attribution link and HTTP headers present when a user clicks or views an ad.|
SRN data not available.
|Restricted users||In some cases, due to privacy rules, impression and click data is either restricted (doesn't have user identifiers) or is not available at all. The availability depends on the media source and platform.|
When a user opens an app for the first time.
After a user engages with a retargeting ad and then opens the app. A retargeting conversion being a re-engagement or re-attribution.See Retargeting attribution guide.
||Similar to installs.|
|Organic vs. non-organic||
|Example report||Installs||Retargeting conversions report has the same structure as the installs report. Some fields are populated in the context of retargeting. See retargeting raw data.|
Chronological list of the actions performed by users after attribution (install, re-attribution, or re-engagement)
Use the report to:
Event value field
The event value field contains all the data related to the event in a JSON. You can load this into your BI system for further analysis.
Tip! You can use Power Query in Microsoft Excel to parse the event parameters from the JSON text strings.
The revenue and ROI data in AppsFlyer are derived from the af_revenue sent in events.
When the af_revenue parameter is sent in an in-app-event, AppsFlyer uses this to populate the event revenue field. It is in this field that AppsFlyer uses to update the dashboard and aggregated reports.
Note! Use only the af_revenue parameter with in-app-events that describe actual revenue generated. For other events that involve revenue, but are not final, for example, add_to_cart, use different parameters like af_price
|Context||When the user opens the app, a session event is sent to AppsFlyer. The event is recorded if the minimum time between sessions threshold is exceeded.|
The report structure is the same as in-app event reports. Sessions (session events) are in a separate report due to the large number of such events.
|Use case||Understand user engagement with the app.|
|Example report||Sessions report is similar to the in-app events report. Note! Sessions have the event name launch in raw data.|
|Context||Record of users uninstalling the app.|
|Example report||Uninstalls Note! In the example, for clarity, row 2 indicates which fields are populated if relevant data is available.|
User journey report availability per tool
|Report||Export data||Pull API||Data Locker||Push API||SDK
|(1) Clicks and impressions data is made available by non-SRNs. SRNs don't make this data available.|
|Report||Export data||Pull API||Data Locker||Push API||SDK conversion data|
|Report||Export data||Pull API||Data Locker||Push API||SDK
|Conversions (re-attributions + re-engagements)||✓||✓||✓||✓||✓|
(1) Clicks and impressions data is made available by non-SRNs. SRNs don't make this data available.
Why are Facebookraw data missing?
What is the difference between the timestamps?
The timestamps are common to all the reports. This makes it possible to combine different reports.
The following timestamps are relevant:
What is the purpose of the contributor field?
What is the keywords field—why isn't available in all non-organic installs?
Installs attributed to Google Ads or Apple Search Ads, can contain the keywords or keyword ID associated with the ad bringing the install.
Install report tips
Understanding the user journey
User journey is a series of steps that the user performs before achieving a goal like purchasing a product or booking a flight. The idea behind analyzing a user journey is to see what the user does in the app, how active they are, and what value they bring during a given period.
You can identify and highlight user journeys with the help of AppsFlyer ID. The ID is generated for each app install per device. The ID remains unchanged throughout the user lifecycle (from install to uninstall.) The ID persists if the user resets their device ID.
Since the install and in-app events reports have the same structures, they can be merged into one report. In the merged report, you can aggregate and filter using AppsFlyer ID and Customer User ID (if available) to analyze user journeys.
Analyzing the user journey for campaign optimization
By analyzing user journey they are able to understand that the campaign might have been too narrow or too focused and that users weren't sufficiently engaged by the app.
Reports relating to addtional features available in the platform
Use postback reports, to review copies of data sent to an ad network. For example, use them to investigate discrepancies. These reports are for information purposes, and are not required for integration with ad networks.
- The report contains:
- Copies of postbacks sent to the attributed media source.
- Raw data fields and additional fields as detailed in this section.
- The report doesn't contain:
- Starting March 2021, fields are populated according to a network's Advanced Privacy setting. Meaning, if Advanced Privacy is on, some fields, like user identifiers aren't included. See Advanced Privacy postback specification for ad networks.
- URIs for postback reports via Pull API
|Report topic||Events sent to the attributed media source|
|Installs||Non-organic (UA) installs|
|In-app events||Non-organic in-app events|
Retargeting conversion postbacks
|Retargeting (re-engagement and re-attribution)|
Retargeting in-app events
Retargeting in-app events
Some values, like revenue, may not appear in the appropriate field, but you can still see this data in the Postback URL.
|Postback HTTP response code||200: Confirms that the postback was received by the ad network|
|Postback error message|
Protect360 fraud and validation rules
- See Protect360 and validation rules raw data reports
- Ad networks and agencies need advertiser permission to access Protect360 and Validation Rules reports
To grant an integrated partner permission to access Protect360:
- Go to Integration > Integrated Partners.
- Select the integrated partner.
- In the Permissions tab, turn on Access your Protect360 dashboard & raw data via API.
- To give access to the In-app events (CPA) dashboard, turn on Access aggregate in-app events data.