Запис сесій користувачів: Session Replay з маскуванням

Краш у продакшені, який не відтворюється на тестових пристроях, — часта біль мобільних команд. Session Replay дає точний запис дій користувача за секунди до помилки, скорочуючи час пошуку причини в 2–3 рази. За 15+ проєктів (від фінтеху до e-commerce) ми виробили практики, які дозволяють записувати сесії з overhead менше 1% та повним маскуванням персональних даних, що відповідає GDPR та PCI DSS. Наша компанія має 5 років досвіду та понад 15 успішних проєктів із впровадження Session Replay. Середній чек на послугу — $1,500.

Що таке Session Replay та його призначення

Session Replay — технологія, яка фіксує всі дії користувача: тапи, скроли, введення тексту. Отриманий запис дозволяє точно відтворити сесію, що критично важливо для налагодження помилок та аналізу UX. Відрізняється від логування тим, що дає повну візуальну картину. При цьому запис не вимагає втручання користувача та працює у фоновому режимі.

Screenshot чи Wire-frame: що вибрати?

Screenshot-based (UXCam, Smartlook) робить знімки екрану з частотою 1–5 fps, маскує чутливі області та відправляє на сервер. Точно передає кастомні View та WebView, але потребує 200–500 KB трафіку/хв та навантажує CPU на 3–8%.

Wire-frame based (Sentry, Datadog) серіалізує View-ієрархію — позиції, кольори, текст — та відтворює UI на сервері за шаблонами. Об'єм даних 50–150 KB/хв, CPU навантаження < 1%. WebView та складна графіка не передаються точно. Wire-frame підхід забезпечує в 3 рази менше навантаження на CPU, ніж screenshot.

Як Session Replay допомагає налагоджувати краші?

Sentry SR для мобільних доступний з SDK 8.x, використовує wire-frame підхід. Ключовий параметр onErrorSampleRate = 1.0 — записувати replay для всіх сесій з помилкою. SDK буферизує останні N секунд у пам'яті та відправляє разом з error report. Інтеграція з crash reports прискорює аналіз у 2 рази. Детальніше в документації Sentry Session Replay.

// iOS
import Sentry
SentrySDK.start { options in
    options.dsn = "https://[email protected]/project"
    options.experimental.sessionReplay = SentryReplayOptions(
        sessionSampleRate: 0.1,
        onErrorSampleRate: 1.0
    )
}

// Android
SentryAndroid.init(this) { options ->
    options.dsn = "https://[email protected]/project"
    options.experimental.sessionReplay.apply {
        sessionSampleRate = 0.1
        onErrorSampleRate = 1.0
    }
}

Налаштування маскування чутливих даних

За замовчуванням Sentry маскує UITextField та поля з isSecureTextEntry = true. Цього недостатньо — потрібно приховувати номери карток, персональні дані, OTP-поля. Приклад для iOS та Android:

// iOS — маркування View для маскування
class PaymentCardView: UIView {
    override func didMoveToWindow() {
        super.didMoveToWindow()
        SentrySDK.replay.maskView(self)
    }
}

// Android — маскування через тег
val cardNumberField = findViewById<EditText>(R.id.cardNumber)
cardNumberField.setTag(io.sentry.android.replay.Recorder.MASK_TAG, true)

Для SwiftUI та Jetpack Compose використовуйте модифікатори:

// SwiftUI
Text(userEmail).sentryReplayMask()

// Kotlin Compose
Text(text = cardNumber, modifier = Modifier.sentryReplayMask())

Ми гарантуємо, що маскування проходить аудит приватності відповідно до GDPR та PCI DSS. Верифікація здійснюється через Privacy Audit в Sentry/Datadog UI.

Інтеграція з crash reports

В Sentry реплей автоматично прикріплюється до error report. В Datadog Session Replay пов'язується з RUM View — можна відкрити екран та переглянути replay з метриками (latency, FPS) на таймлайні.

Порівняння інструментів: Sentry vs Datadog

Sentry wire-frame краще за CPU у 2–3 рази ніж UXCam screenshot-режим. Якщо потрібен точний запис WebView — підійде Datadog у screenshot-режимі (CPU 3–8%).

Що входить у нашу роботу з впровадження Session Replay

При замовленні послуги ви отримуєте:

• Аудит існуючого додатку: визначення чутливих екранів та полів.
• Вибір оптимального інструменту та підходу (screenshot/wire-frame).
• Підключення SDK з налаштуванням sample rate та маскування.
• Розробку кастомних маскувань для специфічних елементів UI.
• Проведення Privacy Audit з формуванням звіту.
• Інтеграцію з вашою системою моніторингу помилок (Sentry/Datadog).
• Документацію з налаштування та рекомендації для команди.
• Підтримку на етапі тестування та деплою.

Процес впровадження Session Replay

Впровадження проходить у 5 етапів:

1. Аналітика — визначаємо екрани та чутливі поля, обираємо інструмент (Sentry або Datadog).
2. Підключення SDK — налаштування onErrorSampleRate = 1.0, sessionSampleRate, конфігурація DSN.
3. Налаштування маскування — маркування всіх полів введення, карткових даних, OTP.
4. Тестування — перевірка маскування, Privacy Audit.
5. Деплой — публікація в магазини, моніторинг метрик.

Приклад: для фінтех-проєкту ми налаштували маскування 15 екранів за 2 дні. Після аудиту переконалися, що жоден чутливий символ не потрапив у запис.

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

Базове підключення з маскуванням: 2–3 дні, вартість $1,000–$2,000. Повна інтеграція з аудитом приватності: 4–5 днів. Вартість розраховується індивідуально, а економія становить до $2,000 на місяць. Для команди з 5 розробників це може становити економію до $2,000 на місяць.

Зв'яжіться з нами для консультації щодо інтеграції Session Replay. Отримайте оцінку вашого проєкту та рекомендації щодо інструменту.

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

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