Налаштування Real User Monitoring (RUM) для мобільного застосунку

Налаштування Real User Monitoring (RUM) для мобільних додатків

Синтетичний мониторинг запускає скрипти у контрольованому середовищі. RUM — це дані про те, що відбувається з реальними користувачами на реальних пристроях у реальних мережах. Різниця принципова: синтетика не покаже, що у користувачів Xiaomi Redmi Note 9 список на екрані гальмує через overdraw у RecyclerView, або що користувачі на LTE в регіоні стикаються з network timeout на 8-й секунді.

Що саме трекує RUM

Стандартний набір подій у мобільному RUM:

• View — перехід на екран (відкриття, закриття, тривалість)
• Action — натиск, swipe, scroll, long press
• Resource — HTTP-запит: URL, метод, статус, розмір, latency
• Error — оброблений виняток, необроблений виняток, ANR, крах
• Long Task — операція на main thread > 100ms (Android) / main runloop > 16ms (iOS)

З усіх подій найцінніша для діагностики — Long Task у кореляції з View. Якщо 250ms Long Task відбувається при переході на екран оплати і це відтворюється у 15% користувачів — це конкретна помилка продуктивності, не «щось іноді гальмує».

Вибір інструменту

Для більшості продуктів Firebase Performance — хороший старт (безплатно, zero-config для мережі). Але як тільки потрібна кореляція з серверними трейсами або кастомні бізнес-атрибути — переходьте на Datadog або Sentry.

Налаштування з Datadog RUM

import DatadogRUM

RUM.enable(with: RUM.Configuration(
    applicationID: "your-rum-app-id",
    sessionSampleRate: 80,         // 80% сесій
    telemetrySampleRate: 20,
    trackBackgroundEvents: false   // не трекаємо фонові события
))

Параметр sessionSampleRate — перший, що потрібно налаштувати для вашого трафіку. 100% семплінг при мільйонній DAU — це дорого. Стандартна практика: 100% для нових релізів перші 48 годин (ловимо регресії), потім знижуємо до 20–30%.

Ручна інструментація екранів (SwiftUI)

struct ProductListView: View {
    var body: some View {
        List(products) { product in
            ProductRow(product: product)
        }
        .trackRUMView(name: "ProductList")
    }
}

Мониторинг конкретного мережевого запиту

// З URLSession + Datadog
let delegate = DDURLSessionDelegate()
let session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil)

Datadog автоматично інжектує x-datadog-trace-id у кожен запит через цей session — ніяких додаткових перехоплювачів не потрібно.

Типова проблема: View duration спотворюється

Частий баг при налаштуванні RUM — View закривається занадто рано. Наприклад, у UIKit без явного виклику stopView агент закриває View при viewWillDisappear, але якщо контролер показує bottom sheet поверх себе — View закриється й откроється заново, створивши дублюючий запис. Рішення:

// iOS — явне керування View lifecycle
override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    RUM.monitor?.startView(viewController: self, name: "ProductDetail")
}

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    if isMovingFromParent {
        RUM.monitor?.stopView(viewController: self)
    }
}

Сеансовий семплінг та GDPR

При включеному RUM потрібно отримати згоду користувача до початку запису сесії. На iOS використовуйте trackingConsent:

Datadog.set(trackingConsent: userConsentedToAnalytics ? .granted : .notGranted)

Для Sentry аналогічно налаштуйте SentryOptions.enableAutoSessionTracking та SentrySDK.setUser() тільки після отримання согласия.

Що ми робимо

• Вибираємо інструмент, що підходить вашому стеку та бюджету (Firebase / Sentry / Datadog / New Relic)
• Підключаємо SDK з належною sessionSampleRate для вашого трафіку
• Інструментуємо перехід на екран (UIKit, SwiftUI, Jetpack Compose, Flutter)
• Налаштовуємо HTTP-перехоплювачі для трекінгу мережевих ресурсів
• Налаштовуємо логіку согласия для GDPR
• Будуємо початковий дашборд: p75/p95 View load time, Error Rate, Long Task Rate

Часові оцінки

Базове налаштування RUM: 1–2 дні. Кастомні атрибути та дашборди: ще 1 день. Ціна розраховується індивідуально.