Screen View in der mobilen Analyse — was es ist, wichtige Metriken und wie man es verfolgt

Was ist Screen View?

Screen View ist ein Analyseereignis, das gesendet wird, wenn ein mobiler Anwendungsbildschirm geöffnet wird. Das Ereignis enthält den Bildschirmnamen (screen_name), die Klasse (screen_class) und einen Zeitstempel. Im Gegensatz zur Webanalyse, wo page_view an eine URL gebunden ist, werden in mobilen Anwendungen Bildschirme durch den Namen der Activity, des Fragments, des ViewControllers oder der Custom View identifiziert.

Struktur des Screen View-Ereignisses

Der Parameter previous_screen ist besonders wichtig: Er ermöglicht die Wiederherstellung der Übergangssequenz und die Erstellung eines Screen Flows — einer Karte der Benutzerpfade durch die Anwendung.

Screen View vs Page View: Hauptunterschiede

Screen View und Page View lösen dieselbe Aufgabe — die Aufzeichnung einer Ansicht — aber in unterschiedlichen Umgebungen. Im Web identifiziert eine URL eine Seite eindeutig, und Page View ist an das Laden des Dokuments gebunden. In mobilen Anwendungen ist ein Bildschirm ein UI-Zustand, der nicht unbedingt einer separaten Adresse entspricht.

• Page View ist an eine HTTP-Anfrage und URL gebunden — Screen View ist an ein Lebenszyklusereignis von Activity/ViewController gebunden
• Page View wird beim Zurückgehen nicht dupliziert (Cache wird verwendet) — Screen View wird bei jedem Öffnen des Bildschirms erneut gesendet
• Page View ist in der Regel kürzer — Benutzer betrachten eine Webseite schneller als einen mobilen Bildschirm mit interaktiven Elementen

Ein weiterer Unterschied ist die Kontexttiefe. Screen View in einer mobilen Anwendung enthält Zustandsparameter: ob der Benutzer authentifiziert ist, welche Daten geladen sind, ob der Bildschirm im Bearbeitungsmodus geöffnet ist. Page View im Web trägt selten einen solchen Kontext — er zeichnet nur die Tatsache des URL-Ladens auf. Dies macht Screen View für die Produktanalyse informativer, da jedes Ereignis nach Zustand segmentiert werden kann.

Typische Fehler bei der Arbeit mit Screen View

Der erste Fehler ist das Senden von screen_view bei jeder Zustandsänderung innerhalb eines Bildschirms (Tab-Wechsel, Öffnen eines Popups). Screen View sollte nur einen vollständigen Übergang zu einem neuen Bildschirm aufzeichnen, nicht Mikrointeraktionen.

Der zweite Fehler ist die Verwendung des technischen Klassennamens anstelle eines lesbaren Namens. „ProductDetailActivityKt“ ist für einen Analysten nutzlos — verwenden Sie „Product Details“ in screen_name.

Der dritte Fehler ist das Senden von screen_view ohne die entsprechenden Felder. Ein leerer screen_name erzeugt eine Reihe von Mülleinträgen, die nicht gruppiert werden können. Übergeben Sie immer mindestens screen_name und screen_class, selbst auf Testbildschirmen.

Wie verfolgt man Screen View?

Die Implementierung der Screen View-Verfolgung hängt von der Navigationsarchitektur ab. Betrachten wir die automatischen und manuellen Ansätze am Beispiel von Jetpack Compose und SwiftUI.

Android: Automatische Verfolgung in Jetpack Compose

Verwenden Sie LifecycleEventObserver auf NavigationComponent-Ebene. Jedes Mal, wenn ein Benutzer zu einer neuen Route navigiert, wird das screen_view-Ereignis ausgelöst.

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

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

Dieser Ansatz stellt sicher, dass screen_view jedes Mal gesendet wird, wenn der Bildschirm in den Vordergrund zurückkehrt, einschließlich der Rückkehr aus dem Hintergrund. Lifecycle.Event.ON_RESUME ist der richtige Zeitpunkt für die Verfolgung, nicht ON_START oder ON_CREATE.

iOS: Automatische Verfolgung in SwiftUI

In SwiftUI wird der in jede View eingebaute Modifikator onAppear verwendet. Für die Automatisierung wird ein ViewModifier erstellt.

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

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

Der Modifikator trackScreen wird mit einer einzigen Zeile zu jeder View hinzugefügt. Dies ist eine saubere und skalierbare Lösung für SwiftUI-Projekte.

Screen View in Multimodul-Projekten

In Projekten mit modularer Architektur kann jedes Modul seine eigene Bildschirmbenennung verwenden, was zu Duplikaten von screen_name führt. Ein zentralisierter ScreenName-Enum löst das Problem — alle Bildschirme werden an einem Ort nach einem einheitlichen Standard benannt. Das Hinzufügen eines neuen Bildschirms erfordert nur eine neue Konstante im Enum, anstatt im gesamten Code zu suchen.

Verwenden Sie eine sealed class zur Beschreibung von screen_name mit Gruppierung nach Funktion: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Dies vereinfacht die Filterung in Analyseberichten.

Screen Flow: Analyse von Bildschirmübergängen

Screen Flow (oder Pfadanalyse) ist eine Visualisierung der Abfolge von Bildschirmen, die ein Benutzer durchläuft. Es ist das wichtigste Werkzeug zur Identifizierung von Engpässen in der Navigation.

Erstellung eines Screen Flows

Jeder Screen View mit dem Parameter previous_screen liefert eine Graphkante: CatalogScreen → ProductDetails → CartScreen. Durch die Aggregation aller Übergänge wird eine Pfadkarte erstellt. Ein Drei-Schritte-Trichter basierend auf Screen Flow zeigt, wo Benutzer abspringen.

• Schritt 1: HomeScreen → CatalogScreen (95% setzen fort)
• Schritt 2: CatalogScreen → ProductDetails (65% setzen fort — 35% verlassen)
• Schritt 3: ProductDetails → AddToCart (30% setzen fort — wir verlieren weitere 35%)

Laut Mixpanel (2024) deckt die Screen Flow-Analyse bis zu 40 % der UX-Probleme auf, die bei der Analyse einzelner Ereignisse nicht sichtbar sind. Beispielsweise weist ein häufiger Übergang ProductDetails → HomeScreen ohne Kauf auf ein Problem mit dem Preis oder der Produktbeschreibung hin.

Abbruchanalyse (Drop-off)

Drop-off ist ein Punkt, an dem ein Benutzer ein Szenario verlässt. Wenn 60 % der Benutzer nach dem Ladebildschirm gehen, liegt das Problem in der Ladegeschwindigkeit oder Animation. Wenn nach einer Paywall — in den Kosten oder dem Wert des Abonnements.

Screen Flow in Firebase und BigQuery

Firebase bietet keinen vorgefertigten Screen Flow-Bericht, aber screen_view-Daten sind in BigQuery verfügbar. Erstellen Sie eine Abfrage, die Übergänge nach Paaren (previous_screen, screen_name) gruppiert und die Häufigkeit zählt. Das Ergebnis ist eine Übergangsmatrix, die in Looker Studio als Sankey-Diagramm visualisiert werden kann.

Ergänzen Sie den Screen Flow mit Segmentierung: getrennt für neue Benutzer (erste 7 Tage) und wiederkehrende Benutzer. Neue Benutzer bleiben häufiger auf Onboarding-Bildschirmen hängen, während erfahrene Benutzer schneller zu Zielaktionen gelangen. Der Vergleich der beiden Flüsse zeigt Anpassungsengpässe auf.

Werkzeuge für Screen View-Analyse

Die Wahl des Werkzeugs für die Screen View-Analyse hängt vom Budget, dem Stack und dem erforderlichen Detailgrad ab. Betrachten wir drei beliebte Lösungen.

Firebase Analytics (kostenlos)

Firebase verfolgt Bildschirme automatisch über den Parameter screen_view in jedem Ereignis. Nach der SDK-Integration ist kein zusätzlicher Code erforderlich. Einschränkung: screen_name wird aus Activity/ViewController generiert, was nicht immer lesbare Namen ergibt.

Amplitude (professionell)

Amplitude bietet einen integrierten Pathfinder — einen visuellen Screen Flow-Builder. Unterstützt Benutzereigenschaften und Kohortensegmentierung. Ermöglicht das Umbenennen von Bildschirmen auf der Serverseite ohne Änderungen am Anwendungscode.

Mixpanel (mittleres Segment)

Mixpanel bietet einen Echtzeit-Flows-Bericht. Es kann nicht nur lineare Übergänge, sondern auch Verzweigungen anzeigen — welche Bildschirme nach einem bestimmten besucht werden. Integriert sich mit iOS-, Android-, Flutter- und React Native-SDKs.

Auswirkung von Screen View auf die Leistung

Jedes screen_view-Ereignis ist ein Netzwerk-Datensendevorgang. Wenn eine App bei jedem Tab-Wechsel (20+ pro Minute) screen_view sendet, erzeugt dies unnötige Last. Optimierung: Puffern Sie screen_view und senden Sie es alle 5 Sekunden als Batch. Firebase aggregiert Ereignisse automatisch, aber benutzerdefinierte SDKs können jeden Aufruf sofort senden.

Messen Sie den Overhead der Verfolgung: Fügen Sie jedem screen_view einen Zeitstempel hinzu und berechnen Sie die Verzögerung von onResume bis zum Senden. Wenn die Verzögerung 100 ms überschreitet, beeinträchtigt die Verfolgung die UX. Verwenden Sie einen Hintergrundthread zum Senden, um den UI-Thread nicht zu blockieren. Auf Geräten der unteren Preisklasse ist der Unterschied spürbar.