Анализ удержания игроков

Удержание — сердцевина экономики продукта: чем дольше игрок остается активным, тем выше LTV, тем стабильнее доход и предсказуемее планирование. Ниже — полный каркас: от корректных определений до моделей выживаемости и контура ре-активации.

1) Определения и единицы учета

Единица: игрок (user/master_id) — по умолчанию; для краткосрочных задач допустим «аккаунт/устройство», но фиксируйте это в паспорте метрики.
Активность: критерий возвращения (≥1 сессия / ≥1 ставка / ≥1 депозит) — зафиксируйте.
Ретеншн Dn: доля когорты, вернувшаяся на n-й день после референтной даты.
Rolling/Bracket: Rolling D7 (в любой из дней 1–7) vs Exact D7 (именно на 7-й день).
Churn (отток): отсутствие активности ≥T дней (например, 14/30); задается как правило продукта.
Когорты: по дате регистрации/первого депозита/первой игры — выбирайте под задачу маркетинга/продукта.

💡 Золотое правило: заранее зафиксируйте триггер активности, тайм-зону, референтную дату и правило оттока.

2) Базовая аналитика: когорты и retention-кривые

Когортные теплокарты: D1/D3/D7/D14/D30/D60; диагонали сравнимы между релизами и кампаниями.
Кривые выживаемости: доля активных от дня 0 до N (survival curve).
Геометрия кривой: «ступеньки» праздников/релизов; ранний «обвал» → проблемы онбординга, «длинный хвост» → ядро лояльных.

Псевдо-SQL: когортный D7

sql
WITH regs AS (
SELECT user_id, DATE_TRUNC('day', ts) AS cohort_day
FROM event_register
),
act AS (
SELECT user_id, DATE_TRUNC('day', ts) AS act_day
FROM event_activity
),
d7 AS (
SELECT r. cohort_day,
COUNT(DISTINCT r. user_id)              AS cohort_size,
COUNT(DISTINCT CASE WHEN a. act_day = r. cohort_day + INTERVAL '7 day'
THEN r. user_id END)       AS retained_d7
FROM regs r
LEFT JOIN act a ON a. user_id = r. user_id
GROUP BY 1
)
SELECT cohort_day, cohort_size,
retained_d7::decimal / NULLIF(cohort_size,0) AS cr_d7
FROM d7
ORDER BY cohort_day;

3) Выживаемость и hazard-модели

Kaplan–Meier: немодельная оценка survival (S(t)); полезна для «снятия формы» кривой и медианы жизни.
Cox PH / Accelerated Failure Time: объяснимые модели влияния признаков (страна, канал, платформа, бонусы, контент) на hazard (риск оттока).
Discrete-time hazard (логит по дням): гибко для продуктовой аналитики и фичей календаря.
Событие «ре-активация»: моделируйте отдельно (competing risks) или как переход в цепи Маркова.

4) Марковские и полумарковские модели

Состояния: New → Active → Dormant → Churned → Reactivated.
Переходы: вероятности за период (день/неделя).
Ценность: мультиплицируйте вероятности пребывания в «Active» на средний чек/частоту — получите ожидаемый вклад в LTV.

5) Связка удержания и LTV

LTV ≈ Σ (Retention_t × ARPU_t × дисконт).
Эластичность: прирост D7 на X п.п. → прирост LTV на Y% (из исторических данных/моделей).
Приоритизация: улучшения, влияющие на раннее удержание (D1–D7), почти всегда самые доходные.

6) Сегментация удержания

Онбординг-когорты: первый контент/игровая категория/поведенческий шаблон в день 0.
Гео/платформа/канал: различия UX и ожиданий; корректируйте на календарь/праздники.
Поведение/ценность: RFM (Recency-Frequency-Monetary), риск оттока, прибыльность.
Ответ на стимулы: сегменты по uplift-реакции на офферы/нотификации.

7) Причинность и эксперименты

А/В: онбординг, туториалы, пуш-стратегии; основная метрика — D7/D14/D30 ретеншн, guardrails — жалобы, время ответа, RG.
Квазиэксперименты: DiD/синтетический контроль, когда рандомизация невозможна (например, региональные выкаты).
Uplift-модели: таргетируют прирост возврата, а не вероятность активности; оценивайте Qini/AUUC.

8) Ре-активация: триггеры и политика

Сигналы: падение частоты, отсутствие депозитов N дней, аномально низкий чек, завершенный онбординг без 2-й сессии.

Decision table (пример)

Условие	Контекст	Действие	Кулдаун	Guardrails
`risk_churn ≥ 0.8` & `value_q ≥ 0.8`	VIP	персональный оффер L	7д	ROMI≥0
`no_session ≥ 7д` & `no_deposit ≥ 14д`	масс-сегм.	пуш + e-mail «вернемся к…»	5д	жалобы≤X
`RG_risk ≥ τ`	любой	paуза/совет RG	1д	FPR≤1%

Гистерезис: разные пороги вход/выход для сигналов, чтобы не «мигать».
Каналы: in-app, пуш, e-mail, SMS, колл-центр — с rate-limit и приоритетами.

9) Метрики удержания

D1/D7/D30 (Rolling/Exact), WAU/MAU, Stickiness (DAU/MAU).
Survival медиана/квантили; hazard на интервалах.
Reactivation rate (R30), Dormancy share.
ROMI ре-активации, NNT (сколько контактов на 1 возврат).
Fairness: различия метрик по странам/платформам; исключайте недопустимые признаки из политик.

10) Дашборды удержания

Когортная теплокарта + линии трендов D1/D7/D30.
Survival/hazard графики по сегментам.
Воронка ранней жизни: install→reg→KYC→1-я игра→1-й депозит.
Карта действий: сигнал→решение→канал→исход (conversion to return).
Guardrails: свежесть данных, coverage событий, жалобы, RG-индикаторы.

11) Данные и качество

События: каноническая схема (UTC, версии), идемпотентность, дедуп.
Идентичности: user/device/e-mail/телефон — мосты и золотая запись.
Окна и TZ: хранение в UTC + локальные представления; единый календарь праздников.
Фильтры: боты/QA/фрод — исключайте из когорты и активностей.
Версионирование метрик: `RET_D7_vN` с changelog.

12) Псевдо-SQL/питон-рецепты

Rolling D30 по когортам

sql
WITH base AS (
SELECT user_id, DATE_TRUNC('day', MIN(ts)) AS cohort_day
FROM event_register GROUP BY 1
),
act AS (
SELECT user_id, DATE_TRUNC('day', ts) AS d
FROM event_activity
),
roll30 AS (
SELECT b. cohort_day,
COUNT(DISTINCT b. user_id)                              AS cohort_size,
COUNT(DISTINCT CASE WHEN a. d BETWEEN b. cohort_day AND b. cohort_day + INTERVAL '30 day'
THEN b. user_id END)                      AS any_1_30
FROM base b LEFT JOIN act a ON a. user_id = b. user_id
GROUP BY 1
)
SELECT cohort_day, any_1_30::decimal/cohort_size AS rolling_d30
FROM roll30;

Kaplan–Meier (эскиз)

python t_i - time to outflow or censorship; e_i - event indicator
S(t) = Π_{t_i ≤ t} (1 - d_i / n_i)

Discrete-hazard (логит по дням)

python
For each user, create records before the event/censorship by day:
target = 1 if there was an outflow on that day; characteristics: calendar, activity, promo, etc.
Training logistic regression/GBM; forecast p_t - probability of outflow on day t.

13) Uplift-таргетинг удержания

Зоны: Persuadables (вернутся, если контактируем), Sure things (вернутся и так), Lost causes, Do-not-disturb (контакт вредит).
Метрики: uplift@k, Qini/AUUC; политика — контактируем топ-k по uplift под бюджет.
Guardrails: cap на частоту контактов, RG/этика, объяснимость причины контакта.

14) Операционная эксплуатация

SLO: обновление ретеншн-дашборда ≤ 06:00 лок.; latency скоринга риска ≤ 300 мс; Decision→Action ≤ 5 с.
Мониторинг: сдвиги кривых по сегментам, PSI дрейфа признаков, «обрыв событий».
Рунибуки: падение D1 (онбординг/релиз), падение D7 (контент/частота), локальные сбои каналов коммуникации.

15) Частые ошибки

Смешение единиц (сессии↔пользователи), TZ, окон активности.
Сравнение Rolling и Exact показателей как равных.
Игнор ботов/фрода → завышенные D1/D7.
Выводы по корреляции без причинной проверки.
Отсутствие гистерезиса/кулдаунов → усталость от контактов.
Нет связки с LTV — оптимизируем CR, но не ценность.

16) Чек-лист перед релизом контура удержания

Паспорт метрик (триггер активности, окно, TZ, версия)
Когортные отчеты и survival/hazard по сегментам
Модели риска оттока и uplift, капы и guardrails каналов
План A/B и/или квазиэкспериментов для интервенций
Дашборды свежести/coverage/жалоб/RG
Рунибуки инцидентов, гистерезис и rate-limits в политике
Связка удержания с LTV и ROMI; приоритизация по ожидаемой ценности

Итог

Анализ удержания — это не только «теплокарта когорт», а управляемая система: корректные определения, survival/hazard-модели, связь с ценностью, таргетированные и этичные интервенции, строгая оценка эффекта и операционные guardrails. Вы строите цикл «наблюдай → понимай → решай → действуй → учись», который стабильно повышает LTV и снижает отток.

Анализ удержания игроков