Logo GH

Прогноз відтоку гравців

Прогноз відтоку гравців

Мета прогнозу відтоку - заздалегідь виявити гравців з ризиком не повернутися і запустити керовані дії (ре-активація, обмежувачі RG, персональні оффери), максимізуючи цінність і мінімізуючи шкоду. Нижче - end-to-end каркас від даних до експлуатації.

1) Визначення та рамки

Одиниця обліку: користувач (user/master_id) - за замовчуванням.
Правило відтоку (churn rule): відсутність цільової активності ≥ T днів (наприклад, 14/30). Активність фіксуйте: ≥1 сесія/ставка/депозит.
Горизонт прогнозу: H днів (ризик відтоку в наступні 7/14/30 днів).
Cutoff дата: день формування фіч; мітки не повинні використовувати інформацію пізніше cutoff.

💡 У паспорті метрик: одиниця, активність, T, H, TZ, виключення (боти/QA/фрод).

2) Розмітка міток без витоків (Point-in-Time)

Target (класифікація): 'churn _ next _ H = 1', якщо гравець не активний жодного разу у вікно (t, t + H] і далі виконує правило T.
Time-to-event (виживання): час до відтоку або цензури; добре для планування капів/черг.
Ковзні зрізи: генеруйте навчальні приклади на різних датах з лагами, щоб не витікало майбутнє.
Вікна істини: чекайте підтвердження відтоку T до фіксації мітки (delayed truth).

3) Фічі та вікна

Recency/Frequency/Monetary: дні з останньою активністю/депозитом, інтенсивності за вікна 7/ 14/30/90, ARPPU/частота.
Поведінка і контент: категорії ігор, різноманітність, «серійність» (run-length), час доби/тижня.
Маркетинг: відкриття гармат/листів, реакції на оффери, відписки.
Ризики/RG/фрод: прапори і лічильники, акуратно - як guardrails.
Календар: свята/матчі/зарплатні дні, сезонні фічі (dow, dom, wom).
Ідентичності/пристрої: платформа/OS/зміни девайсу, стабільність IP/ASN.
Онлайн/офлайн паритет: фічестор з однаковими рецептами і часом зрізу.

4) Моделювання

4. 1 Класифікація (ризик відтоку у вікно H)

Логістична регресія (інтерпретовано), GBM/Random Forest (сильні бейзлайни), Tab/Seq-NN.
Пороги за вартістю помилок, не по «красивому ROC».

4. 2 Виживаність/Hazard (час до відтоку)

Kaplan-Meier (форма кривої), Cox PH/AFT, discrete-time hazard (логіт по днях з календарем).
Дають ймовірність відтоку за часом, дозволяють планувати частоту контактів і капи.

4. 3 Послідовні і гібриди

RNN/TFT/Transformer з тимчасовими ознаками і масками пропусків.
Гібрид: бінарний ризик і час до події → краще прийняття рішень.

4. 4 Uplift-моделі

Прогнозують приріст утримання від контакту; застосовуйте, якщо є лог дій/експериментів.

5) Оцінка та калібрування

Дисбаланс класів: основні - PR-AUC, Recall@FPR≤x%, Precision @k.
Калібрування ймовірностей: Brier, reliability plots; Platt/Isotonic.
Час: backtesting з рознесеними за календарем фолдами (rolling origin).
Стабільність: розкид метрик по сегментах (країна/канал/платформа).
Виживання: інтегральна помилка по кривій ризику, калібрування S (t).

6) Пороги, гістерезис і політика рішень

Розділіть зони:
  • 'score ≥ τ_block' → сильна інтервенція (персональний оффер/дзвінок)
  • 'τ _ review ≤ score <τ_block' → м'який контакт (пуш/е-mail)
  • 'score <τ_review' → без дії

Гістерезис: вхідний поріг вище вихідного, щоб не «блимати».
Кулдауни: мінімальні інтервали повторних торкань per user/channel.
Guardrails: ROMI≥0, zhaloby≤Kh, RG-обмеження, частота контактів.

Приклад decision table

УмоваКонтекстДіяКулдаунGuardrails
`risk≥0. 85` & `value_q≥0. 8`VIPперсональний оффер LROMI≥0
`0. 65≤risk<0. 85` & `no_session≥7д`мас-сегм. пуш + e-mail сценарійzhaloby≤Kh
`RG_risk≥τ`будь-якийпауза + рада RGFPR≤1%

7) Економіка рішення

Очікувана цінність:
[
EV = p_{\text{удержания	дія} }\cdot LTV_{\text{future}}

p_{\text{вред} }\cdot Harm - Cost
]

Оптимізуйте пороги і алокацію каналів по EV, а не по голому CR.

8) Експерименти і причинність

A/B: стратегії контактів/офферів; основна метрика - retention uplift (D7/D30), guardrails - скарги/RG.
Квазіексперименти: DiD/синтетичний контроль при регіональних викативах.
Uplift-оцінка: Qini/AUUC, uplift@k.

9) Деплою і онлайн-контур

Скоринг: p95 ≤ 100-300 мс; ідемпотентність запитів,'correlation _ id'.
Оркестратор: гарантована доставка, retry/backoff, DLQ, rate-limit per channel/user.
Журнал рішень: 'signal→score→decision→action→outcome'з версіями моделі/політики.
Feature parity: однакові фічі онлайн/офлайн; тимчасові зрізи - строго до cutoff.

10) Моніторинг і дрейф

Якість: PR-AUC/Recall @FPR по ковзному вікну, калібрування; частка в зонах'block/review'.
Дрейф: PSI/KL за ключовими фічами, shift цільової частки, «нові» патерни.
Операції: latency, таймаути,% фолбеків, черга контактів, скарги.
Fairness: диференція помилок/порогів за сегментами; аудит пояснюваності.

11) Псевдо-SQL/рецепти

A. формування мітки churn_next_14 (класифікація)

sql
WITH activity AS (
SELECT user_id, DATE_TRUNC('day', ts) AS d
FROM event_activity
),
snap AS (-- cut-off date
SELECT DISTINCT DATE_TRUNC('day', ts) AS cut
FROM event_activity
WHERE ts BETWEEN:train_from AND:train_to
),
label AS (
SELECT s. cut, a. user_id,
CASE WHEN NOT EXISTS (
SELECT 1 FROM activity a2
WHERE a2. user_id = a. user_id
AND a2. d > s. cut AND a2. d <= s. cut + INTERVAL '14 day'
) THEN 1 ELSE 0 END AS churn_next_14
FROM snap s
JOIN (SELECT DISTINCT user_id FROM activity) a ON 1=1
)
SELECT FROM label;

B. rolling-фічі (7/30/90) з point-in-time

sql
SELECT u. user_id, s. cut AS cut_day,
SUM(CASE WHEN a. d > s. cut - INTERVAL '7 day' AND a. d <= s. cut THEN 1 END) AS act_7d,
SUM(CASE WHEN a. d > s. cut - INTERVAL '30 day' AND a. d <= s. cut THEN 1 END) AS act_30d,
SUM(CASE WHEN p. d > s. cut - INTERVAL '30 day' AND p. d <= s. cut THEN p. amount ELSE 0 END) AS rev_30d,
DATE_PART('day', s. cut - MAX(a. d)) AS recency_last_act
FROM snap s
JOIN users u ON 1=1
LEFT JOIN activity a ON a. user_id = u. user_id AND a. d <= s. cut
LEFT JOIN payments p ON p. user_id = u. user_id AND p. d <= s. cut
GROUP BY 1,2;

12) Шаблони артефактів

Паспорт моделі відтоку (template)

ID/версія: `CHURN_14D_GBM_v4`

Target/вікно: 'churn _ next _ 14', PIT-зрізи по днях

Фічі: RFM, контент, маркетинг, календар, пристрій

Метрики: PR-AUC≥0. 45, Recall@FPR≤1% ≥ 0. 30, Brier≤X

Калібрування: isotonic

Пороги: 'τ _ block/ τ _ review'з гістерезисом

SLO: скоринг ≤ 150 мс p95; генерація оффлайн звіту ≤ 06:00

Власники, дата ревізії, runbook деградації

Decision-ready звіт (скелет)

«Churn 14d: ризик за сегментами, топ-причини, forecast конверсії ре-активації"

Ризики: частка high-risk зросла в платформах X/Y (+ Δ п.п.)

Рекомендації: збільшити бюджет контактів в сегменті A, змінити канал B, RG-обмежувачі в сегменті C

13) Безпека, приватність, етика

PII-мінімізація: токенізація ідентифікаторів, RLS/CLS.
Прозорість: причини рішення/контакту (top-features/правила) доступні саппорту.
Етика/RG: не таргетуйте вразливі групи агресивними оферами; cap частоти контактів.

14) Часті помилки

Мітка використовує майбутнє (label leakage), змішання TZ/вікон.
Оцінка по ROC-AUC при 1% таргеті без PR-AUC/Recall @FPR.
Немає калібрування - пороги налаштовані «наосліп».
Відсутність гістерезису/кулдаунів → «миготіння» контактів і скарги.
Не пов'язали ризик з EV/LTV - «лікуємо» тих, кого невигідно лікувати.
Онлайн/офлайн розсинхрон фіч - в проді якість падає.

15) Чек-лист перед релізом контуру

  • Визначені T/H/TZ, активність, винятки; PIT-процедури оформлені
  • Датасети без витоків; rolling-валідація, бенчмарки та калібрування
  • Порогова політика, гістерезис, капи і guardrails документовані

Оркестратор дій, ідемпотентність, аудит «signal→decision→action»

  • Моніторинг якості/дрейфу/fairness, алерти і runbooks
  • Uplift-оцінка і/або A/B готова; звіт decision-ready (з EV)
  • Версії моделі/фіч/метрик, власники, SLO прописані

Підсумок

Прогноз відтоку працює тільки як система: чітка розмітка без витоків → інформативні фічі → відповідна модель (класифікація і/або виживаність) → метрики, калібрування і пороги від вартості помилок → безпечна оркестрація дій → моніторинг дрейфу і fairness. Такий контур дає рішення, а не тільки «ризики»: кого, коли і як контактувати, щоб підвищувати утримання і LTV.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.