Реалізація AI-передбачення оттоку користувачів у мобільному додатку
Відтік користувачів простіше запобігти, ніж повернути втраченого. Проблема в тому, що до моменту, коли користувач припинив заходити, уже пізно: він прийняв рішення кілька днів тому. Churn prediction — це система, яка ідентифікує «вот-вот уйдуть» за 7–14 днів до реального оттоку, поки retention-механіки ще працюють.
Що передбачуємо та на яких даних
Визначення «оттоку» залежить від типу додатка. Для щоденного трекера — не відкривав 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 — модель строити не з чого.
ML-модель: що вибираємо
Gradient Boosting працює краще всього на табличних даних з «поведінковими» ознаками. XGBoost або LightGBM — індустріальний стандарт. Нейронні сети тут надлишкові: у тебе, скоріше за все, кілька десятків ознак, а не тисячі.
Типова точність на добре підготованих даних: precision 0.70–0.80, recall 0.65–0.75 при threshold 0.5. Важливо: оптимізуй recall, а не precision — краще відправити retention-оффер користувачу, який не пішов би, ніж пропустити реального churn'ера.
Навчання — на історичних даних з розміткою: користувач у момент T був у групі ризику, через 14 днів дійсно пішов (Y=1) або залишився (Y=0). Клас несбалансований: churners зазвичай 10–25% від бази. Застосовуємо SMOTE або class_weight='balanced'.
Інфраструктура на бекенді
Скоринг користувачів — батчевий процес, не 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), high risk (> 0.6). Для high risk — триггер retention-дій.
Retention actions з мобільного додатка
Результат передбачення використовується на клієнті через Backend-Driven UI або push-кампанії:
Push-сповіщення: для high risk сегменту — персоналізоване нагадування про цінність додатка. Не «Ми сумуємо по тобі!» — це не працює. А «Ви не записували видатки 5 днів — ваш бюджет може вийти за ліміт». Конкретна, релевантна причина повернутися.
In-app повідомлення: при наступному відкритті — спец-пропозиція або onboarding-підказка для користувача, застрявшого на певному кроці.
Downgrade prevention: якщо користувач заходив у налаштування підписки — триггер для показу retention-оффера перед скасуванням.
Інтеграція на мобільній стороні: при старті сесії додаток запитує конфіг з бекенду (Firebase Remote Config або власний endpoint), отримує retention_variant для поточного користувача та рендерить потрібний UI.
Процес роботи
Аудит поточної аналітики → визначення churn definition → проектування feature pipeline → збір та розмітка історичних даних → навчання та валідація моделі → інтеграція скорингу в бекенд → налаштування retention-триггерів → A/B тест retention actions → моніторинг precision/recall у продакшені.
A/B тест обов'язковий: контрольна група high-risk користувачів без retention actions, експериментальна — з ними. Иначе не зрозумієш, працює ли модель.
Орієнтири за термінами
Базова модель з batch-скорингом та push-сповіщеннями — 3–4 тижні при наявності 6+ місяців історичних даних. Повна система з feature pipeline, A/B тестом, дашбордом моніторингу та автоматичним переобученням — 8–12 тижнів. Вартість розраховується індивідуально.