In-app-events relating to user actions and events sent by the app or S2S to the platform are available in in-app raw-data reports.
In-app raw-data report characteristics
- Main source of activity data, meaning a chronological list of the actions performed by users after conversion (install, reinstall, re-attribution, re-engagement).
- Separate reports are available for organic, non-organic, and retargeting in-app events.
- The organic report has no attribution (media source) data.
- The non-organic and retargeting reports have the attribution data of the media source attributed to the conversion.
- Data freshness: Real-time reports. In-app organic can be delayed by several hours.
- The report structure and fields are similar to those of install reports.
- Filter reports using the in-app name.
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 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 follow a user journey:
- Download install and in-app-event reports having the same time period.
Note: In-app events are limited to a period of 30 days. See report limitations.
- Combine the reports into a single file.
- Sort the file using AppsFlyer ID as the primary sort field and event time as the secondary sort field.
The result is a group or groups of events performed by each of your users.
Retargeting in-app events are attributed to the UA and retargeting campaign
The example below shows a typical re-engagement scenario.
Retargeting in-app events during the re-engagement window are double-attributed when a purchase event takes place during a retargeting campaign. This attributes revenue to both the UA media source and the retargeting media source.
You will only get duplicate event if you are combining in one file data from both:
- UA in-app events
- Retargeting in-app events
In-app events attributed to the UA media source as part of a retargeting campaign have the field is_primary_attribution=false.
- A user installs example_app, which is attributed to ua_network
- Later the user re-engages with example_app's retargeting campaign on retar_network and makes a purchase.
The in-app purchase event is sent twice with the following details:
|Event type||Media source||is_retargeting||re_targeting conversion_type||is_primary_
|UA in-app event||ua_network||False||N/A||False|
|Retargeting in-app event||retar_network||True||re-engagement or re-attribution||True|
How do I identify double-attributed retargeting events in user acquisition in-app reports?
In UA in-app event reports events recorded as a result of double attribution are identified as follows:
- The is_primary_attribution field identifies primary and secondary media sources; when false, it means that the attribution is the result of a retargeting campaign and the UA media source is secondary.
- The is_retargeting field is always false.
The corresponding record in retargeting in-app event reports during the re-engagement window are populated as follows:
- The is_primary_attribution field is always true.
- The is_retargeting field is always true.
- To clarify, there is no record whatsoever if the event does not happen during a re-engagement window.
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.