Навіщо потрібен когортний аналіз?
У нашій практиці це одна з частих проблем: маркетинг показує зростання встановлень, а MAU стоїть на місці. Без когортного retention-аналізу продукт не бачить, коли саме користувачі йдуть — на другий день, через тиждень або після першої транзакції. Метрики Day 1, Day 7, Day 30 Retention — це не просто цифри для дашборду, а діагностичний інструмент, що вказує на конкретну точку відвалу. Наш досвід 10+ років у мобільній аналітиці та 50+ проєктів підтверджують: правильно налаштований когортний аналіз економить до 30% маркетингового бюджету та прискорює продуктові рішення.
Для ефективного налаштування retention аналізу необхідно опанувати BigQuery когорти, Firebase Analytics когорти, SQL когортну таблицю та когортну теплову карту. Ці інструменти дозволяють провести глибокий аналіз утримання користувачів. Ми гарантуємо якість налаштування, адже наші сертифіковані спеціалісти мають 10+ років досвіду та 50+ виконаних проєктів. Когортний аналіз у 3 рази точніше за агрегований retention, що дозволяє економити до $5000 щомісяця на неефективних каналах.
Як працює когортний аналіз?
Когорта — група користувачів, об'єднаних датою першої події. Найчастіше це дата встановлення (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?
Покрокова інструкція:
- Підключіть експорт даних з Firebase у BigQuery. Це безкоштовний Spark-план Firebase підтримує з лімітами.
- Налаштуйте логування meaningful_action на клієнті. Нижче приклади для iOS та Android.
- Напишіть SQL-запит, що об'єднує first_open і session_start по user_pseudo_id, з урахуванням timezone.
- Побудуйте теплову карту в 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 занижується.
Порівняння інструментів
| Інструмент | Необхідна експертиза | Візуалізація | Гнучкість запитів | Ціна |
|---|---|---|---|---|
| Firebase + BigQuery | SQL | Looker Studio, Metabase, Redash | Висока | Безкоштовно (до лімітів) |
| Amplitude | Низька | Вбудовані дашборди | Середня | Від $1,000/рік |
| Mixpanel | Середня | Вбудовані дашборди | Середня | Від $25/міс |
Типові помилки при налаштуванні когортного аналізу
Змішування timezone
Якщо сервер логує події в UTC, а Firebase рахує Day N за локальним часом користувача — когорти розповзаються. Користувач встановив застосунок о 23:50 за московським часом, сервер записав це в UTC наступного дня. Когорта зсувається на добу.
Перерахунок cohort_date при перевстановленні
Після видалення та повторного встановлення Firebase генерує новий instance_id і новий first_open. Користувач потрапляє в нову когорту. Якщо це не врахувати, retention занижується — повертаючі користувачі виглядають як нові.
Маленькі когорти та статистичний шум
Когорта з 15 користувачів дає безглузді цифри: ±1 користувач — це ±7% retention. Когортний аналіз дає надійні дані при розмірі когорти від 200–300 користувачів.
Візуалізація та продуктові висновки
Стандартна теплова карта виглядає так:
| Когорта | Розмір | Day 1 | Day 3 | Day 7 | Day 14 | Day 30 |
|---|---|---|---|---|---|---|
| 01-01 | 420 | 38% | 22% | 14% | 9% | 6% |
| 01-08 | 380 | 41% | 25% | 16% | 11% | 7% |
| 01-15 | 510 | 29% | 18% | 11% | 7% | 4% |
Когорта від 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 дні на запити та дашборд. Вартість розраховується індивідуально після аналізу вимог.
Готові впровадити когортний аналіз? Замовте консультацію — ми допоможемо налаштувати всі етапи. Зв'яжіться з нами, щоб обговорити ваш проєкт.