At a glance: The main place to find hidden gems in your user data is the in-app-events raw data report. The report contains the actions performed by non-organic users, sent to AppsFlyer, using the integrated SDK, server to server API, and by native web view.
The in-app-events raw data report is the main source of activity data, meaning a chronological list of the actions performed by users after acquisition.
In the Dashboard this is the only source for specific event value information (except for the Audiences premium feature), excluding revenue related information.
This article discusses several topics about the in-app-events raw data report and how to use it.
Raw data reports structure
Raw data in-app-events and install reports have the same structure enabling you to combine the reports. The in-app events in the raw data also contain the original attribution data, just like the install event does. See the field list of raw data reports.
Choosing specific in-app-events
You can filter the raw data report by in-app-events type. Note: The in-app-event list, used to filter the report, is updated daily.
To filter the report by in-app-event:
- Go to Reports > Export Data.
- In the raw data reports, select one or more in-app-events. The list contains the non-organic events received by the system. Note: The in-app event filter list is updated daily.
- Select one or many events to appear in the generated report.
- Click outside the box once you've finished selecting events.
- "Off the wagon" - select af_add_to_cart and af_purchase events to see the users that added items to the shopping cart, but didn't go through with it. A good retargeting campaign with a personalized offer may convert these users to buying users.
- "Search and despair" - select af_search and af_content_view events to find out the users that searched for content on your app, but did not consume any content (or else they would have also had af_content_view). You can learn a lot about the most failing search keywords in your app.
- "One at a time" - some apps have such large audiences that even a day of events exceeds the CSV files size limitation. Using the events filter to download files per single event type is a good solution for these app owners.
AppsFlyer in-app-events, called rich in-app events, as they contain value parameters in addition to the basic event name. The in-app-events report contains the parameter values.
The revenue and ROI data available in AppsFlyer come from af_revenue in the various events.
When the af_revenue parameter is sent in an in-app-event, AppsFlyer adds the revenue value to the total revenue of the user and the media sources. In the in-app-events report, this value displays in the event_revenue column.
Only use 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.
How to follow a user's journey
There are many insights you can draw out of observing the different customer journeys your users have from the initial launch of the app, and throughout their lifetime.
To see a user's journey:
- Download installs and in-app-events reports for the same periods of time.
Note: you can download up to a month of in-app-events at a time. See report limitations.
- Combine the CSV files into a single file.
- Sort or filter the file using the AppsFlyer ID field.
The result is a group or groups of events performed by each of your users.
What is the "is primary attribution" value?
During the re-engagement window, which happens after a user engages with a retargeting campaign, AppsFlyer attributes events to both the original media source (prior to the re-engagement) and to the retargeting media source.
During this window the original media source is not considered to be the primary attribution for the user's events ("false" value), while the retargeting media source is considered as primary("true").
After the re-engagement window closes down, the original media source returns to be the primary and only attribution.
What are the "is retargeting" & "is primary attribution" cases?
The example below shows a general re-engagement scenario.
The following table shows where and when in-app-events appear in raw data report, following user acquisition and retargeting conversions:
|When||User acquisition in-app events report||Retargeting in-app events report|
|Events from acquired users (installs)||during user lifetime||Yes, primary||No|
|Events from re-engagements||during re-engagement window||Yes, not primary||Yes, primary|
|Events from re-attributions||during user lifetime||No||Yes, primary|
- Using the regular in-app-events report you can filter in only primary results ("Is Primary Attribution" is true) to see only the regular (non-retargeting) events.
- Using the regular in-app-events report you can filter in only non-primary results ("Is Primary Attribution" is false) to see only the retargeting events. Note that the media sources in these events are the original sources, and not the retargeting ones, which are actually attributed with the events.
Why is af_app_opened event missing?
The af_app_opened Event is automatically generated upon every successful launch of AppsFlyer SDK.
af_app_opened is mainly used by AppsFlyer as a tool for calculating retention data. It is also used for notifying some media sources with launch data directly via postbacks from AppsFlyer.
Therefore, and also due to the vast number of these events, which would "drown" all other events, the af_app_opened Event is not included in the in-app-events raw data report.
Which Geo do events belong to?
AppsFlyer sets the user location parameters, i.e. country, city, DMA etc. according to the user's IP address on install time.
However, human users tend to move around and perform in-app-events from different locations and IP addresses than during their original installs.
AppsFlyer raw data, and consequently the aggregated data, display the actual location of the user during the performance of the event, and not the original location during the install.
The reasoning behind this is to help with analyzing data for user behavior. In some verticals the location of users may have greater effect on their actions than their original install location. Analyzing the relative performance of locations can help advertisers focus on relevant retargeting campaigns to increase their user engagements.
Luber, a hail ride travel app, identified a relatively large number of ride events taking place in Springfield. To maximize its users' engagements Luber sends a retargeting push notification to any user that arrives to Springfield.
In case the IP address during the in-app-event's performance cannot be resolved, the IP address during the install is used.
Contributor and Google play data in in-app-events reports
Contributor data and Google Play data doesn't appear in raw in-app-events reports. All other fields are populated if they are available on the install data.