Чому прогнозування відтоку гравців ламається на живих даних
На офлайн-вибірці модель ризику відходу показує рівні метрики, а в проді розвалюється за перші тижні. Поведінкові ознаки гравців збирають за історичними логами, де відхід уже відомий, а в живому потоці мітка наздоганяє події із затримкою в тижні. Модель навчається на підгляданні в майбутнє і не переносить це знання на поточний день.
Найсильніше просідає точність прогнозу відтоку на рідкісних подіях. Тих, хто пішов, мало, тому частка правильних відповідей залишається високою навіть у моделі, яка всім відповідає «залишиться».
Дивитися потрібно на верхівку списку ризику: скільки реальних відходів потрапляє в перші відсотки і скільки хибних спрацювань отримає команда, яка кличе цих гравців назад.
Друга втрата — затримка між останньою дією і самим відходом. Гравець затихає не миттєво: сесії коротшають, покупки рідшають, інтервал між входами зростає — і це розмазано на два-три тижні.
Ознаки, пораховані за добу, на момент спрацювання застарівають; потрібні віконні агрегати на різних горизонтах і ознаки динаміки, а не зрізи.
Третє джерело помилок — зсув поведінки між сегментами. Новачок, платний гравець і ветеран із багаторічним стажем дають різні сигнали: падіння частоти входів в одного норма, в іншого — початок відходу.
Загальна модель усереднює групи, і прогнозування відтоку гравців втрачає чутливість там, де сегмент малочисельний.
Усі три місця лікуються не зміною алгоритму, а постановкою задачі: горизонт прогнозу, розмітка за часом, окремі пороги ризику для сегментів. Розбираємо, як це закривається на практиці.
Що дає рання система виявлення відтоку: вимірювані ефекти
Рання система виявлення відтоку цінна не звітом, а тим, що прогноз відходу гравця потрапляє в операційний контур: розсилки, лояльність, підтримку.
Тому ефект впровадження моделі ми вимірюємо в чотирьох величинах — горизонт попередження, частка тих, хто пішов, навантаження на підтримку, узгодженість метрик. Нижче — що змінюється на практиці.
Раннє попередження замість розбору постфактум
Класична аналітика фіксує відтік, коли гравець не заходив місяць, — повертати вже нікого. Модель перераховує ризик щодобово і підсвічує сегмент за 10–14 днів до відходу, коли внутрішньоігрові тригери ще працюють. Зсув у частоті сесій і глибині прогресу ловиться як сигнал, а не як факт пропуску.
Ефект на утримання
Контакти йдуть лише в групу ризику, тому офер не розмивається по всій базі й не з'їдає цінність активних гравців.
Порівняння з контрольною групою показує внесок саме точкових сценаріїв: частка тих, хто пішов, у групі ризику вирівнюється до рівня решти бази, а не просто «трохи падає».
Ефект на навантаження підтримки
Частина звернень «видаліть акаунт» — остання стадія розчарування, а не усвідомлене рішення. Тригер за високим ризиком запускає сценарій повернення до звернення, і частка таких тікетів падає. Підтримка перестає бути каналом утримання по факту й займається реальними проблемами.
Одна метрика на всю команду
Ризик-скор рахується за єдиною вітриною ознак у ClickHouse, тому продукт, лояльність і підтримка сперечаються про одну цифру, а не про різні вивантаження. Це прибирає ручні зрізи й робить порівняння сценаріїв відтворюваним.
Режими роботи: правила, статистика, модель на подіях
Оцінку ризику відтоку збирають трьома способами, і вибір диктує не мода, а частота рішень і ціна помилки. Нижче — що дає кожен варіант і на чому він ламається, щоб можна було вибрати відправну точку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Порогові правила | Перший контур: прогрів бази, сегменти, сповіщення за неактивністю | Рішення за однією-двома ознаками, пізнє спрацювання, пороги правлять вручну |
| Статистична модель на агрегатах | Є історія дій за вікно і стабільний баланс механік | Не бачить порядок і контекст дій, потребує регулярного перенавчання |
| Модель на поведінкових подіях | Потрібне раннє попередження і причини ризику для кожного гравця | Потрібні потік подій, розмітка результатів, контроль дрейфу ознак |
Коли достатньо порогових правил
Якщо ознак одна-дві, а рішення ухвалюється раз на добу, поріг за «немає входу N днів» або падіння активності до базової лінії закриває задачу. Правило прозоре, його читає підтримка, а вимкнення займає хвилину.
Межа настає на живому сегменті: сезонність і нові механіки дають хибні спрацювання, і пороги доводиться вести вручну.
Коли потрібна модель на поведінкових подіях
Коли важливо зловити відхід за дні до нього й розрізняти причини, працює модель на подіях: агрегати за вікнами, векторні представлення епізодів, калібрування ймовірності за фактичними результатами.
Плата за це — розмітка «відхід/повернення», контроль якості моделі та перенавчання при зміні балансу механік. Зате ризик приходить із поясненням: які дії гравця його підняли.
Етапи впровадження: від аудиту даних до передачі моделі
Порядок робіт фіксуємо до старту: кожен етап закінчується артефактом, який замовник приймає окремо, — так впровадження не перетворюється на «ми щось навчили, розбирайтеся самі». Нижче — етапи впровадження прогнозування відтоку гравців від аудиту даних до передачі рішення.
Аудит даних і постановка метрики
- Аудит даних і розмітки: вивантажуємо історію сесій, платежів і внутрішніх подій, перевіряємо глибину, повноту й розбіжності між системами, відсікаємо ботів і тестові акаунти. На виході — карта джерел і перелік прогалин, які закриваємо до навчання.
- Постановка метрики: домовляємося, що вважаємо відтоком — відхід на задану кількість днів, падіння активності відносно особистого темпу гравця або відмову від платежів. Тут же фіксуємо горизонт прогнозування і припустиму частку хибних спрацювань, щоб пропозиції утримання не йшли на лояльних гравців.
- Складання схеми ознак: активність за різні вікна, динаміка відносно особистої норми, платіжна поведінка, соціальні зв'язки, прогрес у режимах, відгук на минулі акції. Кожну ознаку документуємо — джерело, формула розрахунку, поведінка при пропуску значення.
Перевірка на історичних періодах і передача
- Навчання моделі та підбір порогу спрацювання під конкретні задачі утримання.
- Перевірка якості моделі: проганяємо на відкладених історичних відрізках, включно зі святковими та кризовими тижнями, і дивимося не середню точність, а потрапляння в топ-сегмент ризику — скільки гравців із найбільш «гарячих» справді пішли. Окремо перевіряємо стійкість: метрика не повинна просідати при зміні сезону або оновленні гри.
- Моніторинг і передача рішення: віддаємо відтворюване навчання, документацію за ознаками, панель контролю дрейфу даних і регламент перенавчання. Команда замовника веде модель далі без нас — це і є критерій завершеного проєкту.
Артефакти: схеми ознак, конфігурації та регламенти
Після здачі в команди замовника залишається не звіт, а робочий комплект: схема ознак, конфігурація розрахунків і регламенти, за якими модель можна розвивати й перенавчати без нас.
Кожен артефакт прив'язаний до етапу експлуатації — за ним новий інженер відтворює розрахунок і розуміє, де межі застосовності.
Схема ознак і розмітка
- Схема ознак: перелік сигналів із вікнами агрегації — частота й тривалість сесій, динаміка рівня, паузи між входами, зміни в покупках — із зазначенням джерела кожного поля та правила перерахунку.
- Розмітка відходу: визначення цільової події, горизонт спостереження та обробка гравців, що повернулися, щоб мітка не «пливла» між запусками й навчання залишалося зіставним.
- Документація моделі: призначення, вхідні ознаки, пороги спрацювання, обмеження застосовності та відомі режими відмови.
- Конфігурація розрахунків: параметри перерахунку ознак, вікна й розклад — запуск відтворюється однією командою, без ручних правок.
Регламенти моніторингу якості
- Регламент моніторингу: які метрики якості вважаються щоденно, які пороги вважаються деградацією, хто реагує і в який строк.
- Журнал контролю зсуву: порівняння розподілів ознак і частки спрацювань з еталонним періодом — розходження видно до того, як упадуть продажі.
- Інструкція з перенавчання та відкату на попередню версію з критеріями, коли перенавчання обов'язкове, а коли достатньо перерахунку ознак.
Усі документи лежать поруч із кодом, версіонуються разом із ним і оновлюються за тим самим регламентом, що й сама модель.
Кейс: як змінилися метрики утримання після впровадження
Проєкт вівся на чинній мобільній грі з багатомільйонною установчою базою: поведінкові події збиралися в Amplitude, але рішення щодо утримання ухвалювалися за тижневими зведеннями.
Нижче — що було до старту, що змінили під час впровадження і як це відобразилося в динаміці утримання.
Вихідна ситуація та гіпотези
Відтік помічали постфактум: гравець не заходив третю добу — і лише тоді потрапляв у розсилку повернення.
Гіпотеза була не про «розумну модель саму по собі», а про момент спрацювання: якщо передбачати відхід за дві доби, у команди залишається вікно на дію, а контакт не виглядає запізнілим.
Ознаки брали поведінкові: падіння частоти ігрових сесій, обрив прогресії на одному й тому самому рівні, зникнення соціальних дій, зміна темпу набору досвіду. Модель навчали на історичних періодах, заздалегідь виключаючи ознаки, які опосередковано «підглядають» майбутнє.
Результат у динаміці утримання
Сигнал приходив за дві доби до фактичного відходу: точність близько 0,8 при частці хибних спрацювань порядку 15%. Кампанії повернення йшли лише тим, у кого спрацював сигнал — масових розсилок по всій базі не було.
Утримання 7-го дня зросло на 6 процентних пунктів, 30-го — на 4. Частка тих, хто повернувся після контактного сценарію, становила 22% проти 9% у контрольній групі, а навантаження на комунікації не зросло.
Результат проєкту: відтік перестав бути фактом зі звіту й став керованою метрикою зі зрозумілим регламентом реакції.
Чим відрізняється скоринг ризику відходу від поведінкової сегментації?
Скоринг ризику відходу відповідає на питання «хто і як скоро піде»: для кожного гравця на заданому горизонті рахується ймовірність, яка оновлюється в міру накопичення подій.
Поведінкова сегментація відповідає інакше — «на які групи схожі гравці і що з кожною групою робити»: на виході не число, а кілька стійких сегментів з описом поведінки.
Різниця підходів починається з даних. Скорингу потрібна розмітка: ми фіксуємо визначення відтоку (наприклад, відсутність сесій довше заданого порогу) і беремо історію, де подія вже підтверджена.
Сегментація розмітки не потребує — вона групує активність за ознаками: частота й глибина сесій, динаміка прогресу, соціальні зв'язки, реакція на внутрішньоігрові події. Тому скоринг чутливий до того, як визначено відтік, а сегментація — до зіставності ознак між гравцями.
Перевіряємо їх теж по-різному. Для скорингу — контроль на відкладеному періоді: модель навчається на минулому, оцінюється на майбутньому, без перемішування подій, інакше якість виявиться завищеною.
Дивимося частку потраплянь у верхню частину списку ризику, стабільність ймовірностей і чи зберігається порядок між когортами. Для сегментації — стійкість груп: чи не розсипаються вони при зміні періоду, чи розрізняються профілі та чи змінюється дія для кожного сегмента.
Критерії вибору прості. Якщо під гравця є регулярна дія — нагадування, персональна пропозиція, зміна складності — і потрібен момент спрацювання, беруть скоринг ризику відходу.
Якщо мета зрозуміти аудиторію, перебудувати баланс або контент і вирішити, куди вкладати зусилля, починають із поведінкової сегментації. На практиці це не альтернатива: сегменти задають контекст, а скоринг усередині сегмента дає точку, в якій варто втрутитися.
Ми починаємо з перевірки даних: чи є підтверджений відтік, чи вистачає історії, чи розрізняються періоди між собою. Стійкий сигнал — будуємо скоринг, ні — спочатку сегментацію, щоб отримати картину аудиторії.
Обмеження: розмітка, дисбаланс класів, зсув даних
Гравці, які йдуть, — рідкісний клас: у вікні спостереження це одиниці відсотків від активної бази, тому частка правильних відповідей нічого не говорить про якість.
Ми рахуємо метрики на верхньому децилі ймовірностей, де рішення реально ухвалюються, і підбираємо поріг під ціну помилок: пропустити того, хто йде, дорожче, ніж зайвий раз показати йому пропозицію.
Якість розмітки обмежує стелю сильніше, ніж вибір алгоритму: момент відходу розмитий — видалення акаунта, пауза між сезонами та зміна платформи виглядають у телеметрії схоже.
Мітку будуємо за подійною історією з явним вікном підтвердження і звіряємо частку тих, хто пішов, із публічними дослідженнями утримання: розходження шукаємо в правилах розмітки, а не в моделі.
Зсув даних — головний обмежувач прогнозу: сезонність, релізи контенту та правки балансу змінюють поведінку аудиторії, і модель, навчена на минулому відрізку, втрачає точність.
Валідацію робимо за часом — навчання на ранньому періоді, перевірка на пізнішому, — а не випадковим перемішуванням записів.
У роботі відстежуємо розходження розподілів ознак і метрику на верхньому децилі: вихід за поріг запускає перенавчання на свіжому вікні замість тихої деградації.
Частина відтоку непередбачувана в принципі — відхід із зовнішніх причин не залишає слідів в ігрових подіях. Тому прогноз вбудовуємо в рішення з горизонтом: важливо, за скільки днів попередження дає запас на дію.
Що робити, якщо якість уже просіла після зсуву?
Перенавчаємо на останньому вікні та порівнюємо на відкладеному періоді. Якщо розрив не скорочується, повертаємо попередню стабільну версію моделі та додаємо ознаки, що пояснюють нову поведінку, — втрати якості обмежені однією версією, а не всією системою.
Обговоримо задачу: дані, горизонт, метрика якості
Щоб оцінка проєкту спиралася на факти, а не на середні цифри по ринку, на старті нам потрібний мінімум ввідних.
Розкид трудомісткості між двома схожими на словах задачами кратний: модель на логах сесій і модель на ознаках із білінгу, внутрішньоігрової економіки та звернень у підтримку збираються й перевіряються по-різному. Тому першим кроком обговорюємо задачу та вимоги до даних.
- визначення відтоку: скільки днів без активності вважаємо відходом гравця і чи однаково це для новачка та для платного гравця;
- горизонт прогнозування: 7, 14 або 30 днів — від нього залежать і набір ознак, і робочий поріг спрацювання;
- метрика якості: що важливіше — не пропустити того, хто йде, чи не турбувати лояльного; звідси точність і повнота на вибраному порозі;
- вивантаження подій: 2-3 вікна спостереження, щоб перевірити стійкість моделі, а не підігнати її під один відрізок;
- склад полів: сесії, покупки, прогрес, канали залучення, звернення в підтримку;
- канал дії: лист, внутрішньоігрова пропозиція або ручна обробка — під нього підбираються пороги й частота спрацювань;
- обмеження: знеособлення, строки зберігання, затримка між подією та її потраплянням у сховище.
За цими відповідями збираємо оцінку проєкту та план робіт: етапи, строки, зона відповідальності нашої команди та вашої сторони, точки проміжної перевірки якості. Опишіть задачу у вільній формі — повернемося з розбором, оцінкою та пропозицією щодо реалізації.
