Session counting explained

At a glance: The sessions metric is used by advertisers to measure app user engagement during a given period.

DAU_example.jpg

Sessions counting principles

Changes to sessions counting starting February 15, 2021

The number of sessions 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 event af_app_opened event raw data is available in the sessions report via Data Locker. Sessions isn't available via other reporting tools. 

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 calculated using the following rules: 

  • The first app open after downloading the app is not counted in the sessions metric. It forms the basis of the installs metric. 
  • Following sessions are 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 very long, more than several hours, 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: 

  1. In AppsFlyer. go to Configuration > App settings.
  2. Set Minimum time between sessions. 
  3. 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:
    • 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 Twitter, to avoid duplicate postbacks, the af_app_opened event is sent once.

Sessions postbacks to partners

You can send partners sessions postbacks so that a postback is sent for each session counted. 

  • To send the postback: Explicitly map af_app_opened to a partner event.
  • Consider that this is a high-volume event and that many partners don't want to receive it. 

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 (Android, iOS), 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.
Was this article helpful?