Аналитика мобильного приложения: почему 1С не видит визиты агентов

Аналитика мобильного B2B-приложения измеряет не количество установок, а то, доходит ли действие сотрудника до документа в 1С: визит до заказа, скан до проведённой накладной. Для этого нужны не отчёты из App Store, а SDK — Firebase, AppMetrica или Amplitude — с событиями, размеченными под бизнес-процесс, и выгрузкой этих событий в учётную систему.

Сорок торговых агентов и ноль совпадений с 1С

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

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

Без аналитики на уровне событий этот разрыв не виден: и в CRM, и в 1С всё выглядит корректно, просто числа не совпадают. Компания оплачивала сорок подписок на приложение, тратила часы бухгалтера на ручную сверку визитов с заказами и не могла посчитать, какой агент реально закрывает точки, а какой числится в системе для галочки. Цена вопроса не в абстрактной «эффективности» — это конкретные часы сверки каждую неделю и повторные заказы, которые не случились там, где визит был, а оформление до 1С не дошло. Формально KPI выполнялся: приложение показывало высокую активность, отчёт по визитам выглядел ровным. Реальная картина всплыла только тогда, когда события сопоставили с документами вручную — а на это ушла неделя работы двух человек, притом что тот же разрыв можно было увидеть за час, если бы события изначально считались по одной и той же логике в приложении и в 1С.

Почему метрики из App Store здесь не работают

Готовые дашборды сторов и большинство инструкций по мобильной аналитике заточены под потребительские приложения: retention на день 1/7/30, виральность, стоимость установки. Для закрытого корпоративного приложения с фиксированным списком из сорока пользователей эти цифры не несут смысла — установка не привлечённый клиент, а сотрудник, которому выдали рабочий телефон. Retention не упадёт: люди открывают приложение по должностной инструкции, а не по желанию. На потребительском рынке retention день 1 — это сигнал, продержится ли пользователь дольше суток после установки. В корпоративном приложении такой вопрос не стоит: сотрудник обязан пользоваться системой, пока работает в компании, и падение retention означает не потерю интереса, а забастовку или сбой в самом приложении — тоже сигнал, но читается он иначе, чем в потребительской аналитике.

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

Как разметить события так, чтобы аналитика говорила на языке 1С

Шаг 1: событие равно документу, а не экрану

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

Шаг 2: воронка визит → заказ → синхронизация

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

Шаг 3: id сотрудника и id точки в каждом событии

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

Сравнение инструментов: Firebase, AppMetrica, Amplitude

Для приложения, которое интегрируется с 1С, инструмент аналитики выбирают не по набору готовых графиков, а по тому, насколько просто вытащить сырые события через API и связать их с документами. Ниже — сравнение трёх вариантов, с которыми чаще всего работают в проектах мобильной разработки для российских компаний.

Для приложения торговых представителей и полевых команд AppMetrica чаще оказывается практичнее: размещение данных в РФ снимает часть вопросов по 152-ФЗ, а выгрузка событий не требует отдельной настройки хранилища. Firebase логичен, если приложение уже живёт в экосистеме Google и часть аналитики нужна для мобильной разработки как таковой — крэши, производительность. Amplitude оправдан, когда воронок много и продуктовая команда сама строит гипотезы, а не заказывает готовый отчёт под 1С.

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

Куда деть данные: выгрузка в 1С и вопрос персональных данных

Событие из приложения полезно ровно в тот момент, когда оно попадает туда, где его видит менеджер, — в отчёт 1С, а не в отдельную консоль аналитики, куда никто, кроме разработчика, не заходит. Практическая схема простая: SDK аналитики пишет событие, тот же обработчик через вебхук или periodic-задачу кладёт очищенную копию события в очередь обмена с 1С, обмен раскладывает событие в регистр или связывает с существующим документом по id визита. Это тот же контур, что при интеграции мобильного приложения с 1С под заказы и остатки — аналитика в нём просто ещё один поток данных, а не отдельная система. Отдельно стоит продумать, что происходит с событием, если у точки нет связи в момент визита. Мобильные приложения для полевых команд обычно пишут события в локальную очередь на устройстве и отправляют пакетом при появлении сети — без этого часть визитов из дальних точек не долетит до 1С физически, и разрыв в отчётах будет объясняться не разметкой событий, а обычным отсутствием связи в конкретном районе.

Отдельный момент — что именно логировать с телефона сотрудника. Геолокация визита и id устройства — персональные данные, и их сбор в корпоративном приложении подчиняется 152-ФЗ: нужно согласие сотрудника и понятная цель сбора, прописанная во внутреннем документе, а не просто включённый по умолчанию трекинг в SDK. Для B2B-приложения это решается на этапе техзадания, а не постфактум, когда данные уже год пишутся неизвестно куда.

Сколько стоит внедрить аналитику и с чего начать

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

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

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

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

Какая аналитика нужна корпоративному приложению, если установки из стора не считаются?

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

Можно ли обойтись бесплатным Firebase Analytics для B2B-приложения?

На старте да, бесплатного лимита хватает. Но сырые события из Firebase нужно выгружать через BigQuery с отдельной настройкой, а данные хранятся за рубежом. Для полевых команд в РФ часто проще AppMetrica с выгрузкой и размещением данных в стране из коробки.

Как события из приложения попадают в отчёты 1С?

SDK аналитики фиксирует событие, обработчик кладёт очищенную копию в очередь обмена с 1С, а обмен связывает её с документом по id визита или заказа. Это тот же контур, что при обычной интеграции приложения с 1С, аналитика идёт в нём отдельным потоком данных.

Нужно ли согласие сотрудников на сбор геолокации и данных устройства в корпоративном приложении?

Да, геолокация и id устройства — персональные данные, их сбор подчиняется 152-ФЗ. Нужны согласие сотрудника и зафиксированная цель сбора во внутреннем документе, а не трекинг, включённый в SDK по умолчанию без ведома человека, который им пользуется.

Сколько времени занимает внедрение аналитики в уже готовое приложение?

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