1. Help Center
  2. Marketers
  3. Analyze & Optimize
  4. Analyze your data
  5. Raw data reporting/APIs

Raw data reporting overview

Avatar
Gray Goldstein
Last update:
  • Marketers
  • Agencies

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.

Considerations:

  • 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.
Reporting tools
Tool Description Multiple /single app (1) Data freshness capability (2) Embed in scripts Time zone Currency
Raw data export page
  • Download report using the user interface
  • Format: CSV file
 Single Continuously updated x

App-specific

 App-specific
Pull API*
  • Download report using API calls.
  • Format: CSV files
 Single Continuously updated ✓
  • Selectable
  • Default: UTC
  • Selectable
  • Default: USD
Data Locker P
  • Data streamed to a bucket in the cloud
  • No volume limitations
  • Data availability window: 14 days.
  • Format: CSV or  parquet
 Multiple Continuously updated with a lag of several hours ✓ UTC USD 
Push API P
  • User journey data (installs, in-apps, retargeting, SKAN) sent to your servers in real-time.
  • Format: JSON or query params
 Can use the same endpoint Minutes after the event is recorded in AppsFlyer ✓ UTC + app-specific USD + app-specific
SDK Conversion data (3)
  • Get attribution conversion data within the app.
  • Format: JSON
 N/A  Real-time <5 seconds  ✓ UTC N/A

Notes and abbreviations:
(1) Multiple app support
(2) Actual data freshness depends on the report itself, as some reports are Daily.
(3) SDK conversion data retrieves user attribution data in less than 5 seconds from the first app launch and therefore is the least accurate method.
(P) Premium feature
(*) Report generation quotas apply
Tool limitations
Limitation  Pull API (*) Push API Data Locker SDK
Conversion data
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 availability window 90 days N/A 14 days  Lifetime (available in the SDK)

(*) Report generation quotas apply
Integration considerations
Consideration  Pull API Push API Data Locker SDK
Conversion Data
Server-side development Optional Required Optional Optional
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 CSV or parquet 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.

Report fields

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.

User journey raw data field groups
Field group Relevant to organic users Example fields
App Yes App ID, app name, app version, SDK version, ATT
Attribution

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
Event

Yes

Populated in in-app event reports:

Event name, event value, event revenue

User journey reports

Raw_data_-_User_acquisition_.png

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)
    • Acquisition
    • Retargeting

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.

      Raw_data_-_Retargeting.png

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. 
User journey reports
Category Unique to Data Locker Report topic Organic Non-organic
User acquisition ✓ Clicks N/A
Retargeting ✓ Clicks from retargeting campaigns  Retargeting always non-organic
User acquisition ✓ Impressions N/A
Retargeting ✓ Impressions from retargeting campaigns Retargeting always non-organic
User acquisition - Installs  ✓ ✓
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  ✓ Sessions ✓ ✓
User acquisition - Non-organic uninstalls  - ✓
User acquisition - Organic uninstalls ✓ -
User acquisition ✓ Cross-platform engagements ✓ ✓

User journey report descriptions

Clicks and impressions
Report Characteristics
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.
Use case
  • Optimize campaigns that don't lead to an app open (install, re-attribution, re-engagement).
  • Retarget these users using different campaigns.
Example report Clicks
Remarks

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. 
Installs and retargeting conversions
Report name 

User acquisition: Installs

 Retargeting: Conversions
Context

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. 
Use cases
  • Generate aggregated reports using fields not available via AppsFlyer analytics tools.
  • Combine with other reports for advanced, cross-section analysis.
  • Analyze performance across different dimensions such as cities, metropolitan areas, and so on. 
  • Segment users according to country, city, and language for targeting purposes.
  • Obtain user device IDs for retargeting purposes.
 Similar to installs.
Organic vs. non-organic
  • Non-organic: The attribution and contributors attribution field groups are populated
  • Organic: The media source field is either blank, null, or organic. Consider this when you load data into your systems. 
 Not applicable
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. 
In-app events
Report Characteristics

Report context

Chronological list of the actions performed by users after attribution (install, re-attribution, or re-engagement)

Characteristics
  • The report structure and fields are similar to those of install reports.
  • Dedicated fields describe the event. These include the event name, value, revenue, and time. 

Use case

Use the report to:

  • Gain insights by observing the user journey during the user's lifetime

  • Combine the install and in-app-event raw data to follow the complete user journey. 

Event values

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.


{"af_level":"10","af_user_journey":"3387","arena":"7","char_type":"paladin"}

Reporting revenue

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

Example report

 In-app events

Remarks
  • Retargeting in-app events are doubly recorded in both the UA and retargeting in-app event raw data reports. 
  • In-app events don't include the launch (af_app_opened) event. This is available in the sessions raw data report. 
  • Geo location: Is derived using the user IP address at the time the event is performed. 
Sessions
Report Characteristics
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. 
Characteristics

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 The sessions report is similar to the in-app events report. Note: In raw data, sessions have the event name launch. 
Uninstalls
Report Characteristics
Context Record of users uninstalling the app. 
Characteristics
  • This report updates daily and not continuously, as is the case for other user journey reports. 
  • In the report, the event time represents the time AppsFlyer determines the app was uninstalled, and not the actual uninstall itself. See Uninstall measurement.
Fields available
  • If the user comes from a non-organic media source, media source fields are populated. 
  • Consider that the uninstall event is generated by AppsFlyer servers after determining that the user uninstalled. Consequently, many fields aren't populated. 
  • User identifiers available are those recorded at the time of install. The CUID is never available. 
  • Geo-related fields are populated with the user location at the time of engagement with the media source (click or impression). If the engagement location isn't available then the location associated with the install event is used. 
Example report Uninstalls Note! In the example, for clarity, row 2 indicates which fields are populated if relevant data is available. 
Use cases
  • Analyze the uninstall event, device, and user characteristics.
  • Build an uninstall event audience for retargeting.

User journey report availability per tool

Report Export data Pull API Data Locker Push API SDK
Conversion Data
Impressions (1) - - ✓ - -
Clicks (1) - - ✓ - -
(1) Clicks and impressions data is made available by non-SRNs. SRNs don't make this data available.
Ad engagement report by tool 
User acquisition reports by tool 
Report Export data Pull API Data Locker Push API SDK conversion data
Installs ✓ ✓ ✓ ✓ ✓
Sessions - - ✓ - -
In-app events ✓ ✓ ✓ ✓ -
Uninstalls ✓ ✓ ✓ - -
Report Export data Pull API Data Locker Push API SDK
conversion Data
Clicks (1) - - ✓ - -
Conversions (re-attributions + re-engagements) ✓ ✓ ✓ ✓ ✓
Impressions - - ✓ - -
Sessions - - ✓ - -
In-app events ✓ ✓ ✓ ✓ -

(1) Clicks and impressions data is made available by non-SRNs. SRNs don't make this data available.
Retargeting raw data reports by tool

FAQ

 
Details

Why is Facebook raw data missing?

By default, Facebook raw data are attributed to the restricted media source. See Facebook user-level data.

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: 

  • Attributed touch time: The time the user engaged with an ad.
  • Install time: The time that the app is launched for the first time.
  • Event time: The time the event takes place.

Consider: 

  • In install reports, the install and event times are the same.
  • In in-app event reports, the install and event times are different. The difference can show the time that passes between app launch and user engagement with the app.

What is the purpose of the contributor field?

The contributor field lists contributor media sources. Sometimes referred to as Assisted Installs. In Protect360, it is also used for hijacked install attribution correction.

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

A 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 the 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 structure, they can be merged into a single report. In the merged report, you can aggregate and filter by AppsFlyer ID and Customer User ID (if available) to analyze user journeys.

 Examples

Engaged user—strong

  • A user installed the app on August 20 at 09:31.
  • The merged report shows that they made purchases on August 20 at 10:31, August 22 at 15:22, and August 25 at 16:47.
  • From this, we conclude that the user is an engaged user. They made a purchase one hour after launching the app and continued purchasing on the days following the install.

Engaged user—weak

  • A user installed the app on July 30. The merged report shows that they added an item to their cart on August 15, but there are no subsequent purchase events.
  • You can assume that the user is hesitant to make a purchase and choose to retarget them with the item they added to the cart.

Analyzing the user journey for campaign optimization

  • The user acquisition (UA) manager of a travel app downloads the install and in-app event reports and merges them.
  • Then, to view user journeys in the app, they filter or aggregate data by AppsFlyer ID.
  • They notice that a given user, identified by their AppsFlyer ID, downloaded the app 12 months ago and booked a flight several days later.
  • Subsequently, the user viewed a few flight deals but didn't make any bookings. Looking further, the UA manager discovers more users with the same pattern and decides to dig even deeper.
  • They find that most of these users came from Ad A of Campaign B run on Media source C. It turns out that this ad and campaign targeted users who wanted to travel to a specific destination.
  • By analyzing the user journey, the UA manager might conclude that the campaign was too narrowly focused and that users weren't sufficiently engaged by the app.

Feature reports

Reports relating to additional features available in the platform

Postbacks

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.

Postback reports
(available via the Export Data page and 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
Additional fields in postback reports
Field Remarks
Postback URL

Some values, like revenue, may not appear in the appropriate field, but you can still see this data in the Postback URL.
Postback method  
Postback HTTP response code 200: Confirms that the postback was received by the ad network
Postback error message   

Protect360 fraud and validation rules

To grant an integrated partner permission to access Protect360:

  1. Go to Integration > Integrated Partners. 
  2. Select the integrated partner.
  3. In the Permissions tab, turn on Access your Protect360 dashboard & raw data via API.
  4. To give access to the In-app events (CPA) dashboard, turn on Access aggregate in-app events data.
Was this article helpful?

Articles in this section

Related articles