Відтік користувачів простіше запобігти, ніж повернути втраченого. Проблема в тому, що на момент, коли користувач перестав заходити, вже пізно: він ухвалив рішення кілька днів тому. Ми допомагаємо впровадити churn prediction — систему, яка ідентифікує «ось-ось підуть» за 7–14 днів до реального відтоку, поки retention-механіки ще працюють. За 5 років ми реалізували понад 50 проєктів у сфері мобільної аналітики та ML. Наш досвід показує, що вчасно виявлений ризик відтоку підвищує retention на 15–25%, а економія на залученні нових користувачів становить до 30% маркетингового бюджету.
Як ми прогнозуємо відтік і на яких даних?
Визначення «відтоку» залежить від типу додатку. Для щоденного трекера — не відкривав 7 днів. Для e-commerce — не здійснював покупку 30 днів. Для підписного сервісу — скасування або non-renewal. Модель має знати це визначення заздалегідь.
Ознаки (features), які працюють на практиці:
- Частота сесій за останні 7/14/30 днів з трендом (зростає / падає)
- Середня тривалість сесії та її динаміка
- Кількість виконаних ключових дій (onboarding steps завершені, платіж здійснено)
- Days since last session — найпотужніша одинична ознака
- Прогрес у core flow: користувач, який не додав перший запис у щоденник, піде з імовірністю 80%
- Push notification open rate за 14 днів
- Версія додатку та платформа (іноді краші на конкретній версії дають аномальний відтік)
Дані беремо з мобільної аналітики: Firebase Analytics, Amplitude, Mixpanel або власний event pipeline. Ключове — правильно налаштувати події на клієнті до початку ML-роботи. Якщо немає session_start, key_action_complete, payment_initiated — модель будувати нема з чого.
Чому Gradient Boosting кращий за нейромережі для цього завдання?
Gradient Boosting Wikipedia працює найкраще на табличних даних із «поведінковими» ознаками. XGBoost або LightGBM — індустріальний стандарт. Нейронні мережі тут надлишкові: у тебе, швидше за все, кілька десятків ознак, а не тисячі.
Типова точність на добре підготовлених даних: precision 0.70–0.80, recall 0.65–0.75 при threshold 0.5. Важливо: оптимізуй recall, а не precision — краще відправити retention-оффер користувачеві, який не пішов би, ніж пропустити реального churn'ера. Дослідження показують, що XGBoost дає точність до 80% на подібних задачах.
Навчання — на історичних даних з розміткою: користувач на момент T був у групі ризику, через 14 днів дійсно пішов (Y=1) або залишився (Y=0). Клас незбалансований: churners зазвичай 10–25% від бази. Застосовуємо SMOTE або class_weight='balanced'.
Як часто потрібно перенавчати модель?
Рекомендується щомісячне перенавчання на свіжих даних з ретроспективною розміткою. При значних змінах продукту — негайно. Процес автоматизується в pipeline. Це гарантує актуальність прогнозів і збереження точності на рівні 75–80%.
Докладніше про метрики
Precision, recall, F1-score, AUC-ROC — стандартний набір для оцінки якості моделі. Поріг прийняття рішення (threshold) підбирається індивідуально: при підвищенні recall зростає кількість хибних спрацювань, що збільшує вартість retention-кампаній. Рекомендуємо фіксувати threshold після A/B тесту.Які retention actions найефективніші?
Результат прогнозу використовується на клієнті через Backend-Driven UI або через push-кампанії:
- Push-сповіщення: для high risk сегменту — персоналізоване нагадування про цінність додатку. Не «Ми сумуємо за тобою!» — це не працює. А «Ви не записували витрати 5 днів — ваш бюджет може вийти за ліміт». Конкретна, релевантна причина повернутися.
- In-app повідомлення: при наступному відкритті — спецпропозиція або onboarding-підказка для користувача, який застряг на певному кроці.
- Downgrade prevention: якщо користувач заходив у налаштування підписки — тригер для показу retention-оффера перед скасуванням.
Інтеграція на мобільній стороні: при старті сесії додаток запитує конфіг з бекенду (Firebase Remote Config або власний endpoint), отримує retention_variant для поточного користувача і рендерить потрібний UI.
Що входить у результат роботи?
- Документація по feature pipeline та визначенню відтоку
- Навчена модель з кодом і конфігами
- Інтеграція batch-скорингу у ваш бекенд
- Налаштування retention-тригерів (push, in-app, remote config)
- Дашборд моніторингу precision/recall
- Навчання команди роботі з системою
Інфраструктура на бекенді
Скоринг користувачів — батчевий процес, не realtime. Запускаємо щодобово: забираємо події з analytics pipeline (BigQuery, ClickHouse, або власне сховище), будуємо feature vector для кожного активного користувача за останні 30 днів, прогоняємо через модель, записуємо в таблицю user_churn_score(user_id, score, risk_segment, calculated_at).
| Сегмент | Score | Дія |
|---|---|---|
| Low risk | < 0.3 | Без дій |
| Medium risk | 0.3–0.6 | Push-сповіщення |
| High risk | > 0.6 | Персоналізоване retention-пропозиція |
Порівняння алгоритмів для churn prediction
| Алгоритм | Типова точність | Швидкість навчання | Інтерпретованість |
|---|---|---|---|
| XGBoost | 75–80% | Висока | Середня |
| LightGBM | 73–78% | Дуже висока | Середня |
| Logistic Regression | 65–70% | Висока | Висока |
| Neural Network | 70–75% | Низька | Низька |
Gradient Boosting залишається найкращим вибором для мобільної аналітики завдяки балансу точності та продуктивності.
Як впровадити churn prediction: покроковий план
-
Аудит поточної аналітики — перевіряємо, які події вже надсилаються, чи є
session_startта ключові дії. - Визначення churn definition — фіксуємо, що вважати відтоком для вашого продукту.
- Проєктування feature pipeline — створюємо pipeline для щоденного розрахунку ознак.
- Збір та розмітка історичних даних — збираємо дані за останні 6+ місяців, розмічаємо відтік.
- Навчання та валідація моделі — тренуємо XGBoost/LightGBM, підбираємо threshold.
- Інтеграція скорингу в бекенд — запускаємо batch-процес.
- Налаштування retention-тригерів — зв'язуємо скоринг з push, in-app, remote config.
- A/B тест retention actions — перевіряємо ефективність моделі та механік.
- Моніторинг precision/recall у продакшені — автоматичне перенавчання.
A/B тест обов'язковий: контрольна група high-risk користувачів без retention actions, експериментальна — з ними. Інакше не зрозумієш, чи працює модель.
Орієнтири за термінами
Базова модель з batch-скорингом та push-сповіщеннями — 3–4 тижні за наявності 6+ місяців історичних даних. Повна система з feature pipeline, A/B тестом, дашбордом моніторингу та автоматичним перенавчанням — 8–12 тижнів. Вартість розраховується індивідуально.
Замовте аудит поточної аналітики, і ми запропонуємо оптимальне рішення для вашого додатку. Отримайте консультацію з налаштування churn prediction.