Screen View у мобилној аналитици — шта је то, које метрике и како пратити

Шта је Screen View?

Screen View — догађај аналитике који се шаље при отварању екрана мобилне апликације. Догађај садржи име екрана (screen_name), класу (screen_class) и временску ознаку. За разлику од веб аналитике, где је page_view везан за URL, у мобилним апликацијама екрани се идентификују по имену Activity, Fragment, ViewController или Custom View.

Структура догађаја Screen View

Параметар previous_screen је посебно важан: омогућава реконструкцију секвенце прелаза и изградњу Screen Flow — мапе корисничких путања у апликацији.

Screen View vs Page View: кључне разлике

Screen View и Page View решавају исти задатак — бележење прегледа — али у различитим окружењима. На вебу, URL једнозначно идентификује страницу, а Page View је везан за учитавање документа. У мобилним апликацијама, екран је стање UI, које не мора нужно да одговара засебној адреси.

• Page View је везан за HTTP захтев и URL — Screen View је везан за догађај животног циклуса Activity/ViewController
• Page View се не дуплира при повратку назад (користи кеш) — Screen View се поново шаље при сваком отварању екрана
• Page View је у просеку краћи — корисник прегледа веб страницу брже него мобилни екран са интерактивним елементима

Још једна разлика — дубина контекста. Screen View у мобилној апликацији укључује параметре стања: да ли је корисник пријављен, који подаци су учитани, да ли је екран отворен у режиму уређивања. Page View на вебу ретко носи такав контекст — бележи само чињеницу учитавања URL. То чини Screen View информативнијим за производну аналитику, јер се сваки догађај може сегментирати по стању.

Типичне грешке при раду са Screen View

Прва грешка — слање screen_view при свакој промени стања унутар екрана (промена табова, отварање попапа). Screen View треба да бележи само потпуни прелаз на нови екран, а не микроинтеракције.

Друга грешка — коришћење техничког имена класе уместо читљивог имена. „ProductDetailActivityKt” је бескорисно за аналитичара — користите „Product Details” у screen_name.

Трећа грешка — слање screen_view без одговарајућих поља. Празан screen_name ствара скуп безвредних записа који се не могу груписати. Увек шаљите бар screen_name и screen_class, чак и на тестним екранима.

Како пратити Screen View?

Имплементација Screen View праћења зависи од архитектуре навигације. Размотримо аутоматски и ручни приступ на примеру Jetpack Compose и SwiftUI.

Android: аутоматско праћење у Jetpack Compose

Користите LifecycleEventObserver на нивоу NavigationComponent. Сваки пут када корисник пређе на нову руту, активира се догађај 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()
            )
        }
    }
}

// Повезивање у NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

Приступ гарантује да се screen_view шаље при сваком повратку екрана у први план, укључујући повратак из позадине. Lifecycle.Event.ON_RESUME је прави тренутак за праћење, не ON_START и не ON_CREATE.

iOS: аутоматско праћење у SwiftUI

У SwiftUI се користи модификатор onAppear уграђен у сваки View. За аутоматизацију се креира 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))
    }
}

// Коришћење:
ProductDetailView()
    .trackScreen("Product Details")

Модификатор trackScreen се додаје било ком View једном линијом. Ово је чисто и скалабилно решење за SwiftUI пројекте.

Screen View у вишемодулним пројектима

У пројектима са модуларном архитектуром, сваки модул може користити своје именовање екрана, што доводи до дуплирања screen_name. Централизовани enum ScreenName решава проблем — сви екрани се именују по јединственом стандарду на једном месту. Додавање новог екрана захтева само нову константу у enum, не претрагу целог кода.

Користите sealed class за опис screen_name са груписањем по функцијама: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS. Ово поједностављује филтрирање у извештајима аналитике.

Screen Flow: аналитика прелаза између екрана

Screen Flow (или Path Analysis) — визуелизација секвенце екрана кроз које корисник пролази. Ово је основни алат за идентификацију уских грла у навигацији.

Изградња Screen Flow

Сваки Screen View са параметром previous_screen ствара ивицу графа: CatalogScreen → ProductDetails → CartScreen. Агрегирањем свих прелаза гради се мапа путања. Тростепени левак заснован на Screen Flow показује где корисници одустају.

• Корак 1: HomeScreen → CatalogScreen (95% пролази)
• Корак 2: CatalogScreen → ProductDetails (65% пролази — 35% одлази)
• Корак 3: ProductDetails → AddToCart (30% пролази — губимо још 35%)

Према подацима Mixpanel (2024), анализа Screen Flow открива до 40% UX проблема који нису видљиви при анализи појединачних догађаја. На пример, чест прелаз ProductDetails → HomeScreen без куповине указује на проблем са ценом или описом производа.

Drop-off анализа

Drop-off — тачка у којој корисник напушта сценарио. Ако након екрана учитавања 60% корисника оде, проблем је у брзини учитавања или анимацији. Ако након Paywall — у цени или вредности претплате.

Screen Flow у Firebase и BigQuery

Firebase не пружа готов Screen Flow извештај, али подаци screen_view су доступни у BigQuery. Направите упит који групише прелазе по пару (previous_screen, screen_name) и израчунава учесталост. Резултат — матрица прелаза која се може визуелизовати у Looker Studio као Sankey дијаграм.

Допуните Screen Flow сегментацијом: одвојено за нове кориснике (првих 7 дана) и за оне који се враћају. Нови корисници чешће застају на онбординг екранима, искусни брже стижу до циљних радњи. Поређење два тока открива уска грла адаптације.

Алати за Screen View аналитику

Избор алата за Screen View зависи од буџета, технолошког стека и потребне детаљности. Размотримо три популарна решења.

Firebase Analytics (бесплатно)

Firebase аутоматски прати екране кроз параметар screen_view у сваком догађају. Не захтева додатни код након интеграције SDK. Ограничење: screen_name се генерише из Activity/ViewController, што не даје увек читљива имена.

Amplitude (професионални)

Amplitude нуди уграђени Pathfinder — визуелни креатор Screen Flow. Подржава user property и сегментацију по кохортама. Омогућава преименовање екрана на серверској страни без измена у коду апликације.

Mixpanel (средњи сегмент)

Mixpanel пружа Flows извештај у реалном времену. Уме да покаже не само линеарне прелазе, већ и гранања — који екрани се посећују након конкретног. Интегрише се са iOS, Android, Flutter и React Native SDK.

Утицај Screen View на перформансе

Сваки догађај screen_view је мрежно слање података. Ако апликација шаље screen_view при свакој промени картице (20+ у минути), ствара додатно оптерећење. Оптимизација: буферишите screen_view и шаљите бач сваких 5 секунди. Firebase аутоматски агрегира догађаје, али прилагођени SDK могу слати сваки позив одмах.

Мерите overhead праћења: додајте временску ознаку у сваки screen_view и израчунајте кашњење од onResume до слања. Ако кашњење прелази 100 ms, праћење утиче на UX. Користите позадинску нит за слање како не бисте блокирали UI нит. На уређајима ниског сегмента разлика је приметна.