AI-прогнозування відтоку користувачів у мобільному додатку

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

Які 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).

Порівняння алгоритмів для churn prediction

Gradient Boosting залишається найкращим вибором для мобільної аналітики завдяки балансу точності та продуктивності.

Як впровадити churn prediction: покроковий план

1. Аудит поточної аналітики — перевіряємо, які події вже надсилаються, чи є session_start та ключові дії.
2. Визначення churn definition — фіксуємо, що вважати відтоком для вашого продукту.
3. Проєктування feature pipeline — створюємо pipeline для щоденного розрахунку ознак.
4. Збір та розмітка історичних даних — збираємо дані за останні 6+ місяців, розмічаємо відтік.
5. Навчання та валідація моделі — тренуємо XGBoost/LightGBM, підбираємо threshold.
6. Інтеграція скорингу в бекенд — запускаємо batch-процес.
7. Налаштування retention-тригерів — зв'язуємо скоринг з push, in-app, remote config.
8. A/B тест retention actions — перевіряємо ефективність моделі та механік.
9. Моніторинг precision/recall у продакшені — автоматичне перенавчання.

A/B тест обов'язковий: контрольна група high-risk користувачів без retention actions, експериментальна — з ними. Інакше не зрозумієш, чи працює модель.

Орієнтири за термінами

Базова модель з batch-скорингом та push-сповіщеннями — 3–4 тижні за наявності 6+ місяців історичних даних. Повна система з feature pipeline, A/B тестом, дашбордом моніторингу та автоматичним перенавчанням — 8–12 тижнів. Вартість розраховується індивідуально.

Замовте аудит поточної аналітики, і ми запропонуємо оптимальне рішення для вашого додатку. Отримайте консультацію з налаштування churn prediction.

Аналітика мобільних застосунків: Firebase, Amplitude, AppsFlyer та атрибуція

Наша команда регулярно стикається з проектами, де аналітика вже «налаштована», але реальних інсайтів немає. Типовий приклад — стартап з 50k DAU: трекінг десятків подій без жодної відповіді на питання «чому користувачі не доходять до оплати». За два тижні ми побудували базову воронку і з'ясували, що 70% аудиторії відвалюється на екрані верифікації номера телефону. Після локалізації бага retention зріс на 12%. Висновок: аналітика повинна починатися з конкретних питань, а не з трекінгу всього підряд.

Чому таксономія подій — основа аналітики мобільних застосунків?

Firebase Analytics, Amplitude, Mixpanel — технічно схожі. Різниця в тому, що ви в них кладете. Типова помилка: події screen_view, button_tap_1, button_tap_2 без контексту. Через місяць ніхто не пам'ятає, що таке button_tap_2.

Правильна таксономія: об'єкт + дія + контекст. product_viewed, checkout_started, payment_completed з параметрами product_id, category, price, source. Це дозволяє будувати воронки, когортний аналіз та retention без додаткового трекінгу.

Ми фіксуємо naming convention у tracking plan — документі (Google Sheet або Amplitude Data Catalog), де описано кожну подію, її параметри та умови спрацьовування. Tracking plan синхронізується з командою аналітиків до початку розробки, а не після. Такий підхід гарантує, що через місяць дані залишаться інтерпретованими, а не перетворяться на звалище. Досвід впровадження на 50+ проектах підтверджує: при відсутності tracking plan вартість підтримки аналітики зростає у 2-3 рази за рахунок переробок.

Що обрати для аналітики мобільних застосунків: Firebase, Amplitude чи Mixpanel?

Таблиця нижче показує ключові відмінності трьох популярних платформ. Вибір залежить від бюджету, трафіку та завдань.

Firebase Analytics — безкоштовно, глибока інтеграція з Google Ads, BigQuery-експорт для сирих даних. Обмеження: затримка даних до 24 годин, обмежені воронки. Для стартапів з Google Ads трафіком — перший вибір.

Amplitude — продуктова аналітика з акцентом на когорти та шляхи користувача. Journeys (колишній Pathfinder) показує реальні шляхи між подіями — не передбачувані воронки, а фактичні маршрути. Session Replay — запис сесій для UX-аналізу. Безкоштовний тир до 10 млн events/місяць достатній для більшості продуктів на старті.

Mixpanel — ближче до Amplitude, сильніший у сегментації в реальному часі. Insights, Funnels, Retention — базові інструменти, які закривають 90% аналітичних завдань продакта.

Більш формальні визначення цих платформ можна знайти у Wikipedia (Firebase) та Wikipedia (Amplitude).

Як вирішити проблему мультиканальної атрибуції з AppsFlyer?

Знати звідки прийшов користувач — окреме завдання. Firebase Attribution працює лише всередині Google-екосистеми. Для мультиканальної атрибуції (Facebook Ads, TikTok, Apple Search Ads, programmatic) потрібен MMP — Mobile Measurement Partner.

AppsFlyer — лідер ринку. OneLink — universal deep link, який працює на iOS та Android і коректно атрибутує встановлення з будь-якого каналу. Protect360 — вбудований захист від fraud (фейкові встановлення, click injection на Android). Adjust та Branch — конкуренти з подібним функціоналом. Branch сильний у deep linking; Adjust популярний у gaming.

Згідно з Apple, з iOS 14.5 застосунки повинні отримувати дозвіл користувача через ATT перед збором IDFA для відстеження. AppsFlyer використовує probabilistic matching (IP + user agent + timing) для цих користувачів — точність нижча, але краще ніж нічого. SKAdNetwork та Privacy Preserving Attribution надають агреговані дані від Apple із затримкою 24-72 години.

Як налаштувати crash-аналітику, щоб не пропускати баги?

Firebase Crashlytics — стандарт для crash reporting. Автоматично групує креші за стектрейсом, показує affected users %, velocity alerts при зростанні crash rate більш ніж на 10% за годину.

Важливо: символікація. На iOS .dSYM файли повинні автоматично завантажуватися при кожній збірці — через Fastlane upload_symbols_to_crashlytics або Xcode Cloud built-in. Без символів креш у Crashlytics виглядає як набір адрес пам'яті. Це трапляється частіше, ніж здається при переході на новий CI — в одному проекті з аудиторією 500k користувачів ми виявили, що 40% крешів залишалися несимволізованими через пропущений етап у CI/CD. Після автоматизації час реакції на баги скоротився з 3 годин до 15 хвилин.

Для React Native та Flutter — @sentry/react-native та sentry_flutter дають додатковий контекст: breadcrumbs, мережеві запити перед крешем, стан Redux/Provider.

Нижче — порівняння популярних інструментів crash-аналітики для вибору під свої завдання.

Налаштування оточення

Три оточення з окремими Firebase проектами: dev, staging, production. Змішувати аналітику з тестових сесій і production — поширена помилка, яка спотворює всі метрики. На iOS через GoogleService-Info.plist для кожної схеми, на Android через google-services.json у папці кожного flavor.

Терміни: базова аналітика з Firebase + Crashlytics — 3-5 днів. Повноцінний tracking plan + Amplitude/Mixpanel з воронками та когортами — 2-3 тижні. Атрибуція через AppsFlyer з deep linking та fraud protection — 1-2 тижні. Вартість розраховується індивідуально залежно від складності інтеграцій.

Що входить у нашу роботу

В рамках впровадження аналітики ми надаємо:

• Розробку та узгодження tracking plan з командами продукту та маркетингу.
• Інтеграцію SDK (Firebase, Amplitude, Mixpanel, AppsFlyer) з урахуванням вашого стеку (Swift/Kotlin/Flutter/React Native).
• Налаштування воронок, когорт, дашбордів та алертів.
• Автоматизацію символікації та завантаження .dSYM через Fastlane.
• Документацію щодо подій та параметрів.
• Навчання команди роботі з аналітичною платформою.
• Два тижні пост-релізної підтримки та коригування трекінгу.

Наш досвід — 7 років впровадження аналітики та понад 80 успішних проектів у сфері мобільної розробки. Ми гарантуємо коректність даних і прозорість кожного етапу.

Зв'яжіться з нами, щоб отримати консультацію з налаштування аналітики вашого застосунку. Замовте аудит поточної аналітики — і ми покажемо, які метрики ви втрачаєте.