Screen View a mobil analitikában — mi ez, milyen metrikák és hogyan kell követni

Mi az a Screen View?

Screen View — analitikai esemény, amelyet a mobilalkalmazás képernyőjének megnyitásakor küldenek. Az esemény tartalmazza a képernyő nevét (screen_name), osztályát (screen_class) és időbélyegét. Ellentétben a webes analitikával, ahol a page_view URL-hez van kötve, a mobilalkalmazásokban a képernyőket az Activity, Fragment, ViewController vagy Custom View neve alapján azonosítják.

A Screen View esemény szerkezete

A previous_screen paraméter különösen fontos: lehetővé teszi az átmenetek sorrendjének rekonstruálását és a Screen Flow — a felhasználói útvonalak térképének felépítését az alkalmazásban.

Screen View vs Page View: főbb különbségek

Screen View és Page View ugyanazt a feladatot oldják meg — a megtekintés rögzítését — de különböző környezetekben. A weben az URL egyedileg azonosítja az oldalt, és a Page View a dokumentum betöltéséhez kötődik. A mobilalkalmazásokban a képernyő egy UI állapot, amely nem feltétlenül felel meg egy külön címnek.

• A Page View HTTP kéréshez és URL-hez kötődik — a Screen View az Activity/ViewController életciklus eseményéhez kötődik
• A Page View nem duplikálódik visszalépéskor (gyorsítótárat használ) — a Screen View minden képernyőnyitáskor újra elküldésre kerül
• A Page View átlagosan rövidebb — a felhasználó gyorsabban böngészi a weboldalt, mint egy mobil képernyőt interaktív elemekkel

Egy másik különbség — a kontextus mélysége. A Screen View a mobilalkalmazásban állapotparamétereket tartalmaz: be van-e jelentkezve a felhasználó, milyen adatok vannak betöltve, szerkesztési módban van-e megnyitva a képernyő. A Page View a weben ritkán hordoz ilyen kontextust — csak az URL betöltésének tényét rögzíti. Ez informatívabbá teszi a Screen View-t a termékanalitika számára, mivel minden esemény állapot szerint szegmentálható.

Tipikus hibák a Screen View használatakor

Első hiba — screen_view küldése a képernyőn belüli minden állapotváltozáskor (lapozó fülek váltása, felugró ablak megnyitása). A Screen View csak a teljes átmenetet rögzítheti egy új képernyőre, nem a mikro-interakciókat.

Második hiba — a technikai osztálynév használata olvasható név helyett. A „ProductDetailActivityKt” használhatatlan az elemző számára — használja a „Product Details” nevet a screen_name-ben.

Harmadik hiba — screen_view küldése a megfelelő mezők nélkül. Az üres screen_name szemét rekordok halmazát hozza létre, amelyek nem csoportosíthatók. Mindig küldjön legalább screen_name és screen_class értéket, még tesztképernyőkön is.

Hogyan kell követni a Screen View-t?

A Screen View követés megvalósítása a navigációs architektúrától függ. Tekintsük át az automatikus és kézi megközelítéseket a Jetpack Compose és SwiftUI példáján.

Android: automatikus követés Jetpack Compose-ban

Használja a LifecycleEventObserver-t a NavigationComponent szintjén. Minden alkalommal, amikor a felhasználó egy új útvonalra lép, a screen_view esemény aktiválódik.

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

// Csatlakoztatás a NavHost-ban
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

A megközelítés garantálja, hogy a screen_view minden alkalommal elküldésre kerül, amikor a képernyő visszatér az előtérbe, beleértve a háttérből való visszatérést is. Lifecycle.Event.ON_RESUME a megfelelő pillanat a követéshez, nem ON_START és nem ON_CREATE.

iOS: automatikus követés SwiftUI-ban

A SwiftUI-ban a onAppear módosító használatos, amely minden View-ba be van építve. Az automatizáláshoz egy ViewModifier jön létre.

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

// Használat:
ProductDetailView()
    .trackScreen("Product Details")

A trackScreen módosító egyetlen sorral hozzáadható bármely View-hoz. Ez egy tiszta és skálázható megoldás SwiftUI projektekhez.

Screen View többmodulos projektekben

A moduláris architektúrájú projektekben minden modul saját képernyő-elnevezést használhat, ami a screen_name duplikálódásához vezet. A centralizált enum ScreenName megoldja a problémát — minden képernyő egyetlen szabvány szerint van elnevezve egy helyen. Új képernyő hozzáadása csak egy új konstanset igényel az enum-ban, nem a teljes kód átkutatását.

Használjon sealed class-t a screen_name leírásához, funkciók szerinti csoportosítással: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Ez egyszerűsíti a szűrést az analitikai jelentésekben.

Screen Flow: képernyők közötti átmenetek elemzése

Screen Flow (vagy Path Analysis) — a felhasználó által bejárt képernyők sorrendjének vizualizációja. Ez az elsődleges eszköz a navigációs szűk keresztmetszetek azonosításához.

Screen Flow építése

Minden Screen View a previous_screen paraméterrel egy gráf élt hoz létre: CatalogScreen → ProductDetails → CartScreen. Az összes átmenet aggregálásával felépül az útvonalak térképe. A Screen Flow-ra épülő háromlépcsős tölcsér megmutatja, hol esnek ki a felhasználók.

• 1. lépés: HomeScreen → CatalogScreen (95% áthalad)
• 2. lépés: CatalogScreen → ProductDetails (65% áthalad — 35% kilép)
• 3. lépés: ProductDetails → AddToCart (30% áthalad — további 35%-ot veszítünk)

A Mixpanel (2024) adatai szerint a Screen Flow elemzés akár a UX-problémák 40%-át is feltárja, amelyek az egyes események elemzésekor nem láthatók. Például a gyakori ProductDetails → HomeScreen átmenet vásárlás nélkül problémát jelez a termék árával vagy leírásával.

Drop-off elemzés

Drop-off — az a pont, ahol a felhasználó elhagyja a forgatókönyvet. Ha a betöltőképernyő után a felhasználók 60%-a távozik, a probléma a betöltési sebességben vagy az animációban van. Ha Paywall után — az előfizetés árában vagy értékében.

Screen Flow Firebase-ben és BigQuery-ben

Firebase nem nyújt kész Screen Flow jelentést, de a screen_view adatok elérhetők a BigQuery-ben. Készítsen lekérdezést, amely az átmeneteket a (previous_screen, screen_name) pár szerint csoportosítja és kiszámítja a gyakoriságot. Az eredmény egy átmeneti mátrix, amely a Looker Studio-ban Sankey-diagramként vizualizálható.

Egészítse ki a Screen Flow-t szegmentációval: külön az új felhasználókra (első 7 nap) és a visszatérőkre. Az új felhasználók gyakrabban ragadnak a bevezető képernyőkön, a tapasztaltak gyorsabban elérik a célműveleteket. A két folyam összehasonlítása feltárja az adaptációs szűk keresztmetszeteket.

Eszközök a Screen View elemzéshez

Az eszköz kiválasztása a Screen View-hoz a költségvetéstől, a technológiai veremtől és a szükséges részletességtől függ. Tekintsünk át három népszerű megoldást.

Firebase Analytics (ingyenes)

Firebase automatikusan követi a képernyőket a screen_view paraméteren keresztül minden eseményben. Nem igényel további kódot az SDK integrációja után. Korlátozás: a screen_name az Activity/ViewController alapján generálódik, ami nem mindig ad olvasható neveket.

Amplitude (professzionális)

Amplitude beépített Pathfinder-t kínál — egy vizuális Screen Flow építőt. Támogatja a user property-t és a kohorszok szerinti szegmentációt. Lehetővé teszi a képernyők átnevezését a szerver oldalon az alkalmazás kódjának módosítása nélkül.

Mixpanel (középső szegmens)

Mixpanel valós idejű Flows jelentést nyújt. Képes nemcsak lineáris átmeneteket, hanem elágazásokat is mutatni — mely képernyőket látogatják egy adott képernyő után. Integrálódik az iOS, Android, Flutter és React Native SDK-kkal.

A Screen View hatása a teljesítményre

Minden screen_view esemény hálózati adatküldés. Ha az alkalmazás minden fülváltáskor (percenként 20+) screen_view-t küld, ez többletterhelést okoz. Optimalizálás: pufferelje a screen_view-t és küldje batch-ben 5 másodpercenként. A Firebase automatikusan aggregálja az eseményeket, de az egyedi SDK-k azonnal küldhetik az egyes hívásokat.

Mérje a követés többletterhelését: adjon időbélyeget minden screen_view-hoz, és számítsa ki a késleltetést az onResume-tól a küldésig. Ha a késleltetés meghaladja a 100 ms-ot, a követés hatással van a UX-re. Használjon háttérszálat a küldéshez, hogy ne blokkolja az UI szálat. Az alacsony kategóriás eszközökön a különbség észrevehető.