At a glance: The sessions metric is used by advertisers to measure app user engagement during a given period.
Sessions counting principles
The number of sessions, AKA launch, performed by users is an important metric and used as a measure of user engagement with the app. It is available via several reports and dashboards. Sessions is used to derive the following metrics:
- Daily active users (DAU)
- Monthly active users (MAU)
- Retention
- Loyal users using the default setting of 3-app opens
Note! In the case of organic sessions, the metric is available in the Activity and Cohort dashboards but isn't available in the Overview dashboard.
Sessions calculation
The sessions metric is calculated using the af_app_opened event reported by the SDK. A minimum time between sessions mechanism regulates which sessions are counted on the server-side.
The af_app_opened event displays as launch in sessions raw data available via Data Locker. Sessions isn't available via other reporting tools. For ease of understanding, in this article, we'll use the term af_app_opened.
Sessions reporting
A session is reported by the SDK when any of the following occur:
- A user launches the app.
- When the app is brought to the foreground from the background. The developer can alter the reporting behavior by calling setMinTimeBetweenSessions.
- An explicit session report by the developer in Android apps. For example, this is implemented by utility apps that are always in the background.
Sessions metric
The sessions metric is counted after considering a minimum time between sessions mechanism with a default duration of 10 minutes as described in the example that follows.
Minimum time between sessions mechanism
The mechanism impacts the sessions count. Note! Consider that if the Minimum time between sessions is long, more than one hour, and users don't open the app many times a day, then some session-related metrics, such as DAU and retention can be impacted. This is especially true in the case of apps where users typically open the app once a day.
Description and example
The mechanism regulates which sessions are counted. A session is counted if the minimum time allowed between sessions has passed.
The flow is as follows: A session is counted → A countdown timer starts → Sessions reported while the timer is counting down are disregarded.
Example
Assumption: The minimum allowed time between sessions setting is 10 minutes.
| Example case | Session reporting times (number of minutes since 00:00) | Number of sessions counted | Sessions disregarded |
|---|---|---|---|
| A | 0, 10, 20, 30 | 4 | None |
| B | 0, 1, 9, 11 | 2 | 1, 9 |
| C | 0, 10, 15, 21 | 3 | 15 |
Timer setting
- Default value: 10 minutes
-
Possible values are:
-
1-60 minutes
-
1-24 hours
-
To set the minimum allowed time between sessions timer:
- In AppsFlyer, from the side menu, select Settings > App settings.
- Set Minimum time between sessions.
- Click Save settings.
The change takes effect within an hour.
Sessions related topics
Retargeting sessions
- Retargeting sessions are available starting July 12, 2020.
-
Retargeting sessions are available in:
- Retargeting and unified view type in the overview dashboard.
-
The relevant Cohort views, meaning retargeting and unified.
- In the case of the unified view, if sessions were attributed to a UA and retargeting media source, the retargeting media source prevails, and the UA media source is not displayed.
- Data freshness: Daily 13:00 UTC.
-
Data Locker: Retargeting sessions reports can be enabled; they include both re-engagement and re-attribution sessions.
- Data freshness: 6-hour lag.
- During re-engagement windows, sessions are attributed to both the UA and retargeting media source. Similarly, other re-engagement in-app events are double-attributed.
- In the case of Google Ads and X Ads, to avoid duplicate postbacks, the af_app_opened event is sent once.
Sessions postbacks to partners
You can send partner session postbacks so that a postback is sent for each session counted.
- To send the postback: Explicitly map af_app_opened to a partner event. Note! In the AppsFlyer raw data report available via Data Locker this event reflects as a launch.
- Consider that this is a high-volume event and that many partners don't want to receive it.
Note
The mapping of af_app_opened is only supported by partners with Send Sessions enabled.
Session reporting by the app (SDK)
App-side: The SDK sends af_app_opened each time the app is opened or brought to the foreground after considering the SDK setMinTimeBetweenSessions setting.
Server-side: Sessions reported by the app are counted and recorded after considering the minimum time between sessions mechanism. Counted sessions are attributed using the same attribution rules as other in-app events.
Explicit sessions reporting by the developer (Android apps only)
Use logSession in Android to explicitly report a session. An equivalent call is not available in iOS.
- Apps that work in the background continuously may require some logic implemented by the developer to report sessions. For example, utility apps like battery savers, launchers, screen locks, and antivirus apps. For these types of apps, consider reporting a session daily at midnight or some other interval appropriate to the app.
- In other cases, you may want to count sessions when users perform some in-app action, such as pressing the clear memory button and so on.
Setting minimum time between app launches
In the SDK, set the minimum time that can lapse between two sessions for them to be reported separately.
Use setMinTimeBetweenSessions, meaning af_app_opened event, to control the minimum amount of time that must occur between sessions so that each of them is reported.
- [Default] five-seconds. Meaning at least 5 seconds must elapse before another session is reported.
- The API allows setting the minimum required time between sessions.
The setMinTimeBetweenSessions SDK reference:
See the setMinTimeBetweenSessions in the Android SDK reference
See the minTimeBetweenSessions in the iOS SDK reference
See the setMinTimeBetweenSessions in the Unity SDK reference