Crash-репортинг в мобильном приложении: зачем и как настроить

Коротко. Crash-репортинг — это автоматический сбор отчётов о падениях мобильного приложения: стек вызовов, модель устройства, версия ОС и сборки, действия пользователя перед сбоем. Сервис группирует тысячи отчётов в несколько задач. Главная метрика — crash-free users; на практике для продакшена целятся в 99,5–99,9 %. Google Play может снизить видимость приложения, если доля пользователей со сбоями выше 1,09 %.

У Google есть конкретный порог стабильности. По правилам Android vitals приложение считается проблемным, если заметные пользователю падения (user-perceived crash rate) превышают 1,09 % в среднем по всем устройствам или 8 % на какой-то отдельной модели телефона. Считается это по скользящему окну 28 дней. При превышении Google Play может снизить видимость приложения в сторе и показать пользователям предупреждение прямо на его странице. Без сбора и разбора крашей держаться ниже этих порогов вслепую не получится, поэтому инструменты вроде Firebase Crashlytics и Sentry давно стали стандартной частью мобильного стека.

Для бизнеса crash-репортинг — это прежде всего скорость. Без него о падении вы узнаёте из гневного отзыва с одной звездой или из звонка в поддержку, причём через дни после релиза. С ним — через несколько минут после первого сбоя, вместе со стеком вызовов, моделью устройства и шагами, которые к нему привели. Поэтому мы закладываем crash-репортинг в каждый проект по разработке мобильных приложений ещё до первого релиза, а не после первых жалоб.

В статье разберём, что такое crash-репортинг и что попадает в отчёт, какие метрики стабильности отслеживать и какие пороги действуют в Google Play, чем отличаются Crashlytics, Sentry, AppMetrica и встроенные консоли сторов, как настроить сбор крашей за семь шагов и выстроить процесс разбора так, чтобы отчёты не копились без дела.

Что такое crash-репортинг и чем он отличается от логов

Crash-репортинг — это автоматический сбор, отправка и группировка отчётов о сбоях мобильного приложения у реальных пользователей. SDK внутри приложения перехватывает падение, сохраняет состояние в момент ошибки и при следующем запуске отправляет отчёт в сервис. Там одинаковые падения объединяются в одну проблему (issue) со счётчиком затронутых пользователей.

Обычные логи устроены иначе. Это поток текстовых записей обо всём, что делает приложение, и на устройстве пользователя они, как правило, недоступны разработчику. Чтобы найти в них причину падения, нужно знать, где искать. Crash-отчёт, наоборот, создаётся ровно в момент сбоя и сразу отвечает на три вопроса: что сломалось, где в коде и при каких условиях. Логи при этом не лишние: короткий хвост последних записей полезно прикладывать к самому отчёту.

Что считается крашем: необработанное исключение, нативный сигнал, ANR

По определению Android, краш — это аварийное завершение приложения из-за необработанного исключения в коде на Java или Kotlin либо из-за сигнала в нативном коде на C или C++ (например, обращение к недопустимому адресу памяти). На iOS аналогично: исключение Objective-C или Swift, которое никто не перехватил, или завершение процесса системой по сигналу.

Отдельный класс проблем — зависания. На Android это ANR (Application Not Responding): главный поток слишком долго не отвечает на ввод, и система предлагает пользователю закрыть приложение. На iOS схожую роль играет watchdog: если приложение не успевает запуститься или выйти из фона за отведённое время, система его завершает. Формально это не исключение в коде, но для пользователя разницы нет: приложение «упало», и Google Play учитывает ANR отдельной метрикой.

Fatal и non-fatal ошибки

Сервисы crash-репортинга разделяют ошибки на два типа:

• Fatal — приложение завершилось аварийно. Это и есть краш в узком смысле, он попадает в метрики стабильности.
• Non-fatal — исключение перехвачено кодом, приложение продолжает работать, но разработчик явно отправил ошибку в сервис. Например, не удалось распарсить ответ сервера, оплата вернула неожиданный статус, не загрузилась картинка профиля.

Non-fatal часто важнее, чем кажется. Пользователь не видит падения, но видит пустой экран или кнопку, которая «ничего не делает». Если такие ошибки не собирать, проблема проявится только в падении конверсии, и искать её придётся по косвенным признакам.

Что входит в crash-отчёт

Хороший crash-отчёт содержит достаточно данных, чтобы воспроизвести проблему без переписки с пользователем. Типичный набор полей такой:

Поле отчёта	Что содержит	Зачем нужно
Стек вызовов (stack trace)	Цепочка функций и строк кода, которая привела к сбою, по каждому потоку	Показывает точное место ошибки в коде
Тип ошибки	Класс исключения или сигнал, текст сообщения	Помогает отличить, например, NullPointerException от нехватки памяти
Устройство и ОС	Производитель, модель, версия Android или iOS, ориентация экрана	Выявляет сбои, характерные для конкретных моделей и прошивок
Версия и номер сборки	versionName / build number приложения	Показывает, в каком релизе появилась или исчезла проблема
Время и длительность сессии	Когда произошёл сбой и сколько приложение работало до него	Отделяет падения на старте от падений в долгой работе
Состояние устройства	Свободная память и диск, тип сети, заряд, фон или передний план	Объясняет сбои из-за нехватки ресурсов или потери сети
Custom keys	Пары «ключ — значение», которые задаёт разработчик: экран, тариф, флаг эксперимента	Добавляет бизнес-контекст, которого нет в стеке
Breadcrumbs и логи	Последние действия и события перед сбоем: переходы, нажатия, запросы	Восстанавливает сценарий, который привёл к падению
Идентификатор пользователя	Анонимный ID, по которому можно найти все сбои одного человека	Помогает поддержке и не раскрывает персональные данные

Зачем бизнесу crash-репортинг

Crash-репортинг нужен бизнесу, потому что каждое падение приложения — это прерванный сценарий пользователя: незавершённая покупка, неотправленная заявка, брошенная регистрация. Сервис превращает эти потери из невидимых в измеримые и показывает, какие из них стоят дороже всего.

Вот что он даёт на практике:

• Рейтинг и отзывы. Пользователи, у которых приложение падает, чаще всего идут писать отзыв. Чем раньше команда узнаёт о сбое, тем меньше таких отзывов успевает появиться.
• Видимость в сторе. Google Play напрямую учитывает стабильность через Android vitals: превышение порогов может снизить видимость приложения и добавить предупреждение на его страницу.
• Деньги в воронке. Краш на экране оплаты — это потерянная транзакция, а не просто баг. Связка crash-репортинга с аналитикой мобильного приложения показывает, на каком шаге воронки происходят сбои и сколько пользователей они задевают.
• Скорость исправления. Отчёт со стеком, устройством и breadcrumbs позволяет починить проблему за часы. Без него разработчик тратит дни на попытки воспроизвести её на своём телефоне.
• Приоритеты. Видно, какой баг задел 2 000 пользователей, а какой — троих. Команда чинит самое массовое и критичное, а не то, на что громче всех пожаловались.

Crash-репортинг — фундамент для пострелизного сопровождения. Подробно о том, что ещё входит в эту работу, мы писали в статье «Техническая поддержка мобильного приложения»: мониторинг сбоев там — первый пункт.

Какие метрики стабильности отслеживать

Ключевая метрика стабильности мобильного приложения — crash-free users, доля пользователей, у которых за период не было ни одного падения. Рядом с ней смотрят crash-free sessions, а для Android — ещё и официальные crash rate и ANR rate из Google Play Console, потому что именно по ним стор оценивает приложение.

Crash-free users и crash-free sessions

В документации Sentry Release Health эти метрики определены так:

• Crash-free sessions — процент сессий, которые не завершились крашем;
• Crash-free users — процент уникальных пользователей, у которых за выбранный период не было ни одного краша.

Разница на примере. За день приложение открыли 1 000 человек, всего было 10 000 сессий. Один пользователь на старой модели телефона запускал приложение 50 раз, и все 50 раз оно падало. Crash-free sessions будет 99,5 % (50 упавших из 10 000), а crash-free users — 99,9 % (один из 1 000). Теперь обратная ситуация: 50 разных людей упали по одному разу. Crash-free sessions те же 99,5 %, а crash-free users уже 95 %. Вторая ситуация гораздо хуже для бизнеса, поэтому users — главная метрика, а sessions — вспомогательная.

Crash rate и ANR rate в Google Play Console

Google Play оценивает стабильность Android-приложений по метрикам Android vitals. Ключевые из них — user-perceived crash rate и user-perceived ANR rate: доля активных за день пользователей, которые столкнулись с заметным им сбоем или зависанием. Пороги «плохого поведения» опубликованы в документации Android vitals:

Метрика	Порог в среднем по устройствам	Порог на одну модель телефона
User-perceived crash rate	1,09 %	8 %
User-perceived ANR rate	0,47 %	8 %
Crash rate на часах (Wear OS)	4 %	—
ANR rate на часах (Wear OS)	5 %	—

Важные детали, которые часто упускают:

• метрики считаются по скользящему окну 28 дней, поэтому одна неудачная неделя сказывается на приложении почти месяц;
• порог 8 % на отдельную модель означает, что можно иметь отличный средний показатель и всё равно получить проблемы из-за одного популярного устройства;
• для новых проблем Google показывает раздел emerging issues: если проблема держится больше 7 дней, у разработчика есть 21 день, чтобы её исправить, прежде чем она повлияет на видимость.

Какие значения считать хорошими

Официальной нормы для crash-free users нет — есть только пороги Google Play, ниже которых опускаться опасно. На практике команды ориентируются на такие значения:

• 99,9 % и выше — хороший уровень для зрелого продукта, особенно для финтеха, e-commerce и приложений, которыми пользуются каждый день;
• 99,5–99,9 % — рабочий уровень, но стоит смотреть, какие проблемы съедают оставшиеся доли процента;
• ниже 99 % — сигнал, что стабильностью нужно заняться прицельно, до следующих фич.

Это ориентиры из практики, а не стандарт. Для внутреннего корпоративного приложения с сотней пользователей одна проблема на одном телефоне сразу роняет метрику на проценты, а для массового продукта 0,1 % — это тысячи людей. Поэтому смотрите на динамику между релизами и на разбивку по устройствам, а не только на одно число.

Какие инструменты crash-репортинга выбрать

Инструменты crash-репортинга делятся на две группы: SDK-сервисы, которые встраиваются в приложение и присылают отчёты почти в реальном времени (Firebase Crashlytics, Sentry, AppMetrica), и встроенные консоли сторов, которые собирают краши без кода, но с задержкой и без контекста (Google Play Console, Xcode Organizer и App Store Connect).

Параметр	Firebase Crashlytics	Sentry	AppMetrica	Google Play Console	Xcode Organizer / App Store Connect
Платформы	iOS, Android, Flutter, Unity; React Native — через сторонние библиотеки	iOS, Android, Flutter, React Native, Unity, веб и бэкенд	iOS, Android, Flutter, React Native, Unity	Только Android	Только платформы Apple
Нужен ли SDK	Да	Да	Да	Нет	Нет
Скорость данных	Почти в реальном времени	Почти в реальном времени	Почти в реальном времени	С задержкой	С задержкой
Алерты	Новые, регрессии, рост (velocity)	Гибкие правила и интеграции	Есть	Ограниченно	Ограниченно
Breadcrumbs и custom keys	Да, плюс события Analytics	Да	Да	Нет	Нет
Self-hosted	Нет	Да	Нет	Нет	Нет
Стоимость	Бесплатно в составе Firebase	Есть бесплатный тариф и платные планы	Бесплатный базовый функционал	Бесплатно	Бесплатно
Особенности для РФ	Облако Google, данные за рубежом	Self-hosted позволяет держать данные на своих серверах	Российский сервис Яндекса	Обязательна для Android-публикации в Google Play	Обязательна для публикации в App Store

Firebase Crashlytics

Firebase Crashlytics — самый распространённый сервис crash-репортинга для нативных и Flutter-приложений. Он собирает отчёты с iOS, Android, Flutter и Unity, группирует лавину падений в короткий список проблем и показывает для каждой серьёзность и распространённость. Алерты в реальном времени приходят о новых проблемах, регрессиях (проблема вернулась после исправления) и о резком росте числа сбоев. Отдельный плюс — связь с Google Analytics: Crashlytics пишет событие app_exception и подтягивает события Analytics как breadcrumbs. Подсказки Crash Insights предлагают типичные причины распространённых сбоев.

Sentry

Sentry — платформа мониторинга ошибок, которая работает не только с мобильными приложениями, но и с вебом и бэкендом. Для мобильной команды это значит, что краш в приложении и ошибку на сервере, которая его вызвала, можно увидеть в одной системе и связать. В Sentry есть раздел Release Health с метриками crash-free sessions и users по каждому релизу, мониторинг производительности и гибкая настройка алертов. Важная для российских компаний деталь — Sentry можно развернуть self-hosted на своих серверах.

AppMetrica

AppMetrica — платформа мобильной аналитики Яндекса со встроенной крэш-аналитикой: отчёты о сбоях собираются SDK «из коробки» вместе с продуктовыми событиями. Для российских проектов это естественный выбор, если AppMetrica уже используется для аналитики и атрибуции или если важно, чтобы сервис был российским. Функциональность крэш-аналитики проще, чем у специализированных инструментов, но для многих приложений её достаточно.

Встроенные консоли Apple и Google — почему их мало без SDK

Google Play Console и Xcode Organizer собирают сбои без единой строки кода. Apple в руководстве Acquiring crash reports and diagnostic logs описывает несколько каналов: Xcode Organizer для отчётов из App Store и TestFlight, отзывы бета-тестеров и фреймворк MetricKit, через который приложение само получает диагностику. Это полезный источник, но у него есть ограничения:

• отчёты приходят только от пользователей, которые согласились делиться диагностикой с разработчиком;
• данные появляются с задержкой, а не через минуты после сбоя;
• нет пользовательского контекста: custom keys, breadcrumbs, логов;
• не собираются non-fatal ошибки;
• гибких алертов в мессенджер или трекер нет.

Поэтому консоли сторов используют в паре с SDK-сервисом: консоль — как официальный взгляд стора на ваше приложение, SDK — как рабочий инструмент команды.

Как выбрать инструмент: 6 критериев

Инструмент crash-репортинга выбирают по стеку приложения и требованиям к данным, а не по популярности. Мы смотрим на шесть критериев:

• Стек и кроссплатформа. Нативные Swift и Kotlin поддерживаются везде. Для Flutter, React Native и Kotlin Multiplatform проверьте качество SDK и символикацию нативной и кроссплатформенной частей.
• Где хранятся данные. Если в отчёты могут попасть персональные данные или у заказчика есть требования к локализации данных, это сразу сужает выбор.
• Self-hosted. Нужна ли установка на собственных серверах — например, для банков, госсектора и внутренних корпоративных приложений.
• Интеграции. Создание задач в Jira или YouTrack, алерты в корпоративный мессенджер, связь с CI для загрузки символов.
• Бюджет и лимиты. Бесплатные тарифы ограничены объёмом событий или сроком хранения. При большой аудитории считайте заранее, во что обойдётся платный план.
• Нужна ли производительность. Если кроме крашей нужно отслеживать медленный старт, долгие запросы и тормозящие экраны, смотрите на платформы с мониторингом производительности.

Ситуация	Что выбрать
Нативные iOS и Android или Flutter, уже используется Firebase	Firebase Crashlytics
React Native, Kotlin Multiplatform или единый мониторинг приложения и бэкенда	Sentry
Требование хранить данные в РФ или на своих серверах	AppMetrica или self-hosted Sentry
AppMetrica уже используется для аналитики и атрибуции	Крэш-аналитика AppMetrica, при необходимости плюс Crashlytics или Sentry
MVP с минимальным бюджетом	Firebase Crashlytics или AppMetrica плюс консоли сторов

Два SDK crash-репортинга в одном приложении ставить можно, но осторожно: оба перехватывают необработанные исключения, и порядок их инициализации влияет на то, кто получит отчёт. Обычно достаточно одного основного инструмента и консолей сторов.

Как настроить crash-репортинг: 7 шагов

Настройка crash-репортинга — это не только подключение SDK. Чтобы отчёты были полезными, нужно позаботиться о символах, контексте и алертах. Мы идём по семи шагам.

1. Выберите инструмент и заведите проекты по окружениям. Определитесь с сервисом по критериям выше. Создайте отдельные проекты или окружения для dev, stage и prod: тестовые падения разработчиков не должны портить боевые метрики и будить дежурного ночью.
2. Подключите SDK и инициализируйте его как можно раньше. SDK добавляется через Gradle на Android, Swift Package Manager или CocoaPods на iOS, pub во Flutter и npm в React Native. Инициализируйте его в самом начале запуска приложения — до загрузки конфигурации, базы и сетевых клиентов. Иначе падения на старте, самые болезненные для пользователя, пройдут мимо.
3. Настройте автоматическую загрузку символов. Для iOS нужны файлы dSYM, для Android — mapping-файлы ProGuard или R8 и символы нативных библиотек. Загружайте их из CI для каждой сборки, которая уходит пользователям, подробнее — в следующем разделе.
4. Добавьте контекст. Задайте custom keys (текущий экран, тариф, вариант A/B-теста), пишите короткие логи в ключевых местах, установите анонимный идентификатор пользователя. Breadcrumbs — переходы между экранами, нажатия и запросы — покажут, что человек делал перед сбоем.
5. Логируйте non-fatal ошибки. В критичных местах — сеть, оплата, авторизация, парсинг ответов — отправляйте перехваченные исключения в сервис. Это ловит проблемы, при которых приложение не падает, но и не работает.
6. Настройте алерты. Включите оповещения о новых проблемах, регрессиях и резком росте числа сбоев (velocity alerts). Отправляйте их в канал, который команда реально читает, а не на общий email, который никто не открывает.
7. Проверьте тестовым крашем до релиза. Вызовите искусственное падение в release-сборке и убедитесь, что отчёт пришёл, стек символизирован, а custom keys на месте. Затем прогоните бету через TestFlight или закрытое тестирование в Google Play — бета-тестеры поймают то, что не нашли в QA.

Схематично инициализация в любом SDK выглядит одинаково — сервис, окружение, версия и контекст:

onAppStart():
    crashReporter.init(dsn/appId, environment = "prod", release = "2.4.1 (412)")
    crashReporter.setUserId(anonymousId)         // без email и телефона
    crashReporter.setKey("screen", currentScreen)

onPaymentError(e):
    crashReporter.recordNonFatal(e, key = "payment_step")

Подробности для каждой платформы — в официальной документации, например в руководстве Firebase по настройке отчётов Crashlytics: там описаны custom keys, логи, идентификаторы пользователей и breadcrumbs из Analytics. Проверка сбора отчётов, кстати, хорошо вписывается в регрессионное тестирование — о том, какие ещё проверки нужны мобильному приложению, мы рассказывали в статье «Виды тестирования мобильных приложений».

Почему краш-отчёт бывает нечитаемым: символикация и обфускация

Краш-отчёт бывает нечитаемым, когда сервис не может сопоставить адреса памяти и сокращённые имена в стеке вызовов с исходным кодом. Вместо понятного PaymentViewModel.confirm() в отчёте оказываются шестнадцатеричные адреса или имена вида a.b.c(), и найти место ошибки становится почти невозможно.

Причины разные для платформ:

• iOS. В release-сборке имена функций убраны из бинарника. Чтобы восстановить их, нужен файл dSYM (debug symbols) именно от этой сборки. Процесс восстановления называется символикацией.
• Android, Kotlin и Java. R8 или ProGuard обфусцируют и сжимают код: классы и методы переименовываются в короткие бессмысленные имена. Расшифровать стек помогает mapping-файл, который создаётся при каждой сборке.
• Android, нативный код. Для библиотек на C и C++ нужны файлы символов, иначе стек нативного краша состоит из адресов.
• Flutter и React Native. К нативным символам добавляются свои: символы Dart при обфусцированной сборке Flutter, source maps для JavaScript-бандла React Native.

Правило одно: символы хранятся для каждой сборки, которая когда-либо попала к пользователям, и загружаются в сервис автоматически из CI. Ручная загрузка «когда вспомним» заканчивается тем, что через месяц приходит волна крашей из старой версии, а символов к ней уже нет.

Как выстроить процесс разбора крашей

Процесс разбора крашей — это договорённость о том, кто смотрит новые проблемы, как определяет их приоритет и в какой срок исправляет. Без него даже идеально настроенный сервис превращается в свалку из сотен непрочитанных issues, на которые все смотрят и никто не реагирует.

Триаж: от отчёта к задаче

Триаж — регулярный разбор новых проблем. Мы проводим его так:

1. Назначьте владельца. На каждую неделю или релиз есть дежурный, который отвечает за разбор алертов. «Смотрит вся команда» на практике значит «не смотрит никто».
2. Оцените масштаб. Сколько пользователей задето, на каких версиях и устройствах, растёт ли число сбоев.
3. Оцените критичность сценария. Падение на старте или на оплате важнее, чем падение в редком разделе настроек, даже при меньшем охвате.
4. Заведите задачу. Проблема из сервиса превращается в задачу в трекере со ссылкой на issue и приоритетом.
5. Закройте цикл. После исправления отметьте issue как решённую в конкретной версии — тогда сервис сам сообщит о регрессии, если проблема вернётся.

SLA на исправление

Приоритеты удобно привязать к срокам. Вот схема, которую мы используем как отправную точку и адаптируем под проект:

Приоритет	Примеры	Реакция
P0 — критично	Падение на старте, на авторизации или оплате; массовый рост сбоев после релиза	Остановка раскатки, hotfix-релиз в ближайшие часы или сутки
P1 — высокий	Падение в важном сценарии с заметным охватом, регрессия	Исправление в ближайшем плановом релизе
P2 — обычный	Редкие сбои на отдельных устройствах, некритичные экраны	Бэклог, разбор по мере накопления

Связь с релизным процессом

Crash-репортинг сильнее всего работает в связке с поэтапной раскаткой (staged rollout). Новая версия сначала уходит небольшой доле пользователей, команда смотрит на crash-free users этой версии и только потом расширяет аудиторию. Если показатель падает ниже прежнего релиза, раскатку останавливают, пока не выйдет hotfix. Тот же принцип в большем масштабе — мягкий запуск продукта на ограниченном рынке, где стабильность проверяют до основного запуска.

Для этого crash-free users по каждой версии должен быть частью критерия готовности релиза: «раскатываем на 100 %, если стабильность не ниже, чем у предыдущей версии». Тогда регрессии ловятся на 5–10 % аудитории, а не на всех пользователях сразу.

Дежурство по крашам требует постоянного внимания команды и после релиза. Если своей команды на это нет, такую работу закрывает поддержка мобильного приложения с понятным SLA: мониторинг сбоев, триаж, hotfix-релизы и регулярные отчёты о стабильности.

Что нельзя отправлять в crash-отчёты: персональные данные

В crash-отчёты нельзя отправлять персональные и платёжные данные пользователей: телефоны, email, ФИО, адреса, токены авторизации, номера карт и пароли. Отчёты хранятся в стороннем сервисе, их видят многие участники команды, и попавшие туда данные трудно отследить и удалить.

Практические правила:

• Анонимный идентификатор вместо реального. Передавайте внутренний ID или его хеш, по которому поддержка найдёт пользователя в своей системе, — но не телефон и не email.
• Чистите логи и breadcrumbs. Не пишите в логи тела запросов и ответов целиком, маскируйте заголовки авторизации, параметры URL с токенами и поля форм.
• Используйте фильтры SDK. Большинство сервисов позволяют вычищать данные перед отправкой — например, через обработчик beforeSend в Sentry.
• Учитывайте 152-ФЗ. Если по отчёту можно определить человека, это обработка персональных данных: нужны правовое основание, упоминание в политике конфиденциальности и, при необходимости, согласие пользователя. Безопаснее устроить сбор так, чтобы персональных данных в отчётах не было вовсе.
• Проверьте, где хранятся данные. Облачные сервисы держат данные на своих серверах, часто за рубежом. Если это не подходит проекту — выбирайте AppMetrica или self-hosted Sentry.
• Дайте пользователю выбор. Переключатель «Отправлять диагностические данные» в настройках снимает часть вопросов и повышает доверие.

Типичные ошибки при внедрении

Типичные ошибки при внедрении crash-репортинга связаны не с выбором сервиса, а с настройкой и процессом. Вот что мы чаще всего видим, когда принимаем проект на аудит или поддержку:

• SDK инициализируется поздно. Сначала загружается конфиг, база и половина зависимостей, а уже потом crash-репортинг, и все падения на старте теряются.
• Нет символов. dSYM и mapping-файлы не загружаются, отчёты состоят из адресов, и команда перестаёт их открывать.
• Алерты в никуда. Оповещения уходят на почту бывшего сотрудника или в канал, где они тонут среди сотни других сообщений в день.
• Non-fatal не собираются. Ошибки оплаты и сети молча проглатываются в catch, и о них узнают только по падению выручки.
• Один проект на dev и prod. Тестовые падения смешиваются с боевыми, и метрики стабильности теряют смысл.
• Смотрят только на общий процент. Средний crash rate в норме, а на одной популярной модели телефона он выше 8 % — и Google Play это учитывает отдельно.
• Нет владельца. Сервис настроен, но issues никто не разбирает — проблема не в инструменте, а в отсутствии процесса.

Частые вопросы

Что такое crash-free users и какой показатель считается хорошим?

Crash-free users — доля уникальных пользователей, у которых за выбранный период приложение ни разу не упало. Официальной нормы нет, но на практике для продакшена ориентируются на 99,5 % и выше, а для приложений с оплатой и частым использованием — на 99,9 %. Важнее не абсолютное число, а динамика между релизами и значения на отдельных моделях устройств.

Чем краш отличается от ANR?

Краш — аварийное завершение приложения из-за необработанного исключения в Java или Kotlin либо сигнала в нативном коде. ANR (Application Not Responding) — зависание: главный поток Android-приложения слишком долго не отвечает, и система предлагает закрыть приложение. Оба показателя отдельно учитываются в Android vitals и оба влияют на видимость в Google Play.

Можно ли обойтись без SDK, только консолями Google Play и App Store Connect?

Для старта можно, но этого мало. Консоли показывают краши только от пользователей, согласившихся делиться диагностикой, данные приходят с задержкой, в отчётах нет пользовательского контекста, логов, breadcrumbs и non-fatal ошибок, а гибких алертов нет. SDK crash-репортинга даёт данные почти в реальном времени и полный контекст сбоя.

Что выбрать: Firebase Crashlytics или Sentry?

Firebase Crashlytics проще подключить в нативные iOS- и Android-приложения и во Flutter, он бесплатен в составе Firebase и связан с Google Analytics. Sentry удобнее, когда нужно видеть ошибки мобильного приложения, веба и бэкенда в одном месте, нужен мониторинг производительности или self-hosted установка на своих серверах.

Влияют ли краши на позиции приложения в Google Play?

Да. Google Play оценивает стабильность по Android vitals за скользящие 28 дней. Если доля пользователей с заметными сбоями выше 1,09 % в среднем по устройствам или 8 % на конкретной модели телефона, Play может снизить видимость приложения и показать пользователям предупреждение на странице в сторе.

Нужно ли согласие пользователя на сбор crash-отчётов?

Если отчёты содержат данные, по которым можно определить человека, — идентификатор пользователя, email, телефон, — это обработка персональных данных, и по 152-ФЗ нужны правовое основание и описание в политике конфиденциальности. Безопаснее отправлять только анонимные идентификаторы, не логировать персональные данные и дать пользователю возможность отключить сбор диагностики.