In-app events

In-app events provide insights into how users interact with your app. AppsFlyer SDKs enable you to easily log these interactions.

In-app events SDK guides

Anatomy of an event

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.

👍

Tip

Quickly define and generate in-app events code for all major platforms using our in-app event generator tool.

Event constants

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 af_.

Custom events and event parameters

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.

🚧

Attention

To avoid confusion with predefined events, don't prefix custom event names with af_.

Valid custom event names

Custom event names should follow these rules:

• Be up to 100 characters long.
• Non-English characters are supported.

Valid custom event parameters

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

Understanding event structure definitions

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:

• The first column (Event name) is the value you pass as logEvent's second argument.

  af_content_view is 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 logEvent:

  • af_price
  • af_content_type
  • af_content_id

• 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_id event 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

See how the example definition above is implemented on Android and iOS.

Offline in-app events

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.