Screen View în analitica mobilă — ce este, ce metrici și cum să urmărești

Ce este Screen View?

Screen View — eveniment de analitică care este trimis la deschiderea ecranului unei aplicații mobile. Evenimentul conține numele ecranului (screen_name), clasa (screen_class) și marca temporală. Spre deosebire de analitica web, unde page_view este legat de URL, în aplicațiile mobile ecranele sunt identificate după numele Activity, Fragment, ViewController sau Custom View.

Structura evenimentului Screen View

Parametrul previous_screen este deosebit de important: permite reconstituirea secvenței de tranziții și construirea Screen Flow — harta căilor utilizatorului în aplicație.

Screen View vs Page View: diferențe cheie

Screen View și Page View rezolvă aceeași sarcină — înregistrarea vizualizării — dar în medii diferite. În web, URL identifică unic pagina, iar Page View este legat de încărcarea documentului. În aplicațiile mobile, ecranul este o stare a UI, care nu corespunde neapărat unei adrese separate.

• Page View este legat de cererea HTTP și URL — Screen View este legat de evenimentul ciclului de viață Activity/ViewController
• Page View nu se dublează la întoarcerea înapoi (folosește cache) — Screen View este retrimis la fiecare deschidere a ecranului
• Page View este în medie mai scurt — utilizatorul navighează o pagină web mai repede decât un ecran mobil cu elemente interactive

O altă diferență — adâncimea contextului. Screen View în aplicația mobilă include parametri de stare: dacă utilizatorul este autentificat, ce date sunt încărcate, dacă ecranul este deschis în modul de editare. Page View în web rareori poartă un astfel de context — înregistrează doar faptul încărcării URL. Acest lucru face Screen View mai informativ pentru analitica de produs, deoarece fiecare eveniment poate fi segmentat după stare.

Greșeli tipice la lucrul cu Screen View

Prima greșeală — trimiterea screen_view la fiecare schimbare de stare în cadrul ecranului (schimbarea filelor, deschiderea unui pop-up). Screen View trebuie să înregistreze doar tranziția completă către un ecran nou, nu micro-interacțiunile.

A doua greșeală — folosirea numelui tehnic al clasei în locul unui nume lizibil. „ProductDetailActivityKt” este inutil pentru analist — folosește „Product Details” în screen_name.

A treia greșeală — trimiterea screen_view fără câmpurile corespunzătoare. Un screen_name gol creează un set de înregistrări nedorite care nu pot fi grupate. Trimite întotdeauna cel puțin screen_name și screen_class, chiar și pe ecranele de test.

Cum să urmărești Screen View?

Implementarea urmăririi Screen View depinde de arhitectura navigației. Să analizăm abordările automată și manuală pe exemplul Jetpack Compose și SwiftUI.

Android: urmărirea automată în Jetpack Compose

Folosește LifecycleEventObserver la nivelul NavigationComponent. De fiecare dată când utilizatorul trece la un nou rute, se declanșează evenimentul screen_view.

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

// Conectarea în NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

Abordarea garantează că screen_view este trimis la fiecare revenire a ecranului în prim-plan, inclusiv la revenirea din fundal. Lifecycle.Event.ON_RESUME este momentul corect pentru urmărire, nu ON_START și nu ON_CREATE.

iOS: urmărirea automată în SwiftUI

În SwiftUI se folosește modificatorul onAppear încorporat în fiecare View. Pentru automatizare se creează un 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))
    }
}

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

Modificatorul trackScreen se adaugă la orice View cu o singură linie. Este o soluție curată și scalabilă pentru proiectele SwiftUI.

Screen View în proiecte multi-modul

În proiectele cu arhitectură modulară, fiecare modul poate folosi propria denumire a ecranelor, ceea ce duce la duplicarea screen_name. Enum-ul centralizat ScreenName rezolvă problema — toate ecranele sunt denumite după un standard unic într-un singur loc. Adăugarea unui ecran nou necesită doar o nouă constantă în enum, nu căutarea în tot codul.

Folosește sealed class pentru descrierea screen_name cu grupare pe funcționalități: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Acest lucru simplifică filtrarea în rapoartele de analitică.

Screen Flow: analiza tranzițiilor între ecrane

Screen Flow (sau Path Analysis) — vizualizarea secvenței de ecrane prin care trece utilizatorul. Este instrumentul principal pentru identificarea blocajelor în navigare.

Construirea Screen Flow

Fiecare Screen View cu parametrul previous_screen creează o muchie a grafului: CatalogScreen → ProductDetails → CartScreen. Agregând toate tranzițiile, se construiește harta căilor. Pâlnia în trei pași bazată pe Screen Flow arată unde pierd utilizatorii.

• Pasul 1: HomeScreen → CatalogScreen (95% trec)
• Pasul 2: CatalogScreen → ProductDetails (65% trec — 35% pleacă)
• Pasul 3: ProductDetails → AddToCart (30% trec — pierdem încă 35%)

Conform datelor Mixpanel (2024), analiza Screen Flow dezvăluie până la 40% din problemele de UX care nu sunt vizibile la analiza evenimentelor individuale. De exemplu, tranziția frecventă ProductDetails → HomeScreen fără cumpărare indică o problemă cu prețul sau descrierea produsului.

Analiza Drop-off

Drop-off — punctul în care utilizatorul părăsește scenariul. Dacă după ecranul de încărcare 60% din utilizatori pleacă, problema este în viteza de încărcare sau animație. Dacă după Paywall — în prețul sau valoarea abonamentului.

Screen Flow în Firebase și BigQuery

Firebase nu oferă un raport Screen Flow gata făcut, dar datele screen_view sunt disponibile în BigQuery. Construiește o interogare care grupează tranzițiile după perechea (previous_screen, screen_name) și calculează frecvența. Rezultatul — o matrice de tranziții care poate fi vizualizată în Looker Studio ca diagramă Sankey.

Completează Screen Flow cu segmentare: separat pentru utilizatorii noi (primele 7 zile) și pentru cei reveniți. Utilizatorii noi se blochează mai des pe ecranele de onboarding, cei experimentați ajung mai repede la acțiunile țintă. Compararea celor două fluxuri dezvăluie blocajele de adaptare.

Instrumente pentru analiza Screen View

Alegerea instrumentului pentru Screen View depinde de buget, stiva tehnologică și detalierea necesară. Să analizăm trei soluții populare.

Firebase Analytics (gratuit)

Firebase urmărește automat ecranele prin parametrul screen_view în fiecare eveniment. Nu necesită cod suplimentar după integrarea SDK. Limitare: screen_name este generat din Activity/ViewController, ceea ce nu oferă întotdeauna nume lizibile.

Amplitude (profesional)

Amplitude oferă Pathfinder încorporat — constructor vizual de Screen Flow. Suportă user property și segmentarea pe cohorte. Permite redenumirea ecranelor pe partea de server fără modificări în codul aplicației.

Mixpanel (segment mediu)

Mixpanel oferă raportul Flows în timp real. Poate arăta nu doar tranziții liniare, ci și ramificații — ce ecrane sunt vizitate după unul specific. Se integrează cu SDK-urile iOS, Android, Flutter și React Native.

Impactul Screen View asupra performanței

Fiecare eveniment screen_view este o trimitere de date în rețea. Dacă aplicația trimite screen_view la fiecare schimbare de filă (20+ pe minut), creează o încărcare suplimentară. Optimizare: bufferizează screen_view și trimite în batch la fiecare 5 secunde. Firebase agregă automat evenimentele, dar SDK-urile personalizate pot trimite fiecare apel imediat.

Măsoară overhead-ul urmăririi: adaugă o marcă temporală în fiecare screen_view și calculează întârzierea de la onResume până la trimitere. Dacă întârzierea depășește 100 ms, urmărirea afectează UX. Folosește un fir de execuție în fundal pentru trimitere, pentru a nu bloca firul UI. Pe dispozitivele low-end, diferența este vizibilă.