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