Налаштування когортного аналізу мобільного додатка
Retention — найважливіша метрика продукту. Day-1 retention 40% та Day-7 retention 20% означають різні продукти з різними проблемами. Когортний аналіз відповідає на питання: як ведуть себе користувачі, які встановили додаток одну і ту ж тиждень, через 1, 7, 14, 30 днів?
Агрегований DAU приховує деградацію: якщо нові користувачі приходять швидше, ніж йдуть старі, DAU зростає — а retention падає. Когорти це показують.
Що потрібно для когортного аналізу
Два обов'язкові умови: стабільний user_id та подія активації. Без них когорта не будується коректно.
User ID повинен бути одинаковим при переустановці додатка — якщо кожен раз генерувати новий, користувач завжди в «новій» когорті. Рішення:
- iOS:
Keychainдля зберігання сгенерованого UUID (переживає видалення додатка) - Android:
AccountManagerабо server-side ID після реєстрації - Після авторизації:
Analytics.setUserId(serverUserId)→ користувач прив'язується до аккаунту
Подія активації — перша дія, яка показує цінність продукту. Для різних додатків різна:
| Тип додатка | Подія активації |
|---|---|
| Маркетплейс | first_purchase |
| Стриминг | content_played (3+ хвилини) |
| Фітнес | workout_completed |
| Гра | level_2_started |
| Соцмережа | first_post або 5_connections |
Вибір события активації впливає на те, що показує когорта. app_open — занадто широко, включає випадкових користувачів. premium_purchase — занадто вузько для аналізу retention всієї аудиторії.
Реалізація когортного аналізу
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 дозволяє порівнювати когорти бок о бок — зручно видити, чи покращився retention після продуктового оновлення.
Mixpanel
У Mixpanel розділ Retention будує класичну retention-матрицю. Додатково є Lifecycle — показує, який відсоток користувачів «воскресає» після довготривалої відсутності. Для казуальних ігор це важлива метрика.
Поведінкові когорти
Крім часових когорт (за датою установки) корисні поведінкові когорти — групи користувачів, які здійснили певну дію:
# Приклад логіки в BigQuery:
# Когорта: користувачі, які завершили онбординг
# Питання: якою є їхня retention vs користувачі, які пропустили онбординг?
Якщо retention завершивших онбординг у 2 рази вищий — доказ, що онбординг потребує покращення, а не скорочення.
Що входить до роботи
- Аудит стабільності user_id в поточній реалізації
- Визначення подій активації разом з продукт-менеджером
- Налаштування когортного аналізу в Firebase + BigQuery / Amplitude / Mixpanel
- SQL-запити для користувацьких когортних звітів
- Налаштування поведінкових когорт для ключових гіпотез
- Документація та передача команді
Сроки
Налаштування когортного аналізу в готовому інструменті (Amplitude/Mixpanel): 1–2 дні. BigQuery + кастомні SQL-запити: 2–4 дні. Вартість розраховується індивідуально.







