Реализация AI-предсказания оттока пользователей (Churn Prediction) в мобильном приложении
Отток пользователей проще предотвратить, чем вернуть потерянного. Проблема в том, что к моменту, когда пользователь перестал заходить, уже поздно: он принял решение несколько дней назад. 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 недель. Стоимость рассчитывается индивидуально.