Ми часто бачимо, як команди орієнтуються на 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 та коректність подій безкоштовно.