Session in mobiele analytics: wat is het, hoe wordt het berekend en welke metrics

Wat is een sessie in mobiele analytics?

Sessie is een tijdsperiode waarin de gebruiker actief interactie heeft met de app. Een sessie begint op het moment dat de app wordt geopend (of terugkeert uit de achtergrond) en eindigt na een periode van inactiviteit of sluiting.

Verschillende analyseplatforms definiëren de grenzen van een sessie verschillend. Firebase Analytics beschouwt een sessie als beëindigd na 30 minuten inactiviteit, AppsFlyer — na 60 minuten, Amplitude — na 5 minuten of na een session_end-gebeurtenis. Er is geen universele standaard.

Waarom sessies belangrijk zijn

Op sessies gebaseerde metrics vormen de basis voor het berekenen van retentie (Retention Rate), betrokkenheidsdiepte (Stickiness Ratio) en de verdeling van gebruikers op gebruiksfrequentie (Session Frequency). Zonder een correcte definitie van een sessie zullen alle afgeleide metrics onjuist zijn.

Volgens gegevens van Mixpanel (2024) laten apps die de Session Duration met 15% hebben verbeterd een LTV-groei van 22% zien binnen een kwartaal. Dit is een directe correlatie tussen tijd in de app en monetisatie.

Hoe wordt een sessie gemeten?

Het meten van een sessie is gebaseerd op levenscyclusgebeurtenissen van de app: open (session_start) en close (session_end). Tussen deze gebeurtenissen worden alle gebruikersacties geregistreerd.

// Eenvoudigste sessietracker voor Android
class SessionTracker {

    private var sessionStart: Long = 0L
    private val SESSION_TIMEOUT = 30 * 60 * 1000L

    fun onAppOpened() {
        sessionStart = System.currentTimeMillis()
        Analytics.logEvent("session_start")
    }

    fun onAppClosed() {
        val duration = System.currentTimeMillis() - sessionStart
        Analytics.logEvent("session_end") {
            param("duration_ms", duration)
        }
    }

    fun isNewSession(lastActive: Long): Boolean {
        return (System.currentTimeMillis() - lastActive) > SESSION_TIMEOUT
    }
}

De code volgt het begin en einde van een sessie via systeemcallbacks. De parameter SESSION_TIMEOUT (30 minuten) bepaalt wanneer terugkeer uit de achtergrond wordt beschouwd als een nieuwe sessie en niet als een voortzetting van de vorige.

Timeout-regels van verschillende platforms

De keuze van de timeout beïnvloedt de metrics: een korte timeout (5 min) creëert meer sessies, een lange timeout (60 min) — combineert interacties. Het belangrijkste is om een regel vast te stellen en deze niet te wijzigen bij het vergelijken van perioden.

Belangrijkste sessiemetrics

Sessieanalyse is gebaseerd op vier basis metrics. Elk onthult een specifiek aspect van gebruikersgedrag.

Session Duration

Sessieduur — de gemiddelde tijd die een gebruiker in de app doorbrengt tijdens één bezoek. Voor nieuwsapps is de norm 2–4 minuten, voor games — 8–15 minuten, voor streamingdiensten — 20+ minuten. Als de Session Duration daalt, is dit een signaal van problemen met content of prestaties.

Session Interval

Interval tussen sessies — de tijd tussen het einde van de vorige sessie en het begin van de volgende. Een kort interval (minuten of uren) wijst op hoge betrokkenheid. Een lang interval (dagen) — op lage interesse of een utilitair scenario waarbij de app zelden nodig is.

Sessions Per User

Aantal sessies per gebruiker in een periode (dag, week, maand) — een indicator van Stickiness. Formule: DAU / MAU (Day Active Users / Monthly Active Users). Een waarde boven 20% wordt als goed beschouwd, boven 50% — als uitstekend voor de meeste app-categorieën.

Session Depth

Sessiediepte — het aantal schermen of acties tijdens één sessie. Toont hoe diep de gebruiker in de functionaliteit van de app duikt. Een lage diepte bij een hoge duur wijst op navigatieproblemen.

• Session Duration — tijd in de app per bezoek
• Session Interval — terugkeerfrequentie
• Sessions Per User — betrokkenheidsniveau
• Session Depth — interactiekwaliteit

Sessie in iOS en Android

Platformverschillen in de levenscyclus van de app beïnvloeden direct de definitie van een sessie. iOS en Android verwerken achtergrondtoestanden en meldingen verschillend.

Android — levenscyclus van Activity

Op Android begint een sessie bij het aanroepen van onStart() van de eerste Activity en eindigt bij onStop() van de laatste Activity. Het systeem kan echter het proces op de achtergrond doden, wat de sessie onterecht beëindigt. Het wordt aanbevolen om Application.ActivityLifecycleCallbacks te gebruiken voor betrouwbare tracking.

class AnalyticsApp : Application() {

    private var activityReferences = 0

    override fun onCreate() {
        super.onCreate()
        registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks {
            override fun onActivityStarted(act: Activity) {
                if (++activityReferences == 1) {
                    Analytics.trackSessionStart()
                }
            }
            override fun onActivityStopped(act: Activity) {
                if (--activityReferences == 0) {
                    Analytics.trackSessionEnd()
                }
            }
        })
    }
}

De teller activityReferences bepaalt of de gebruiker ten minste één scherm ziet. Wanneer het aantal activiteiten 0 wordt — is de app naar de achtergrond gegaan, de sessie is beëindigd.

iOS — UIApplicationDelegate

Op iOS is een sessie gekoppeld aan de methoden applicationDidBecomeActive en applicationDidEnterBackground. Meldingen van het indrukken van een pushbericht kunnen de sessieteller kunstmatig verhogen — hiermee moet rekening worden gehouden in de analyse.

Swift voorbeeld:

import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {

    func applicationDidBecomeActive(_ application: UIApplication) {
        Analytics.trackSessionStart()
    }

    func applicationDidEnterBackground(_ application: UIApplication) {
        Analytics.trackSessionEnd()
    }
}

Let op: op iOS beëindigt het schakelen tussen apps (App Switcher) de sessie niet — alleen het gaan naar de diepe achtergrond of het wegvegen om te sluiten.

Hoe analyseer je gebruikerssessies?

Sessieanalyse gaat verder dan eenvoudig tellen. Segmentatie en cohortanalyse onthullen betrokkenheidspatronen die niet zichtbaar zijn in geaggregeerde gegevens.

Cohortanalyse van sessies

Groepeer gebruikers op installatieweek en bekijk het gemiddelde aantal sessies in de eerste 7 dagen. Als in het cohort van recente installaties Sessions Per User lager is dan bij oudere, is dit een signaal van verslechtering van de onboarding of de kwaliteit van het verkeer.

• Dag 0 — installatie + eerste sessie
• Dag 1–3 — activeringsperiode (verwacht 3+ sessies)
• Dag 7–30 — gewoontevorming (stabiel 1–2 sessies per dag)
• Dag 30+ — behoud van loyale gebruikers

Sessie-anomalieën: hoe ze te detecteren

Anomalieën in sessiemetrics zijn vroege indicatoren van problemen. Een plotselinge toename van korte sessies (tot 5 seconden) na een release wijst op een bug bij het opstarten. Een daling van Session Duration met 30% op één dag — mogelijke serverstoring of API-wijziging. Stel monitoring in met drempels: als de gemiddelde Session Duration met meer dan 2 standaarddeviaties is gedaald ten opzichte van het 7-daags voortschrijdend gemiddelde — een alert in het systeem.

Gebruik segmentatie op app-versie in sessierapportages. Versie 3.2.0 toont een Session Duration van 4 minuten, versie 3.2.1 — 2 minuten. Oorzaak — een wijziging in de onboarding. Terugdraaien van de versie herstelt de metriek. Zonder segmentatie op versie zou je een gemiddelde daling zien, maar de oorzaak niet vinden.

Segmentatie op sessiefrequentie

Power Users (5+ sessies per dag) — jouw kernpubliek. Casual Users (1–2 sessies per week) — groep voor reactivatie. Dormant Users (0 sessies in 30 dagen) — kandidaten voor retargeting of uitschrijven voor pushmeldingen.

Bereken voor elk segment afzonderlijke metrics: Session Duration voor Power Users toont de gebruiksdiepte, en voor Casual — de toegangsbarrières. Volgens gegevens van Amplitude (2024) verhogen apps die content personaliseren op sessiesegment de Session Duration gemiddeld met 18% per maand.

Gebruik van sessies in retentierapportages

Retentie wordt berekend via sessies: een gebruiker is behouden op dag N als hij ten minste één sessie heeft gehad. Verschillende producten vereisen echter verschillende definities. Voor sociale netwerken kan een sessie 1 seconde zijn (gewoon geopend om meldingen te checken), voor een streamingdienst — 15 minuten.

Gebruik de-installatiesessies als kwaliteitsindicator: als na een update het aantal korte sessies (minder dan 10 seconden) is toegenomen, vinden gebruikers de benodigde functionaliteit niet. Dit is een vroeg signaal van UX-problemen voordat het aantal de-installaties toeneemt.

Sessietoewijzing aan verkeersbronnen

Koppel sessies aan de verkeersbron: gebruikers uit betaalde kanalen zouden meer sessies en een langere Session Duration moeten hebben. Als organisch verkeer een Session Duration laat zien die 40% hoger is dan betaald verkeer, ligt het probleem in de kwaliteit van de targeting. Sessietoewijzing helpt bij het optimaliseren van het acquisitiebudget.