Аналіз утримання гравців

Утримання - серцевина економіки продукту: чим довше гравець залишається активним, тим вище 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 ( дисконт).
Еластичність: приріст 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д	zhaloby≤Kh
`RG_risk ≥ τ`	будь-який	рауза/рада 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 -я igra→1 -й депозит.
Карта дій: signal→resheniye→kanal→iskhod (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) Часті помилки

Змішування одиниць (sessii↔polzovateli), 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 і знижує відтік.

Аналіз утримання гравців