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

Короткий ответ: владельцу приложения хватает семи метрик — установки по источникам, активация, удержание D1/D7/D30, DAU/MAU, воронка до целевого действия, доля пользователей без сбоев и сами целевые действия в штуках. Чтобы их считать, список событий нужно заложить в ТЗ до разработки, выбрать одну основную систему аналитики — например, AppMetrica или Firebase — и заранее решить вопрос с персональными данными. Ниже — что значит каждая метрика, пример плана событий и ошибки, из-за которых цифры потом нельзя использовать.

Статья — про аналитику внутри мобильного приложения. Цели и заявки на сайте устроены иначе: их разбирали в статье о целях Яндекс Метрики. Факты о платформах сверены с документацией Apple, Google, Firebase и AppMetrica на 30 октября 2026 года.

Зачем аналитика, если есть отчёт магазина?

Магазины показывают, что происходит вокруг приложения: просмотры карточки, загрузки, оценки, сбои. Что человек делает внутри — какой экран открыл, где бросил оформление заказа, вернулся ли через неделю к нужной функции — они не видят. Это знает только код приложения, если в нём есть события.

У отчётов магазинов есть и ограничения по полноте. В App Store Connect данные об использовании приходят только от пользователей, которые согласились делиться диагностикой и данными об использовании с разработчиками, — так прямо написано в справке App Store Connect Analytics. Сессией там считается использование приложения не короче двух секунд. То есть сессии и активные устройства в консоли Apple — это выборка, а не все пользователи.

Google Play Console сильна в другом: раздел Android vitals считает долю сбоев и зависаний (ANR), которые заметил пользователь, и сравнивает их с порогами Google. Об этом — ниже, в разделе о сбоях. Итог простой: отчёты магазинов смотрим всегда, но вопросы бизнеса — «почему мало заказов из приложения» — они не закрывают.

Какие 7 метрик смотреть каждую неделю?

Установки по источникам, активация, удержание D1/D7/D30, DAU/MAU, конверсия воронки, доля пользователей без сбоев и целевые действия в штуках. Первые пять отвечают на вопрос «нужно ли приложение людям», шестая — «не мешают ли им ошибки», седьмая — «приносит ли оно деньги».

Десятки графиков в системе аналитики — для разбора конкретного вопроса, когда одна из семи цифр поехала вниз. Порядок чтения такой:

1. Целевые действия. Заказы, записи, оплаты из приложения за неделю. Берём их с сервера, а не только из аналитики: сервер знает, какая запись реально создана и оплачена.
2. Установки по источникам. Если целевых действий меньше, сначала смотрим, не просел ли приток людей и из какого канала.
3. Активация. Ключевое действие вы определяете сами: для магазина — добавление в корзину, для записи — выбор услуги, для приложения сотрудников — первый отправленный отчёт.
4. Воронка. Если люди приходят, но не доходят до цели, воронка покажет экран, на котором они уходят.
5. Удержание и DAU/MAU. Медленные метрики: их смотрим по когортам раз в неделю, а выводы делаем за месяц.
6. Пользователи без сбоев. Резкое падение после релиза — сигнал откатывать или срочно выпускать исправление.

Метрика	Как считается	Что показывает
Установки по источникам	Новые установки за неделю в разрезе: поиск в магазине, реклама, сайт, QR-код в точке	Какой канал приводит людей и сколько стоит каждый
Активация	Доля новых пользователей, сделавших ключевое действие в первые сутки	Понятно ли приложение с первого запуска
Удержание D1 / D7 / D30	Доля когорты установок, открывшей приложение на 1-й, 7-й и 30-й день	Возвращаются ли люди, нужна ли им вещь
DAU / MAU	Уникальные пользователи за день и за 30 дней; их отношение	Насколько приложение вошло в привычку
Воронка до целевого действия	Доля дошедших от первого шага до заказа, записи, оплаты	На каком экране теряются люди
Пользователи без сбоев	Доля активных пользователей, у которых приложение ни разу не упало	Не уходят ли люди из-за ошибок
Целевые действия в штуках	Заказы, записи, оплаты из приложения за неделю — по данным сервера	Зарабатывает ли приложение вообще

Как читать удержание и DAU/MAU без ошибок?

Удержание считают по когортам — группам людей, установивших приложение в один день или неделю. D7 = 20 % значит, что из всех установивших в понедельник пятая часть открыла приложение на седьмой день. DAU/MAU — доля месячной аудитории, которая заходит ежедневно.

Пример на условных цифрах. За неделю 1 000 установок; на следующий день вернулись 350 человек — D1 35 %; на седьмой день — 180, D7 18 %; на тридцатый — 90, D30 9 %. В день приложением пользуются 400 человек, за 30 дней — 2 500: DAU/MAU = 16 %, то есть обычный пользователь открывает приложение примерно раз в шесть дней.

Три правила, которые уберегут от неверных выводов:

• Не сравнивайте себя с чужими «нормами». Универсальных нормативов удержания нет: приложению такси не нужно ежедневное открытие, а приложению учёта смен — нужно. Сравнивайте когорту этого месяца с когортой прошлого.
• Учитывайте естественный ритм. Если клиент стрижётся раз в месяц, D7 у приложения записи будет низким, и это нормально. Важнее, вернулся ли он к следующей записи.
• Смотрите на когорты после изменений. Новый онбординг вышел 1-го числа — сравнивайте установивших до и после, а не общую среднюю за квартал.

Что такое доля пользователей без сбоев и какие пороги у Google?

Это процент пользователей, у которых за выбранный период приложение ни разу не упало. Так её определяет документация Firebase Crashlytics; аналогичный отчёт о сбоях есть в AppMetrica. У Google Play свои пороги, после которых магазин может снизить видимость приложения.

По странице Android vitals «плохое поведение» начинается, когда в среднем по устройствам сбои замечают больше 1,09 % пользователей в день, а зависания (ANR) — больше 0,47 %. Для отдельной модели телефона порог — 8 % по обоим показателям. Google оценивает качество по данным последних 28 дней.

Для владельца отсюда практический вывод: долю пользователей без сбоев стоит видеть рядом с бизнес-метриками, а не только в консоли разработчика. Как устроена работа со сбоями после запуска и кто за неё отвечает, мы описали в статье о поддержке мобильного приложения.

Какие события заложить в ТЗ до разработки?

События под каждую из семи метрик: первый запуск и онбординг, регистрация, ключевое действие активации, каждый шаг воронки до целевого действия, само целевое действие, отмена или возврат, открытие push-уведомления. Для каждого в ТЗ пишут название, момент срабатывания и параметры.

Удобный формат — таблица «план событий» отдельным разделом ТЗ. Она занимает страницу, но избавляет от главной беды: через три месяца после запуска выясняется, что шаг «выбор времени» не размечен, и воронку построить нельзя. Добавить событие задним числом можно только новым релизом, а данные за прошедшие месяцы уже не появятся. Как в целом описать экраны и сценарии, разобрано в статье о ТЗ на мобильное приложение.

Ниже — пример плана для приложения записи на услуги: салона, клиники, автосервиса. Для магазина шаги воронки будут другими — карточка товара, корзина, оформление, оплата, — но принцип тот же.

Событие	Когда срабатывает	Параметры	Для какой метрики
onboarding_done	Пользователь прошёл приветственные экраны	шаг, на котором закрыл (если пропустил)	Активация
sign_up	Аккаунт создан	способ входа	Воронка, активация
service_view	Открыта карточка услуги	id услуги, категория	Воронка
slot_selected	Выбрано время	id услуги, через сколько дней запись	Воронка
booking_created	Запись подтверждена сервером	id услуги, сумма, способ оплаты	Целевое действие
booking_cancelled	Запись отменена	кто отменил, за сколько часов	Качество сервиса
push_opened	Открыто push-уведомление	тип рассылки	Возврат пользователей

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

Одно имя события на iOS и Android, названия латиницей в одном стиле, целевые действия — по подтверждению сервера, а не по нажатию кнопки, и никаких телефонов и email в параметрах. Плюс укладываться в лимиты системы: у Firebase, например, они жёсткие.

• Единый словарь. Если на iOS событие называется «booking_created», а на Android — «BookingDone», в отчётах будет два разных события. Словарь событий живёт в ТЗ, и обе платформы берут имена оттуда.
• Лимиты. По справке Firebase у приложения может быть до 500 разных названий событий на пользователя (автоматически собираемые события не в счёт), название — не длиннее 40 знаков, у события — до 25 параметров, пользовательских свойств — до 25. Если делать отдельное событие на каждую кнопку, лимит заканчивается быстрее, чем кажется.
• Цель — по серверу. Нажатие «Оплатить» ещё не оплата. Событие целевого действия отправляем после ответа сервера, а итоговые цифры сверяем с базой заказов. AppMetrica, например, умеет принимать события и с сервера через Post API — это описано в её документации.
• Без персональных данных в параметрах. Вместо телефона — внутренний id пользователя, вместо адреса — район или город, если он вообще нужен.
• Версия приложения в каждом отчёте. Системы аналитики обычно передают её сами; важно не сломать это при сборке, иначе нельзя сравнить поведение до и после релиза.
• Проверка при приёмке. Перед релизом проходим сценарии на тестовом устройстве и смотрим, что каждое событие из плана пришло с правильными параметрами. Этот пункт стоит добавить в чек-лист приёмки.

Чем считать: системы аналитики и их ограничения

Для большинства приложений достаточно одной системы аналитики в коде, отчётов магазинов и данных своего сервера. Чаще всего выбирают между AppMetrica и Firebase: обе считают события, удержание, воронки и сбои. Две системы с одинаковой задачей подключать не стоит — цифры будут расходиться, а SDK в сборке станет больше.

• AppMetrica. По документации — события, в том числе электронная коммерция и покупки в приложении, отчёты по аудитории, удержанию и воронкам, статистика сбоев, отслеживание источников установок, push-кампании по когортам и эксперименты. Условия и лимиты использования смотрите на сайте сервиса на дату подключения.
• Firebase. Google Analytics для приложений и Crashlytics на странице тарифов Firebase отмечены как бесплатные на обоих тарифах, Spark и Blaze. Ограничения — лимиты событий, описанные выше, и то, что данные обрабатываются на инфраструктуре Google.
• Отчёты магазинов. App Store Connect и Google Play Console — установки, просмотры карточки, оценки, стабильность. Ставить ничего не нужно.
• Свой сервер. Заказы, оплаты, отмены, выручка. Это главный источник для седьмой метрики: о возвратах и ручных отменах точнее всего знает ваша база.

Если приложение уже использует Firebase для push-уведомлений на Android, это частый довод в его пользу. Если нужен трекинг источников установок в российском сервисе с документацией на русском, чаще смотрят на AppMetrica. Где обрабатываются данные, уточняйте по условиям системы. Окончательный выбор стоит делать вместе с юристом по персональным данным — об этом следующий раздел.

Аналитика и персональные данные

Аналитика собирает идентификаторы устройства, IP-адрес, модель телефона и действия человека. Это нужно указать в анкетах о данных App Store и Google Play, в политике конфиденциальности и учесть по 152-ФЗ. Если сервер системы за границей, это трансграничная передача данных.

Подробно требования магазинов и закона мы разобрали в статье о персональных данных в мобильном приложении. Здесь — только то, что касается аналитики:

• SDK аналитики — ваша ответственность. Данные, которые собирает библиотека аналитики или отчёта о сбоях, магазины считают данными вашего приложения, их указывают в анкетах.
• Рекламный идентификатор на iOS. Доступ к нему требует разрешения пользователя через запрос App Tracking Transparency. Если рекламный трекинг не нужен, проще отключить сбор идентификатора в настройках SDK.
• Трансграничная передача. Порядок описан в статье 12 Закона 152-ФЗ. Статья менялась, поэтому актуальную редакцию и необходимость уведомлений сверяет юрист до подключения системы.
• Минимум данных. Чем меньше лишних параметров в событиях, тем короче анкеты и проще политика. Имя, телефон и email в аналитику не отправляем вообще.

Мы не юристы: разработчик отвечает за то, чтобы приложение технически делало то, что написано в политике, а текст политики и уведомления готовит юрист.

Что входит в аналитику при разработке у Roboweb.team?

В тариф мобильного приложения от 200 000 ₽ входят push-уведомления и базовая аналитика, а доступы ко всем сервисам — Firebase, платежам, аналитике — передаём вам. Расширенный план событий под сложную воронку оцениваем после брифа.

Состав тарифа — на странице разработки мобильных приложений и в прайсе. Что важно знать заранее:

• Аккаунты систем аналитики оформляются на вашу компанию, а не на студию: это ваши данные, и они не должны зависеть от подрядчика.
• Платные сторонние сервисы, в том числе аналитика, если выбран платный тариф, оплачиваются вами напрямую и в цену разработки не входят.
• После публикации 14 дней бесплатно исправляем мелкие недочёты, в том числе в разметке событий. Дальше доработки аналитики — в рамках поддержки от 7 900 ₽ в месяц или почасово.
• Гарантия по договору — 30 календарных дней с даты акта, отдельно от поддержки: если событие из согласованного плана не отправляется по нашей вине, исправляем бесплатно.

Когда подробная аналитика не нужна?

Если приложение внутреннее и им пользуются двадцать сотрудников, если это прототип для проверки идеи на нескольких клиентах или если все действия и так видны в базе. Тогда хватит отчётов магазина, отчёта о сбоях и выгрузки с сервера.

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

Типичные ошибки

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

1. Нет плана событий в ТЗ. Разработчики размечают то, что сочли нужным, и воронку до оплаты потом не собрать без нового релиза.
2. Разные названия на iOS и Android. Отчёты по платформам не складываются, сравнивать их приходится вручную.
3. Целевое действие — по нажатию кнопки. В аналитике 120 оплат, в базе — 95: часть платежей не прошла, а отчёт рисует картину красивее реальной.
4. Две системы для одного и того же. Цифры расходятся на десятки процентов из-за разных правил подсчёта, и команда спорит, какой верить.
5. Персональные данные в параметрах. Телефон или email в событии — лишняя передача данных стороннему сервису и вопрос к анкетам магазинов.
6. Аккаунт аналитики на подрядчике. При смене разработчика история данных остаётся у него. Доступы оформляйте на компанию с первого дня.
7. Смотрят «всё время» вместо когорт. Средние за год скрывают, что последний релиз ухудшил удержание.

Чек-лист владельца перед разработкой

Перед стартом достаточно ответить на шесть вопросов и вписать ответы в ТЗ. На это уходит один созвон с разработчиком.

• Какое целевое действие приносит деньги и как сервер его подтверждает?
• Какое действие считаем активацией нового пользователя?
• Из каких шагов состоит воронка до целевого действия?
• Какая система аналитики основная и на чей аккаунт она оформлена?
• Какие данные уходят в аналитику, где их сервер и что об этом сказано в политике конфиденциальности?
• Кто и когда смотрит семь метрик и что делает, если одна из них падает?

Короткие ответы на частые вопросы

Что такое DAU и MAU в приложении?

DAU — число уникальных пользователей, открывших приложение за день, MAU — за 30 дней. Их отношение показывает, какую долю месячной аудитории вы видите каждый день: чем оно выше, тем прочнее привычка.

Что такое удержание D1, D7 и D30?

Это доля людей из одной группы установок, которые снова открыли приложение на первый, седьмой и тридцатый день после установки. Сравнивать удержание стоит между своими когортами, а не с чужими «нормами».

Что выбрать: AppMetrica или Firebase?

Обе системы считают события, удержание, воронки и сбои. Выбор чаще решают вопросы данных и интеграций: где хранятся данные, какой рекламный трекинг нужен, есть ли уже Firebase для push. Одну систему делают основной, вторую ставят только под конкретную задачу.

Хватит ли отчётов App Store Connect и Google Play Console?

Для числа установок, оценок и стабильности — да. Что происходит внутри приложения, на каком экране люди бросают заказ, магазины не покажут: для этого нужны события в коде.

Можно ли добавить аналитику в уже работающее приложение?

Да, но это отдельный релиз через проверку магазинов, а историю до него восстановить нельзя. Поэтому план событий дешевле заложить в ТЗ до разработки.

Услуги и кейсы по теме: мобильные приложения · поддержка сайта от 7 900 ₽/мес · цены и сроки