измеряя незримое: что и как измерять в мобильной разработке

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

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

Большинство компаний в Москве, которые заказывают мобильное приложение для склада, доставки или отдела продаж, смотрят в статистику Google Play Console или App Store Connect и на этом останавливаются: число установок, средняя оценка, количество удалений. Эти цифры описывают магазин приложений, а не бизнес-процесс, который приложение должно закрыть.

Полезная система метрик собирается из четырёх слоёв. Технический — crash-free rate, время холодного старта, ANR (Application Not Responding) на Android. Продуктовый — retention на 1, 7 и 30 день, глубина сессии, доля пользователей, которые доходят до целевого действия, а не просто открывают экран. Бизнес-слой — конверсия в заказ, средний чек через приложение, доля повторных заявок. И интеграционный слой, специфичный для B2B-приложений, которые обмениваются данными с 1С: время синхронизации, процент неудачных обменов, задержка между действием в приложении и его отражением в учётной системе.

Условный пример: сеть из шести розничных точек в Москве. По App Store Connect — 4,3 звезды и 1200 установок за квартал, отдел маркетинга доволен. По внутренней аналитике из этих установок только треть хотя бы раз оформила через приложение перемещение товара, а регулярно, каждую смену, им пользуется меньшая часть сотрудников. Именно эта регулярная группа — реальный охват, на который стоит опираться при планировании доработок, а не общее число установок.

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

почему возникает разрыв между метриками и реальностью бизнеса

У логистической компании 200 курьеров работают с внутренним приложением для приёма заявок. В аналитике retention держится на уровне 92%, на еженедельной встрече это зелёный график и переход к следующему слайду. Но склад в Подольске каждый понедельник в девять утра звонит в IT-отдел: сборка заявок опаздывает на 30-40 минут, потому что курьеры открывают приложение, видят список, сворачивают его и звонят диспетчеру напрямую — сессия в аналитике засчиталась, а целевое действие нет.

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

Если не разобраться в причине, потери накапливаются: диспетчер тратит по 2-3 часа в неделю на звонки, которые должно было закрыть приложение, склад срывает тайминг отгрузки, а в B2B-контракте с SLA задержка выше нормы оборачивается штрафом по договору. Отдел, который заказывал приложение за деньги, платит второй раз — временем сотрудников, продолжающих работать по телефону в обход системы, которую для того и строили, чтобы от телефона уйти.

как исправить систему метрик: от установок к деньгам

Исправление начинается не со смены SDK аналитики, а с формулировки целевого сценария на языке бизнеса: не «пользователь открыл приложение», а «курьер подтвердил доставку, и это ушло в 1С без ручного ввода». От сценария выстраивают события: старт, точки отвала, финальное действие, время между шагами.

Инструмент для сбора данных выбирают отдельно от процесса: Firebase Analytics, AppMetrica или собственная система логов одинаково хорошо посчитают открытия экрана, но не умеют сами понять, что для вашего бизнеса является завершённым сценарием. Подключение SDK — техническая задача на день, а описание событий и их владельцев — управленческая задача, которая требует участия не только разработчика, но и человека, отвечающего за процесс на земле: диспетчера, кладовщика, менеджера по продажам.

какие события фиксировать в первую очередь

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

кто отвечает за метрику

Каждый слой закрепляют за конкретным человеком. Технические метрики — за разработчиком, продуктовые — за владельцем продукта или руководителем отдела, бизнес-метрики — за коммерческим директором. Без владельца метрика превращается в цифру, которую никто не проверяет месяцами и на которую никто не реагирует, даже если график ползёт вниз.

Ниже — сравнение слоёв метрик, которые стоит держать в одном отчёте, а не в разных, не связанных друг с другом инструментах.

что делать, если проблема с метриками повторяется после каждого релиза

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

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

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

Для B2B-приложений с интеграцией 1С отдельная частая причина расхождений — обновление конфигурации 1С или смена версии мобильной платформы. Если приложение построено на 1С:Мобильной платформе, логи обмена стоит проверять отдельно от пользовательской аналитики: это разные потоки данных, и сбой одного не всегда заметен в другом, пока не накопится расхождение в остатках или заказах.

как предотвратить слепые зоны в аналитике мобильного приложения

Слепые зоны предотвращают на этапе технического задания, а не после релиза.

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

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

Отдельно тестируют сценарии с плохой связью и офлайн-режимом: часть B2B-сценариев — склад, курьеры, монтажники на объекте — регулярно работает без интернета. Если приложение не логирует действия локально с последующей досылкой, часть данных теряется навсегда, а не искажается — и это хуже, потому что незаметно на первый взгляд.

Перед каждым релизом полезно на 15 минут открыть тестовое приложение и убедиться, что события действительно долетают до дешборда, а не полагаться на то, что раз код смёржен, аналитика тоже работает. Ручная проверка дешевле, чем разбор пропавшей недели данных, который заметили только при подготовке ежемесячного отчёта.

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

сколько стоит выстроить измеримую аналитику в приложении

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

Разработка мобильного приложения с проработанной аналитикой и интеграцией с учётной системой начинается от 500 000 рублей — в эту стоимость входит проектирование сценариев вместе с событиями для бизнес-метрик, а не только пользовательский интерфейс. Дальнейшее сопровождение — обновление дешбордов, разбор расхождений после релиза, донастройка синхронизации с 1С — тарифицируется по часам работы специалиста, от 3800 рублей в час.

Итоговая цена складывается из объёма сценариев, а не из количества экранов: приложение с пятью экранами и сложной логикой синхронизации с 1С может требовать больше работы по аналитике, чем приложение с двадцатью экранами и одним сценарием заказа.

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

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

Какие метрики мобильного приложения обязательны для B2B-бизнеса?

Минимум четыре слоя: технические (crash-free rate, время старта), продуктовые (retention, глубина сессии), бизнес-метрики (конверсия в заказ, средний чек) и интеграционные — время синхронизации с 1С и доля неудачных обменов. Без интеграционного слоя B2B-приложение показывает красивую аналитику, но не объясняет расхождения с учётной системой.

Можно ли добавить бизнес-аналитику в уже готовое приложение?

Да, но это дороже, чем заложить её сразу: нужно вручную размечать события в существующем коде и проверять, что они не конфликтуют с уже собранными данными. Часть исторических метрик при этом теряется — они просто не собирались до момента доработки.

Чем техническая метрика отличается от бизнес-метрики?

Техническая метрика — crash-free rate, время отклика — показывает, работает ли приложение исправно. Бизнес-метрика — конверсия в заказ, средний чек — показывает, приносит ли приложение деньги. Оба слоя нужны вместе: технические объясняют причину, бизнес-метрики — последствия для выручки.

Сколько стоит настроить аналитику с интеграцией 1С?

Аналитика закладывается в стоимость разработки мобильного приложения — от 500 000 рублей, если проектируется вместе с интеграцией и событиями с самого начала. Доработка аналитики на готовом приложении и сопровождение синхронизации с 1С тарифицируются отдельно, от 3800 рублей в час.

Как понять, что текущая аналитика приложения врёт?

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