Screen View in mobiele analytics — wat is het, welke metrics en hoe te volgen

Wat is Screen View?

Screen View — een analytics-gebeurtenis die wordt verzonden bij het openen van een scherm van een mobiele app. De gebeurtenis bevat de schermnaam (screen_name), klasse (screen_class) en een tijdstempel. In tegenstelling tot webanalytics, waar page_view aan een URL is gekoppeld, worden schermen in mobiele apps geïdentificeerd aan de hand van de naam van Activity, Fragment, ViewController of Custom View.

Structuur van de Screen View-gebeurtenis

De parameter previous_screen is bijzonder belangrijk: hiermee kan de volgorde van overgangen worden gereconstrueerd en kan Screen Flow worden gebouwd — een kaart van gebruikerspaden in de app.

Screen View vs Page View: belangrijkste verschillen

Screen View en Page View lossen dezelfde taak op — het registreren van een weergave — maar in verschillende omgevingen. Op het web identificeert een URL een pagina uniek en is Page View gekoppeld aan het laden van een document. In mobiele apps is een scherm een UI-status, die niet noodzakelijk overeenkomt met een afzonderlijk adres.

• Page View is gekoppeld aan een HTTP-verzoek en URL — Screen View is gekoppeld aan een levenscyclusgebeurtenis van Activity/ViewController
• Page View wordt niet gedupliceerd bij terugkeren (gebruikt cache) — Screen View wordt opnieuw verzonden bij elke opening van een scherm
• Page View is gemiddeld korter — een gebruiker bekijkt een webpagina sneller dan een mobiel scherm met interactieve elementen

Een ander verschil is de contextdiepte. Screen View in een mobiele app bevat statusparameters: of de gebruiker is ingelogd, welke gegevens zijn geladen, of het scherm in bewerkingsmodus is geopend. Page View op het web heeft zelden dergelijke context — het registreert alleen het feit dat een URL is geladen. Dit maakt Screen View informatiever voor productanalytics, omdat elke gebeurtenis per status kan worden gesegmenteerd.

Typische fouten bij het werken met Screen View

Eerste fout — het verzenden van screen_view bij elke statuswijziging binnen een scherm (tabbladen wisselen, pop-up openen). Screen View mag alleen een volledige overgang naar een nieuw scherm registreren, geen micro-interacties.

Tweede fout — het gebruik van de technische klassenaam in plaats van een leesbare naam. „ProductDetailActivityKt” is nutteloos voor een analist — gebruik „Product Details” in screen_name.

Derde fout — het verzenden van screen_view zonder de bijbehorende velden. Een lege screen_name creëert een reeks waardeloze records die niet kunnen worden gegroepeerd. Stuur altijd ten minste screen_name en screen_class, zelfs op testschermen.

Hoe Screen View volgen?

Implementatie van Screen View tracking hangt af van de navigatiearchitectuur. Laten we de automatische en handmatige benaderingen bekijken aan de hand van Jetpack Compose en SwiftUI.

Android: automatische tracking in Jetpack Compose

Gebruik LifecycleEventObserver op het niveau van NavigationComponent. Telkens wanneer een gebruiker naar een nieuwe route gaat, wordt de screen_view-gebeurtenis geactiveerd.

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

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

Deze benadering garandeert dat screen_view wordt verzonden bij elke terugkeer van het scherm naar de voorgrond, inclusief terugkeer uit de achtergrond. Lifecycle.Event.ON_RESUME is het juiste moment voor tracking, niet ON_START en niet ON_CREATE.

iOS: automatische tracking in SwiftUI

In SwiftUI wordt de modifier onAppear gebruikt, die in elke View is ingebouwd. Voor automatisering wordt een ViewModifier gemaakt.

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

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

De modifier trackScreen wordt met één regel aan elke View toegevoegd. Dit is een schone en schaalbare oplossing voor SwiftUI-projecten.

Screen View in multimodulaire projecten

In projecten met een modulaire architectuur kan elke module zijn eigen schermnaamgeving gebruiken, wat leidt tot duplicatie van screen_name. Een gecentraliseerde enum ScreenName lost het probleem op — alle schermen worden op één locatie volgens één standaard benoemd. Het toevoegen van een nieuw scherm vereist alleen een nieuwe constante in de enum, niet het doorzoeken van de hele code.

Gebruik een sealed class voor het beschrijven van screen_name met groepering per functie: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Dit vereenvoudigt het filteren in analytics-rapporten.

Screen Flow: analyse van overgangen tussen schermen

Screen Flow (of Path Analysis) — visualisatie van de reeks schermen die een gebruiker doorloopt. Het is het belangrijkste hulpmiddel voor het identificeren van knelpunten in de navigatie.

Screen Flow bouwen

Elke Screen View met de parameter previous_screen creëert een rand van de graaf: CatalogScreen → ProductDetails → CartScreen. Door alle overgangen te aggregeren, wordt een padkaart gebouwd. Een driestaps-trechter op basis van Screen Flow laat zien waar gebruikers afhaken.

• Stap 1: HomeScreen → CatalogScreen (95% gaat door)
• Stap 2: CatalogScreen → ProductDetails (65% gaat door — 35% valt uit)
• Stap 3: ProductDetails → AddToCart (30% gaat door — verliezen nog eens 35%)

Volgens gegevens van Mixpanel (2024) onthult Screen Flow-analyse tot 40% van UX-problemen die niet zichtbaar zijn bij analyse van afzonderlijke gebeurtenissen. Bijvoorbeeld een frequente overgang ProductDetails → HomeScreen zonder aankoop wijst op een probleem met de prijs of beschrijving van het product.

Drop-off-analyse

Drop-off — het punt waarop een gebruiker het scenario verlaat. Als na het laadscherm 60% van de gebruikers weggaat, ligt het probleem bij de laadsnelheid of animatie. Als na Paywall — bij de prijs of waarde van het abonnement.

Screen Flow in Firebase en BigQuery

Firebase biedt geen kant-en-klaar Screen Flow-rapport, maar screen_view-gegevens zijn beschikbaar in BigQuery. Maak een query die overgangen groepeert per paar (previous_screen, screen_name) en de frequentie berekent. Het resultaat is een overgangsmatrix die in Looker Studio kan worden gevisualiseerd als een Sankey-diagram.

Vul Screen Flow aan met segmentatie: apart voor nieuwe gebruikers (eerste 7 dagen) en terugkerende gebruikers. Nieuwe gebruikers blijven vaker hangen op onboarding-schermen, ervaren gebruikers bereiken sneller doelacties. Vergelijking van twee stromen onthult aanpassingsknelpunten.

Tools voor Screen View analytics

De keuze van een tool voor Screen View hangt af van budget, technologiestack en vereiste detailering. Laten we drie populaire oplossingen bekijken.

Firebase Analytics (gratis)

Firebase volgt automatisch schermen via de parameter screen_view in elke gebeurtenis. Vereist geen extra code na integratie van de SDK. Beperking: screen_name wordt gegenereerd uit Activity/ViewController, wat niet altijd leesbare namen oplevert.

Amplitude (professioneel)

Amplitude biedt een ingebouwde Pathfinder — een visuele Screen Flow-bouwer. Ondersteunt user property en segmentatie op cohorten. Maakt het mogelijk om schermnamen aan de serverzijde te wijzigen zonder aanpassingen in de app-code.

Mixpanel (middensegment)

Mixpanel biedt een realtime Flows-rapport. Kan niet alleen lineaire overgangen tonen, maar ook vertakkingen — welke schermen worden bezocht na een specifiek scherm. Integreert met iOS, Android, Flutter en React Native SDK.

Impact van Screen View op prestaties

Elke screen_view-gebeurtenis is een netwerkverzending van gegevens. Als een app screen_view verzendt bij elke tabwisseling (20+ per minuut), creëert dit extra belasting. Optimalisatie: buffer screen_view en verzend batchgewijs elke 5 seconden. Firebase aggregeert gebeurtenissen automatisch, maar aangepaste SDK's kunnen elke aanroep onmiddellijk verzenden.

Meet de overhead van tracking: voeg een tijdstempel toe aan elke screen_view en bereken de vertraging van onResume tot verzending. Als de vertraging 100 ms overschrijdt, beïnvloedt tracking de UX. Gebruik een achtergrondthread voor verzending om de UI-thread niet te blokkeren. Op low-end apparaten is het verschil merkbaar.