In-app events provide insights into how users interact with your app. AppsFlyer SDKs enable you to easily log these interactions.
In-app events consist of 2 parts:
- Event name: The unique event identifier. It is usually how marketers see the event in the dashboard.
- Event values: An object that consists of key-value pairs called event parameters. Event parameters provide additional context and information about the occurring event.
Event names and event parameters can be either predefined or custom.
Quickly define and generate in-app events code for all major platforms using our in-app event generator tool.
In the SDKs, predefined events and parameters are exposed as constants.
When sending events, it's recommended to use the constants instead of raw strings:
- It reduces the chance to introduce naming discrepancies.
- Changes to the underlying event/parameter names are transparent to you and require less maintenance.
Technically, predefined event names/parameters are strings prefixed with
Custom event names and parameters are user-defined and usually describe scenarios that are specific to your app's business logic and your users' interaction with the app.
To avoid confusion with predefined events, don't prefix custom event names with
Custom event names should follow these rules:
- Be up to 100 characters long.
- Non-English characters are supported.
Custom event parameters:
- Must not exceed 1000 characters; if longer, it might be truncated
- Pricing and revenue: use only digits and decimals, for example, 5 or 5.2
- Pricing and revenue values can have up to 5 digits after the period, for example, 5.12345
Ideally, the marketer should provide you with clear event structure definitions, based on the instructions in Defining In-app events. For example, a definition of an
af_content_view event for an eCommerce app would look something like this:
|Event name||Event parameters||Parameter values||Where/When (Optional)|
|When a user navigates to an item view.|
The first column (Event name) is the value you pass as
logEvent's second argument.
af_content_viewis how marketers see the event in the dashboard. It's recommended to use the predefined event constants instead of the raw string values marketers provide.
The second column (Event parameters) lists the event parameters associated with the event. In this case, you should pass the following event parameters to
The third column (Parameter values) contains additional information about particular values assigned to event parameters. In the example above, the marketer clearly communicates that the
af_content_idevent parameter value should be the viewed item's SKU.
The fourth column is where the marketer describes where and when in the app should the event occur
The SDK can cache in-app events that occur when no internet connection is available:
- The SDK sends the events to AppsFlyer servers and waits for a response
- If the SDK doesn’t receive a 200 response, the events are cached
- Once the next 200 response is received, the stored events are re-sent to the server
- If there are multiple events in the cache, they are sent to the server one after another (unbatched, one network request per event).
The SDK can cache up to 40 events. Only the first 40 offline events are stored. Everything that comes afterward (until the next successful response), gets discarded.
Updated about 2 months ago