Реалізація бота для збору лідів у мобільному додатку

Форма зворотного зв'язку дає 10% конверсії, і половина лідів — «сміття». Клієнти кидають заповнення, менеджери витрачають час на холодні дзвінки. Рішення — діалоговий бот з розгалуженими питаннями, який кваліфікує ліда в реальному часі. За 5 років ми реалізували понад 15 таких інтеграцій для e-commerce та SaaS-проектів. Гарантуємо доставку push-сповіщень з SLA 99.9%.

Чому бот ефективніший за звичайну форму?

Форма збору лідів дає 10–15% конверсії, а діалоговий бот — 40–60%. Користувач не кидає заповнення, тому що бот адаптує питання під відповіді. Якщо клієнт вибирає «бюджет до певного порогу», бот позначає його як cold і не турбує менеджера. Це скорочує навантаження на відділ продажів у 2–3 рази.

Як влаштований збір лідів через бота

Мобільний додаток виступає як керівний інтерфейс: оператор бачить вхідні ліди, налаштовує воронку питань, отримує сповіщення. Сам бот працює на бекенді — через Telegram Bot API webhooks або власний чат-движок.

На практиці типова архітектура виглядає так: бот на сервері (Node.js + telegraf або Python + aiogram) приймає повідомлення користувачів, веде FSM діалогу, зберігає зібрані дані в базу, а мобільний додаток через REST/WebSocket отримує нові ліди в реальному часі.

// iOS: отримання нового ліда через WebSocket (Starscream)
socket.onEvent = { [weak self] event in
    switch event {
    case .text(let text):
        guard let lead = try? JSONDecoder().decode(Lead.self, from: Data(text.utf8)) else { return }
        DispatchQueue.main.async {
            self?.viewModel.appendLead(lead)
            self?.triggerHaptic(.notification(.success))
        }
    default: break
    }
}

Форма кваліфікації — це набір питань з розгалуженням. Наприклад: «Який у вас бюджет?» — якщо вибрано «невеликий бюджет», бот позначає лід як cold і не надсилає сповіщення. Це FSM зі станами, які зберігаються на сервері в Redis per chat_id.

Що таке картка ліда і як вона працює?

Кожен лід проходить через кілька статусів: new → in_progress → qualified / rejected. Мобільний додаток показує список з групуванням або фільтрацією за статусом — new завжди вгорі з сортуванням за часом надходження.

Детальна картка ліда містить відповіді на питання воронки у вигляді пар «питання — відповідь», а не сирого логу чату. Так оператор бачить одразу: ім'я, бюджет, тип запиту — без прокрутки переписки. Відповіді структуруються на бекенді при завершенні діалогу.

Призначення менеджера — PATCH /leads/{id} з {assignee_id}. При призначенні відповідальному приходить push. Якщо лід не взято в роботу за N хвилин — повторне сповіщення або переназначення за round-robin: логіка на бекенді, мобільний додаток тільки відображає статус.

Як забезпечити швидку доставку push-сповіщень?

Push при новому ліді — критична функція. На Android використовуємо FCM з high priority та data payload (не notification), щоб додаток отримував сповіщення навіть у фоні через FirebaseMessagingService. На iOS — APNs з content-available: 1 для silent push плюс звичайний алерт.

Як інтегрувати бота з CRM?

Інтеграція з популярними CRM (amoCRM, Bitrix24) відбувається через REST API. Після завершення діалогу бекенд відправляє POST-запит з полями ліда. Маппінг полів налаштовується один раз і займає не більше 4 годин. При необхідності реалізуємо двосторонню синхронізацію статусів.

Процес розробки

1. Аналіз бізнес-логіки та воронки питань.
2. Проектування FSM-діалогу та схеми даних.
3. Розробка бота на Node.js або Python з webhook-обробкою.
4. Реалізація мобільного додатку (SwiftUI/Jetpack Compose) зі списком лідів, push та карткою.
5. Інтеграція з CRM через REST API.
6. Тестування та деплой на сервер.

Типовий кейс: фінансовий сектор

Для одного клієнта з фінансового сектору ми розгорнули бота на Python + aiogram з FSM на Redis. Мобільний додаток (SwiftUI + Combine) отримував ліди через WebSocket. Інтеграція з amoCRM зайняла 4 години: маппінг полів, тестування, деплой. Результат: конверсія з чату в qualified лід зросла з 8% до 35%.

Порівняйте: реалізація бота під ключ займає в середньому 5–7 днів, тоді як розробка власної CRM-системи — місяці. Ми беремо на себе повний цикл: від аналітики до деплою. Зв'яжіться з нами, щоб оцінити ваш проект — ми запропонуємо архітектуру та терміни за 1 день. Отримайте консультацію щодо впровадження бота у ваш мобільний додаток.

Аналітика мобільних застосунків: 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 успішних проектів у сфері мобільної розробки. Ми гарантуємо коректність даних і прозорість кожного етапу.

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