Реализация Retention-анализа по когортам для мобильного приложения

Зачем нужен когортный анализ?

В нашей практике это одна из частых проблем: маркетинг показывает рост установок, а MAU стоит на месте. Без когортного retention-анализа продукт не видит, когда именно пользователи уходят — на второй день, через неделю или после первой транзакции. Метрики Day 1, Day 7, Day 30 Retention — это не просто цифры для дашборда, а диагностический инструмент, указывающий на конкретную точку отвала. Наш опыт 10+ лет в мобильной аналитике и 50+ проектов подтверждают: правильно настроенный когортный анализ экономит до 30% маркетингового бюджета и ускоряет продуктовые решения.

Как работает когортный анализ?

Когорта — группа пользователей, объединённых датой первого события. Чаще всего это дата установки (install_date), реже — дата первой покупки или регистрации.

Без когортной разбивки retention считается по формуле: активные сегодня / активные за период. Это усреднение смешивает новых и старых. Приложение может показывать стабильный 30-дневный retention 20%, хотя последние когорты деградируют до 8% — старые пользователи тянут среднее вверх.

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

Day N Retention = unique_users_active_on_day_N / cohort_size 

Отметим: где Day 0 — день установки, Day 1 — следующий календарный день (не 24 часа). Разница в интерпретации дня важна: Firebase по умолчанию считает по календарным дням в timezone пользователя (Firebase Documentation).

Как настроить когортный анализ через BigQuery?

Пошаговая инструкция:

1. Подключите экспорт данных из Firebase в BigQuery. Это бесплатный Spark-план Firebase поддерживает с лимитами.
2. Настройте логирование meaningful_action на клиенте. Ниже примеры для iOS и Android.
3. Напишите SQL-запрос, объединяющий first_open и session_start по user_pseudo_id, с учётом timezone.
4. Постройте тепловую карту в Looker Studio, Metabase или Redash.

Что трекать на клиенте

Минимальный набор для retention-анализа:

• app_open — факт запуска (Firebase Analytics логирует автоматически как session_start)
• user_engagement — лучше определить своё meaningful_action — действие, которое означает «пользователь нашёл ценность»
• install — атрибуция установки, нужна для правильного определения cohort_date

На iOS через Firebase SDK:

// AppDelegate или SceneDelegate Analytics.logEvent("meaningful_action", parameters: [ "action_type": "first_purchase" as NSObject, "item_category": product.category as NSObject ]) 

На Android (Kotlin):

firebaseAnalytics.logEvent("meaningful_action") { param("action_type", "first_purchase") param("item_category", product.category) } 

Ключевая ошибка — логировать app_open вместо meaningful_action. Тогда retention считается от факта запуска, а не от реального использования.

SQL-запрос для BigQuery

После подключения BigQuery события льются в таблицы вида events_YYYYMMDD. Запрос для когортной таблицы Day 0–7:

WITH installs AS ( SELECT user_pseudo_id, DATE(TIMESTAMP_MICROS(event_timestamp), "Europe/Moscow") AS cohort_date FROM `project.analytics_XXXXXXXXX.events_*` WHERE event_name = 'first_open' ), activity AS ( SELECT user_pseudo_id, DATE(TIMESTAMP_MICROS(event_timestamp), "Europe/Moscow") AS activity_date FROM `project.analytics_XXXXXXXXX.events_*` WHERE event_name = 'session_start' ) SELECT i.cohort_date, COUNT(DISTINCT i.user_pseudo_id) AS cohort_size, DATE_DIFF(a.activity_date, i.cohort_date, DAY) AS day_n, COUNT(DISTINCT a.user_pseudo_id) AS retained_users, ROUND(COUNT(DISTINCT a.user_pseudo_id) / COUNT(DISTINCT i.user_pseudo_id), 3) AS retention_rate FROM installs i LEFT JOIN activity a ON i.user_pseudo_id = a.user_pseudo_id AND a.activity_date BETWEEN i.cohort_date AND DATE_ADD(i.cohort_date, INTERVAL 30 DAY) GROUP BY 1, 3 ORDER BY 1, 3 

Этот запрос даёт таблицу: каждая строка — когорта + день + retention rate. Из неё строится тепловая карта.

Amplitude и Mixpanel как альтернатива

Для продуктов без BigQuery-экспертизы Amplitude — удобнее. Встроенный Retention Analysis строит когортные таблицы в несколько кликов. Но важно правильно настроить User ID. На iOS нужно передавать стабильный идентификатор до первого identify:

Amplitude.instance().setUserId(user.stableId) Amplitude.instance().logEvent("meaningful_action") 

Если userId не задан, Amplitude создаёт device-based identity — один пользователь на двух устройствах считается двумя разными. Retention занижается.

Сравнение инструментов

Типичные ошибки при настройке когортного анализа

Смешение timezone

Если сервер логирует события в UTC, а Firebase считает Day N по локальному времени пользователя — когорты расползаются. Пользователь установил приложение в 23:50 по московскому времени, сервер записал это в UTC следующего дня. Когорта сдвигается на сутки.

Пересчёт cohort_date при переустановке

После удаления и повторной установки Firebase генерирует новый instance_id и новый first_open. Пользователь попадает в новую когорту. Если это не учесть, retention занижается — возвращающиеся пользователи выглядят как новые.

Маленькие когорты и статистический шум

Когорта из 15 пользователей даёт бессмысленные цифры: ±1 пользователь — это ±7% retention. Когортный анализ даёт надёжные данные при размере когорты от 200–300 пользователей.

Визуализация и продуктовые выводы

Стандартная тепловая карта выглядит так:

Когорта от 15 января резко хуже — совпадает с релизом версии 2.3.0. Продукт видит это немедленно и откатывает или фиксит до того, как деградация распространится. По нашим оценкам, настройка когортного анализа окупается за 1–2 месяца за счёт снижения затрат на неэффективные каналы.

Что входит в работу

• Аудит текущей схемы событий, проверка наличия first_open / meaningful_action
• Настройка BigQuery-экспорта из Firebase или конфигурация Amplitude Retention
• SQL-запросы для когортных таблиц с учётом timezone
• Дашборд в Looker Studio / Metabase / Redash
• Документация: словарь событий, описание cohort_date logic

Сроки и стоимость

Настройка с нуля: 3–5 дней (зависит от текущего состояния аналитики и наличия BigQuery). Если события уже настроены — 1–2 дня на запросы и дашборд. Стоимость рассчитывается индивидуально после анализа требований.

Готовы внедрить когортный анализ? Закажите консультацию — мы поможем настроить все этапы. Свяжитесь с нами, чтобы обсудить ваш проект.