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

Приложение выпустили, установки растут, отчёты в сторах выглядят прилично — а выручка не меняется. Знакомая картина: команда смотрит на установки и рейтинг, тогда как деньги лежат в трёх метриках, которых в стандартном отчёте нет. Аналитика мобильного приложения начинается не с дашборда, а с решения, которое вы собираетесь принять по цифрам.

Разберём продуктовые метрики, которые действительно влияют на выручку: удержание по когортам, конверсию в ключевое действие, стоимость привлечения платящего пользователя и техническое качество. С ценами на 2026 год, составом работ и набором событий, который можно внедрить за две недели.

Ключевые выводы

• Продуктовая аналитика мобильного приложения стоит 250–700 тыс. ₽ на старте и 40–120 тыс. ₽ в месяц на поддержку и разбор данных.
• Retention на 7-й день ниже 15% означает, что проблема в продукте, а не в рекламе: увеличение бюджета только ускорит потери.
• Полный набор событий для типового приложения — 40–80 штук, из них для решений хватает 12–15.
• Стоимость привлечения платящего пользователя в 2026 году: 800–2 500 ₽ в тематике услуг, 400–1 200 ₽ в ритейле; окупается, если LTV выше в 3 раза.
• Ошибки в аналитике стоят дороже отсутствия аналитики: цифры, которым не верят, игнорируют полностью.
• BI аналитика на биллинговых данных и продуктовая аналитика в приложении — разные контуры, их нельзя смешивать в одном отчёте.

Три уровня метрик: продукт, деньги, техника

Следите за тремя группами — продукт (что делают люди), деньги (что они приносят) и техника (не мешает ли им приложение). Метрики одного уровня без двух других дают ложную картину.

Продуктовые метрики отвечают на вопрос, возвращаются ли пользователи и доходят ли до ценности. Метрики монетизации показывают, сколько стоит привлечение и сколько приносит один пользователь. Технические метрики — не мешает ли приложение пользоваться: время запуска, доля падений, скорость ключевых экранов.

Когорты вместо средних

Средние по всей базе скрывают провалы. Если у вас 10 000 пользователей и удержание 20%, это может быть 45% у одной когорты и 6% у другой — например, у привлечённых из одного канала. Стройте отчёт по когортам: неделя установки, источник, платформа, версия приложения. Обычно именно версия объясняет падение — релиз выкатили, часть аудитории обновилась, и метрика просела.

Как настроить сбор данных: события, свойства, срезы

Составьте список решений, которые хотите принимать, и под каждое заведите событие. Не наоборот. Практика «залогируем всё, потом разберёмся» приводит к 300 событиям, из которых используют 10.

Порядок работ для типового приложения:

1. Сформулируйте 8–12 вопросов к данным: где отваливаются в регистрации, кто доходит до оплаты, что делают вернувшиеся.
2. Составьте карту событий: имя, момент отправки, обязательные свойства (ID пользователя, экран, версия, источник).
3. Определите ключевое действие — то, ради чего приложение установили: заказ, запись, платёж, отправка заявки.
4. Настройте воронки и сквозную аналитику по шагам от установки до платежа.
5. Подключите события к рекламным кабинетам, чтобы считать окупаемость по каналам, а не только установки.
6. Соберите дашборд на 12–15 показателей и не добавляйте туда ничего «на всякий случай».

Технически это Firebase, AppsFlyer и Яндекс Метрика для приложений как базовый набор, а для собственных данных — события в PostgreSQL и витрины. Купить мобильного приложения с уже готовой аналитикой почти не встречается: сборку под чужие процессы приходится переписывать под свои события. Создать мобильного приложения без этапа аналитики — значит получить продукт, который нельзя улучшать. Разработка мобильного приложения в этом смысле не отличается от веба: сбор событий проектируется на этапе архитектуры, а не после релиза.

Сколько стоит и сколько занимает

Настройка аналитики в готовом приложении — 250–450 тыс. ₽ и 3–4 недели, если структура событий простая. Полный контур с витринами, склейкой с CRM и отчётами по каналам — 400–700 тыс. ₽ и 5–8 недель. Дальше поддержка: 40–120 тыс. ₽ в месяц в зависимости от числа отчётов и того, кто разбирает данные — подрядчик или ваш аналитик.

Настройка мобильного приложения: гипотезы и A/B-тесты

Аналитика без тестов превращается в дорогой отчёт. Настроенное мобильное приложение позволяет проверять по одной гипотезе за раз и получать ответ за 2–4 недели.

Как считают: для роста целевой метрики на 10% с базовым уровнем 20% нужно 2 000–4 000 пользователей в каждой группе. При трафике 300 человек в день тест идёт три недели — не запускайте десять тестов одновременно, они перемешают эффекты и вы не поймёте, что сработало.

Список гипотез, которые чаще других дают результат:

• Сокращение пути до ключевого действия на один шаг.
• Отложенная регистрация: сначала ценность, потом аккаунт.
• Другой момент показа paywall — после первого успешного действия, а не при входе.
• Напоминание в нужный час, а не в 10:00 для всех.
• Настройка мобильного приложения под слабые устройства: облегчённый главный экран и кеш изображений.

Что делать, если трафика мало

При базе меньше 1 000 активных пользователей статистика не наберётся, и A/B-тесты бессмысленны. Работайте качественно: 8–12 интервью с пользователями, запись экрана в тестах юзабилити (5 человек дают 80% проблем), анализ падений и отвалов в воронке. Это дешевле тестов — 60–150 тыс. ₽ за раунд — и на малых числах надёжнее. Заодно проверьте, нет ли в приложении функций, которые никто не открывает: приложения где ИИ поставлен ради ИИ, — типичный кандидат на удаление, а вместе с ним уходит лишний вес сборки и расходы на модель.

Метрики маркетплейсов и продуктовая аналитика: в чём разница

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

Если вы продаёте и через приложение, и через Wildberries с Ozon, сведите оба контура в одну витрину хотя бы по выручке на пользователя — иначе решения будут противоречить друг другу. Схема такой сборки — создание мобильного приложения, дашборда и витрин в одном контуре — разобрана в материалах создание дашбордов и BI-аналитика.

Частые вопросы

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

Первичная настройка событий, воронок и дашборда — 250–450 тыс. ₽ и 3–4 недели работы. Расширенный контур с витринами и интеграцией с CRM — 400–700 тыс. ₽. Поддержка и разбор данных — 40–120 тыс. ₽ в месяц.

Какие метрики смотреть в первую очередь?

Удержание на 1, 7 и 30 день, конверсию в ключевое действие, LTV к CAC и долю сессий без падений. Эти пять метрик отвечают на вопрос, живёт продукт или нет. Остальные уточняют причину.

Нужен ли отдельный аналитик в команде?

На старте — нет: 3–6 часов в неделю аналитика подрядчика или продакта закрывают потребность. Аналитик на 0,5 ставки нужен, когда событий больше 60, отчётов больше десяти и вы принимаете решения по данным каждую неделю.

Можно ли считать аналитику только по отчётам сторов?

Нет. Google Play и App Store дают установки, удаления и доход по подпискам, но не показывают поведение внутри приложения. Без событий вы не узнаете, на каком шаге теряются пользователи и почему падает удержание.

Как часто нужно пересматривать набор метрик?

Раз в квартал и после каждого крупного релиза. Продукт меняется: метрика, которая была ключевой полгода назад, может стать бесполезной. Удаляйте из дашборда то, по чему не принимали решений три месяца.

Что делать дальше

Определите три решения, которые примете в следующем квартале: например, оставить или закрыть канал привлечения, менять или нет paywall, вкладываться ли в удержание. Под эти решения выпишите метрики и события. Это одна страница, но она экономит месяцы работы с бесполезными отчётами.

Отдельно проверьте, хватает ли пользователям уведомлений: возврат в приложение напоминанием часто даёт тот же эффект, что доработка продукта, и стоит дешевле. Механика описана в статье push-уведомления.

Дальше — настройка событий, воронки и дашборда: 3–4 недели и 250–450 тыс. ₽. Вести разработку мобильного приложения вместе с аналитикой выгоднее сразу, чем достраивать данные после запуска, — сборка событий закладывается в архитектуру, а не прикручивается сверху. Команда, которая закрывает и код, и данные, описана на странице разработка приложений.

Статья основана на практике проектов НейроДела и данных Яндекс Вордстата по кластеру «Разработка приложений». Основной запрос материала — «аналитика мобильного приложения» (892 показов в месяц). Если у вас другая ситуация — напишите, разберём.