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 дни) и за завърнали се. Новите потребители по-често засядат на onboarding екрани, опитните стигат по-бързо до целевите действия. Сравнението на двата потока разкрива тесни места в адаптацията.

Инструменти за 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 нишката. На устройства от нисък клас разликата е забележима.