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 tracking залежить від архітектури навігації. Розглянемо автоматичний та ручний підходи на прикладі 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 — точка, в якій користувач покидає сценарій. Якщо після Loading екрана 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 мс, трекінг впливає на UX. Використовуйте фоновий потік для надсилання, щоб не блокувати UI-потік. На пристроях низького сегмента різниця помітна.