Основные метрики мобильного приложения: что считать и как улучшать
Основные метрики мобильного приложения — это короткий список чисел, по которым продуктовый менеджер за минуту понимает, работает ли продуктовая стратегия, окупаются ли рекламные кампании и насколько эффективно команда тратит время разработчиков. Статья пригодится продуктологам, владельцам бизнеса, фаундерам и тем, кто уже запустил приложение или только готовит релиз. Разберёмся, как определить свои ключевые метрики, не утонуть в аналитике и использовать цифры не «ради отчёта», а для конкретных действий по росту продукта.

Что считать «основными метриками мобильного приложения» и как их выбрать
Под основными метриками мобильного приложения будем понимать минимальный набор показателей эффективности, который отражает здоровье продукта: приходят ли новые пользователи, проходят ли они ключевые шаги, возвращаются ли, приносят ли доход. Это не полный каталог цифр из отчёта аналитики, а управленческая «приборная панель» проекта.
Логика выбора проста и при этом почти всегда игнорируется начинающими:
- цель продукта → ключевой вопрос → метрика → событие в аналитике
Пример 1. Цель: стабильный доход от подписки в фитнес‑приложении. Вопрос: пользователи возвращаются и видят value от тренингов? Метрика: retention по дням и неделям, процент активных пользователей, которые заходят хотя бы раз в неделю. События: первое открытие, просмотр тренировок, завершённые курсы.
Пример 2. Цель: частые заказы в e‑commerce. Вопрос: сколько пользователей доходит от экрана каталога до оплаты? Метрика: конверсия по шагам воронки (просмотр товара → корзина → ввод данных → оплата). События: add_to_cart, checkout_start, purchase.
Важно отличать vanity‑метрики от actionable. Vanity — это красиво, но мало что значит для решений: общее количество установок, лайки и отзывы в сторе без связи с поведением внутри приложения. Actionable‑метрики напрямую подсказывают действия: конверсия в первую покупку, доля активных пользователей нового релиза, churn платящих клиентов в течение первого месяца.
Практическая схема выбора для продукта:
- 1–2 метрики привлечения: количество установок, CPI/CAC, конверсия страницы в сторе в установку.
- 1–2 метрики активации: доля завершивших онбординг, время до первого целевого события (Time to Value).
- 1–2 метрики удержания и активности: retention, daily active users (DAU), monthly active users (MAU), соотношение DAU/MAU.
- 1–2 метрики монетизации: ARPU, LTV (lifetime value), конверсия в оплату или покупки.
- + 1–2 технические: процент crash‑free users, скорость старта.
Типичные ошибки:
- гнаться за количеством показателей и строить по 10 дашбордов «на всякий случай»;
- оценивать себя по средним цифрам из чужих статей, не учитывая нишу, политику цен и модель монетизации;
- считать только маркетинговые метрики (CPI, количество установивших) без связи с удержаниями и доходом.
Метрики воронки: от установки до выручки
Чтобы понять, где продукт «течёт», полезно разложить метрики по этапам воронки: привлечения, активации, удержания и монетизации. На каждом этапе свои ключевые показатели, и в разные периоды жизни проекта приоритеты могут меняться.
Привлечение и установка
На уровне маркетинга и рекламных кампаний обычно смотрят на:
- Install vs First Open — сколько людей установили приложение и сколько реально его открыли. Просто считать установки недостаточно: часть пользователей никогда не запускает приложение после загрузки.
- Конверсию из просмотров страницы приложения в сторе в установку (store conversion rate) — насколько хорошо страница и креативы «продают» ваш сервис.
- CPI и CAC per канал — цена установки и цена привлечения клиента из разных источников рекламы.
Продукту важно не только «сколько установили», а насколько эти users подходят аудитории. Если креативы обещают одно, а внутри другой контент и политика использования, пользователи быстро удаляют приложение. В аналитике это видно как высокий процент деинсталлов и низкий retention D1/D7. Пример: маркетологи нашли канал с очень низким CPI, но daily active через неделю почти ноль — такой трафик не должен считаться ключевым.
Активация и первый опыт
На этапе активации основное — довести новых пользователей до первого ощутимого value. Здесь критичны:
- доля, завершившая онбординг и дошедшая до ключевого действия (создание проекта в CRM, первый заказ еды, первая запись на курсы);
- Time to Value — время от первого открытия до первой значимой «победы» пользователя;
- конверсия из установки в регистрацию и создание профиля, если без этого пользоваться нельзя.
Если приложение сложное (B2B‑сервис, учёт финансов, CRM‑система), метрики активации часто важнее «голых» DAU. Микропример: улучшили сценарий онбординга, убрали один шаг регистрации — доля завершивших выросла с 40% до 65%, retention D7 поднялся на 7 процентных пунктов без увеличения бюджета на рекламу.
Удержание и вовлечённость
Retention показывает, какой процент пользователей возвращается приложение спустя N дней, недель или месяцев после установки. Чаще всего считают D1, D7, D30. Для игр критичны D1 и D7; для e‑commerce — D30 и повторные заказы в течение месяца; для подписки — удержания по неделям и месяцам, пока действует оплаченный период.
Вовлечённость оценивают через:
- DAU (daily active users) и MAU (monthly active users);
- коэффициент «липкости» — DAU/MAU, который рассчитывается по формуле: DAU, делённый на MAU, в процентах; высокий показатель значит, что активных пользователей много и они регулярно возвращаются;
- среднее (average) число сессий в день и среднюю длину сессии.
Важно понимать контекст. Для мессенджера высокое DAU/MAU и большое количество коротких сессий — норма. Для сервиса сложной аналитики бесконечные долгие сессии могут означать, что интерфейс запутан, а пользователю трудно понять, какие действия вести к результату.
Монетизация и ценность пользователя
Бизнес‑метрики отвечают на вопрос, насколько продукт окупает маркетинг и разработки:
- ARPU — средний доход per пользователь за период (обычно месяц);
- ARPPU — средний доход с платящего пользователя;
- LTV / lifetime value — сколько в среднем приносит один клиент за всё время использования продукта;
- конверсия в оплату или покупки, churn платящих пользователей;
- соотношение выручки от новых пользователей и тех, кто регулярно возвращается.
Частый вопрос: как оценить LTV без сложных моделей? Базовый подход: взять средний чек, умножить на среднее количество покупок за lifetime и вычесть возвраты. Со временем формула может усложняться, учитывать разные когорты и ценовые планы.
Для разных моделей ядро метрик будет отличаться:
- реклама в приложении — важны DAU, показов на пользователя, доход per 1000 показов;
- подписка — конверсия в триал, переход в платёж, churn по месяцам, LTV;
- игры с внутриигровыми покупками — доля платящих, средний чек, LTV платящих, поведение «китов»;
- B2B‑сервисы — количество активных аккаунтов, продления, LTV контрактов, влияние на доход клиентов.
Как понимать цифры: сегментация, когорты, бенчмарки
Среднее значение метрики по всем пользователям приложения редко даёт точный ответ, где проблема. Один и тот же общий retention может складываться из «золотых» и «токсичных» сегментов, и без сегментации вы этого не увидите.
Когортный подход подразумевает анализ групп пользователей, объединённых по какому‑то признаку: дате регистрации, источнику трафика, версии приложения. Например, общий retention D7 = 25%, но у когорты, пришедшей из последней рекламной кампании, — всего 10%, а у когорты с новым онбордингом — 35%. Когорты позволяют оценивать изменения продукта в динамике и честно измерять, насколько новый эксперимент действительно работает.
Минимальные сегментации, без которых метрики легко обманут:
- по каналам и кампаниям маркетинга — один канал может давать высокий DAU, но низкий LTV и плохое удержание;
- по устройствам и версиям ОС — рост крашей на старых устройствах сразу бьёт по удержанию и отзывам;
- по поведению: новые vs возвращающиеся пользователи, платящие vs неплатящие.
Вопрос, который часто задают: на какие бенчмарки ориентироваться по retention, DAU/MAU, ARPU? Универсального ответа нет: для игр, маркетплейсов, образовательных сервисов и CRM «нормальные» уровни сильно отличаются. Надёжнее выстраивать внутреннюю «политику бенчмарков»: фиксировать свои показатели, тестировать изменения и сравнивать себя с собой же полгода назад, а не с усреднёнными данными из разных ниш.
Практическая настройка: дашборды, алерты, эксперименты
Чтобы метрики работали каждый день, а не только в отчёте раз в квартал, необходимы удобные дашборды и система отслеживания изменений. Базовый ежедневный дашборд продукта — это 5–7 показателей на одном экране: по одной‑две метрики на каждый уровень воронки плюс технические. Например: установки и CAC, активация (Time to Value, онбординг), retention D1/D7, DAU/MAU, ARPU и crash‑free active users.
Хорошая практика — привязывать состав дашборда к целям спринта или квартала. Если сейчас задача — повысить удержание, в центр выносятся retention, метрики активности и события, на которые вы влияете: пуши, промо, контент. Если цель — протестировать новую цену подписки и политику скидок, фокус смещается на конверсию в оплату, средний чек и LTV новых когорт.
Алерты помогают реагировать до того, как проблемы попадут в негативные отзывы. Имеет смысл настроить уведомления при:
- падении retention D1 или D7 более чем на заданный процент;
- резком снижении конверсии на шаге оплаты;
- росте крашей или ANR у значимой доли активных пользователей.
Для проверки гипотез используйте A/B‑тесты: меняете онбординг, paywall, цены, контент — заранее определяете, какие метрики будут критерием успеха (например, DAU/MAU, конверсия в покупку, LTV за первый месяц). Список основных метрик — не догма; его стоит пересматривать при смене бизнес‑модели, выходе на новый рынок, крупном редизайне или изменении аудитории.
Если вы планируете запуск приложения, веб‑сервиса, CRM‑системы, игры или интернет‑магазина и хотите, чтобы аналитику не приходилось «прикручивать задним числом», можно обсудить проект с нашей командой. Мы поможем спроектировать продукт, настроить события, выбрать ключевые метрики, собрать дашборды и сделать так, чтобы цифры ежедневно подсказывали, какие действия принесут максимальный эффект.
