Screen View sa mobile analytics — ano ito, anong metrics at paano subaybayan

Ano ang Screen View?

Screen View — pangyayari sa analytics na ipinapadala kapag nagbubukas ng screen ng mobile app. Ang pangyayari ay naglalaman ng pangalan ng screen (screen_name), klase (screen_class) at timestamp. Hindi tulad ng web analytics, kung saan ang page_view ay nakatali sa URL, sa mga mobile app ang mga screen ay nakikilala sa pamamagitan ng pangalan ng Activity, Fragment, ViewController o Custom View.

Istraktura ng Screen View na pangyayari

Ang parameter na previous_screen ay lalong mahalaga: pinapayagan nito ang muling pagbuo ng pagkakasunod-sunod ng mga transisyon at paggawa ng Screen Flow — mapa ng mga landas ng user sa app.

Screen View vs Page View: mga pangunahing pagkakaiba

Screen View at Page View ay lumulutas ng parehong gawain — pagtatala ng pagtingin — ngunit sa magkaibang kapaligiran. Sa web, ang URL ay natatanging tumutukoy sa pahina, at ang Page View ay nakatali sa pag-load ng dokumento. Sa mga mobile app, ang screen ay isang estado ng UI, na hindi kinakailangang tumutugma sa isang hiwalay na address.

• Ang Page View ay nakatali sa HTTP request at URL — ang Screen View ay nakatali sa pangyayari sa lifecycle ng Activity/ViewController
• Ang Page View ay hindi nadoble kapag bumalik (gumagamit ng cache) — ang Screen View ay muling ipinapadala sa bawat pagbubukas ng screen
• Ang Page View ay karaniwang mas maikli — mas mabilis na tinitingnan ng user ang web page kaysa sa mobile screen na may mga interactive na elemento

Isa pang pagkakaiba — lalim ng konteksto. Ang Screen View sa mobile app ay may kasamang mga parameter ng estado: kung naka-log in ang user, anong datos ang na-load, kung ang screen ay binuksan sa edit mode. Ang Page View sa web ay bihirang nagdadala ng ganitong konteksto — itinatala lamang nito ang katotohanan ng pag-load ng URL. Ito ay ginagawang mas impormatibo ang Screen View para sa product analytics, dahil ang bawat pangyayari ay maaaring i-segment ayon sa estado.

Mga karaniwang pagkakamali sa paggamit ng Screen View

Unang pagkakamali — pagpapadala ng screen_view sa bawat pagbabago ng estado sa loob ng screen (pagpalit ng tab, pagbubukas ng pop-up). Ang Screen View ay dapat magtala lamang ng kumpletong transisyon sa bagong screen, hindi mga micro-interaksyon.

Pangalawang pagkakamali — paggamit ng teknikal na pangalan ng klase sa halip na nababasang pangalan. Ang "ProductDetailActivityKt" ay walang silbi para sa analyst — gamitin ang "Product Details" sa screen_name.

Pangatlong pagkakamali — pagpapadala ng screen_view nang walang kaukulang mga field. Walang laman na screen_name ay lumilikha ng basurang record na hindi maaaring pagsama-samahin. Palaging magpadala ng kahit man lang screen_name at screen_class, kahit sa mga test screen.

Paano subaybayan ang Screen View?

Implementasyon ng pagsubaybay sa Screen View ay depende sa arkitektura ng nabigasyon. Tingnan natin ang awtomatiko at manu-manong mga approach sa halimbawa ng Jetpack Compose at SwiftUI.

Android: awtomatikong pagsubaybay sa Jetpack Compose

Gumamit ng LifecycleEventObserver sa antas ng NavigationComponent. Sa bawat oras na ang user ay pumunta sa bagong ruta, ang screen_view na pangyayari ay na-trigger.

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

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

Tinitiyak ng approach na ito na ang screen_view ay ipinapadala sa bawat pagbalik ng screen sa foreground, kabilang ang pagbalik mula sa background. Lifecycle.Event.ON_RESUME ang tamang sandali para sa pagsubaybay, hindi ON_START o ON_CREATE.

iOS: awtomatikong pagsubaybay sa SwiftUI

Sa SwiftUI, ginagamit ang modifier na onAppear na naka-embed sa bawat View. Para sa automation, ginagawa ang 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))
    }
}

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

Ang modifier na trackScreen ay idinaragdag sa anumang View sa isang linya. Ito ay malinis at scalable na solusyon para sa SwiftUI projects.

Screen View sa multi-module projects

Sa mga project na may modular architecture, ang bawat module ay maaaring gumamit ng sarili nitong pagpapangalan ng screen, na humahantong sa pagdoble ng screen_name. Ang centralized enum ScreenName ay lumulutas ng problema — lahat ng screen ay pinapangalanan ayon sa iisang standard sa isang lugar. Ang pagdaragdag ng bagong screen ay nangangailangan lamang ng bagong constant sa enum, hindi paghahanap sa buong code.

Gumamit ng sealed class para sa paglalarawan ng screen_name na may pagpapangkat ayon sa feature: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Pinapasimple nito ang pag-filter sa mga ulat ng analytics.

Screen Flow: pagsusuri ng mga transisyon sa pagitan ng mga screen

Screen Flow (o Path Analysis) — visualization ng pagkakasunod-sunod ng mga screen na dinadaanan ng user. Ito ang pangunahing tool para sa pagtukoy ng mga bottleneck sa nabigasyon.

Pagbuo ng Screen Flow

Ang bawat Screen View na may parameter na previous_screen ay lumilikha ng gilid ng graph: CatalogScreen → ProductDetails → CartScreen. Sa pamamagitan ng pagsasama-sama ng lahat ng transisyon, nabubuo ang mapa ng mga landas. Ang tatlong-hakbang na funnel batay sa Screen Flow ay nagpapakita kung saan umaalis ang mga user.

• Hakbang 1: HomeScreen → CatalogScreen (95% pumapasa)
• Hakbang 2: CatalogScreen → ProductDetails (65% pumapasa — 35% umaalis)
• Hakbang 3: ProductDetails → AddToCart (30% pumapasa — nawawalan pa ng 35%)

Ayon sa datos ng Mixpanel (2024), ang pagsusuri ng Screen Flow ay nagpapakita ng hanggang 40% ng mga problema sa UX na hindi nakikita sa pagsusuri ng mga indibidwal na pangyayari. Halimbawa, ang madalas na transisyon ProductDetails → HomeScreen nang walang pagbili ay nagpapahiwatig ng problema sa presyo o paglalarawan ng produkto.

Drop-off analysis

Drop-off — punto kung saan iniiwan ng user ang scenario. Kung pagkatapos ng loading screen 60% ng mga user ay umalis, ang problema ay nasa bilis ng pag-load o animation. Kung pagkatapos ng Paywall — sa presyo o halaga ng subscription.

Screen Flow sa Firebase at BigQuery

Firebase ay hindi nagbibigay ng handa na Screen Flow report, ngunit ang data ng screen_view ay available sa BigQuery. Gumawa ng query na nagpapangkat ng mga transisyon ayon sa pares (previous_screen, screen_name) at kinakalkula ang dalas. Resulta — isang transisyon matrix na maaaring i-visualize sa Looker Studio bilang Sankey diagram.

Kumpletuhin ang Screen Flow ng segmentation: hiwalay para sa mga bagong user (unang 7 araw) at sa mga bumabalik. Ang mga bagong user ay mas madalas na natatrap sa onboarding screens, ang mga may karanasan ay mas mabilis na nakakarating sa target na aksyon. Ang paghahambing ng dalawang daloy ay nagpapakita ng mga bottleneck sa adaptasyon.

Mga tool para sa Screen View analytics

Pagpili ng tool para sa Screen View ay depende sa budget, tech stack, at kinakailangang detalye. Tingnan natin ang tatlong sikat na solusyon.

Firebase Analytics (libre)

Firebase ay awtomatikong sumusubaybay ng mga screen sa pamamagitan ng parameter na screen_view sa bawat pangyayari. Hindi nangangailangan ng karagdagang code pagkatapos ng SDK integration. Limitasyon: ang screen_name ay nabubuo mula sa Activity/ViewController, na hindi palaging nagbibigay ng nababasang pangalan.

Amplitude (propesyonal)

Amplitude ay nag-aalok ng built-in na Pathfinder — visual na tagabuo ng Screen Flow. Sumusuporta sa user property at segmentation ayon sa cohorts. Pinapayagan ang pagpapalit ng pangalan ng screen sa server side nang walang pagbabago sa code ng app.

Mixpanel (medium segment)

Mixpanel ay nagbibigay ng Flows report sa real-time. Maaaring magpakita hindi lamang ng linear transisyon, kundi pati na rin ng mga sangay — kung aling mga screen ang binibisita pagkatapos ng isang partikular na screen. Nagsasama sa iOS, Android, Flutter at React Native SDK.

Epekto ng Screen View sa performance

Ang bawat screen_view na pangyayari ay network data transmission. Kung ang app ay nagpapadala ng screen_view sa bawat pagpalit ng tab (20+ bawat minuto), ito ay lumilikha ng dagdag na load. Optimization: i-buffer ang screen_view at magpadala ng batch bawat 5 segundo. Awtomatikong ina-aggregate ng Firebase ang mga pangyayari, ngunit ang custom na SDK ay maaaring magpadala ng bawat tawag agad.

Sukatin ang overhead ng pagsubaybay: magdagdag ng timestamp sa bawat screen_view at kalkulahin ang delay mula onResume hanggang pagpapadala. Kung ang delay ay lumampas sa 100 ms, ang pagsubaybay ay nakakaapekto sa UX. Gumamit ng background thread para sa pagpapadala upang hindi ma-block ang UI thread. Sa low-end devices, kapansin-pansin ang pagkakaiba.