Налаштування атрибуції встановлень (Install Attribution)

Налаштування атрибуції встановлень (Install Attribution)

Ми налаштували атрибуцію для 50+ мобільних додатків — від фінтех-стартапів до геймінгу з різними бюджетами. Типовий біль: рекламний бюджет розмазаний по п'яти каналах (Google UAC, Meta Ads, TikTok, Telegram, ASA), встановлення йдуть, конверсії є, але маркетинг не знає, який канал приніс покупця. Без коректної атрибуції до 40% бюджету йде на ботів і нецільові встановлення. Наша гарантія — прозора звітність по кожному встановлювачу та економія коштів.

Як працює атрибуція: MMP в середині ланцюжка

Mobile Measurement Partner — незалежна третя сторона між рекламними мережами та вашим додатком. Принцип: користувач клікає на рекламу — MMP фіксує клік з параметрами кампанії. Після встановлення SDK додатку зіставляє пристрій зі збереженим кліком і повертає атрибуцію джерелу. Ключові гравці: AppsFlyer, Adjust, Branch, Kochava. Для України AppsFlyer та Adjust — стандарт.

Механіка матчингу після iOS 14.5 розділилася:

• Deterministic (точний): через SKAdNetwork-постбеки — коли користувач дав дозвіл ATT
• Probabilistic (ймовірнісний): по fingerprint (IP + User-Agent + час кліку) — без ATT, точність 60–70%

На Android Google Play Referrer API дає точний атрибуційний токен без дозволів.

Як налаштувати інтеграцію AppsFlyer на iOS та Android?

iOS (Swift)

// AppDelegate.swift
import AppsFlyerLib

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    AppsFlyerLib.shared().appsFlyerDevKey = "YOUR_DEV_KEY"
    AppsFlyerLib.shared().appleAppID = "123456789"
    AppsFlyerLib.shared().delegate = self
    AppsFlyerLib.shared().isDebug = false // тільки dev
    return true
}

func applicationDidBecomeActive(_ application: UIApplication) {
    AppsFlyerLib.shared().start() // після відповіді ATT
}

Згідно офіційної документації AppsFlyer (AppsFlyer Developer Guide), start() не можна викликати до відповіді на ATT — інакше Apple заблокує постбек. Правильна послідовність: показати ATT → дочекатися відповіді → викликати start().

Android (Kotlin)

AppsFlyerLib.getInstance().init("YOUR_DEV_KEY", object : AppsFlyerConversionListener {
    override fun onConversionDataSuccess(data: Map<String, Any>) {
        val campaign = data["campaign"] as? String
        val mediaSource = data["media_source"] as? String // "googleadwords_int" для Google UAC
    }
    override fun onConversionDataFail(error: String) {}
    override fun onAppOpenAttribution(data: Map<String, Any>) {}
    override fun onAttributionFailure(error: String) {}
}, this)

AppsFlyerLib.getInstance().start(this)

На Android додайте залежність com.android.installreferrer:installreferrer:2.2 — без неї атрибуція Google UAC буде ймовірнісною.

Чому постбеки критичні для оптимізації рекламних кампаній?

Без постбеків рекламні мережі не отримують сигнал про цільові події (покупка, реєстрація). Google UAC та Meta оптимізуються під встановлення, а не під in-app event. Налаштування постбеків у кожну мережу — обов'язковий крок. Типова помилка: не вказано event_name для покупки в постбеку Meta, через що мережа вважає конверсією просто встановлення. Вартість виправлення такої помилки — значна.

Deeplink-атрибуція: де найчастіше ламається

OneLink (AppsFlyer) / Universal Links / App Links дозволяють атрибутувати не тільки встановлення, але й конкретний deeplink. Користувач клікає по посиланню в Telegram, встановлює додаток — і потрапляє на потрібний екран з коректною атрибуцією.

Типові помилки:

• Universal Links перестають працювати після оновлення додатку — не оновлено apple-app-site-association файл або змінено Bundle ID.
• Відсутній onAppOpenAttribution — повторні переходи по deeplink не атрибутуються.
• В Android не вказано intent-filter для App Links, і система відкриває браузер замість додатку.

Порівняння MMP: AppsFlyer vs Adjust vs Branch

Наш досвід: для фінтеху з високою ціною встановлення краще підходить AppsFlyer через більш точний anti-fraud. Для e-commerce з глибоким deeplinking — Branch забезпечує кращий користувацький досвід.

Процес інтеграції

Перевірка коректності атрибуції

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

• Вибір MMP та ліцензування (якщо потрібно)
• Інтеграція SDK на обидві платформи (iOS + Android)
• Налаштування ATT-flow та SKAdNetwork
• Конфігурація постбеків у 3+ рекламні мережі
• Реалізація deeplink-атрибуції (OneLink / Branch Links)
• Тестування та верифікація

Гарантія: ми надаємо звіт про тестування та постбеків. Наші інженери сертифіковані по AppsFlyer та Adjust.

Терміни та вартість

• Базова інтеграція одного MMP на обидві платформи: 3–5 днів
• З налаштуванням deeplink та всіх рекламних постбеків: до 7 днів
• Вартість розраховується індивідуально — зв'яжіться з нами для оцінки. Зазвичай бюджет варіюється в залежності від складності.

Помилки, яких варто уникати

• Виклик start() до ATT — блокування постбеків Apple.
• Відсутність обробника onAppOpenAttribution — втрата атрибуції повторних переходів.
• Ігнорування Apple App Site Association — Universal Links не працюють.
• Неправильний event name в постбеку — мережа не оптимізується під цільову дію.
• Використання одного postback URL для всіх мереж — кожна мережа потребує свій формат.

Замовте інтеграцію атрибуції — ми налаштуємо MMP під ваш стек та рекламні канали за 5–7 днів. Отримайте консультацію по вашому проекту.

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

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