Аналитика мобильного приложения: метрики, инструменты и решения по данным

По данным AppsFlyer, средний мобильный продукт теряет более 70% пользователей в первые 30 дней — и это кросс-индустриальный бенчмарк, а не исключение. Day-30 retention в среднем составляет около 5,4%. При этом, по данным UXCam, показатели сильно расходятся по категориям: Sendbird фиксирует Day-30 для новостных приложений около 11%, бизнес-приложений — около 5%, игр — около 2,4%. Это означает одно: если вы не знаете, почему пользователи уходят или остаются, вы летите вслепую. Аналитика мобильного приложения — это не дашборд ради дашборда, а инструмент, который превращает поведение пользователей в конкретные продуктовые решения. В этой статье разберём, какие метрики действительно важны, чем их собирать и как переходить от цифр к действиям.

Зачем нужна аналитика мобильного приложения

Разработчик, выпустивший приложение без аналитики, похож на водителя с завязанными глазами: машина едет, но куда — непонятно. В веб-аналитике хватает куки и UTM-меток, но мобильная специфика принципиально сложнее в нескольких измерениях.

Главные отличия от веб-аналитики:

• В вебе сессии описываются куки; в мобильных приложениях — SDK-инициализацией и device ID. При удалении и переустановке — это технически «новый» пользователь без специальных механизмов идентификации.
• Источник трафика в вебе определяется UTM-метками в URL. Для мобильных нужна атрибуция установок — отдельный класс инструментов (AppsFlyer, Adjust), связывающих установку с рекламным каналом ещё до App Store или Google Play.
• Мобильные приложения работают офлайн — события накапливаются на устройстве и отправляются пачкой при восстановлении соединения. Это усложняет time-based анализ.
• Push-уведомления, виджеты и App Clips создают дополнительные точки входа, которых нет в вебе.

Без аналитики вы не знаете, какие фичи реально используются, на каком шаге пользователи бросают регистрацию, сколько стоит один платящий пользователь и окупается ли реклама. Цена этого незнания — решения по интуиции, которые в лучшем случае нейтральны, в худшем — сжигают маркетинговый бюджет и ускоряют отток.

Какие метрики отслеживать в аналитике мобильного приложения

Метрик существуют сотни. Отслеживать все — значит не понять ничего. Разделим по зонам ответственности.

Метрики аудитории и активности

• DAU (Daily Active Users) — уникальные пользователи за сутки. Базовый «пульс» продукта.
• WAU и MAU — аудитория за неделю и месяц. WAU полезен для продуктов с еженедельным циклом использования (B2B-инструменты, фитнес).
• Stickiness = DAU / MAU — какая доля месячной аудитории возвращается ежедневно. Stickiness выше 20–25% считается хорошим результатом для большинства категорий; Facebook исторически держит около 50%.
• Новые vs. возвращающиеся пользователи — соотношение говорит о балансе между привлечением и удержанием. Если retention низкий, рост установок маскирует, но не решает проблему «дырявого ведра».

Удержание и отток

Retention — самая важная группа метрик для долгосрочного здоровья продукта.

• Day-1 retention — вернулся ли пользователь на следующий день после установки. Говорит о первом впечатлении и качестве онбординга. Day-1 ниже 25–30% — повод смотреть онбординговый флоу.
• Day-7 и Day-30 retention — более зрелые индикаторы «приживаемости». Показывают, формируется ли привычка. Медианный Day-30 по всем категориям — около 5,4%, лидирующие продукты держат 20%+.
• Churn rate — процент пользователей, переставших пользоваться приложением за период. Обратная сторона retention (Churn = 1 − Retention).
• Uninstall rate — процент удалений. Стабильно высокий uninstall rate — системный сигнал: перегруженность пушами, баги или нереализованные ожидания.
• Когортный анализ (cohort analysis) — группировка пользователей по дате первой сессии и отслеживание поведения во времени. Только когортный анализ показывает, стало ли лучше после обновления или новые пользователи ведут себя так же, как месяц назад.

Вовлечённость (Engagement)

• Длина сессии — сколько времени пользователь проводит за один визит. Контекст важен: для игры «чем больше, тем лучше», для банковского приложения — «чем быстрее задача решена, тем лучше UX».
• Частота сессий — сколько раз в день/неделю пользователь открывает приложение.
• Глубина сессии — сколько экранов просматривает пользователь за визит.
• Ключевые события и фичи — какие функции реально используются, а какие игнорируются. Именно это определяет приоритет в roadmap.
• Воронки (funnels) — последовательности действий: регистрация → онбординг → первое целевое действие. Воронка показывает, на каком шаге теряются пользователи.

Монетизация и unit-экономика

• LTV (Lifetime Value) — пожизненная ценность пользователя, суммарный доход за всё время. Определяет допустимый CAC.
• ARPU / ARPPU — средний доход на пользователя и на платящего пользователя. Разница показывает долю платящих в аудитории.
• Конверсия в платящих — процент пользователей, совершивших хотя бы одну покупку.
• CAC (Customer Acquisition Cost) — стоимость привлечения одного пользователя через маркетинг.
• ROI / ROAS — возврат инвестиций в маркетинг. Если LTV > CAC, бизнес масштабируем; если нет — маркетинг убыточен.
• Период окупаемости — сколько месяцев нужно, чтобы LTV превысил CAC. Для стартапов норма — до 12 месяцев.

Технические и качественные метрики

• Crash-free rate — процент сессий без падения. Минимальная планка — 99%+. App Store и Google Play учитывают crash rate в алгоритме ранжирования.
• ANR (Application Not Responding) — зависания на Android. Напрямую влияют на оценку в Google Play.
• Время холодного запуска — от нажатия иконки до интерактивного экрана. Google рекомендует не более 5 секунд.
• Точки отвала в воронке — конкретный экран или действие, на котором пользователь уходит. Самая ценная точка для UX-исправлений.

Метрика	Что показывает	Какое решение подсказывает
Низкий Day-1 retention	Плохой онбординг или нереализованные ожидания	A/Б-тест онбординга, упрощение первого флоу
Высокий churn на 7–14 день	Нет привычкообразующей фичи или её сложно найти	Анализ пути к aha-моменту, навигация
Низкий stickiness (DAU/MAU)	Продукт нужен редко или недостаточно ценен	Push-стратегия, геймификация, ценностное предложение
CAC > LTV	Маркетинг убыточный	Срезать неэффективные каналы, поднять монетизацию
Crash-free rate < 99%	Технические проблемы снижают рейтинг	Приоритет на исправление критических багов
Отвал на конкретном экране воронки	Проблема UX или технический баг	Запись сессий (UXCam), A/Б-тест экрана

Инструменты аналитики мобильных приложений

Не существует «лучшего инструмента для всех» — выбор зависит от задачи, зрелости продукта и требований к хранению данных.

Продуктовая аналитика:

• Amplitude — де-факто стандарт продуктовой аналитики: когорты, воронки, пути пользователей, предиктивная аналитика. Есть щедрый free-tier до 10 млн событий в месяц.
• Mixpanel — конкурент Amplitude, исторически сильнее в event-based аналитике и встроенном A/Б-тестировании.
• Firebase / Google Analytics for Firebase — бесплатный, тесно интегрирован с Android и Google Play. Хорошая точка входа для начинающих; менее гибкий в продвинутых когортных запросах.

Российские и локальные решения:

• Yandex AppMetrica — бесплатная аналитика от Яндекса. Хранит данные в российских ЦОД, что важно для компаний под 152-ФЗ и требованиями импортозамещения. Поддерживает attribution, воронки, когорты и пуш-уведомления. Оптимальный выбор для рунет-продуктов.

Атрибуция установок:

• AppsFlyer — лидер рынка атрибуции. Показывает, из какого канала и кампании пришла установка, ROAS по каждому каналу.
• Adjust — альтернатива с гибкой ценовой политикой и сильной защитой от рекламного фрода.

Краш-аналитика:

• Firebase Crashlytics — бесплатный инструмент отслеживания падений с группировкой по стеку, версии ОС и устройству. Практически стандарт для iOS и Android.

Сессионная аналитика:

• UXCam — записи сессий, тепловые карты касаний, воронки на основе UX. Особенно ценен, когда event-аналитика показывает отвал, но не объясняет причину.

Требования по хранению данных в России: если приложение обрабатывает персональные данные российских пользователей, 152-ФЗ требует первичную обработку на серверах в РФ. В этом контексте Yandex AppMetrica — наиболее очевидный выбор. Firebase и Amplitude хранят данные за рубежом и требуют юридической проработки. Зрелый вариант для крупных продуктов — гибридная схема: AppMetrica для пользовательских данных плюс Amplitude или Mixpanel для агрегированной аналитики через server-side tracking.

Как устроен сбор данных

Аналитика — это не «установить SDK и забыть». Данные нужно собирать структурировано с первого дня.

Event tracking — основа мобильной аналитики

Базовый принцип современной аналитики — события (events), а не страницы. Вместо «пользователь открыл экран X» вы трекаете конкретные действия: screen_view, button_click, purchase_complete, onboarding_step_completed. Каждое событие несёт контекст через свойства (properties):

{"event_name": "purchase_complete", "amount": 1299, "currency": "RUB", "item_id": "pro_subscription"}

Именно свойства превращают сырые события в полезные данные: вы видите не просто «была покупка», а «пользователь из Новосибирска, пришедший из Instagram, купил pro-подписку через 3 дня после установки».

Tracking plan — фундамент нормальной аналитики

Tracking plan — документ, описывающий: какие события отслеживаются, с какими свойствами, в каких условиях и кто отвечает за каждое. Без tracking plan аналитика превращается в хаос: разные разработчики называют одно и то же по-разному (purchase vs payment_done vs buy_click), свойства несогласованы, и дашборды расходятся. Принятое соглашение по именованию — object_action в snake_case: cart_checkout_started, subscription_renewed.

SDK на клиенте vs server-side tracking

Клиентский SDK (встроен в приложение) — простейший вариант: событие отправляется с устройства напрямую в аналитическую платформу. Проблема: зависит от соединения, может потеряться офлайн или блокироваться некоторыми корпоративными конфигурациями.

Server-side tracking — приложение отправляет событие на ваш бэкенд, который ретранслирует его в аналитические системы. Надёжнее, даёт контроль над обогащением данных (добавить CRM-атрибуты, очистить персональные данные перед отправкой), не зависит от клиентских блокировщиков. Server-side — правильный подход для производственных продуктов с требованиями по 152-ФЗ или сложной сегментацией. Реализация такого pipeline — часть работы по разработке мобильного приложения: бэкенд принимает события от клиента и направляет их в нужные системы.

Data Warehouse для зрелой аналитики

На зрелом этапе все события складываются в Data Warehouse (BigQuery, ClickHouse, Snowflake), где строятся кастомные когорты, объединяются данные из приложения, CRM и рекламных кабинетов. Это выходит за рамки стандартных интерфейсов аналитических платформ и требует инфраструктуры. Построение таких решений охватывает услуга аналитики данных и BI — от проектирования схемы событий до дашбордов для руководства.

Как метрики превращать в решения

Это самый важный и самый часто упускаемый шаг. Данные сами по себе не принимают решений — это делают люди по выстроенному процессу.

Цикл гипотез

Правильный процесс: наблюдение (аномалия в метрике) → гипотеза (почему?) → измерение (какая метрика подтвердит гипотезу?) → A/Б-тест → решение (внедрить / откатить / итерировать).

Примеры из практики:

• Day-1 retention упал с 35% до 22% после обновления → гипотеза: новый онбординг-флоу слишком длинный → A/Б-тест с коротким и длинным вариантом → результат: вернули короткий, retention восстановился.
• LTV у пользователей из канала B в 2,3 раза выше, чем из канала A → гипотеза: канал B приводит более качественную аудиторию → решение: перераспределить бюджет в пользу канала B.
• 42% пользователей бросают регистрацию на шаге ввода номера телефона → гипотеза: барьер слишком высокий → перенесли ввод телефона после первого aha-момента → конверсия +18%.

North Star Metric

North Star Metric (NSM) — одна метрика, наилучшим образом отражающая ценность продукта для пользователей и коррелирующая с долгосрочным ростом. Для музыкального стримингового сервиса это «время прослушивания», для e-commerce — «количество завершённых покупок в месяц», для B2B-инструмента — «еженедельно активные рабочие пространства». NSM объединяет команды вокруг общей цели и помогает расставлять приоритеты: «эта фича двигает NSM или нет?»

Антипаттерн: vanity metrics

Vanity metrics — цифры, которые выглядят хорошо, но не влияют на реальный рост. Классика: общее число установок при нулевом retention, количество просмотров экранов без привязки к конверсии. Ориентируйтесь на actionable metrics — те, на которые вы можете влиять и которые связаны с бизнес-результатом.

Частые ошибки в аналитике мобильного приложения

1. Трекать всё подряд без tracking plan. Результат — «аналитика есть, данных нет»: тысячи событий с несогласованными именами, которые невозможно агрегировать. Инвестиция в tracking plan до начала разработки окупается многократно.
2. Нет сегментации. Средние цифры по всей аудитории прячут реальность. «Средний retention 8%» может скрывать, что у iOS-пользователей он 20%, а у Android — 3%. Всегда сегментируйте по платформе, версии приложения, источнику установки.
3. Сравнение с чужой категорией. Retention 5% для игры и 5% для банковского приложения — разные планеты. Сравнивайте только с бенчмарками своей категории по данным AppsFlyer, UXCam или Liftoff.
4. Решения по «средним по больнице». Если у вас когорта суперпользователей с LTV 50 000 рублей и масса с LTV 100 рублей, средний LTV 500 рублей не говорит ничего полезного — только скрывает, кого нужно удерживать.
5. Игнорирование приватности (ATT / согласий). После iOS 14.5 пользователи активно отказывают в отслеживании. Без согласия вы получаете частичную картину — учитывайте sampling bias при интерпретации метрик.
6. «Дашборд ради дашборда». Красивые дашборды без регулярного ревью и без связи с roadmap — это орнамент. Аналитика работает только если за каждой метрикой стоит ответственный и процесс принятия решений.

Как выстроить аналитику с нуля: чек-лист

1. Сформулируйте бизнес-вопросы. Не «трекаем всё», а «нам нужно знать X и Y, чтобы решить A и B».
2. Определите North Star Metric — одну главную метрику успеха под ваш тип продукта и монетизацию.
3. Составьте tracking plan — список событий, свойств, владельцев и naming convention.
4. Выберите инструмент под бюджет и требования к локализации данных (152-ФЗ, импортозамещение).
5. Внедрите события через разработку — клиентский SDK или server-side tracking.
6. Постройте дашборды по ключевым воронкам, retention-когортам и unit-экономике.
7. Введите регулярный ревью — еженедельный или двухнедельный разбор метрик с продактом и командой с принятием конкретных решений по итогам.

Частые вопросы (FAQ)

Какие метрики мобильного приложения самые важные?

Если выбирать три — retention (Day-1/7/30), LTV и CAC. Они описывают, насколько продукт ценен для пользователей и окупается ли маркетинг. На конкретный продукт нужно дополнительно выбрать North Star Metric, которая лучше всего отражает созданную ценность — для e-commerce это завершённые покупки, для SaaS — еженедельно активные аккаунты.

Чем аналитика мобильного приложения отличается от веб-аналитики?

Три главных отличия: события вместо страниц (event-based модель), атрибуция установок через специальные инструменты (AppsFlyer, Adjust), соображения по приватности ATT на iOS. Мобильные приложения работают офлайн — события накапливаются и отправляются пачкой. Push-уведомления создают дополнительный канал возврата пользователей, которого нет в вебе.

Какие инструменты аналитики выбрать в России?

При требованиях 152-ФЗ — Yandex AppMetrica: бесплатная, хранит данные в РФ, поддерживает attribution, воронки и когорты. Для продуктовой аналитики без жёстких требований — Firebase GA4 (бесплатно) или Amplitude / Mixpanel (платные, с мощным когортным анализом). Зрелый вариант — AppMetrica для пользовательских данных плюс Amplitude через server-side для агрегированной аналитики.

Сколько стоит внедрить аналитику в приложение?

Стоимость зависит от объёма tracking plan и способа интеграции. Базовое внедрение SDK с 20–30 ключевыми событиями занимает 1–2 спринта разработки и не требует отдельного бюджета, если аналитика закладывается с самого начала. Server-side tracking с Data Warehouse — это отдельный инфраструктурный проект. Точную оценку даём после разбора требований на консультации.

Что такое retention Day-1/7/30?

Retention Day-N — процент пользователей, вернувшихся в приложение на N-й день после первой сессии. Day-1: норма 20–40% для большинства категорий. Day-7: 10–20% — хорошо. Day-30: кросс-индустриальный медиан около 5,4% по данным AppsFlyer; лидирующие продукты держат 20%+. Ниже медиана для вашей категории — сигнал к работе над онбордингом и ценностным предложением.