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-поток. На устройствах низкого сегмента разница заметна.