Session in der mobilen Analytik: was es ist, wie es gemessen wird und welche Metriken

Was ist eine Session in der mobilen Analytik?

Eine Session ist ein Zeitraum, in dem ein Benutzer aktiv mit der App interagiert. Die Session beginnt beim Öffnen der App (oder bei der Rückkehr aus dem Hintergrund) und endet nach einer Inaktivitätsphase oder beim Schließen.

Verschiedene Analyseplattformen definieren die Grenzen einer Session unterschiedlich. Firebase Analytics betrachtet eine Session nach 30 Minuten Inaktivität als beendet, AppsFlyer nach 60 Minuten, Amplitude nach 5 Minuten oder beim session_end-Ereignis. Es gibt keinen einheitlichen Standard.

Warum Sitzungen wichtig sind

Auf Sitzungen basierende Metriken sind die Grundlage für die Berechnung der Retention (Retention Rate), der Engagement-Tiefe (Stickiness Ratio) und der Benutzerverteilung nach Nutzungshäufigkeit (Session Frequency). Ohne eine korrekte Session-Definition sind alle abgeleiteten Metriken ungenau.

Laut Mixpanel (2024) verzeichneten Apps, die die Session Duration um 15% verbesserten, innerhalb eines Quartals ein LTV-Wachstum von 22%. Dies ist eine direkte Korrelation zwischen der Zeit in der App und der Monetarisierung.

Wie wird eine Session gemessen?

Die Sitzungsmessung basiert auf Ereignissen des App-Lebenszyklus: öffnen (session_start) und schließen (session_end). Dazwischen werden alle Benutzeraktionen aufgezeichnet.

// Basic session tracker for 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
    }
}

Der Code verfolgt Start und Ende der Sitzung über System-Callbacks. Der Parameter SESSION_TIMEOUT (30 Minuten) legt fest, wann eine Rückkehr aus dem Hintergrund als neue Sitzung und nicht als Fortsetzung der vorherigen betrachtet wird.

Timeout-Regeln nach Plattform

Die Wahl des Timeouts beeinflusst die Metriken: ein kurzes Timeout (5 Min) erzeugt mehr Sitzungen, ein langes (60 Min) fasst Interaktionen zusammen. Wichtig ist, eine Regel festzulegen und sie beim Vergleich von Zeiträumen nicht zu ändern.

Wichtige Session-Metriken

Die Sitzungsanalyse stützt sich auf vier grundlegende Metriken. Jede deckt einen bestimmten Aspekt des Benutzerverhaltens auf.

Session Duration

Die Sitzungsdauer ist die durchschnittliche Zeit, die ein Benutzer pro Besuch in der App verbringt. Bei Nachrichten-Apps beträgt die Norm 2–4 Minuten, bei Spielen 8–15 Minuten, bei Streaming-Diensten 20+ Minuten. Wenn die Session Duration sinkt, ist dies ein Signal für Probleme mit Inhalten oder der Leistung.

Session Interval

Das Intervall zwischen Sitzungen ist die Zeit zwischen dem Ende der vorherigen Sitzung und dem Beginn der nächsten. Ein kurzes Intervall (Minuten oder Stunden) weist auf hohes Engagement hin. Ein langes Intervall (Tage) signalisiert geringes Interesse oder einen utilitaristischen Anwendungsfall, bei dem die App selten benötigt wird.

Sessions Per User

Die Anzahl der Sitzungen pro Benutzer in einem Zeitraum (Tag, Woche, Monat) ist ein Indikator für die Stickiness. Formel: DAU / MAU (täglich aktive Benutzer / monatlich aktive Benutzer). Ein Wert über 20% gilt als gut, über 50% — als ausgezeichnet für die meisten App-Kategorien.

Session Depth

Die Sitzungstiefe ist die Anzahl der Bildschirme oder Aktionen innerhalb einer einzelnen Sitzung. Sie zeigt, wie tief der Benutzer in die Funktionalität der App eintaucht. Eine geringe Tiefe bei hoher Dauer weist auf Navigationsprobleme hin.

• Session Duration — Zeit in der App pro Besuch
• Session Interval — Rückkehrhäufigkeit
• Sessions Per User — Engagement-Level
• Session Depth — Interaktionsqualität

Session in iOS und Android

Die Plattformunterschiede im App-Lebenszyklus wirken sich direkt auf die Definition einer Sitzung aus. iOS und Android behandeln Hintergrundzustände und Benachrichtigungen unterschiedlich.

Android — Activity-Lebenszyklus

Unter Android beginnt eine Sitzung, wenn onStart() der ersten Activity aufgerufen wird, und endet mit onStop() der letzten Activity. Das System kann den Prozess jedoch im Hintergrund beenden, was die Sitzung fälschlicherweise beendet. Für eine zuverlässige Verfolgung wird die Verwendung von Application.ActivityLifecycleCallbacks empfohlen.

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()
                }
            }
        })
    }
}

Der Zähler activityReferences bestimmt, ob der Benutzer mindestens einen Bildschirm sieht. Wenn er 0 erreicht, ist die App in den Hintergrund gegangen und die Sitzung ist beendet.

iOS — UIApplicationDelegate

Unter iOS ist eine Sitzung an die Methoden applicationDidBecomeActive und applicationDidEnterBackground gebunden. Push-Benachrichtigungen können die Sitzungsanzahl künstlich erhöhen — dies sollte in der Analytik berücksichtigt werden.

Swift-Beispiel:

import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {

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

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

Hinweis: Unter iOS beendet das Wechseln zwischen Apps (App Switcher) eine Sitzung nicht — nur das Wechseln in den tiefen Hintergrund oder das Schließen durch Wischen löst sie aus.

Wie analysiert man Benutzersitzungen?

Die Sitzungsanalyse geht über das einfache Zählen hinaus. Segmentierung und Kohortenanalyse decken Engagement-Muster auf, die in aggregierten Daten nicht sichtbar sind.

Kohortenanalyse von Sitzungen

Gruppieren Sie Benutzer nach Installationswoche und betrachten Sie die durchschnittliche Anzahl der Sitzungen in den ersten 7 Tagen. Wenn die aktuellste Installationskohorte eine niedrigere Sessions Per User aufweist als ältere, ist dies ein Zeichen für eine Verschlechterung des Onboardings oder der Traffic-Qualität.

• Tag 0 — Installation + erste Sitzung
• Tag 1–3 — Aktivierungsphase (3+ Sitzungen erwartet)
• Tag 7–30 — Gewohnheitsbildung (stabile 1–2 Sitzungen pro Tag)
• Tag 30+ — Bindung treuer Benutzer

Sitzungsanomalien: wie man sie erkennt

Anomalien in den Sitzungsmetriken sind frühe Indikatoren für Probleme. Ein plötzlicher Anstieg kurzer Sitzungen (unter 5 Sekunden) nach einem Release deutet auf einen Startfehler hin. Ein 30%iger Rückgang der Session Duration an einem Tag kann auf einen Serverausfall oder eine API-Änderung hinweisen. Richten Sie eine Überwachung mit Schwellenwerten ein: wenn die durchschnittliche Session Duration um mehr als 2 Standardabweichungen vom 7-Tage-gleitenden Mittelwert abfällt, lösen Sie einen Alarm aus.

Verwenden Sie die Segmentierung nach App-Version in den Sitzungsberichten. Version 3.2.0 zeigt eine Session Duration von 4 Minuten, Version 3.2.1 zeigt 2 Minuten. Ursache ist eine Änderung im Onboarding. Das Zurücksetzen der Version stellt die Metrik wieder her. Ohne Version-Segmentierung würden Sie einen durchschnittlichen Rückgang sehen, aber die Ursache nicht finden.

Segmentierung nach Sitzungshäufigkeit

Power Users (5+ Sitzungen pro Tag) — Ihre Schlüsselzielgruppe. Casual Users (1–2 Sitzungen pro Woche) — eine Gruppe für die Reaktivierung. Dormant Users (0 Sitzungen in 30 Tagen) — Kandidaten für Retargeting oder Push-Abmeldung.

Berechnen Sie für jedes Segment separate Metriken: die Session Duration für Power Users zeigt die Nutzungstiefe, für Casual Users die Einstiegsbarrieren. Laut Amplitude (2024) steigern Apps, die Inhalte nach Sitzungssegment personalisieren, die Session Duration um durchschnittlich 18% pro Monat.

Verwendung von Sitzungen in Retentionsberichten

Die Retention wird über Sitzungen berechnet: ein Benutzer gilt an Tag N als gebunden, wenn er mindestens eine Sitzung hatte. Unterschiedliche Produkte erfordern jedoch unterschiedliche Definitionen. Für soziale Netzwerke kann eine Sitzung 1 Sekunde dauern, für einen Streaming-Dienst 15 Minuten.

Verwenden Sie Deinstallations-Sitzungen als Qualitätsindikator: wenn nach einem Update die Anzahl kurzer Sitzungen (unter 10 Sekunden) zunimmt, finden Benutzer die benötigte Funktionalität nicht. Dies ist ein frühes UX-Problemsignal vor dem Anstieg der Deinstallationen.

Sitzungsbasierte Traffic-Attribution

Verknüpfen Sie Sitzungen mit Traffic-Quellen: Benutzer aus bezahlten Kanälen sollten mehr Sitzungen und eine längere Session Duration haben. Wenn organischer Traffic eine 40% höhere Session Duration aufweist als bezahlter, liegt ein Problem mit der Targeting-Qualität vor. Die Sitzungsattribution hilft, das Akquisitionsbudget zu optimieren.