Screen View w analityce mobilnej — co to jest, jakie metryki i jak śledzić

Czym jest Screen View?

Screen View — zdarzenie analityki wysyłane przy otwarciu ekranu aplikacji mobilnej. Zdarzenie zawiera nazwę ekranu (screen_name), klasę (screen_class) i znacznik czasu. W przeciwieństwie do analityki webowej, gdzie page_view jest powiązany z URL, w aplikacjach mobilnych ekrany identyfikowane są po nazwie Activity, Fragment, ViewController lub Custom View.

Struktura zdarzenia Screen View

Parametr previous_screen jest szczególnie ważny: umożliwia odtwarzanie sekwencji przejść i budowanie Screen Flow — mapy ścieżek użytkownika w aplikacji.

Screen View vs Page View: kluczowe różnice

Screen View i Page View rozwiązują to samo zadanie — rejestrację wyświetlenia — ale w różnych środowiskach. W webie URL jednoznacznie identyfikuje stronę, a Page View jest powiązany z załadowaniem dokumentu. W aplikacjach mobilnych ekran to stan UI, niekoniecznie odpowiadający osobnemu adresowi.

• Page View jest powiązany z żądaniem HTTP i URL — Screen View jest powiązany ze zdarzeniem cyklu życia Activity/ViewController
• Page View nie duplikuje się przy powrocie wstecz (używany jest cache) — Screen View jest ponownie wysyłany przy każdym otwarciu ekranu
• Page View jest średnio krótszy — użytkownik przegląda stronę internetową szybciej niż ekran mobilny z interaktywnymi elementami

Kolejną różnicą jest głębokość kontekstu. Screen View w aplikacji mobilnej zawiera parametry stanu: czy użytkownik jest zalogowany, jakie dane są załadowane, czy ekran jest otwarty w trybie edycji. Page View w webie rzadko niesie taki kontekst — rejestruje tylko fakt załadowania URL. To czyni Screen View bardziej informacyjnym dla analityki produktowej, ponieważ każde zdarzenie można segmentować według stanu.

Typowe błędy przy pracy z Screen View

Pierwszy błąd — wysyłanie screen_view przy każdej zmianie stanu wewnątrz ekranu (przełączanie zakładek, otwieranie popupa). Screen View powinien rejestrować tylko pełne przejście na nowy ekran, a nie mikrointerakcje.

Drugi błąd — używanie technicznej nazwy klasy zamiast czytelnej nazwy. „ProductDetailActivityKt” jest bezużyteczne dla analityka — używaj „Product Details” w screen_name.

Trzeci błąd — wysyłanie screen_view bez odpowiednich pól. Pusty screen_name tworzy zbiór śmieciowych wpisów, których nie można pogrupować. Zawsze przekazuj przynajmniej screen_name i screen_class, nawet na ekranach testowych.

Jak śledzić Screen View?

Implementacja Screen View tracking zależy od architektury nawigacji. Rozważmy automatyczne i ręczne podejścia na przykładzie Jetpack Compose i SwiftUI.

Android: automatyczne śledzenie w Jetpack Compose

Użyj LifecycleEventObserver na poziomie NavigationComponent. Za każdym razem, gdy użytkownik przechodzi do nowego routa, uruchamiane jest zdarzenie 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()
            )
        }
    }
}

// Podłączenie w NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

To podejście gwarantuje, że screen_view jest wysyłany przy każdym powrocie ekranu na pierwszy plan, w tym po powrocie z tła. Lifecycle.Event.ON_RESUME to odpowiedni moment do śledzenia, nie ON_START ani ON_CREATE.

iOS: automatyczne śledzenie w SwiftUI

W SwiftUI używa się modyfikatora onAppear wbudowanego w każdy View. Do automatyzacji tworzony jest 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))
    }
}

// Użycie:
ProductDetailView()
    .trackScreen("Product Details")

Modyfikator trackScreen dodaje się do dowolnego View jedną linią. To czyste i skalowalne rozwiązanie dla projektów SwiftUI.

Screen View w projektach wielomodułowych

W projektach z architekturą modułową każdy moduł może używać własnego nazewnictwa ekranów, co prowadzi do duplikacji screen_name. Scentralizowany enum ScreenName rozwiązuje problem — wszystkie ekrany są nazywane według jednolitego standardu w jednym miejscu. Dodanie nowego ekranu wymaga tylko nowej stałej w enum, a nie przeszukiwania całego kodu.

Używaj sealed class do opisu screen_name z grupowaniem według funkcji: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Upraszcza to filtrowanie w raportach analityki.

Screen Flow: analiza przejść między ekranami

Screen Flow (lub Path Analysis) — wizualizacja sekwencji ekranów, przez które przechodzi użytkownik. To podstawowe narzędzie do identyfikacji wąskich gardeł w nawigacji.

Budowanie Screen Flow

Każdy Screen View z parametrem previous_screen tworzy krawędź grafu: CatalogScreen → ProductDetails → CartScreen. Agregując wszystkie przejścia, buduje się mapa ścieżek. Lejek trzech kroków oparty na Screen Flow pokazuje, gdzie użytkownicy odpadają.

• Krok 1: HomeScreen → CatalogScreen (95% przechodzi)
• Krok 2: CatalogScreen → ProductDetails (65% przechodzi — 35% odpada)
• Krok 3: ProductDetails → AddToCart (30% przechodzi — tracimy kolejne 35%)

Według danych Mixpanel (2024), analiza Screen Flow ujawnia do 40% problemów z UX, które nie są widoczne przy analizie pojedynczych zdarzeń. Na przykład częste przejście ProductDetails → HomeScreen bez zakupu wskazuje na problem z ceną lub opisem produktu.

Analiza Drop-off

Drop-off — punkt, w którym użytkownik opuszcza scenariusz. Jeśli po ekranie Ładowania 60% użytkowników odchodzi, problem leży w szybkości ładowania lub animacji. Jeśli po Paywall — w cenie lub wartości subskrypcji.

Screen Flow w Firebase i BigQuery

Firebase nie udostępnia gotowego raportu Screen Flow, ale dane screen_view są dostępne w BigQuery. Zbuduj zapytanie grupujące przejścia według pary (previous_screen, screen_name) i obliczające częstotliwość. Wynik — macierz przejść, którą można zwizualizować w Looker Studio jako diagram Sankeya.

Uzupełnij Screen Flow segmentacją: osobno dla nowych użytkowników (pierwsze 7 dni) i dla powracających. Nowi użytkownicy częściej utykają na ekranach onboardingu, doświadczeni — szybciej docierają do docelowych działań. Porównanie dwóch strumieni ujawnia wąskie gardła adaptacji.

Narzędzia do analizy Screen View

Wybór narzędzia do Screen View zależy od budżetu, stosu technologicznego i wymaganej szczegółowości. Rozważmy trzy popularne rozwiązania.

Firebase Analytics (bezpłatnie)

Firebase automatycznie śledzi ekrany przez parametr screen_view w każdym zdarzeniu. Nie wymaga dodatkowego kodu po integracji SDK. Ograniczenie: screen_name jest generowany z Activity/ViewController, co nie zawsze daje czytelne nazwy.

Amplitude (profesjonalny)

Amplitude oferuje wbudowany Pathfinder — wizualny kreator Screen Flow. Obsługuje user property i segmentację według kohort. Pozwala zmieniać nazwy ekranów po stronie serwera bez zmian w kodzie aplikacji.

Mixpanel (średni segment)

Mixpanel udostępnia raport Flows w czasie rzeczywistym. Potrafi pokazywać nie tylko przejścia liniowe, ale także rozgałęzienia — które ekrany są odwiedzane po konkretnym. Integruje się z iOS, Android, Flutter i React Native SDK.

Wpływ Screen View na wydajność

Każde zdarzenie screen_view to sieciowe wysyłanie danych. Jeśli aplikacja wysyła screen_view przy każdym przełączeniu zakładki (20+ na minutę), tworzy to dodatkowe obciążenie. Optymalizacja: buforuj screen_view i wysyłaj batch co 5 sekund. Firebase automatycznie agreguje zdarzenia, ale niestandardowe SDK mogą wysyłać każde wywołanie natychmiastowo.

Mierz overhead śledzenia: dodaj znacznik czasu w każdym screen_view i obliczaj opóźnienie od onResume do wysłania. Jeśli opóźnienie przekracza 100 ms, śledzenie wpływa na UX. Używaj wątku tła do wysyłania, aby nie blokować wątku UI. Na urządzeniach niskiego segmentu różnica jest zauważalna.