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

Минимальный набор аналитики, который нужно заложить в мобильное приложение до релиза, - это 12-15 событий: открытие приложения, прохождение онбординга, регистрация и вход, просмотр ключевого экрана, добавление в корзину или заявка, оплата или отправка формы, разрешение на пуши, поиск, ошибка и сбой. К каждому событию обязательно передаются версия приложения, платформа, источник установки и идентификатор пользователя в вашей системе. Если этого нет в первой версии, после релиза вы будете видеть только количество установок и ничего не узнаете о том, где люди отваливаются. Актуально на октябрь 2026 года.

По опыту Honey Hunters Digital аналитику в приложении почти всегда вспоминают в последнюю неделю перед отправкой в стор, когда функционал готов и бюджет закончился. Итог предсказуем: в первой версии стоит один SDK с автоматическими событиями, экраны не размечены, и на вопрос «почему из 2 000 установок только 40 заявок» ответить нечем. Разница с сайтом принципиальная: на сайте вы в любой момент добавите цель в Метрике и через час увидите данные, а в приложении каждое новое событие - это новая сборка, ревью в сторе и ожидание, пока пользователи обновятся. Ниже - какие события и параметры нужны, как их называть, чего не стоит логировать, какие метрики смотреть в первые месяцы, чек-лист приёмки и порядок цен.

Короткий ответ: какие события нужны в первой версии

В первой версии приложения достаточно разметить путь пользователя от установки до ключевого действия и зафиксировать всё, что этот путь ломает. Это примерно 12-15 событий, не больше: каждое лишнее событие в релизе стоит времени разработчика, а каждое пропущенное - месяца ожидания до следующего обновления.

Логика отбора простая. Выпишите цепочку из 5-7 шагов, которую пользователь должен пройти, чтобы принести вам деньги или заявку, и поставьте событие на каждый шаг. Затем добавьте события на три источника потерь: отказ дать разрешение (пуши, геолокация, камера), пустой результат (поиск ничего не нашёл, список пуст) и техническая ошибка (запрос к серверу упал, оплата не прошла). Всё остальное - нажатия на второстепенные кнопки, прокрутки, открытия настроек - добавляется во второй и третьей версии, когда появятся конкретные вопросы.

Почему это нужно заложить до релиза, а не после

Аналитику в приложении нельзя докрутить снаружи, как счётчик на сайте: события живут в коде, и любое изменение требует новой сборки и публикации. Поэтому забытое событие - это не «добавим завтра», а минимум 1-3 недели до того, как данные начнут приходить, плюс время на то, чтобы пользователи обновили приложение.

Три последствия, которые мы видим чаще всего:

1. Нет данных по первым дням жизни приложения. Самый ценный период - первые две недели после релиза, когда идёт первая волна установок и видно, на каком шаге люди спотыкаются. Эти данные невозвратны: доразметили через месяц - первая волна уже прошла.
2. Старые версии остаются слепыми навсегда. Часть пользователей не обновляется месяцами. Если событие появилось в версии 1.2, по людям на 1.0 вы его не увидите никогда, и доля таких пользователей в отчётах будет выглядеть как падение конверсии.
3. Решения принимаются по установкам. Когда из метрик есть только установки и выручка, продвижение оптимизируют по цене установки. Это приводит к дешёвому мусорному трафику: установок много, до ключевого действия не доходит почти никто.

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

Один инструмент аналитики или два

Для большинства приложений в России рабочая схема - один продуктовый инструмент аналитики плюс отдельный инструмент для сбоев. Два продуктовых SDK одновременно нужны редко: они удваивают работу по разметке и почти всегда расходятся в цифрах на 5-15% из-за разных правил подсчёта сессий.

Что обычно выбирают:

• AppMetrica (Яндекс). Бесплатна, умеет и продуктовые события, и атрибуцию установок с рекламных кампаний, и отчёты по сбоям. Для российского проекта это чаще всего основной вариант: данные остаются в российской инфраструктуре, а рекламные кабинеты Яндекса подключаются без посредников.
• Firebase Analytics / GA4. Удобна, если у вас уже вся веб-аналитика в GA4 и нужны сквозные отчёты. Ограничения стоит знать заранее: до 500 уникальных имён событий на проект и до 25 параметров на событие. Для проектов, которым важна работа без зарубежных сервисов, это рискованный единственный вариант.
• Сбор событий в своё хранилище. Приложение отправляет события на ваш сервер, оттуда они попадают в базу и в отчёты. Дороже на старте, но даёт полный контроль и связку с CRM без ограничений. Разумно, когда приложение - основной канал продаж.
• Отдельный инструмент для сбоев. Отчёты по падениям и ANR с привязкой к версии и устройству. Это не дублирование продуктовой аналитики: без них вы увидите падение конверсии, но не поймёте, что на части устройств приложение просто закрывалось.

Практический совет: решение по инструменту принимайте до начала разметки, потому что имена и структура событий у разных систем различаются, и перенос разметки с одной на другую - это переделка, а не настройка.

Таблица: 14 событий, которые нужны почти любому приложению

Это базовый каркас. Названия даны в универсальном виде; под свой проект меняйте только предметную часть, структуру лучше сохранить.

Два события из таблицы обычно пытаются выкинуть как необязательные, и оба раза это ошибка. push_permission определяет, сможете ли вы вообще возвращать людей в приложение: если разрешение дают 20% вместо 60%, канал возврата закрыт, а узнаете вы об этом только по этому событию. api_error показывает тихие поломки, которые не роняют приложение и потому не попадают в отчёты по сбоям, но для пользователя выглядят как «приложение не работает».

Параметры, которые нужно передавать с каждым событием

Параметры важнее количества событий. Одно событие с правильными параметрами заменяет пять узких, потому что в отчётах вы просто фильтруете по параметру вместо того, чтобы искать отдельное событие.

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

Как называть события, чтобы через год в них можно было разобраться

Соглашение об именовании пишется один раз на полстраницы и экономит десятки часов. Без него через три релиза в кабинете окажутся ButtonClick, btn_click и click_button - три события об одном и том же, и ни одно не покажет полной картины.

Рабочие правила, которых достаточно:

1. Нижний регистр и подчёркивания: add_to_cart, а не AddToCart. Большинство систем различают регистр.
2. Объект, затем действие: cart_add, order_submit, filter_apply. События одного объекта тогда стоят в списке рядом.
3. Никаких данных в имени события. Не purchase_1999 и не view_item_sneakers: сумма и категория - это параметры. Иначе список событий разрастётся до тысяч строк и упрётся в лимиты системы.
4. Одно событие на один факт. Если нужно отличить успех от ошибки, это два события (payment_success, payment_error) или один параметр status, но не свободный текст.
5. Единый язык. Имена событий и параметров - латиницей, значения параметров - как удобно, но тоже единообразно.
6. Реестр событий в таблице. Имя, описание, когда срабатывает, параметры, кто отвечает. Таблица живёт рядом с техзаданием и обновляется в том же релизе, в котором меняются события.

Реестр - это не бюрократия. Это единственный документ, по которому новый разработчик или подрядчик поймёт, что означает step_3_done, когда автора события в проекте уже нет.

Чего не нужно логировать

В параметры событий нельзя отправлять персональные данные и всё, что относится к платёжным реквизитам. Это требование и закона, и правил сторов: App Store и RuStore запрашивают сведения о собираемых данных при публикации, и несоответствие заявленного фактическому поведению приложения - основание для отклонения или снятия с публикации.

Конкретный список того, что не должно попадать в события:

• телефон, почта, ФИО, адрес - вместо них обезличенный user_id, который расшифровывается только в вашей базе;
• номера карт, CVC, токены оплаты - никогда и ни в каком виде;
• содержимое переписки, медицинские и иные особые категории данных;
• пароли и ключи доступа (встречается чаще, чем кажется, в событиях об ошибках входа);
• точная геолокация, если она не нужна функционально; для аналитики почти всегда достаточно города.

Отдельно про iOS: запрос разрешения на отслеживание нужен, когда вы связываете данные пользователя с данными сторонних сервисов для рекламы. Текст этого запроса пользователь видит, и формулировка влияет на долю согласий - её стоит написать осознанно, а не оставить шаблон. И сведения о сборе данных в карточке приложения должны совпадать с тем, что реально отправляет SDK. Про юридическую часть - политику и согласия - мы подробно писали в материале про 152-ФЗ, политику и реальные штрафы; для приложения действуют те же правила плюс требования сторов.

Воронка первого запуска: что вы увидите после релиза

Правильно размеченное приложение даёт воронку из 6 шагов, и каждый шаг - это конкретная цифра, по которой принимается решение. Ниже - ориентиры, а не нормативы: разброс по нишам огромный, но порядок величин помогает понять, где у вас провал, а где нормальная жизнь.

Четыре метрики, которые стоит смотреть каждую неделю первые два месяца: возвраты на 1-й, 7-й и 30-й день (D1/D7/D30), конверсия первого запуска в ключевое действие, доля сессий без сбоев (норма - выше 99%) и время от запуска до ключевого действия. Последняя метрика недооценена: если среднее время до первой заявки больше 2-3 минут, проблема почти всегда в навигации, а не в спросе.

Откуда пришёл пользователь: атрибуция установок

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

Что нужно подготовить:

1. Трекинговые ссылки для каждого канала продвижения, чтобы в отчётах различать кампании, а не видеть «органику» целиком.
2. Передачу источника в первое событие: install_source фиксируется при первом запуске и дальше хранится в профиле пользователя, иначе в отчёте по покупкам источника уже не будет.
3. Диплинки - ссылки, открывающие нужный экран приложения. Нужны и для рекламы, и для возврата из писем и пушей; события по ним размечаются отдельно (deeplink_open с параметром target).
4. Связку с сайтом, если трафик идёт через сайт: переход на страницу приложения, нажатие на кнопку установки и сама установка должны сводиться в одну цепочку.

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

Технические вещи, которые проверяются до отправки в стор

Разметка считается готовой не когда код написан, а когда события видны в кабинете в правильном виде. Проверка занимает несколько часов и экономит релиз.

• Отладочный режим. У инструментов аналитики есть режим, в котором события приходят в кабинет сразу, а не с задержкой. Без него проверка превращается в угадывание.
• Разделение тестовых и реальных данных. Отдельный проект или признак окружения в параметрах. Иначе внутренние тесты смешаются со статистикой пользователей, и первые недели данные будут завышены.
• Поведение без сети. События должны копиться в очереди и уходить при появлении связи. Если SDK настроен неправильно, вы молча теряете часть данных в метро и лифтах.
• Проверка по реестру. Пройдите приложение руками по всем шагам воронки и сверьте с таблицей: каждое событие сработало один раз, не продублировалось при повороте экрана и возврате из фона, все параметры заполнены.
• Сбои в релизной сборке. Отчёты по падениям должны быть читаемыми в собранной версии: без загрузки файлов с символами вы получите нерасшифрованные отчёты и не поймёте, где падает.
• Согласие и разрешения. Проверьте, что при отказе от отслеживания приложение продолжает работать, а события не передаются с данными, на которые согласия нет.

Этот этап обычно совпадает по времени с подготовкой карточки в сторе, так что делайте их вместе: требования к сведениям о данных и к политике конфиденциальности как раз здесь и всплывают. Про сам процесс публикации и сроки у нас есть отдельный разбор - как опубликовать приложение в RuStore и App Store.

Чек-лист приёмки аналитики перед релизом

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

1. Есть таблица-реестр событий с описанием и параметрами, она совпадает с тем, что реально отправляет приложение.
2. Все события из воронки от первого запуска до ключевого действия присутствуют и срабатывают по одному разу.
3. С каждым событием приходят версия приложения, платформа и, после авторизации, user_id.
4. Источник установки фиксируется при первом запуске и доступен в отчётах по покупкам и заявкам.
5. Настроены события на ошибки: неуспешный вход, ошибка сервера, неуспешная оплата.
6. Отчёты по падениям подключены и читаемы в релизной сборке.
7. Тестовые данные отделены от реальных.
8. В параметрах событий нет персональных и платёжных данных (проверено выборочно по 10 событиям).
9. Сведения о сборе данных в карточке приложения соответствуют фактическому поведению SDK.
10. В кабинете собрана воронка и сохранены 3-5 отчётов, которые вы будете смотреть каждую неделю.

Последний пункт пропускают чаще всего, а он определяет, будет ли аналитика использоваться. Данные, для которых не собран отчёт, не смотрит никто.

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

Разметка аналитики для первой версии приложения занимает на рынке от 15 до 40 часов работы: проектирование событий и реестр, внедрение SDK, сама разметка, проверка и сборка отчётов. В деньгах это обычно от 50 000 до 150 000 ₽ в зависимости от числа экранов и того, нужна ли связка с CRM; работа по часам у агентств и студий встречается в диапазоне от 2 500 до 5 000 ₽ за час. Это рыночные ориентиры, а не наши тарифы: точная цифра зависит от проекта, и считать её нужно по вашему списку экранов.

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

Дальнейшее сопровождение - это регулярная работа: новые экраны размечаются в том же релизе, в котором выходят, отчёты пересобираются под новые вопросы, ошибки в данных ловятся до того, как по ним приняли решение. В Honey Hunters Digital такие задачи идут по тарифам поддержки: базовый - от 15 000 ₽ в месяц (4 часа работ и «Красная кнопка» на срочные ситуации, неиспользованные часы не переносятся), 51 000 ₽ в месяц при стоимости часа 3 000 ₽ и 96 000 ₽ в месяц при стоимости часа 2 900 ₽ - в этих двух тарифах часы переносятся на следующий месяц. Отдельно про сопровождение приложений после запуска мы писали в материале сколько стоит поддержка мобильного приложения.

Шесть ошибок, из-за которых аналитика оказывается бесполезной

1. Разметили всё подряд. Сотни событий на каждое нажатие выглядят солидно, но в них невозможно работать: воронка не собирается, а лимиты систем на число уникальных имён заканчиваются к третьему релизу.
2. Нет параметра с версией приложения. После каждого обновления данные превращаются в кашу: непонятно, выросла конверсия или просто сменился состав пользователей по версиям.
3. Событие дублируется. Классика - событие открытия экрана, которое срабатывает при каждом возврате из фона и при повороте устройства. Конверсия в отчётах падает в разы без всякой причины.
4. Нет связки с CRM. В приложении видно заявки, в CRM - сделки, и соединить их нечем. Тогда оптимизация идёт по заявкам, а не по деньгам, и дешёвый канал с плохими заявками выглядит лучшим.
5. Ошибки не размечены. Падения и ошибки сервера не логируются, и отток списывают на «неинтересный продукт», хотя часть пользователей просто не смогла пользоваться приложением.
6. Данные никто не смотрит. Самая частая и самая обидная ошибка. Если за отчёты не отвечает конкретный человек и для них нет ритма (например, 20 минут каждый вторник), разметка перестаёт обновляться через два релиза.

Проверить себя можно одним вопросом: если завтра конверсия в ключевое действие упадёт на треть, сможете ли вы за полчаса сказать, на каком шаге и у какой версии приложения это произошло? Если да - аналитика сделана правильно.

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

Ещё одно. Разбираться в цифрах легче, когда можно спросить у тех, кто уже прошёл этот путь: какой retention считается нормальным в похожей нише, стоит ли ввязываться в своё хранилище, что в итоге дало рост. Такие разговоры идут у нас в Telegram «Тусовка владельцев сайтов» - по-человечески и без рекламных обещаний.

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

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

Можно ли добавить аналитику в приложение после релиза?
Можно, но это новая сборка и новая публикация в сторе, а данные начнут приходить только с тех пользователей, которые обновятся. На практике это 1-3 недели задержки и полная потеря статистики по первой волне установок - самому важному периоду жизни приложения.

Чем аналитика приложения отличается от аналитики сайта?
Тремя вещами: события живут в коде и меняются только с обновлением, у пользователей одновременно работают разные версии приложения, и нет привычного «источника перехода» - его заменяет атрибуция установки, которую нужно закладывать заранее.

Нужно ли ставить два инструмента аналитики сразу?
В большинстве случаев нет. Один продуктовый инструмент плюс отдельные отчёты по сбоям закрывают задачи небольшого приложения. Второй продуктовый SDK удваивает работу по разметке и даёт расхождения в цифрах из-за разных правил подсчёта сессий.

Какие метрики смотреть в первый месяц после запуска?
Четыре: возвраты на 1-й, 7-й и 30-й день, конверсия первого запуска в ключевое действие, доля сессий без сбоев (норма - выше 99%) и время от запуска до ключевого действия. Этого набора достаточно, чтобы понять, проблема в продукте, в трафике или в технике.

Какие данные нельзя передавать в события?
Телефоны, почту, ФИО, адреса, платёжные реквизиты, пароли, содержимое переписки и точную геолокацию без функциональной необходимости. Вместо персональных данных передаётся обезличенный идентификатор пользователя, а сведения о сборе данных в карточке приложения должны совпадать с фактическим поведением SDK.