Мы часто видим, как команды ориентируются на DAU, но не замечают, что retention падает. Наш опыт показывает: day-1 retention 40% и day-7 retention 20% — признаки разных проблем. Когортный анализ — единственный способ увидеть реальное поведение пользователей. Он показывает, как ведут себя пользователи одной недели установки через 7, 14, 30 дней после первого запуска. Агрегированный DAU скрывает деградацию: если новые пользователи приходят быстрее, чем уходят старые, DAU растёт — а удержание падает. Когорты это показывают. Понятие когортного анализа широко используется в мобильной аналитике. Однако на практике сталкиваются с типичными ошибками: нестабильный идентификатор пользователя, неправильный выбор первого ценного действия, отсутствие разбивки по версиям. Эти проблемы искажают данные, вводя команду в заблуждение. Свяжитесь с нами, чтобы настроить когортный анализ корректно.
Что нужно для когортного анализа
Два обязательных условия: стабильный user_id и событие активации. Без них когорта не строится корректно. Экономия на рекламном бюджете после точной настройки может достигать 20%.
User ID должен быть одинаковым при переустановке приложения. Если генерировать новый каждый раз, пользователь всегда будет в новой когорте. Решения:
- iOS: Keychain для хранения сгенерированного UUID (переживает удаление приложения)
- Android: AccountManager или server-side ID после регистрации
- После авторизации: Analytics.setUserId(serverUserId) — пользователь привязывается к аккаунту
Совет: проверьте, сохраняется ли ID при переустановке
Установите тестовый билд, удалите приложение и переустановите. Если user_id остался тем же — всё в порядке. Если нет — настройте Keychain или AccountManager.Событие активации — первое действие, которое показывает ценность продукта. Для разных приложений разное:
| Тип приложения | Событие активации |
|---|---|
| Маркетплейс | first_purchase |
| Стриминг | content_played (3+ минуты) |
| Фитнес | workout_completed |
| Игра | level_2_started |
| Соцсеть | first_post или 5_connections |
Выбор события активации влияет на то, что показывает когорта. app_open — слишком широко, включает случайных пользователей. premium_purchase — слишком узко для анализа удержания всей аудитории.
Почему важен stable user_id?
Без стабильного идентификатора вы не сможете отличить нового пользователя от вернувшегося после переустановки. Это приводит к завышению числа новых пользователей и занижению удержания. Мы гарантируем правильную настройку Keychain и AccountManager на основе вашей платформы. По нашим данным, 90% клиентов до настройки имели нестабильность user_id, что искажало когорты на 50% и более. Получите аудит текущей аналитики — оценим стабильность user_id и корректность событий бесплатно.
Как выбрать событие активации?
Событие активации должно отражать первый момент, когда пользователь получает пользу. Например, для фитнес-приложения это workout_completed, а не app_open. Один из наших клиентов (фитнес-приложение) после настройки когорт по workout_completed обнаружил, что удержание у тех, кто завершил первую тренировку в первые 2 дня, на 30% выше. Мы изменили онбординг, подталкивая к первой тренировке, и retention вырос на 15% за месяц. Обратитесь за консультацией, чтобы подобрать событие активации для вашего приложения.
Реализация когортного анализа
Firebase / BigQuery — настройка когортного анализа
Firebase сам строит Retention Chart в разделе Analytics, но с ограниченной гибкостью. Для глубокого анализа экспортируем сырые данные в BigQuery через Firebase → Integrations → BigQuery. Дальше SQL:
-- Когорта по неделям установки, retention на 7-й день WITH cohorts AS ( SELECT user_pseudo_id, DATE_TRUNC(MIN(PARSE_DATE('%Y%m%d', event_date)), WEEK) AS cohort_week, MIN(event_timestamp) AS first_open_ts FROM `project.analytics_*.events_*` WHERE event_name = 'first_open' GROUP BY user_pseudo_id ), activity AS ( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(PARSE_DATE('%Y%m%d', event_date), WEEK) AS activity_week FROM `project.analytics_*.events_*` WHERE event_name = 'session_start' ) SELECT c.cohort_week, DATE_DIFF(a.activity_week, c.cohort_week, WEEK) AS week_number, COUNT(DISTINCT c.user_pseudo_id) AS cohort_size, COUNT(DISTINCT a.user_pseudo_id) AS retained_users, ROUND(COUNT(DISTINCT a.user_pseudo_id) / COUNT(DISTINCT c.user_pseudo_id) * 100, 1) AS retention_pct FROM cohorts c LEFT JOIN activity a ON c.user_pseudo_id = a.user_pseudo_id GROUP BY 1, 2 ORDER BY 1, 2 Этот запрос даёт retention-таблицу по неделям.
Amplitude
В Amplitude когортный анализ — нативный инструмент в разделе Retention Analysis. Настраиваем:
- Starting Event — first_open или событие активации
- Return Event — session_start или app_open
- Группировка по дням/неделям
- Breakdown по: источнику установки, платформе, версии приложения
Amplitude позволяет сравнивать когорты бок о бок — удобно видеть, улучшилось ли удержание после продуктового обновления.
Mixpanel
В Mixpanel раздел Retention строит классическую retention-матрицу. Дополнительно есть Lifecycle — показывает, какой процент пользователей возвращается после длительного отсутствия. Для казуальных игр это важная метрика.
Сравнение инструментов для когортного анализа
| Критерий | Firebase + BigQuery | Amplitude | Mixpanel |
|---|---|---|---|
| Гибкость | Высокая (SQL) | Средняя (UI) | Средняя (UI) |
| Поведенческие когорты | SQL | Нативные | Lifecycle |
| Сложность настройки | Высокая | Низкая | Низкая |
| Стоимость | Запросы в BigQuery | Подписка | Подписка |
Поведенческие когорты
Кроме временных когорт (по дате установки) полезны поведенческие когорты — группы пользователей, совершивших определённое действие. Например, в Amplitude Behavioural Cohorts можно сегментировать пользователей по действиям: "добавил в корзину", "поделился контентом".
# Пример логики в BigQuery: # Когорта: пользователи, завершившие онбординг # Вопрос: каков их retention vs пользователи, которые пропустили онбординг? Если удержание у завершивших онбординг в 2 раза выше — это доказательство, что онбординг нужно улучшать, а не сокращать.
Типичные проблемы при настройке когортного анализа
- Нестабильный user_id — данные искажены.
- Неправильное событие активации — когорта не отражает ценность.
- Использование только app_open как возврата — смешиваются сессии и активные пользователи.
- Отсутствие breakdown по версиям — не видно эффекта обновлений.
Наш опыт включает настройку когортного анализа для приложений с аудиторией от 10 000 до 5 млн пользователей. Мы гарантируем корректное отображение retention и LTV.
Что входит в работу
- Аудит стабильности user_id в текущей реализации
- Определение событий активации совместно с продукт-менеджером
- Настройка когортного анализа в Firebase + BigQuery / Amplitude / Mixpanel
- SQL-запросы для кастомных когортных отчётов
- Настройка поведенческих когорт для ключевых гипотез
- Документация и передача команде
Сроки
Настройка когортного анализа в готовом инструменте (Amplitude/Mixpanel): 1–2 дня. BigQuery + кастомные SQL-запросы: 2–4 дня. Стоимость рассчитывается индивидуально.
Получите аудит текущей аналитики — оценим стабильность user_id и корректность событий бесплатно.