Реализация AI-предсказания конверсии в мобильном приложении
Конверсия в мобильном приложении — размытый термин. Регистрация, первая покупка, переход на платную подписку, выполнение целевого действия — всё это конверсии, и модель нужно строить под конкретную. Предсказание «вероятность покупки в течение 7 дней» и «вероятность завершения онбординга» — принципиально разные задачи с разными признаками и разной практической ценностью.
Определение цели конверсии
Прежде чем строить модель — фиксируем, что именно предсказываем:
- Free-to-paid конверсия в подписочном приложении
- Первая покупка в e-commerce или in-app shop
- Завершение onboarding flow (часто предсказывает долгосрочный retention лучше, чем прямые покупки)
- Возврат к заброшенной корзине / незавершённой форме
Для каждой цели — свой временной горизонт (7 дней, 30 дней) и своя разметка в обучающей выборке.
Признаки, которые реально работают
Из практики построения conversion prediction моделей:
Поведенческие паттерны первых сессий работают лучше всего. Пользователь, который в первые 48 часов открыл приложение 3+ раза и добрался до экрана с premium-фичами, конвертирует с вероятностью значительно выше среднего. Первые 48 часов — критическое окно.
Глубина использования функций: дошёл ли до paywall, нажал ли «Подробнее», добавил ли что-то в избранное. Это бинарные признаки, дешёвые в реализации и мощные для модели.
Источник атрибуции: пользователи из organic search конвертируют иначе, чем из платной рекламы. SKAdNetwork (iOS) / Install Referrer API (Android) дают атрибуцию — добавляй в фичи.
Характеристики устройства: владельцы iPhone 14 Pro и выше конвертируют статистически иначе, чем бюджетные Android. Это не discrimination, это корреляция с платёжеспособностью.
Архитектура модели
Binary classification: LightGBM или XGBoost для табличных данных, обученный на исторических когортах. Выборка: пользователи, зарегистрировавшиеся за последние 6–12 месяцев, с разметкой «конвертировал в течение N дней» (Y=1) или нет (Y=0).
Главная ловушка — data leakage. Нельзя включать в фичи события, которые произошли после точки предсказания. Если предсказываем конверсию за день 3, признаки должны быть только из дней 0–3. Звучит очевидно — на практике ошибаются часто.
Обновление модели: переобучение раз в месяц или при drift — когда distribution признаков в продакшене начинает расходиться с обучающей выборкой. PSI (Population Stability Index) для мониторинга drift.
Применение предсказания на клиенте
Скоринг — серверный, батчевый. Ежедневно или в realtime при новой сессии (latency < 200ms через Redis-кеш результатов).
Что делаем с результатом на мобильной стороне:
Персонализированный paywall. High-propensity пользователю показываем расширенный trial (14 дней вместо 7) или социальное доказательство. Low-propensity — агрессивнее скидку. A/B тест обязателен для валидации гипотез.
Timing push-уведомлений. Пользователю с высокой predicted conversion вероятностью отправляем onboarding-напоминание в момент пикового engagement — как правило, вечер в часовом поясе пользователя. Firebase Functions + FCM для реализации.
Feature gating. Пользователю с conversion score > 0.6 временно открываем premium-фичу — дать «попробовать». Конфиг управляется через Firebase Remote Config, мобильный клиент проверяет флаг при старте сессии.
Измерение результата
Модель нужно валидировать не только offline метриками (AUC, precision/recall), но и бизнес-метриками в продакшене. A/B тест: группа A получает персонализацию на основе модели, группа B — дефолтный флоу. Смотрим на conversion rate, ARPU через 30 дней.
Процесс работы
Аудит аналитики и event tracking → определение целевой конверсии и горизонта → построение feature pipeline → обучение и валидация модели → интеграция скоринга → настройка персонализации на клиенте → A/B тест → мониторинг.
Ориентиры по срокам
Базовая модель с персонализированным paywall и A/B тестом — 3–5 недель при наличии данных. Полная система с realtime scoring, feature gating и monitoring дашбордом — 8–12 недель. Стоимость рассчитывается индивидуально.