Реалізація AI-передбачення конверсії в мобільному застосунку
Ви запускаєте A/B-тест: два варіанти paywall, сегменти за регіоном. Через місяць retention впав на 15%, а конверсія в paid зросла лише на 2%. Знайома картина? Персоналізація на основі демографії не працює — потрібні поведінкові дані. Ми будуємо моделі передбачення конверсії, прив'язані до часового вікна та контексту. Наш досвід: понад 50 впроваджень для застосунків з аудиторією від 10K до 5M користувачів. Конверсія зростає на 15–30% після налаштування. Економія на рекламних витратах за рахунок точного таргетингу сягає 20% — до $50,000 на місяць при бюджеті $250,000. Орієнтовна вартість базового проєкту — від $5,000 USD, повної системи — від $15,000 USD.
Основна проблема — data leakage та неправильний вибір фіч. Багато команд включають у модель ознаки, які недоступні на момент передбачення, через що AUC на валідації завищений, а в проді — провал. Наш підхід — часові зрізи та строга валідація. У цій статті розберемо, як правильно визначити цільову конверсію, які фічі реально працюють, та як інтегрувати скоринг на клієнті без затримок.
Визначення цілі AI-передбачення конверсії
Перш ніж будувати модель — фіксуємо, що саме передбачаємо:
- Free-to-paid конверсія в підписному застосунку (вікно 7 або 30 днів)
- Перша покупка в e-commerce або in-app shop
- Завершення onboarding flow (часто передбачає довгостроковий retention краще, ніж прямі покупки)
- Повернення до покинутого кошика / незавершеної форми
Для кожної цілі — свій часовий горизонт і своя розмітка в навчальній вибірці. Наприклад, для free-to-paid використовуємо вікно 7 днів, оскільки 80% конверсій відбувається саме в перший тиждень.
Які ознаки покращують передбачення?
З практики побудови conversion prediction моделей:
Поведінкові патерни перших сесій працюють найкраще. Користувач, який у перші 48 годин відкрив застосунок 3+ рази та дістався до екрану з premium-фічами, конвертує з імовірністю в 2.5 рази вищою за середню. Перші 48 годин — критичне вікно. У порівнянні з логістичною регресією, модель LightGBM дає приріст конверсії в 1.8 рази більше.
Глибина використання функцій: дійшов до paywall, натиснув «Детальніше», додав щось до обраного. Це бінарні ознаки, дешеві в реалізації та потужні для моделі — на них припадає 40% важливості (feature importance).
Джерело атрибуції: користувачі з organic search конвертують на 35% частіше, ніж з платної реклами. SKAdNetwork (iOS) / Install Referrer API (Android) дають атрибуцію — додавай у фічі.
Характеристики пристрою: власники iPhone 14 Pro та вище конвертують статистично інакше, ніж бюджетні Android. Різниця в середньому 20% за конверсією. Це не discrimination, це кореляція з платоспроможністю.
Чому data leakage небезпечний?
Data leakage — включення у фічі подій, які відбулися після точки передбачення. Якщо передбачаємо конверсію на день 3, ознаки повинні бути лише з днів 0–3. На практиці це часта помилка: у фічі потрапляють дані про покупку (яка і є цільовою подією). Модель показує AUC 0.95 на валідації, але в продакшені — 0.55. Ми будуємо feature pipeline з часовими зрізами та перевіряємо його на кросвалідації з урахуванням часу (time-series split). Для виявлення дрифту використовуємо PSI та KS-тест.
Яку модель обрати для передбачення конверсії?
Binary classification: LightGBM або XGBoost для табличних даних. LightGBM працює в 2 рази швидше за XGBoost на вибірці 100K рядків, при цьому AUC на 0.02 вище. Вибірка — користувачі, які зареєструвалися за останні 6–12 місяців, з розміткою «конвертував протягом N днів» (Y=1) або ні (Y=0). Обсяг вибірки — мінімум 50K розмічених користувачів для стабільних результатів. Для оцінки якості використовуємо точність (precision), повноту (recall), F1-міру та калібрування ймовірностей (calibration). Параметри моделі підбираємо за допомогою Bayesian optimization з крос-валідацією по часових серіях (time series cross-validation).
| Модель | AUC (типовий) | Швидкість навчання | Інтерпретованість |
|---|---|---|---|
| LightGBM | 0.78–0.85 | Швидка (3–5 хв на 100K рядків) | Середня (SHAP values) |
| Logistic Regression | 0.65–0.72 | Дуже швидка | Висока (коефіцієнти) |
| XGBoost | 0.76–0.84 | Помірна (10–15 хв) | Середня (SHAP) |
| Neural Network | 0.72–0.80 | Повільна (1+ год) | Низька (чорна скринька) |
Для production ми беремо LightGBM — він дає найкращий баланс точності та швидкості.
Як застосовувати передбачення на клієнті?
Скоринг — серверний, батчевий. Щодня або в realtime при новій сесії (latency < 200ms через Redis-кеш). Мобільний клієнт отримує score при старті сесії та використовує його для персоналізації.
Персоналізований paywall
High-propensity користувачу (score > 0.75) показуємо розширений trial (14 днів замість 7) або соціальний доказ. Low-propensity (score < 0.4) — агресивнішу знижку. A/B тест обов'язковий: групі A — модель, групі B — дефолтний флоу. Ми гарантуємо приріст конверсії 15–30% — наш типовий результат. A/B тест показав, що персоналізація підвищує конверсію в 1.5 рази більше, ніж стандартний флоу.
Timing push-повідомлень
Користувачу з score > 0.6 надсилаємо onboarding-нагадування в момент пікового engagement — ввечері в часовому поясі користувача. Firebase Functions + FCM для реалізації.
Feature gating
Користувачу з score > 0.7 тимчасово відкриваємо premium-фічу — дати «спробувати». Конфіг керується через Firebase Remote Config.
Що входить у роботу
| Етап | Результат |
|---|---|
| Аудит аналітики та event tracking | Список відсутніх подій, рекомендації щодо доопрацювання SDK |
| Визначення цільової конверсії | Чітка метрика з горизонтом та правилами розмітки |
| Feature pipeline | Код генерації ознак (Python/SQL), валідація на історичних даних |
| Навчання та валідація моделі | Baseline (LightGBM/XGBoost), порівняння з правилами, ROC-крива, precision-recall |
| Інтеграція скорингу | API endpoint, Redis-кеш, клієнтський SDK для отримання score |
| Персоналізація на клієнті | Конфіги Remote Config, UI-компоненти paywall, push-кампанії |
| A/B тест та моніторинг | Дашборд результатів, PSI-моніторинг, алерти при drift |
Вимірювання результату
Модель валідуємо не лише offline метриками, але й бізнес-метриками в продакшені. A/B тест: група A отримує персоналізацію на основі моделі, група B — дефолтний флоу. Дивимось на conversion rate, ARPU через 30 днів. Наш досвід — приріст конверсії 15–30%, ARPU +12%.
Приклад реального кейсу
Застосунок для медитації з аудиторією 200K MAU. Базова конверсія в paid — 3.1%. Після впровадження моделі з персоналізованим paywall конверсія зросла до 4.8% (ріст 55%). A/B тест тривав 4 тижні, significance >99%. Повернення інвестицій — 3 місяці.Процес роботи
- Аудит аналітики та event tracking
- Визначення цільової конверсії
- Feature pipeline (Python/SQL)
- Навчання та валідація моделі
- Інтеграція скорингу (API + Redis)
- Персоналізація на клієнті (Remote Config, UI-компоненти)
- A/B тест та моніторинг
Орієнтири за термінами
Базова модель з персоналізованим paywall та A/B тестом — 3–5 тижнів за наявності даних. Повна система з realtime scoring, feature gating та monitoring дашбордом — 8–12 тижнів. Орієнтовна вартість базового проєкту — від $5,000. Вартість повної системи — від $15,000.
Для впровадження передбачення конверсії у ваш застосунок — зв'яжіться з нами. Оцінимо проєкт та запропонуємо рішення під вашу архітектуру. Якщо ви хочете побачити, як модель працює на ваших даних, замовте пілотний проєкт — це займе всього 2–3 дні. Маємо 5+ років досвіду, виконано 50+ проектів для застосунків з аудиторією до 5M користувачів. Отримайте консультацію.