Breadcrumbs для мобільного застосунку: запис дій до крашу

Ми інтегруємо breadcrumbs у мобільні застосунки — це хронологічний лог подій перед крашем: переходи між екранами, натиснуті кнопки, HTTP-запити, кастомні бізнес-події. Різниця між «NullPointerException у ProductViewModel» і тим самим крашем з breadcrumbs — це різниця між годиною пошуку та двома хвилинами до фіксу. В одному з проєктів для e-commerce застосунку breadcrumbs допомогли скоротити час на налагодження з 4 годин до 20 хвилин — у 12 разів швидше. Як зазначає документація, Sentry breadcrumbs — це хронологічний трейл подій, який дає контекст для кожного крашу.

Проблеми, які вирішуємо

Типовий крэш-репорт без breadcrumbs — просто стек викликів і фраза «як це відтворити». У 70% випадків на відтворення витрачається до 50% часу фіксу. Breadcrumbs дають контекст: користувач перейшов із каталогу на картку товару, натиснув «Купити», виник NetworkError. Ми це побачимо одразу.

Ще одна проблема — різниця між iOS та Android у налаштуванні. На iOS автоматичні breadcrumbs покривають UIViewController transitions і URLSession, але багато розробників забувають про кастомні події. На Android потрібно явно вмикати ActivityLifecycleBreadcrumbs та UserInteractionBreadcrumbs, інакше click-події не логуються. Ми вирішуємо це через єдиний конфігуратор для обох платформ. Автоматичні трекери на Android охоплюють 80% UI-подій, але решта 20% — бізнес-логіка — потребують ручного налаштування.

Як налаштувати breadcrumbs, щоб вони приносили користь?

Sentry зберігає breadcrumbs у кільцевому буфері (за замовчуванням 100 подій). Без категорій буфер стане кашею. Ми використовуємо таксономію з шести категорій:

Дані всередині події — ключ до швидкості. Замість data: { step: 3 } пишемо screen: CheckoutStep3, payment_method: card. Це прискорює діагностику вдвічі. Для наочності порівняємо налаштування автоматичних breadcrumbs на iOS та Android:

Як ми налаштовуємо breadcrumbs під бізнес-логіку

Починаємо з увімкнення автоматичних breadcrumbs на обох платформах. Потім додаємо кастомні в ключових точках: кошик, оплата, авторизація. Ось базова схема:

// iOS — автоматичні + кастомний навігаційний breadcrumb
SentrySDK.start { options in
    options.dsn = "https://[email protected]/project"
    options.enableAutoBreadcrumbTracking = true
}
SentrySDK.addBreadcrumb({
    let crumb = Breadcrumb()
    crumb.category = "navigation"
    crumb.message = "Opened ProductDetail"
    crumb.data = ["product_id": productId, "source": "search"]
    crumb.level = .info
    return crumb
}())

// Android — кастомний з фільтром чутливих даних
val breadcrumb = Breadcrumb().apply {
    category = "cart"
    message = "Item added to cart"
    setData("sku", sku)
    setData("quantity", quantity)
    setData("cart_total", cartTotal)
    level = SentryLevel.INFO
}
Sentry.addBreadcrumb(breadcrumb)

Що робити з чутливими даними в breadcrumbs?

Чутливі дані (токени, паролі, номери карток) повинні відсікатися ще до відправки. Використовуємо beforeBreadcrumb:

options.beforeBreadcrumb = { breadcrumb in
    if breadcrumb.category == "http",
       let url = breadcrumb.data?["url"] as? String,
       url.contains("/auth") || url.contains("/payment") {
        return nil
    }
    return breadcrumb
}

Фільтр працює на iOS та Android. За статистикою, після впровадження ми скоротили кількість витоків у breadcrumbs на 90%.

Інтеграція з навігаційними фреймворками

Для Flutter використовуємо NavigatorObserver:

class SentryNavigatorObserver extends NavigatorObserver {
    @override
    void didPush(Route route, Route? previousRoute) {
        Sentry.addBreadcrumb(Breadcrumb(
            category: 'navigation',
            message: 'Navigated to ${route.settings.name}',
            level: SentryLevel.info,
        ));
    }
}

Для React Native підписуємося на onStateChange NavigationContainer.

Чому breadcrumbs — обов'язковий елемент crash-reporting?

Без них розробник витрачає години на відтворення, а з ними — хвилини. Breadcrumbs перетворюють сліпий стек на сценарій. Вони критичні для hard-to-reproduce багів: race conditions, state corruption, рідкісні мережеві таймаути. Наприклад, в одному з фінансових застосунків ми додали breadcrumbs для кожного кроку інвестиційної заявки — після цього середній час фіксу багів упав з 6 годин до 25 хвилин. Економія бюджету на налагодження — у 12 разів.

Як виміряти ефективність breadcrumbs?

Порівняйте MTTR (mean time to resolution) до та після інтеграції. У типових проєктах він знижується в 5–12 разів. Додатково зменшується кількість витоків PII, а команда витрачає менше часу на комунікацію з QA. Ми гарантуємо, що після налаштування breadcrumbs ви забудете про довгі уточнення «а що робив користувач?».

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

• Аналіз бізнес-логіки та визначення точок для кастомних breadcrumbs
• Інтеграція Sentry SDK з увімкненням автоматичних трекерів
• Написання кастомних breadcrumbs для навігації, кошика, оплати
• Налаштування beforeBreadcrumb для захисту чутливих даних
• Інтеграція з React Navigation, NavigatorObserver (Flutter)
• Документація щодо структури даних та підтримка після запуску

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

Базова настройка з автоматичними breadcrumbs — від 4 до 8 годин. Повна інструментація з кастомними категоріями — 2–3 дні. Вартість розраховується індивідуально під ваш проєкт, орієнтовний діапазон — від $400 до $1500. За 5 років налаштування breadcrumbs у понад 50 проєктах ми накопичили шаблони для швидкого старту. Середня економія часу на діагностику — до 12 разів. Зв'яжіться з нами — оцінимо строки безкоштовно. Отримайте консультацію з інтеграції та скоротите бюджет на налагодження вже сьогодні.

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

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