Screen View dans l'analyse mobile — définition, métriques clés et suivi

Qu'est-ce que Screen View ?

Screen View est un événement d'analyse qui est envoyé lorsqu'un écran d'application mobile est ouvert. L'événement contient le nom de l'écran (screen_name), la classe (screen_class) et un horodatage. Contrairement à l'analyse web, où page_view est lié à une URL, dans les applications mobiles, les écrans sont identifiés par le nom de l'Activity, Fragment, ViewController ou Custom View.

Structure de l'événement Screen View

Le paramètre previous_screen est particulièrement important : il permet de restaurer la séquence des transitions et de construire un Screen Flow — une carte des parcours utilisateur dans l'application.

Screen View vs Page View : différences clés

Screen View et Page View résolvent la même tâche — enregistrer une vue — mais dans des environnements différents. Sur le web, une URL identifie de manière unique une page, et Page View est lié au chargement du document. Dans les applications mobiles, un écran est un état de l'interface qui ne correspond pas nécessairement à une adresse distincte.

• Page View est lié à une requête HTTP et à une URL — Screen View est lié à un événement du cycle de vie de l'Activity/ViewController
• Page View n'est pas dupliqué lors du retour en arrière (le cache est utilisé) — Screen View est renvoyé à chaque ouverture de l'écran
• Page View est généralement plus court — les utilisateurs consultent une page web plus rapidement qu'un écran mobile avec des éléments interactifs

Une autre différence est la profondeur du contexte. Screen View dans une application mobile inclut des paramètres d'état : si l'utilisateur est authentifié, quelles données sont chargées, si l'écran est ouvert en mode édition. Page View sur le web porte rarement ce contexte — il enregistre seulement le fait du chargement de l'URL. Cela rend Screen View plus informatif pour l'analyse produit, car chaque événement peut être segmenté par état.

Erreurs typiques lors du travail avec Screen View

La première erreur est d'envoyer screen_view à chaque changement d'état dans un écran (changement d'onglet, ouverture d'un popup). Screen View doit enregistrer uniquement une transition complète vers un nouvel écran, pas les micro-interactions.

La deuxième erreur est d'utiliser le nom technique de la classe au lieu d'un nom lisible. « ProductDetailActivityKt » est inutile pour un analyste — utilisez « Product Details » dans screen_name.

La troisième erreur est d'envoyer screen_view sans les champs correspondants. Un screen_name vide crée un ensemble d'enregistrements inutiles qui ne peuvent pas être regroupés. Transmettez toujours au moins screen_name et screen_class, même sur les écrans de test.

Comment suivre Screen View ?

L'implémentation du suivi de Screen View dépend de l'architecture de navigation. Examinons les approches automatique et manuelle en utilisant Jetpack Compose et SwiftUI comme exemple.

Android : suivi automatique dans Jetpack Compose

Utilisez LifecycleEventObserver au niveau de NavigationComponent. Chaque fois qu'un utilisateur navigue vers une nouvelle route, l'événement screen_view est déclenché.

class ScreenTrackingObserver(
    private val analytics: AnalyticsProvider
) : LifecycleEventObserver {

    override fun onStateChanged(
        source: LifecycleOwner,
        event: Lifecycle.Event
    ) {
        if (event == Lifecycle.Event.ON_RESUME) {
            val route = source.getRouteFromLifecycleOwner()
            analytics.logScreenView(
                screenName = route.screenName,
                screenClass = source.getLocalClassName()
            )
        }
    }
}

// Connexion dans NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

Cette approche garantit que screen_view est envoyé à chaque retour de l'écran au premier plan, y compris le retour depuis l'arrière-plan. Lifecycle.Event.ON_RESUME est le bon moment pour le suivi, pas ON_START ou ON_CREATE.

iOS : suivi automatique dans SwiftUI

Dans SwiftUI, le modificateur onAppear intégré à chaque View est utilisé. Pour l'automatisation, un ViewModifier est créé.

struct ScreenTrackingModifier: ViewModifier {

    let screenName: String

    func body(content: Content) -> some View {
        content.onAppear {
            Analytics.shared().logScreenView(
                name: screenName,
                className: "\(Self.self)"
            )
        }
    }
}

extension View {
    func trackScreen(_ name: String) -> some View {
        modifier(ScreenTrackingModifier(screenName: name))
    }
}

// Utilisation :
ProductDetailView()
    .trackScreen("Product Details")

Le modificateur trackScreen est ajouté à n'importe quelle View en une seule ligne. C'est une solution propre et évolutive pour les projets SwiftUI.

Screen View dans les projets multi-modules

Dans les projets à architecture modulaire, chaque module peut utiliser sa propre nomenclature d'écrans, ce qui entraîne une duplication de screen_name. Une énumération ScreenName centralisée résout le problème — tous les écrans sont nommés selon un standard unique en un seul endroit. L'ajout d'un nouvel écran ne nécessite qu'une nouvelle constante dans l'énumération, sans avoir à chercher dans tout le code.

Utilisez une sealed class pour décrire screen_name avec un regroupement par fonctionnalité : ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Cela simplifie le filtrage dans les rapports d'analyse.

Screen Flow : analyse des transitions entre écrans

Screen Flow (ou analyse de chemin) est une visualisation de la séquence d'écrans parcourue par un utilisateur. C'est l'outil principal pour identifier les goulots d'étranglement dans la navigation.

Construction d'un Screen Flow

Chaque Screen View avec le paramètre previous_screen fournit une arête du graphe : CatalogScreen → ProductDetails → CartScreen. En agrégeant toutes les transitions, une carte des chemins est construite. Un entonnoir en trois étapes basé sur Screen Flow montre où les utilisateurs abandonnent.

• Étape 1 : HomeScreen → CatalogScreen (95 % continuent)
• Étape 2 : CatalogScreen → ProductDetails (65 % continuent — 35 % quittent)
• Étape 3 : ProductDetails → AddToCart (30 % continuent — nous perdons encore 35 %)

Selon Mixpanel (2024), l'analyse Screen Flow révèle jusqu'à 40 % des problèmes d'UX qui ne sont pas visibles lors de l'analyse d'événements individuels. Par exemple, une transition fréquente ProductDetails → HomeScreen sans achat indique un problème avec le prix ou la description du produit.

Analyse d'abandon (Drop-off)

Drop-off est un point où l'utilisateur quitte un scénario. Si 60 % des utilisateurs partent après l'écran de chargement, le problème est dans la vitesse de chargement ou l'animation. Si c'est après un Paywall — dans le coût ou la valeur de l'abonnement.

Screen Flow dans Firebase et BigQuery

Firebase ne fournit pas de rapport Screen Flow prêt à l'emploi, mais les données screen_view sont disponibles dans BigQuery. Créez une requête qui regroupe les transitions par paire (previous_screen, screen_name) et compte la fréquence. Le résultat est une matrice de transitions qui peut être visualisée dans Looker Studio sous forme de diagramme de Sankey.

Complétez le Screen Flow avec une segmentation : séparément pour les nouveaux utilisateurs (7 premiers jours) et les utilisateurs qui reviennent. Les nouveaux utilisateurs restent plus souvent bloqués sur les écrans d'onboarding, tandis que les utilisateurs expérimentés atteignent plus rapidement les actions cibles. La comparaison des deux flux révèle des goulots d'étranglement d'adaptation.

Outils d'analyse Screen View

Le choix de l'outil pour l'analyse Screen View dépend du budget, de la pile technologique et du niveau de détail requis. Examinons trois solutions populaires.

Firebase Analytics (gratuit)

Firebase suit automatiquement les écrans via le paramètre screen_view dans chaque événement. Aucun code supplémentaire n'est requis après l'intégration du SDK. Limitation : screen_name est généré à partir de l'Activity/ViewController, ce qui ne produit pas toujours des noms lisibles.

Amplitude (professionnel)

Amplitude propose un Pathfinder intégré — un constructeur visuel de Screen Flow. Prend en charge les propriétés utilisateur et la segmentation par cohortes. Permet de renommer les écrans côté serveur sans modifier le code de l'application.

Mixpanel (moyen segment)

Mixpanel fournit un rapport Flows en temps réel. Il peut montrer non seulement les transitions linéaires, mais aussi les branches — quels écrans sont visités après un écran spécifique. S'intègre avec les SDK iOS, Android, Flutter et React Native.

Impact de Screen View sur les performances

Chaque événement screen_view est un envoi de données réseau. Si une application envoie screen_view à chaque changement d'onglet (20+ par minute), cela crée une charge inutile. Optimisation : mettez en mémoire tampon les screen_view et envoyez-les par lots toutes les 5 secondes. Firebase agrège automatiquement les événements, mais les SDK personnalisés peuvent envoyer chaque appel immédiatement.

Mesurez la surcharge du suivi : ajoutez un horodatage à chaque screen_view et calculez le délai entre onResume et l'envoi. Si le délai dépasse 100 ms, le suivi affecte l'UX. Utilisez un thread d'arrière-plan pour l'envoi afin de ne pas bloquer le thread de l'interface. Sur les appareils d'entrée de gamme, la différence est notable.