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 limitations

Integration considerations

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

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.

    

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. 

• 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

Clicks and impressions

Installs and retargeting conversions

In-app events

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

Sessions

Uninstalls

Ad engagement report by tool 

User acquisition reports by tool 

Retargeting raw data reports by tool

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.

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: 
  • SRN installs.
  • In-app events relating to Meta ads, Twitter, and Apple Search Ads. 
  • Unattributed partner postbacks. See events attributed to any partner or organic. 
  • Organic users. See about organic installs.
  • CPA install campaigns having disabled Install postbacks.
• Starting in 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 

Postback reports (available via the Export Data page and Pull API)

Additional fields in postback reports

• 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:

1. Go to Configuration > Active Integrations. 
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.