Реалізація 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. Це не discriminatіon, це кореляція з платіжеспроможністю.
Архітектура моделі
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 тижнів. Вартість розраховується індивідуально.