Проще всего аналитика превращается в ритуал: раз в неделю открыть дашборд, посмотреть на графики и закрыть вкладку до следующей недели. От этого продукт не меняется. Метрика приносит пользу, только когда за ней стоит вопрос, на который нужен ответ прямо сейчас: почему после обновления упала активация, стоит ли вкладывать бюджет в этот канал, какую функцию доделывать в первую очередь.
Поэтому разумно идти не от списка «модных» показателей, а от пути пользователя: на каждом шаге есть один-два вопроса, а метрика — способ получить измеримый ответ. Ниже — путь целиком, формулы для каждого показателя и граница, где заканчивается расчёт и начинаются домыслы про «нормальные» значения.
Путь пользователя и метрики на каждом шаге
Удобный каркас для разговора о метриках — модель AARRR (Acquisition, Activation, Retention, Referral, Revenue), которую в стартап-среде иногда называют «пиратскими метриками» по первым буквам английских слов. Это не стандарт, а способ не забыть ни один этап: привлечение, активация, удержание, рекомендации, монетизация. Дальше в статье используются русские названия этих же этапов.
| Этап | Ключевая метрика | На какой вопрос отвечает |
|---|---|---|
| Привлечение | Установки, конверсия карточки в сторе | Достаточно ли людей узнают о приложении и скачивают его |
| Активация | Доля дошедших до ключевого действия | Понимают ли новые пользователи, зачем нужно приложение |
| Удержание | Retention D1/D7/D30 | Возвращаются ли люди сами, без напоминаний |
| Активность | DAU, WAU, MAU, stickiness | Насколько часто приложением пользуются те, кто остался |
| Монетизация | ARPU, ARPPU, LTV, CAC | Окупается ли привлечение пользователей и растёт ли выручка |
| Рекомендации | Доля пользователей, приведших других | Советуют ли продукт без просьбы об этом |
Ни одна метрика не имеет смысла в отрыве от вопроса, который она обслуживает. Растущее число установок при падающей активации — не успех, а сигнал, что реклама приводит не ту аудиторию.
Установки и конверсия карточки в сторе
Первая развилка воронки — от показа карточки приложения до установки. App Store, Google Play и RuStore в консолях разработчика показывают этот путь минимум двумя числами: сколько раз карточку увидели и сколько раз после этого нажали «Установить». Отношение второго к первому — конверсия карточки: она показывает, насколько убедительны иконка и описание, а не то, насколько хорош сам продукт. Как улучшать карточку и выбирать каналы привлечения — в статье «Продвижение мобильного приложения и ASO».
У показателя «установки» есть источник — платный трафик, органический поиск в сторе, переходы по прямой ссылке, кросс-промо из других приложений. Разбивку по источникам стоит смотреть отдельно: канал с наибольшим числом установок не обязательно приводит пользователей, которые потом останутся и заплатят.
Число установок в консоли стора и число новых пользователей в аналитике почти никогда не совпадают день в день: сторы считают факт скачивания, аналитика — первый запуск с инициализированным SDK. Это разная механика подсчёта, а не ошибка инструментов — держите оба числа в голове, но не сводите их к одному.
Активация: момент, когда пользователь получает ценность
Установка ничего не говорит о том, понял ли человек, зачем открыл приложение. Активация — доля новых пользователей, дошедших до действия, после которого они на практике получили обещанную ценность, а не просто пролистали экраны.
Событие активации выбирают под конкретный продукт осознанно, а не оставляют «по умолчанию» первым экраном. Для сервиса записи к мастеру моментом ценности логично считать не открытие приложения и даже не просмотр списка мастеров, а подтверждённую запись — до этого пользователь ничего не получил, кроме интерфейса. Для трекера привычек это может быть первая отмеченная привычка через день после установки, а не сама регистрация.
Ориентир при выборе события активации — вопрос «что должно произойти, чтобы пользователь на своём опыте убедился: приложение решает его задачу?». Ответ «увидел список услуг» означает, что активация выбрана слишком рано и станет красивой, но бесполезной цифрой.
Удержание (retention): возвращаются ли люди сами
Retention — доля пользователей из определённой когорты (например, установивших приложение в один день), которые вернулись в приложение через заданный промежуток времени. Чаще всего смотрят на три точки:
- D1 — вернулись ли на следующий день (не оттолкнуло ли первое впечатление);
- D7 — вернулись ли через неделю (пережил ли интерес обычную рабочую неделю);
- D30 — вернулись ли через месяц (стало ли приложение привычкой).
У retention есть два способа счёта. Классический (classic) retention учитывает только тех, кто зашёл ровно в указанный день. Rolling retention учитывает всех, кто зашёл в этот день или позже, — поэтому он всегда даёт число не меньше, чем classic retention той же когорты, и их нельзя сравнивать напрямую. Сравнивая своё значение с чужим (статья, кейс, презентация подрядчика), стоит убедиться, что оба посчитаны одним способом.
Пример расчёта (условные цифры, не реальные данные). В понедельник приложение установили и открыли в первый раз 500 человек — это когорта D0. Через 7 дней в приложение вернулись 85 из них. D7 retention (classic) для этой когорты = 85 / 500 × 100% = 17%. Если бы считали rolling retention, в числитель попали бы и те, кто вернулся на 8-й, 9-й день и позже, — значение получилось бы выше.
Смотреть retention стоит по когортам (все, кто установил приложение в один день или неделю), а не «в среднем за месяц»: усреднённое число прячет и провальные, и удачные запуски конкретных версий. Полезна когортная таблица: по строкам — дата установки, по столбцам — день после установки, так видно, улучшается ли удержание от когорты к когорте после изменений в продукте.
Отдельная тема — «нормальный» retention. Единого порога не существует: он зависит от типа продукта (ежедневная задача и разовое обращение к специалисту несравнимы по одной шкале), частоты использования и аудитории. В статье нет цифр вида «хороший D7 — это N%»: такие ориентиры без источника создают ложное чувство единого эталона. Разумнее сравнивать метрику саму с собой во времени, чем с чужим нормативом.
DAU, WAU, MAU и stickiness
Если retention показывает, вернулся ли конкретный человек, то DAU/WAU/MAU показывают масштаб активности всей аудитории:
- DAU (Daily Active Users) — число уникальных пользователей, открывших приложение за день;
- WAU (Weekly Active Users) — за неделю;
- MAU (Monthly Active Users) — за 28 или 30 дней (период стоит фиксировать и не менять без пометки, иначе графики скачут не из-за продукта, а из-за смены методологии).
Отношение DAU к MAU называют stickiness («липкость»): DAU / MAU × 100% — какая доля месячной аудитории пользуется приложением в конкретный день. Чем ближе к ежедневному сценарию продукт (мессенджер, трекер шагов), тем выше можно ожидать stickiness; чем реже нужен продукт (запись к стоматологу, оформление визы), тем меньше смысла ждать высокого DAU/MAU — низкое значение здесь не сигнал проблемы, а следствие частоты сценария. Для таких продуктов осмысленнее WAU, MAU и retention на длинных интервалах (D30, D90).
Деньги: ARPU, ARPPU, конверсия в оплату, LTV, CAC
Эта группа метрик отвечает на вопрос, окупается ли привлечение и растёт ли выручка с человека со временем. Сами модели заработка и правила магазинов описаны в статье «Монетизация мобильного приложения».
| Метрика | Формула | Что показывает |
|---|---|---|
| ARPU (Average Revenue Per User) | Выручка за период / число активных пользователей за период | Средняя выручка на одного пользователя, включая тех, кто не платил |
| ARPPU (Average Revenue Per Paying User) | Выручка за период / число платящих пользователей за период | Средний чек только среди тех, кто заплатил |
| Конверсия в оплату | Число платящих / число активных пользователей × 100% | Доля аудитории, доходящая до покупки |
| LTV (Lifetime Value) | ARPU за период × средняя продолжительность «жизни» пользователя в этих периодах | Сколько в среднем приносит один пользователь за всё время использования |
| CAC (Customer Acquisition Cost) | Затраты на привлечение за период / число привлечённых пользователей за период | Сколько стоит привлечь одного пользователя |
Продолжительность «жизни» пользователя для LTV на практике часто оценивают через отток (churn): грубо как «1 / доля оттока за период». Это упрощённая модель, а не точный прогноз — она годится для сравнения каналов и версий продукта между собой, но не как гарантия конкретной суммы.
Пример расчёта (условные цифры). ARPU приложения за месяц — 120 ₽, ежемесячный отток — 20%. Условная продолжительность «жизни» ≈ 1 / 0,2 = 5 месяцев, LTV ≈ 120 ₽ × 5 = 600 ₽. Если CAC по каналу — 450 ₽, отношение LTV к CAC (≈ 1,33) удобно использовать для сравнения каналов привлечения между собой, а не как абсолютный показатель прибыльности бизнеса.
Срок окупаемости (payback period) — за сколько периодов накопленная выручка с пользователя покрывает CAC. Он важен отдельно от LTV: даже продукт с хорошим LTV может испытывать кассовые разрывы, если окупаемость растянута на месяцы, а платить за рекламу нужно сейчас.
Для приложений, которые обслуживают офлайн-бизнес — доставку, запись к специалисту, услуги, — монетизацию считают иначе: не ARPU внутри приложения, а выручку через заказы из приложения и долю заказов, оформленных именно через него, а не по телефону. Это те же деньги бизнеса, но метрика показывает, окупает ли себя мобильный канал.
Качество и стабильность: не только про деньги и вовлечённость
Плохая стабильность искажает все метрики выше: если приложение падает или зависает, пользователь уходит не потому, что продукт ему не нужен, а потому что не смог им воспользоваться. Качество стоит отслеживать отдельно, а не выводить из падения активности постфактум.
- Crash-free users / crash-free sessions — доля пользователей (или сессий) без единого сбоя за период. Считается через SDK крэш-репортинга, встроенный в консоли сторов, или отдельные сервисы того же назначения.
- ANR (Application Not Responding) — на Android это когда приложение не отвечает на действия пользователя дольше определённого системой времени (например, ввод не обрабатывается 5 секунд), и система предлагает закрыть приложение.
- Время запуска (cold start) — сколько проходит от нажатия на иконку до готового экрана.
- Рейтинг и отзывы в сторе — отложенный, но заметный сигнал о качестве, на который влияют и ответы поддержки на негативные отзывы.
По документации Android vitals в Google Play Console заданы пороги «плохого поведения» (bad behavior thresholds), при превышении которых приложение хуже показывается в сторе: для пользовательских сбоев — от 1,09% дневных активных пользователей по всем моделям устройств или от 8% на одной модели; для ANR — от 0,47% по всем моделям или также от 8% на одной. Превышение общего порога снижает заметность во всём сторе, по модели — только на её устройствах, вплоть до предупреждения в карточке. Google может пересматривать значения, стоит сверяться с актуальной страницей Android vitals.
У App Store и RuStore похожая логика отслеживания сбоев есть в своих консолях, но публичных числовых порогов, аналогичных Android vitals, они так же явно не публикуют — для iOS и RuStore разумнее следить за трендом собственного crash-free показателя, а не искать готовый норматив.
Как настроить аналитику
Метрики выше не появляются сами — их считают из событий (events), которые отправляет приложение. Основа настройки — план событий (tracking plan): список того, что фиксируется, с какими параметрами и зачем. Его стоит составить до начала разработки экранов, а не восстанавливать по памяти перед первым отчётом.
| Событие | Когда срабатывает | Параметры |
|---|---|---|
| app_open | Каждый запуск приложения | источник открытия (push, органика, диплинк) |
| service_selected | Выбор услуги в каталоге | id услуги, категория |
| master_time_selected | Выбор мастера и времени | id мастера, дата и время слота |
| booking_confirmed | Подтверждение записи — событие активации | id записи, id услуги, стоимость |
| booking_cancelled | Отмена записи пользователем | id записи, причина (если указана) |
| reminder_push_opened | Открытие приложения по напоминанию о записи | id записи, время до визита |
Для учёта событий и отчётов по ним применяют инструменты нескольких категорий, а не один универсальный сервис:
- встроенные консоли магазинов — Android vitals в Google Play Console, аналитика App Store Connect, кабинет RuStore: бесплатны, но ограничены техническими метриками и данными, которые видит сам стор;
- системы продуктовой аналитики — считают воронки, retention, когорты по событиям приложения; в России распространена, в частности, AppMetrica, но выбор сервиса стоит делать под свои требования к хранению данных, а не по умолчанию;
- сервисы крэш-репортинга — отдельно фиксируют сбои и ANR с трассировкой стека, часто отдельным SDK от продуктовой аналитики.
Почти любое такое событие связано с идентификатором пользователя, а значит подпадает под правила работы с персональными данными: нужно согласие на аналитику, отдельное от согласия на использование приложения, и понимание, куда передаются данные каждого SDK — подробнее в статье «Персональные данные в мобильном приложении».
Как принимать решения по метрикам
Дашборд с двадцатью графиками сам по себе не подсказывает, что делать дальше. Несколько практик, которые превращают цифры в решения.
- Одна North Star Metric. Метрика, которая лучше всего отражает ценность для пользователя и одновременно связана с ростом бизнеса — например, число завершённых записей в месяц, а не число установок.
- Одна главная метрика на этап продукта. На ранней стадии важнее активация, чем LTV — если люди не доходят до ценности, разговор про монетизацию преждевременный.
- A/B-тесты — с оглядкой на размер аудитории. Надёжный результат нужен на достаточном числе пользователей в группе и достаточном времени наблюдения; при небольшом DAU тест месяцами может не набрать значимой разницы — это нормальный итог, а не повод тянуть эксперимент, пока не «получится».
Типичные ловушки, из-за которых метрики врут не по вине инструментов, а по вине интерпретации:
- Метрики тщеславия (vanity metrics). Растущее число установок ничего не говорит о продукте, если следом не смотреть активацию и удержание той же аудитории.
- Средние значения вместо когорт. «Средний retention за квартал» смешивает удачные и провальные периоды и скрывает момент, когда что-то реально изменилось.
- Изменение событий без версионирования. Переименовали событие активации или изменили параметр без пометки версии — графики «до» и «после» стали несравнимыми, а разница выглядит как смена поведения пользователей.
Частые вопросы
Какие 3–5 метрик смотреть в первый месяц после запуска?
Разумный минимум: установки с разбивкой по источникам, доля активированных пользователей, D1 и D7 retention, crash-free users. Этого достаточно, чтобы увидеть, доходят ли люди до ценности продукта и не мешает ли этому нестабильность, — денежные метрики на этом этапе обычно преждевременны.
У меня retention 15% на седьмой день — это хорошо?
Однозначного ответа без контекста нет: многое зависит от типа продукта, частоты обращения к нему и способа подсчёта (classic или rolling). Осмысленнее сравнивать число с retention своих же прошлых когорт после изменений в продукте, чем искать общий норматив «для мобильных приложений» — единого проверяемого норматива для всех категорий не существует.
Чем DAU отличается от числа сессий?
DAU считает уникальных пользователей за день: человек, открывший приложение десять раз, даст 1 в DAU. Число сессий считает каждый заход отдельно и покажет 10. DAU — про охват аудитории, сессии — про интенсивность использования внутри дня.
Нужна ли аналитика уже в MVP?
Да, минимальный набор событий (открытие приложения, начало и завершение основного сценария) нужен с первой версии — иначе не из чего будет посчитать, подтвердилась ли гипотеза. Подробнее — в статье «MVP мобильного приложения».
Почему число установок в консоли стора не совпадает с числом пользователей в аналитике?
Сторы считают факт скачивания, а система продуктовой аналитики — первый запуск с инициализированным SDK; между этими событиями может пройти время, а может не произойти вовсе, если приложение не открыли после установки. Это нормальное следствие разной методологии подсчёта, а не ошибка одного из инструментов.
Как считать LTV, если приложение бесплатное и без покупок?
Если выручки внутри приложения нет, а монетизация — реклама или продажи через офлайн-канал (доставка без встроенной оплаты), классический денежный LTV напрямую не посчитать. Его заменяют выручкой бизнеса от заказов из приложения или рекламным доходом на пользователя — смотря как продукт зарабатывает.
Аналитика готова к запуску, если…
- определено событие активации — конкретное действие, а не открытие приложения;
- план событий составлен и согласован до начала разработки экранов, а не восстанавливается задним числом;
- подключены крэш-репортинг и мониторинг ANR, а не только продуктовая аналитика;
- retention и активность считаются по когортам, а не только «в среднем за период»;
- для денежных метрик определено, что именно считается выручкой (внутри приложения или через заказы из него);
- есть отдельное согласие пользователя на аналитику и понимание, куда передают данные подключённые SDK;
- выбрана одна North Star Metric и одна главная метрика для текущего этапа продукта.
Итог
Метрики мобильного приложения складываются в понятную последовательность: от установки — к активации, от активации — к удержанию, от удержания — к деньгам, а качество работы влияет на каждый из этих шагов одновременно. Универсального набора «правильных» цифр нет — есть вопросы, которые ставит перед собой команда, и метрики, дающие на них честный, проверяемый ответ.
Практический ориентир: начинать с малого набора показателей, привязанных к текущему этапу — сначала активация и стабильность, потом удержание, и только затем монетизация, — и наращивать план событий по мере новых вопросов, а не собирать сразу всё без плана, что с этим делать. Как поддерживать показатели после релиза — в статье «Поддержка мобильного приложения после релиза», а требования к аналитике стоит заранее зафиксировать в техническом задании на приложение. На сроки первой публикации влияют и технические проверки платформ, включая стабильность, — подробнее в статье «Публикация приложения в RuStore, App Store и Google Play».