Raw-data report—in-app-events

At a glance:  In-app-events raw-data report lists actions performed by users.

  • 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 conversion.  
  • Separate reports are available for organic and non-organic in-app events. The main difference being that in non-organic in-app events the media source fields are populated using the media source the install was attributed to. 
  • Data freshness: Real-time reports. In-app organic can be delayed by several hours 
  • App-specific time zone: Supported
  • To download the reports see: Data delivery tools

Reports structure

  • Raw data in-app events report:
    • has the same structure as the installs report. This means you can combine them.
    • contains the attribution data of the conversion that brought the user; similar to the install reports. See raw data fields.

Filter by specific in-app-events

Reports can be filters by the in-app event name. 

 Examples

  • "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.

Event values

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 raw data file contains a field Event value, which holds strings of the JSON structured event values.
{"af_level":"10","af_score":"3387","arena":"7","char_type":"paladin"}

Reporting revenue

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.

 Caution

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.

The combination of installs and in-app-events raw data reports contains the full life-time actions performed by your users.

To see a user's journey:

  1. 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.
  2. Combine the CSV files into a single file.
  3. 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.

Retargeting in-app events can be attributed to the UA and retargeting campaign

The example below shows a general re-engagement scenario.

 

Retargeting in-app events are duplicated when a purchase event takes place as part of a retargeting campaign during the UA re-engagement window. This attributes revenue to both the UA media source and the retargeting media source. 

You will only get duplicate event if you have enabled both:

  • install 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_attribtuion=false. 

 Example

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

Retargeting in-app event fields
Event type Media source is_retargeting re_targeting conversion_type is_primary_
attribution 
UA in-app event ua_network False re-engagement or reattribution  False
Retargeting in-app event retar_network True re-engagement or reattribution  True


How do I identify duplicate retargeting events?

The is_primary_attribution boolean field identifies primary and secondary media sources in retargeting campaigns:

  • False: identifies the original UA media source. Note: This is the only scenario where the value is false. 
  • True: identifies the re-engagement media source 

This reason for this is as follows: If a user, as a result of a retargeting campaign, engages with the campaign, a re-engagement window opens. The re-engagement media source is regarded as the primary media source when the re-engagement window is open, and the UA source is secondary. After the window closes, the original UA media source reverts to being primary. 

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.

 Example

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.

 Note

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.

 

Was this article helpful?