Screen View i mobilanalys — vad är det, vilka mätvärden och hur man spårar

Vad är Screen View?

Screen View — en analyshändelse som skickas när en skärm i en mobilapp öppnas. Händelsen innehåller skärmnamnet (screen_name), klassen (screen_class) och en tidsstämpel. Till skillnad från webbanalys, där page_view är kopplat till en URL, identifieras skärmar i mobilappar via namnet på Activity, Fragment, ViewController eller Custom View.

Struktur för Screen View-händelsen

Parametern previous_screen är särskilt viktig: den gör det möjligt att rekonstruera sekvensen av övergångar och bygga Screen Flow — en karta över användarvägar i appen.

Screen View vs Page View: viktiga skillnader

Screen View och Page View löser samma uppgift — att registrera en visning — men i olika miljöer. På webben identifierar en URL unikt en sida och Page View är kopplat till att ett dokument laddas. I mobilappar är en skärm ett UI-tillstånd som inte nödvändigtvis motsvarar en separat adress.

• Page View är kopplat till en HTTP-förfrågan och URL — Screen View är kopplat till en livscykelhändelse för Activity/ViewController
• Page View dupliceras inte vid återgång (använder cache) — Screen View skickas igen vid varje skärmöppning
• Page View är i genomsnitt kortare — användaren bläddrar igenom en webbsida snabbare än en mobil skärm med interaktiva element

En annan skillnad är kontextdjupet. Screen View i en mobilapp innehåller tillståndsparametrar: om användaren är inloggad, vilka data som har laddats, om skärmen är öppen i redigeringsläge. Page View på webben har sällan sådan kontext — det registrerar bara det faktum att en URL har laddats. Detta gör Screen View mer informativt för produktanalys, eftersom varje händelse kan segmenteras efter tillstånd.

Typiska misstag vid arbete med Screen View

Första misstaget — att skicka screen_view vid varje tillståndsändring inom en skärm (växla flikar, öppna popup). Screen View bör endast registrera en fullständig övergång till en ny skärm, inte mikrointeraktioner.

Andra misstaget — att använda det tekniska klassnamnet istället för ett läsbart namn. "ProductDetailActivityKt" är oanvändbart för en analytiker — använd "Product Details" i screen_name.

Tredje misstaget — att skicka screen_view utan motsvarande fält. Ett tomt screen_name skapar en uppsättning skräpposter som inte kan grupperas. Skicka alltid minst screen_name och screen_class, även på testskärmar.

Hur spårar man Screen View?

Implementering av Screen View-spårning beror på navigationsarkitekturen. Låt oss titta på automatiska och manuella tillvägagångssätt med exemplet Jetpack Compose och SwiftUI.

Android: automatisk spårning i Jetpack Compose

Använd LifecycleEventObserver på NavigationComponent-nivå. Varje gång en användare navigerar till en ny rutt utlöses screen_view-händelsen.

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

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

Tillvägagångssättet garanterar att screen_view skickas vid varje återkomst av skärmen till förgrunden, inklusive återkomst från bakgrunden. Lifecycle.Event.ON_RESUME är rätt tidpunkt för spårning, inte ON_START eller ON_CREATE.

iOS: automatisk spårning i SwiftUI

I SwiftUI används modifieraren onAppear som är inbyggd i varje View. För automatisering skapas en ViewModifier.

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

// Användning:
ProductDetailView()
    .trackScreen("Product Details")

Modifieraren trackScreen läggs till på valfri View med en rad. Detta är en ren och skalbar lösning för SwiftUI-projekt.

Screen View i multimodulära projekt

I projekt med modulär arkitektur kan varje modul använda sin egen skärmnamngivning, vilket leder till dubbelarbete av screen_name. En centraliserad enum ScreenName löser problemet — alla skärmar namnges enligt en enhetlig standard på ett ställe. Att lägga till en ny skärm kräver bara en ny konstant i enum, inte att söka igenom hela koden.

Använd sealed class för att beskriva screen_name med gruppering efter funktion: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Detta förenklar filtrering i analysrapporter.

Screen Flow: analys av övergångar mellan skärmar

Screen Flow (eller Path Analysis) — visualisering av sekvensen av skärmar som en användare går igenom. Det är det främsta verktyget för att identifiera flaskhalsar i navigeringen.

Bygga Screen Flow

Varje Screen View med parametern previous_screen skapar en grafkant: CatalogScreen → ProductDetails → CartScreen. Genom att aggregera alla övergångar byggs en vägkarta. Tre-stegs-tratten baserad på Screen Flow visar var användare hoppar av.

• Steg 1: HomeScreen → CatalogScreen (95 % passerar)
• Steg 2: CatalogScreen → ProductDetails (65 % passerar — 35 % lämnar)
• Steg 3: ProductDetails → AddToCart (30 % passerar — förlorar ytterligare 35 %)

Enligt data från Mixpanel (2024) avslöjar Screen Flow-analys upp till 40 % av UX-problem som inte är synliga vid analys av enskilda händelser. Till exempel indikerar en frekvent övergång ProductDetails → HomeScreen utan köp ett problem med priset eller produktbeskrivningen.

Drop-off-analys

Drop-off — den punkt där användaren lämnar scenariot. Om 60 % av användarna lämnar efter laddningsskärmen ligger problemet i laddningshastigheten eller animationen. Om efter Paywall — i priset eller värdet på prenumerationen.

Screen Flow i Firebase och BigQuery

Firebase tillhandahåller ingen färdig Screen Flow-rapport, men screen_view-data är tillgängliga i BigQuery. Skapa en fråga som grupperar övergångar efter par (previous_screen, screen_name) och beräknar frekvensen. Resultatet är en övergångsmatris som kan visualiseras i Looker Studio som ett Sankey-diagram.

Komplettera Screen Flow med segmentering: separat för nya användare (första 7 dagarna) och återkommande användare. Nya användare fastnar oftare på introduktionsskärmar, erfarna användare når målgärder snabbare. Jämförelse av två flöden avslöjar anpassningsflaskhalsar.

Verktyg för Screen View-analys

Val av verktyg för Screen View beror på budget, teknologisk stack och önskad detaljnivå. Låt oss titta på tre populära lösningar.

Firebase Analytics (gratis)

Firebase spårar automatiskt skärmar via parametern screen_view i varje händelse. Kräver ingen extra kod efter SDK-integration. Begränsning: screen_name genereras från Activity/ViewController, vilket inte alltid ger läsbara namn.

Amplitude (professionell)

Amplitude erbjuder en inbyggd Pathfinder — en visuell Screen Flow-byggare. Stöder user property och segmentering efter kohorter. Tillåter namnbyte av skärmar på serversidan utan ändringar i appkoden.

Mixpanel (mellansegment)

Mixpanel tillhandahåller en Flows-rapport i realtid. Kan visa inte bara linjära övergångar utan även förgreningar — vilka skärmar som besöks efter en specifik skärm. Integreras med iOS, Android, Flutter och React Native SDK.

Screen Views påverkan på prestanda

Varje screen_view-händelse är en nätverksöverföring av data. Om en app skickar screen_view vid varje flikbyte (20+ per minut) skapar det extra belastning. Optimering: buffra screen_view och skicka batchvis var 5:e sekund. Firebase aggregerar automatiskt händelser, men anpassade SDK:er kan skicka varje anrop omedelbart.

Mät överhead för spårning: lägg till en tidsstämpel i varje screen_view och beräkna fördröjningen från onResume till sändning. Om fördröjningen överstiger 100 ms påverkar spårningen UX. Använd en bakgrundstråd för sändning för att inte blockera UI-tråden. På lågprisenheter är skillnaden märkbar.