Аналитика мобильного приложения: важны не скачивания, а удержание
Команда запускает рекламную кампанию, и график в консоли магазина за неделю показывает тысячи новых установок — в рабочем чате радость. Через месяц выручка не сдвинулась ни на процент, и никто толком не может объяснить почему.
Причина обычно простая: тот же график, что показывает установки, ничего не говорит о том, кто остался в приложении на следующей неделе. Приложение считается не по числу нажатий кнопки «Установить», а по числу возвращений в него — и именно там лежит настоящий ответ на вопрос, сработала ли кампания.
Что не показывает число установок
Когда цифра установок в консоли растёт, команда расслабляется — но эта цифра фиксирует только один момент: нажатие кнопки «Установить». Она ничего не говорит о том, откроет ли человек приложение завтра. Google Play Console вводит для этого отдельное понятие: платформа определяет 7-дневное удержание как число устройств, на которых приложение было открыто повторно именно на седьмой день после первого открытия (справка Google Play Console) — то есть отдельно измеряемое событие, а не производная от установок.
Отсюда практический вывод для отчёта: строка «N установок за неделю» сама по себе бесполезна, рядом должна стоять строка «сколько из прошлонедельных установщиков открыли приложение сегодня». Первая цифра показывает, что бюджет потрачен. Вторая — во что он превратился. Рекламный кабинет сам подталкивает к этой путанице: в Meta и Google Ads «установка приложения» обычно настроена как основное событие конверсии, а повторное открытие отдельно не отслеживается и вообще не попадает в отчёт по кампании.
День 1: проверка первого впечатления
Человек ставит приложение, листает пару экранов и удаляет его до конца дня. На следующий день от него не остаётся ни сессии, ни открытого пуша — след исчезает полностью.
Причина обычно не в качестве продукта, а в тяжести первых пяти минут: регистрация обязательна, запросы на разрешения сыплются один за другим, а пользователь ещё не увидел, зачем ему приложение вообще. Он закрывает дверь, так и не узнав, что за ней. Три препятствия встречаются чаще всего:
- обязательная регистрация до того, как показана хоть какая-то польза
- запросы на разрешения подряд — уведомления, геолокация, контакты
- пустой первый экран без объяснения, пользователю приходится угадывать, что делать
Считайте retention дня 1 в процентах — сколько установивших открыли приложение на следующий день — и смотрите по событиям, на каком шаге онбординга люди отваливаются. Конкретное действие на эту неделю: отодвиньте регистрацию на один экран позже, сначала покажите главную функцию, а аккаунт создавайте потом.
Как читается когорта
Цифра считается не за один день, а за когорту: все, кто установил приложение в один день, образуют группу, и дальше замеряется, какой процент этой группы вернулся на 1-й, 7-й, 30-й день. Именно так устроено официальное определение 7-дневного удержания у Google Play — число устройств, повторно открывших приложение на седьмой день после первого открытия.
День 7: формируется ли привычка
День 1 выглядит неплохо, но через неделю большинства пользователей уже нет — приложение попробовали один раз и забыли о нём.
Обычно это значит, что между моментом, когда продукт даёт пользу, и повседневной жизнью пользователя нет моста. Польза реальна, но ничто о ней не напоминает: нет уведомления, нет повода вернуться, либо функция такая, что нужна раз в год, а не раз в неделю.
Найдите конкретное событие-«озарение» — первый заказ, первый поиск, первый сохранённый элемент — и сравните retention дня 7 у тех, кто пережил это событие рано, с теми, у кого его не было. Если разрыв большой, задача не в новой функции, а в том, чтобы подвести пользователя к этому событию быстрее. Канал напоминания тоже нужен — push, письмо или баннер внутри приложения — но отправлять его стоит только тем, кто уже пережил «озарение»: тому, кто ещё не увидел ценность, напоминание просто закрывают не глядя.
День 30: долгосрочная ценность
Через месяц на графике остаётся тонкая полоска — почти все либо удалили приложение, либо просто его не открывают.
У каждой установки, пришедшей через рекламу, есть своя цена (CPI). Она платится один раз, а окупается только тем временем, что пользователь остаётся. Если retention дня 30 стремится к нулю, рекламный бюджет фактически покупает разовые установки, а не клиентов — и этот факт прячется именно за строкой «установки» в отчёте.
Сопоставьте CPI по каналам с retention дня 30. Если установки с «дешёвого» канала к 30-му дню почти никого не оставляют, канал не дешёвый — просто затраты записаны под другим названием. Это сопоставление и есть решение о распределении бюджета: оно показывает, какой канал стоит масштабировать, а какой остановить, — по цифре, а не по ощущению.
Как построить и отслеживать эту метрику
У большинства команд этих цифр просто нет, потому что консоль магазина показывает только установки, а событийная аналитика внутри приложения не настроена.
Чтобы считать retention, нужно фиксировать не только событие «открытие», но и конкретные действия внутри приложения — вход, использование основной функции, сессию. Это данные, которых консоль магазина никогда не даёт.
Подключение SDK аналитики
Для iOS и Android интеграция делается отдельно — это разные кодовые базы, но панель отчётов можно объединить в одну.
Определение событий для отслеживания
На каждый экран и каждое ключевое действие заводится своё событие, чтобы ответ на вопрос «где мы теряем людей» был цифрой, а не догадкой. Здесь же заранее фиксируется, что считать «сессией» — обычно окно от перехода приложения на передний план до определённого числа минут бездействия, — потому что при разных определениях цифры по iOS и Android перестают быть сравнимыми.
Настройка панели и еженедельный просмотр
Сырые данные сами по себе бесполезны — retention дня 1, 7 и 30 должен быть на одной панели, которую команда реально открывает каждую неделю, в разбивке по каналу и кампании, чтобы было видно, какая реклама действительно приводит остающихся пользователей.
Сто тысяч установок и ноль удержания на 30-й день — это не клиентская база, а квитанция за месячный рекламный бюджет.
На бумаге это звучит просто, но выстроить всё правильно — найти то самое событие-«озарение», корректно подключить SDK отдельно для iOS и Android, не запутать когорты при выводе на панель — отдельная работа. Обычно это четыре шага: вместе определяем, какие события отслеживать, подключаем SDK аналитики к приложению, проверяем, что каждый экран и каждое событие фиксируются верно, и превращаем поведение пользователей в понятную панель. Наша услуга по настройке аналитики для мобильных приложений выстраивает это с нуля, так что измеримым становится каждый экран приложения.
