Аналитика и поддержка приложений: инструменты и лучшие практики

Аналитикой и технической поддержкой занимаются разные специалисты, но их работа связана. Поддержка фиксирует факт сбоя: например, краш (внезапное аварийное закрытие приложения), задержку во времени отклика и другие ошибки. Аналитика показывает, на каких версиях и где именно (во время онбординга, поиска, оплаты) это случается, сколько сессий прервано и заказов потеряно. Та же связка работает для улучшений: повторяющиеся обращения из поддержки превращаются в гипотезы, которые проверяют через аналитику.

Когда техподдержка и аналитика связаны, приоритеты можно расставлять по влиянию на показатели: например, в первую очередь исправляют и улучшают то, что быстрее возвращает конверсию.

Более половины компаний оценивает последний крупный инцидент дороже $100 000, около одной пятой — свыше $1 миллиона за случай. Четыре из пяти респондентов считают, что инцидент можно было предотвратить при выстроенных процессах и управлении (Uptime Institute).

Поддержка мобильного приложения

Главная задача техподдержки — быстро обнаружить и устранить любые сбои в работе приложения. В базовой модели три уровня: L1 фиксирует инцидент и ставит приоритет, L2 разбирает технические детали (журналы событий, трассировки — пути запроса, версии приложения, затронутые API и интеграции), L3 вносит изменения в код и инфраструктуру или откатывает релиз.

Поддержка должна иметь компетенции анализа ситуации: нужно воспроизвести путь, на котором возникла проблема, воспользоваться инструментами для анализа (DevTools, Kibana, Sentry, в меньшей степени Grafana) и передать обогащенную информацию дата-аналитику.

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

Руслан Юсупов, системный аналитик Friflex

Для диагностики инцидентов используют разные инструменты. Для веба — DevTools и Sentry; для логов — Elasticsearch, Kibana; для метрик и трасс — Grafana, OpenTelemetry. Для мобильных приложений — Crashlytics, Sentry и профилировщики Android Studio, Xcode Instruments.

После локализации причины поддержка привлекает исполнителей (разработчиков и DevOps, внешних партнеров — если дело касается интеграций) и ведет инцидент до восстановления.

Качество и скорость работы поддержки измеряются по SLO (целевым уровням стабильности и скорости) и двум операционным метрикам: MTTA — времени от возникновения инцидента до его принятия в работу и MTTR — времени до полного устранения инцидента.

Аналитика мобильных приложений

Система аналитики приложений — это набор правил и инструментов, который превращает пользовательские действия и технические события в метрики. В основе лежит план трекинга (карта событий): он описывает, какие события фиксируются, в каком формате передаются и как их трактовать.

Аналитики используют разные инструменты для мобильных продуктов и вэба. Для мобайла — SDK продуктовой аналитики (например, AppMetrica или Firebase). Для веба — веб-аналитику (Яндекс.Метрика или GA4).

Мониторинг ошибок (Sentry, Crashlytics) фиксирует аварийные закрытия с контекстом и дополняет эти данные. Системы наблюдаемости и APM (Datadog, New Relic, Grafana и OpenTelemetry) показывают состояние серверной части — задержки, ошибки и путь запроса между сервисами. Данные хранятся в аналитических системах управления базами данных (BigQuery, Snowflake), отчеты открываются в BI-системах (Looker, Metabase, Power BI).

Как связать работу поддержки и аналитики

Чтобы имелась связь между поддержкой и аналитикой, в мобильном приложении и на сайте все должно быть покрыто метриками. Иначе аналитика данных не даст никакого фидбека по тому, как дела у пользователей.

Можно, конечно, косвенно пользоваться Sentry (платформой для мониторинга и исправления ошибок в приложениях), но там будет заметен только некоторый процент отказов какого-то функционала. При этом, чтобы Sentry работал, его тоже нужно импортировать в клиент.

Руслан Юсупов, системный аналитик Friflex

Совместная работа начинается с общих правил. Задаются SLO и пороги для ключевых метрик (крашей, времени от открытия приложения до реакции интерфейса, времени ответа API и других). Важно договориться, какие события и поля при инциденте уходят в аналитику.

Вводится единый формат карточки инцидента. Она может содержать информацию о версии приложения и ОС, устройстве и браузере, API-методе, шаге воронки. Все инциденты и повторяющиеся обращения попадают в общий бэклог с оценкой влияния на конверсию, ретеншн и выручку. Совместные дашборды показывают одно и то же событие с точки зрения технической причины и масштаба для продукта.

Дальше работает единый порядок действий: локализация по логам и трассам, оценка масштаба в аналитике, решение и подтверждение эффекта на метриках.

Аналитика может заметить тенденции в поведении пользователей, а поддержка — внести системные изменения, чтобы не допускать простоя.

У нас есть такой кейс: бизнес-аналитик со стороны заказчика раз–два в неделю делает прямые запросы к производственной продовой (боевой, эксплуатируемой) базе данных. Запросы тяжелые и ресурсоемкие — из-за этого растет нагрузка и замедляется мобильное приложение. Поддержка обратила на это внимание и вместе с DevOps настроила отдельную реплику базы данных для аналитики (read-replica). Можно читать ее и это никак не влияет на работу мобильного приложения.

Алексей Гормаков, руководитель отдела технической поддержки Friflex

Охранные метрики качества

Для совместной работы поддержки и аналитики задают охранные метрики качества. Это стоп-линии — пороговые показатели, которые защищают продукт от деградаций при инцидентах и релизах. Если метрика вышла за предел, релиз приостанавливают или откатывают.

Охранных метрик много для разных случаев. Например, о стабильности клиента говорят краши, о состоянии интерфейса — холодный старт (время от открытия до действия), LCP (Largest Contentful Paint), INP (Interaction to Next Paint). О работе сервера и интеграций — время ответа API и частота ошибок.

Обычно выделяют три главные группы метрик. Стабильность продукта фиксируют краши, ANR, App Hangs и watchdog terminations (зависание интерфейса). Скорость первого действия — холодный старт, LCP (время загрузки основного контента). Производительность бэкенда — время ответа API.

Пороговые значения для этих метрик согласуются с целями SLO (уровнями стабильности и скорости), чтобы уведомления о проблемах и отчеты опирались на одни критерии.

Для работы с ключевыми показателями в аналитике применяют дашборды. Разные отделы берут из них ту информацию, которая им нужна. Например, поддержка следит за крашами, показателями зависания интерфейса, задержками API и другими метриками. Так одна и та же проблема видна под разными углами и решения принимаются на основе общих данных.