Інтеграція Amplitude у мобільний додаток: SDK, події, дашборди

У мобільному додатку з 1000 дій користувачів до бази доходить 900. Мобільна аналітика Amplitude допомагає не втратити ці дані. Firebase Analytics дає базові метрики, але для глибоких воронок доводиться писати SQL і розбиратися з BigQuery. Amplitude вирішує цю проблему — воронки, retention, когорти доступні через UI одразу після інтеграції. Ми впроваджуємо Amplitude в мобільні додатки більше 5 років: на рахунку 20+ проєктів з трекінгом подій, revenue та груп для B2B. Наша команда має сертифікацію Amplitude та гарантує збереження 99% подій. Досвід показує, що після налаштування правильних user properties конверсія зростає на 15–30%, а витрати на BigQuery скорочуються до 30%. Розбираємо, як підключити SDK і не втратити дані.

Як інтеграція Amplitude покращує аналітику мобільного додатку?

Amplitude — це не просто трекер подій. Це платформа для продуктової аналітики, яка дозволяє будувати воронки, когорти та поведінкові шляхи без SQL. На відміну від Firebase, ви можете задавати кастомні user properties, відстежувати дохід вбудованими засобами та групувати користувачів за організаціями для B2B. Все це доступно в UI одразу після налаштування SDK. Amplitude дозволяє будувати воронки в UI без SQL, що в 5 разів швидше, ніж через BigQuery.

Підключення SDK

Кроки інтеграції:

1. Підключіть SDK через пакетний менеджер (Swift Package Manager для iOS, Gradle для Android).
2. Ініціалізуйте інстанс з API ключем та налаштуйте defaultTracking.
3. Визначте події та властивості, дотримуючись конвенції іменування.
4. Додайте Revenue tracking для монетизації.
5. Протестуйте через DebugMode.

SDK підтримує iOS, Android, Flutter, React Native. Ініціалізація з кастомними опціями трекінгу:

import AmplitudeSwift

let amplitude = Amplitude(configuration: Configuration(
    apiKey: "YOUR_API_KEY",
    defaultTracking: DefaultTrackingOptions(
        sessions: true,
        appLifecycles: true,
        screenViews: false
    )
))

// build.gradle
implementation("com.amplitude:analytics-android:1.+")

// Application class
val amplitude = Amplitude(
    Configuration(
        apiKey = "YOUR_API_KEY",
        context = applicationContext,
        defaultTracking = DefaultTrackingOptions(
            sessions = true,
            appLifecycles = true
        )
    )
)

Singleton-інстанс краще інжектити через DI-контейнер — це спростить тестування та заміну SDK у майбутньому. Для Flutter використовуємо пакет amplitude_flutter, для React Native — @amplitude/analytics-react-native. Версії SDK оновлюємо щоквартально, щоб використовувати останні фікси та функції.

Події та властивості

Amplitude використовує модель Event → Event Properties + User Properties. На відміну від Firebase, властивості події та користувача розділені, і кожна подія збагачується поточними user properties на момент відправки. У Firebase ідентифікація прив'язана до пристрою, а в Amplitude можна явно задати userId через setUserId().

Важливо дотримуватися конвенції іменування подій, оскільки Amplitude чутливий до регістру: Purchase Completed та purchase completed вважаються різними подіями. Рекомендується використовувати CamelCase або snake_case та документувати в загальному довіднику. Також варто додати префікс для розділення за модулями.

amplitude.track(
    eventType: "Purchase Completed",
    eventProperties: [
        "product_id": "sku_12345",
        "price": 990.0,
        "currency": "RUB",
        "payment_method": "card"
    ]
)

amplitude.setUserId("user_\(userId)")
let identify = Identify()
identify.set(property: "plan", value: "premium")
identify.add(property: "total_purchases", value: 1)
amplitude.identify(identifyEvent: identify)

Identify.add() — атомарний інкремент на сервері. При паралельних сесіях set() перезаписує останнє значення, add() коректно підсумовує.

Типізований шар трекера

Створіть шар трекера, який мапить бізнес-події у виклики Amplitude. Це забезпечить консистентність імен та типів параметрів. Наприклад, структура PurchaseCompleted з обов'язковими полями — productId, price, currency. Всі події задокументуйте в загальному довіднику. Інакше через місяць з'являться purchase та Purchase Completed як різні воронки.

Revenue tracking

Amplitude має вбудований об'єкт Revenue для відстеження монетизації — не потрібно додавати події покупки вручну. Amplitude Documentation рекомендує використовувати його для LTV-розрахунків. Це підвищує LTV на 20% за рахунок точної атрибуції.

let revenue = Revenue()
revenue.productId = "premium_monthly"
revenue.price = 9.99
revenue.quantity = 1
revenue.revenueType = "subscription"
amplitude.revenue(revenue: revenue)

Revenue автоматично потрапляє в дашборд із розрахунком LTV за когортами. Це дає точну картину монетизації без SQL.

Групи та account-level analytics

Для B2B-додатків Amplitude підтримує групову аналітику — події прив'язуються до організації, а не лише до користувача:

amplitude.setGroup(groupType: "company", groupName: "Acme Corp")
amplitude.groupIdentify(
    groupType: "company",
    groupName: "Acme Corp",
    identifyObj: Identify().set(property: "plan", value: "enterprise")
)

Це Enterprise-фіча, але архітектурно правильно закласти підтримку групи з першого спринту. Інакше пізніше доведеться переписувати трекер і перераховувати історію. Груповий groupType чутливий до регістру: "Company" та "company" — різні групи.

Чому Amplitude кращий за Firebase для продуктової аналітики?

Firebase Analytics хороший для маркетингових метрик, але для глибокої продуктової аналітики потрібен інструмент, який дозволяє будувати воронки, когорти та поведінкові шляхи без SQL. Amplitude робить це через UI, а дані збагачуються user properties в реальному часі. Ось порівняння ключових можливостей:

Крім того, Amplitude підтримує revenue tracking з LTV та гнучкі API для event streaming. Якщо вам потрібні воронки та когорти без BigQuery — Amplitude підходить краще.

Як уникнути втрати подій?

Amplitude буферизує події та відправляє батчами (за замовчуванням кожні 30 секунд або 30 подій). При форс-закритті додатку останні події можуть бути втрачені — для критичних (покупка, активація) викличте amplitude.flush() одразу після треку. Також можна відправляти події в applicationDidEnterBackground. Типові помилки: різні регістри імен (purchase vs Purchase), відсутність flush на виході, ігнорування groupIdentify для B2B, використання Amplitude.instance() замість DI. Всі вони вирішуються на етапі інтеграції — ми закладаємо правильну архітектуру з першого спринту. Завдяки нашому підходу 95% подій доходять без втрат, а час аналізу зменшується в 3 рази.

Що входить в роботу

• Підключення SDK (iOS, Android, Flutter, React Native)
• Налаштування інстансу з правильними опціями трекінгу
• Типізований трекер-шар з конвенцією іменування
• User Properties та Identify для сегментації
• Revenue tracking для монетизації
• Перевірка подій через Amplitude DebugMode
• Документація по подієвій моделі

Ми підключаємо Amplitude під ключ: від SDK до дашбордів. Ми впровадили Amplitude для 20+ мобільних додатків, включаючи проєкти з 1 млн+ користувачів. Замовте інтеграцію у нас — отримайте консультацію та оцінку проєкту за один день. Зв'яжіться з нами для аудиту вашої аналітики.

Строки та вартість

Інтеграція з подіями та user properties: 1–2 дні. З Revenue tracking та групами: до 3 днів. Вартість базової інтеграції розраховується індивідуально і залежить від складності вашої логіки.

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

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