Настройка Release Health мониторинга (Sentry) для мобильного приложения

Настройка Release Health мониторинга (Sentry) для мобильного приложения

Мы команда с 5-летним опытом в настройке мониторинга для мобильных приложений. Настроили Release Health для более чем 20 проектов. Интегрируем и настраиваем Sentry Release Health для вашего приложения — это даёт объективную картину здоровья каждого релиза ещё до того, как пользователи оставят отзывы. Без этой системы деградация часто остаётся незамеченной до жалоб. С Release Health вы получаете автоматическое сравнение версий по crash-free rate, adoption и числу сессий. Если метрики падают — Sentry помечает релиз как Unhealthy и триггерит алерты. Наш опыт показывает: такая настройка окупается за первый же инцидент. Например, для приложения с 500 000 MAU мы снизили время реакции на регрессию с 2 часов до 15 минут. Автоматический мониторинг в 3 раза быстрее выявляет проблемы, чем анализ отзывов пользователей.

Как Sentry вычисляет Crash Free Rate?

В основе Release Health лежат сессии. Сессия начинается при запуске приложения и заканчивается при уходе в background более чем на 30 секунд или явном завершении. Каждая сессия маркируется либо как crashed, либо как ok. Crash Free Rate = (сессии без крэшей / общее число сессий) × 100%. Sentry автоматически агрегирует эти данные по каждому релизу.

// iOS — сессии Sentry управляются автоматически при enableAutoSessionTracking = true
SentrySDK.start { options in
    options.dsn = "https://[email protected]/project"
    options.releaseName = "MyApp@\(Bundle.main.releaseVersionNumber)+\(Bundle.main.buildNumber)"
    options.environment = "production"
    options.enableAutoSessionTracking = true
    options.sessionTrackingIntervalMillis = 30_000 // 30 сек в background = новая сессия
}

// Android
SentryAndroid.init(this) { options ->
    options.dsn = "https://[email protected]/project"
    options.release = "myapp@${BuildConfig.VERSION_NAME}+${BuildConfig.VERSION_CODE}"
    options.environment = "production"
    options.enableAutoSessionTracking = true
    options.sessionTrackingIntervalMillis = 30_000L
}

Параметр releaseName должен совпадать с тем, что передаётся при загрузке dSYM (iOS) или ProGuard mapping (Android) в Sentry. Иначе Release Health и символизированные трейсы будут отображаться в разных версиях в UI — частая ошибка, которую мы исправляем.

Почему важно загружать dSYM и ProGuard mapping?

Без символов вы не увидите читаемые стектрейсы в Issues. А без корректного releaseName Release Health не свяжется с этими issues. Мы автоматизируем загрузку через Sentry CLI в CI/CD.

# Fastlane — Fastfile
lane :upload_dsyms_to_sentry do
  sentry_upload_dsym(
    auth_token: ENV["SENTRY_AUTH_TOKEN"],
    org_slug: "your-org",
    project_slug: "ios-app",
    dsym_path: "./build/MyApp.app.dSYM"
  )
end

Или через sentry-cli в CI/CD:

sentry-cli releases new "[email protected]+456"
sentry-cli releases set-commits "[email protected]+456" --auto
sentry-cli upload-dsyms ./build/MyApp.app.dSYM
sentry-cli releases finalize "[email protected]+456"

set-commits --auto привязывает git-коммиты к релизу. Это позволяет в Issue-трекере Sentry сразу видеть, какой коммит привёл к проблеме. Мы гарантируем, что эта цепочка настроена без разрывов.

Как читать Release Health в UI Sentry?

В разделе Releases отображается ключевая метрика — Crash Free Rate. Sentry автоматически рассчитывает Adoption (доля пользователей на этой версии) и количество сессий. Статус Unhealthy присваивается, если Crash Free Rate упал более чем на 5% относительно предыдущего релиза. Мы настраиваем этот порог под ваш проект.

Как настроить алерты на деградацию?

Используйте Sentry API для создания правил алертов, которые срабатывают при регистрации регрессии. Пример на Python:

# Sentry API — создать Alert Rule
import requests

rule = {
    "name": "Release Health Degradation",
    "environment": "production",
    "actionMatch": "all",
    "conditions": [
        {
            "id": "sentry.rules.conditions.regression_event.RegressionEventCondition"
        }
    ],
    "filters": [
        {"id": "sentry.rules.filters.latest_release.LatestReleaseFilter"}
    ],
    "actions": [
        {
            "id": "sentry.integrations.slack.notify_action.SlackNotifyServiceAction",
            "workspace": "SLACK_WORKSPACE_ID",
            "channel": "#mobile-releases"
        }
    ],
    "frequency": 60
}

requests.post(
    f"https://sentry.io/api/0/projects/YOUR_ORG/ios-app/rules/",
    headers={"Authorization": "Bearer YOUR_TOKEN"},
    json=rule
)

Мы также создаём post-deploy скрипт, который сравнивает Crash Free Rate нового релиза с предыдущим через API — это позволяет заблокировать pipeline, если деградация превышает допустимый порог.

Сравнение конфигураций iOS и Android

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

• Интеграция enableAutoSessionTracking с правильным форматом releaseName для iOS и Android
• Подключение Sentry CLI в CI/CD для автоматической загрузки dSYM и ProGuard mapping
• Настройка git commit tracking через set-commits
• Создание алертов на Regression Event с нотификацией в Slack или Telegram
• Реализация post-deploy check Crash Free Rate для gate в pipeline
• Документация по процессу и рекомендации по порогам метрик

Кейс из практики

На одном из проектов — приложении для доставки еды с аудиторией 500 000 MAU — после обновления версии crash-free rate упал на 8% за час. Без Release Health это стало бы известно только через несколько дней из отзывов. Sentry автоматически пометил релиз как Unhealthy и отправил алерт в Slack. Мы за 30 минут откатили релиз и исправили регрессию. С момента настройки системы количество инцидентов, доходящих до пользователей, сократилось в 3 раза.

Сроки и стоимость

Базовая настройка Release Health занимает 4–8 часов. Интеграция в CI/CD с автозагрузкой символов — 1–2 дня. Стоимость рассчитывается индивидуально. Получите бесплатную оценку вашего проекта — свяжитесь с нами. Оценим ваш проект за 30 минут и предложим план интеграции.

Аналитика мобильных приложений: 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 и Wikipedia.

Как решить проблему мультиканальной атрибуции с 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 успешных проектов в сфере мобильной разработки. Мы гарантируем корректность данных и прозрачность каждого этапа.

Свяжитесь с нами, чтобы получить консультацию по настройке аналитики вашего приложения. Закажите аудит текущей аналитики — и мы покажем, какие метрики вы теряете.