Screen View nell'analisi mobile — cos'è, metriche chiave e come tracciarlo

Cos'è Screen View?

Screen View è un evento di analisi che viene inviato quando viene aperto uno schermo di un'applicazione mobile. L'evento contiene il nome dello schermo (screen_name), la classe (screen_class) e un timestamp. A differenza dell'analisi web, dove page_view è legato a un URL, nelle applicazioni mobili gli schermi sono identificati dal nome di Activity, Fragment, ViewController o Custom View.

Struttura dell'evento Screen View

Il parametro previous_screen è particolarmente importante: permette di ripristinare la sequenza delle transizioni e costruire un Screen Flow — una mappa dei percorsi degli utenti attraverso l'applicazione.

Screen View vs Page View: differenze chiave

Screen View e Page View risolvono lo stesso compito — registrare una visualizzazione — ma in ambienti diversi. Sul web, un URL identifica in modo univoco una pagina e Page View è legato al caricamento del documento. Nelle applicazioni mobili, uno schermo è uno stato dell'interfaccia che non corrisponde necessariamente a un indirizzo separato.

• Page View è legato a una richiesta HTTP e a un URL — Screen View è legato a un evento del ciclo di vita di Activity/ViewController
• Page View non viene duplicato quando si torna indietro (viene usata la cache) — Screen View viene inviato di nuovo ogni volta che lo schermo viene aperto
• Page View è generalmente più breve — gli utenti visualizzano una pagina web più velocemente di uno schermo mobile con elementi interattivi

Un'altra differenza è la profondità del contesto. Screen View in un'applicazione mobile include parametri di stato: se l'utente è autenticato, quali dati sono caricati, se lo schermo è aperto in modalità di modifica. Page View sul web raramente porta questo contesto — registra solo il fatto del caricamento dell'URL. Questo rende Screen View più informativo per l'analisi di prodotto, poiché ogni evento può essere segmentato per stato.

Errori tipici nel lavorare con Screen View

Il primo errore è inviare screen_view a ogni cambiamento di stato all'interno di uno schermo (cambio di scheda, apertura di un popup). Screen View dovrebbe registrare solo una transizione completa verso un nuovo schermo, non micro-interazioni.

Il secondo errore è usare il nome tecnico della classe invece di un nome leggibile. “ProductDetailActivityKt” è inutile per un analista — usa “Product Details” in screen_name.

Il terzo errore è inviare screen_view senza i campi corrispondenti. Un screen_name vuoto crea un insieme di record spazzatura che non possono essere raggruppati. Passa sempre almeno screen_name e screen_class, anche sugli schermi di test.

Come tracciare Screen View?

L'implementazione del tracciamento di Screen View dipende dall'architettura di navigazione. Esaminiamo gli approcci automatico e manuale usando Jetpack Compose e SwiftUI come esempio.

Android: tracciamento automatico in Jetpack Compose

Usa LifecycleEventObserver a livello di NavigationComponent. Ogni volta che un utente naviga verso una nuova route, l'evento screen_view viene attivato.

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

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

Questo approccio garantisce che screen_view venga inviato ogni volta che lo schermo torna in primo piano, incluso il ritorno dallo sfondo. Lifecycle.Event.ON_RESUME è il momento giusto per il tracciamento, non ON_START o ON_CREATE.

iOS: tracciamento automatico in SwiftUI

In SwiftUI si usa il modificatore onAppear, integrato in ogni View. Per l'automazione, viene creato 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))
    }
}

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

Il modificatore trackScreen viene aggiunto a qualsiasi View con una singola riga. È una soluzione pulita e scalabile per progetti SwiftUI.

Screen View in progetti multimodulo

Nei progetti con architettura modulare, ogni modulo può usare una propria nomenclatura degli schermi, portando a duplicazioni di screen_name. Un enum ScreenName centralizzato risolve il problema — tutti gli schermi vengono nominati secondo uno standard unico in un unico posto. Aggiungere un nuovo schermo richiede solo una nuova costante nell'enum, senza dover cercare in tutto il codice.

Usa una sealed class per descrivere screen_name con raggruppamento per funzionalità: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Questo semplifica il filtraggio nei report di analisi.

Screen Flow: analisi delle transizioni tra schermi

Screen Flow (o Path Analysis) è una visualizzazione della sequenza di schermi che un utente attraversa. È lo strumento principale per identificare i colli di bottiglia nella navigazione.

Costruzione di un Screen Flow

Ogni Screen View con il parametro previous_screen fornisce un bordo del grafo: CatalogScreen → ProductDetails → CartScreen. Aggregando tutte le transizioni, viene costruita una mappa dei percorsi. Un funnel a tre passaggi basato su Screen Flow mostra dove gli utenti abbandonano.

• Passaggio 1: HomeScreen → CatalogScreen (95% procede)
• Passaggio 2: CatalogScreen → ProductDetails (65% procede — 35% abbandona)
• Passaggio 3: ProductDetails → AddToCart (30% procede — perdiamo un altro 35%)

Secondo Mixpanel (2024), l'analisi di Screen Flow rivela fino al 40% dei problemi di UX che non sono visibili analizzando singoli eventi. Ad esempio, una transizione frequente ProductDetails → HomeScreen senza acquisto indica un problema con il prezzo o la descrizione del prodotto.

Analisi dell'abbandono (Drop-off)

Drop-off è un punto in cui l'utente abbandona uno scenario. Se il 60% degli utenti abbandona dopo la schermata di caricamento, il problema è nella velocità di caricamento o nell'animazione. Se dopo un Paywall — nel costo o nel valore dell'abbonamento.

Screen Flow in Firebase e BigQuery

Firebase non fornisce un report Screen Flow pronto, ma i dati screen_view sono disponibili in BigQuery. Crea una query che raggruppi le transizioni per coppia (previous_screen, screen_name) e conti la frequenza. Il risultato è una matrice di transizioni che può essere visualizzata in Looker Studio come diagramma di Sankey.

Completa il Screen Flow con segmentazione: separatamente per nuovi utenti (primi 7 giorni) e utenti di ritorno. I nuovi utenti rimangono più spesso bloccati sugli schermi di onboarding, mentre gli utenti esperti raggiungono più velocemente le azioni target. Il confronto dei due flussi rivela colli di bottiglia nell'adattamento.

Strumenti per l'analisi di Screen View

La scelta dello strumento per l'analisi di Screen View dipende dal budget, dallo stack e dal livello di dettaglio richiesto. Esaminiamo tre soluzioni popolari.

Firebase Analytics (gratuito)

Firebase traccia automaticamente gli schermi tramite il parametro screen_view in ogni evento. Non richiede codice aggiuntivo dopo l'integrazione dell'SDK. Limitazione: screen_name viene generato da Activity/ViewController, che non sempre produce nomi leggibili.

Amplitude (professionale)

Amplitude offre un Pathfinder integrato — un costruttore visivo di Screen Flow. Supporta proprietà utente e segmentazione per coorti. Permette di rinominare gli schermi lato server senza modifiche al codice dell'applicazione.

Mixpanel (segmento medio)

Mixpanel fornisce un report Flows in tempo reale. Può mostrare non solo transizioni lineari, ma anche ramificazioni — quali schermi vengono visitati dopo uno specifico. Si integra con gli SDK iOS, Android, Flutter e React Native.

Impatto di Screen View sulle prestazioni

Ogni evento screen_view è un invio di dati in rete. Se un'app invia screen_view a ogni cambio di scheda (20+ al minuto), crea un carico inutile. Ottimizzazione: bufferizza gli screen_view e inviali in batch ogni 5 secondi. Firebase aggrega automaticamente gli eventi, ma gli SDK personalizzati possono inviare ogni chiamata immediatamente.

Misura l'overhead del tracciamento: aggiungi un timestamp a ogni screen_view e calcola il ritardo da onResume all'invio. Se il ritardo supera i 100 ms, il tracciamento influisce sull'UX. Usa un thread in background per l'invio per non bloccare il thread dell'interfaccia. Sui dispositivi di fascia bassa, la differenza è notevole.