Session en analytique mobile : définition, mesure et métriques clés

Qu’est-ce qu’une session en analytique mobile ?

Une session est une période pendant laquelle un utilisateur interagit activement avec l’application. La session commence à l’ouverture de l’application (ou au retour de l’arrière-plan) et se termine après une période d’inactivité ou de fermeture.

Différentes plateformes d’analyse définissent les limites de session différemment. Firebase Analytics considère une session terminée après 30 minutes d’inactivité, AppsFlyer après 60 minutes, Amplitude après 5 minutes ou sur événement session_end. Il n’existe pas de standard unique.

Pourquoi les sessions sont importantes

Les métriques basées sur les sessions sont le fondement du calcul de la rétention (Retention Rate), de la profondeur d’engagement (Stickiness Ratio) et de la répartition des utilisateurs par fréquence d’utilisation (Session Frequency). Sans une définition correcte de la session, toutes les métriques dérivées seront inexactes.

Selon Mixpanel (2024), les applications qui ont amélioré la Session Duration de 15% ont connu une croissance du LTV de 22% en un trimestre. Il s’agit d’une corrélation directe entre le temps passé dans l’application et la monétisation.

Comment une session est-elle mesurée ?

La mesure de session repose sur les événements du cycle de vie de l’application : ouverture (session_start) et fermeture (session_end). Entre les deux, toutes les actions de l’utilisateur sont enregistrées.

// Traqueur de sessions basique pour 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
    }
}

Le code suit le début et la fin de la session via des callbacks système. Le paramètre SESSION_TIMEOUT (30 minutes) détermine quand un retour de l’arrière-plan est considéré comme une nouvelle session et non une continuation de la précédente.

Règles de timeout par plateforme

Le choix du timeout affecte les métriques : un timeout court (5 min) crée plus de sessions, un long (60 min) fusionne les interactions. L’important est de fixer une règle et de ne pas la modifier lors de la comparaison des périodes.

Métriques clés de session

L’analyse des sessions repose sur quatre métriques de base. Chacune révèle un aspect spécifique du comportement utilisateur.

Session Duration

La durée de session est le temps moyen qu’un utilisateur passe dans l’application par visite. Pour les applications d’actualités, la norme est de 2–4 minutes ; pour les jeux, 8–15 minutes ; pour les services de streaming, 20+ minutes. Si la Session Duration chute, c’est un signe de problèmes de contenu ou de performance.

Session Interval

L’intervalle entre sessions est le temps entre la fin de la session précédente et le début de la suivante. Un intervalle court (minutes ou heures) indique un engagement élevé. Un intervalle long (jours) signale un faible intérêt ou un cas d’utilisation utilitaire où l’application est rarement nécessaire.

Sessions Per User

Le nombre de sessions par utilisateur sur une période (jour, semaine, mois) est un indicateur de Stickiness. Formule : DAU / MAU (utilisateurs actifs quotidiens / utilisateurs actifs mensuels). Une valeur supérieure à 20% est considérée comme bonne, supérieure à 50% — excellente pour la plupart des catégories d’applications.

Session Depth

La profondeur de session est le nombre d’écrans ou d’actions dans une seule session. Elle montre à quel point l’utilisateur explore les fonctionnalités de l’application. Une faible profondeur avec une durée élevée indique des problèmes de navigation.

• Session Duration — temps dans l’application par visite
• Session Interval — fréquence de retour
• Sessions Per User — niveau d’engagement
• Session Depth — qualité d’interaction

Session sous iOS et Android

Les différences de plateforme dans le cycle de vie de l’application affectent directement la définition de la session. iOS et Android gèrent les états d’arrière-plan et les notifications différemment.

Android — cycle de vie de l’Activity

Sur Android, une session commence lorsque onStart() de la première Activity est appelé et se termine à onStop() de la dernière Activity. Cependant, le système peut tuer le processus en arrière-plan, ce qui met fin à la session de manière erronée. Il est recommandé d’utiliser Application.ActivityLifecycleCallbacks pour un suivi fiable.

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

Le compteur activityReferences détermine si l’utilisateur voit au moins un écran. Lorsqu’il atteint 0, l’application est passée en arrière-plan et la session est terminée.

iOS — UIApplicationDelegate

Sous iOS, une session est liée aux méthodes applicationDidBecomeActive et applicationDidEnterBackground. Les clics sur les notifications push peuvent gonfler artificiellement le nombre de sessions — cela doit être pris en compte dans l’analyse.

Exemple en Swift :

import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {

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

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

Remarque : sous iOS, le changement d’application (App Switcher) ne met pas fin à la session — seul le passage en arrière-plan profond ou le balayage de fermeture la termine.

Comment analyser les sessions utilisateur ?

L’analyse des sessions va au-delà du simple comptage. La segmentation et l’analyse de cohorte révèlent des schémas d’engagement invisibles dans les données agrégées.

Analyse de cohorte des sessions

Regroupez les utilisateurs par semaine d’installation et observez le nombre moyen de sessions au cours des 7 premiers jours. Si la cohorte d’installation la plus récente a un Sessions Per User inférieur aux anciennes, c’est un signe de détérioration de l’intégration ou de la qualité du trafic.

• Jour 0 — installation + première session
• Jours 1–3 — période d’activation (3+ sessions attendues)
• Jours 7–30 — formation d’habitude (1–2 sessions stables par jour)
• Jour 30+ — rétention des utilisateurs fidèles

Anomalies de session : comment les détecter

Les anomalies dans les métriques de session sont des indicateurs précoces de problèmes. Une augmentation soudaine des sessions courtes (moins de 5 secondes) après une publication indique un bug de démarrage. Une chute de 30% de la Session Duration en un jour peut indiquer une panne serveur ou un changement d’API. Mettez en place une surveillance avec des seuils : si la durée moyenne de Session Duration chute de plus de 2 écarts-types par rapport à la moyenne mobile sur 7 jours, déclenchez une alerte.

Utilisez la segmentation par version d’application dans les rapports de session. La version 3.2.0 affiche une Session Duration de 4 minutes, la version 3.2.1 affiche 2 minutes. La cause est un changement dans l’intégration. Revenir à la version précédente rétablit la métrique. Sans segmentation par version, vous verriez une baisse moyenne mais ne trouveriez pas la cause racine.

Segmentation par fréquence de session

Les Power Users (5+ sessions par jour) — votre audience clé. Les Casual Users (1–2 sessions par semaine) — un groupe à réactiver. Les Dormant Users (0 session en 30 jours) — candidats au reciblage ou à la désinscription des notifications push.

Pour chaque segment, calculez des métriques séparées : la Session Duration pour les Power Users montre la profondeur d’utilisation, tandis que pour les Casual Users elle montre les barrières à l’entrée. Selon Amplitude (2024), les applications qui personnalisent le contenu par segment de session augmentent la Session Duration de 18% en moyenne par mois.

Utilisation des sessions dans les rapports de rétention

La rétention est calculée via les sessions : un utilisateur est retenu au Jour N s’il a eu au moins une session. Cependant, différents produits nécessitent des définitions différentes. Pour les réseaux sociaux, une session peut durer 1 seconde (juste ouvert pour vérifier les notifications), pour un service de streaming, 15 minutes.

Utilisez les sessions de désinstallation comme indicateur de qualité : si après une mise à jour le nombre de sessions courtes (moins de 10 secondes) augmente, les utilisateurs ne trouvent pas les fonctionnalités nécessaires. C’est un signal précoce de problème UX avant la hausse des désinstallations.

Attribution de trafic basée sur les sessions

LieZ les sessions aux sources de trafic : les utilisateurs des canaux payants devraient avoir plus de sessions et une Session Duration plus longue. Si le trafic organique montre une Session Duration 40% plus élevée que le trafic payant, il y a un problème de qualité de ciblage. L’attribution de sessions aide à optimiser le budget d’acquisition.