Мобильное приложение магазина установили десятки тысяч человек, а вы не знаете, где они отваливаются: до корзины, на оформлении или ещё на экране каталога. Дашборд из магазина приложений показывает установки и удаления, но молчит про то, что происходит внутри. В результате продуктовые решения принимаются на ощущениях, а не на данных — а каждая неверная догадка стоит недель разработки.
Эта статья — о том, как выстроить аналитику поведения в мобильном приложении интернет-магазина: считать события вместо страниц, собрать воронку покупки, измерить удержание по когортам и связать поведение в приложении с реальными продажами в 1С через автоматизацию продаж и склада на 1С. Без магии и «модных метрик» — только то, что помогает принимать решения.
Коротко
- В приложении нет URL — базой аналитики становятся события с параметрами и переходы между экранами.
- Сначала опишите словарь событий пути к покупке, потом внедряйте — иначе данные будут разнородными и бесполезными.
- Связывайте событие оплаты с заказом в 1С, чтобы мерить конверсию в отгруженную выручку, а не в «оформления».
- Сквозной идентификатор пользователя сводит поведение на сайте и в приложении в одну картину.
Зачем магазину аналитика приложения
Приложение — это отдельный канал продаж со своей экономикой. У него дороже привлечение (установка), но выше удержание и частота повторных покупок: лояльный клиент возвращается через иконку на экране, а не через поиск. Чтобы этот канал окупался, нужно понимать, как люди в нём себя ведут — иначе вы вкладываетесь в установки, а они удаляют приложение после первой сессии.
Аналитика отвечает на конкретные бизнес-вопросы: какие экраны ведут к покупке, где рвётся оформление, какие категории смотрят, но не покупают, стоит ли пуш-уведомление роста отписок. Без событийных данных на эти вопросы отвечают маркетолог и разработчик своими догадками — и обычно расходятся во мнениях.
Экраны и события вместо страниц
Главное отличие от веб-аналитики: в приложении нет адресов страниц. Пользователь перемещается между экранами внутри одного процесса, данные подгружаются, а привычный «просмотр страницы» с URL не возникает. Поэтому автоматический сбор хитов, как на сайте, здесь не работает — события нужно расставлять руками в коде приложения.
Единицей измерения становится событие: «открыл экран товара», «нажал добавить в корзину», «начал оформление». У каждого события есть имя и набор параметров. Просмотры экранов — тоже события особого типа. Такой подход даёт больше контроля: вы фиксируете ровно то, что важно бизнесу, а не тонете в автоматических хитах. Но и ответственность выше: не расставили событие — данных нет, восстановить их задним числом нельзя.
Какие события собирать
Соблазн «собирать всё» вреден: разнородный поток событий без структуры невозможно анализировать. Начните с минимального набора, описывающего путь к деньгам, и расширяйте его под конкретные вопросы.
- Открытие приложения и сессия. Точка входа, источник (пуш, ссылка, иконка), номер запуска.
- Просмотр каталога и категории. Какие разделы смотрят, глубина листания.
- Просмотр товара. Id товара, категория, цена, наличие.
- Добавление в корзину. Товар, количество, сумма.
- Начало и шаги оформления. Доставка, оплата, ввод данных.
- Оплата. Сумма, состав, способ оплаты, id заказа.
- Поиск и фильтр. Запрос, число результатов, пустая выдача.
Схема событий и словарь параметров
Данные полезны, только когда они единообразны. Если один экран шлёт событие add_to_cart, другой — cartAdd, а третий — «добавление», построить воронку невозможно. Поэтому до внедрения составляют словарь: список событий с фиксированными именами и обязательными параметрами. Это документ, по которому пишут и приложение, и сайт.
| Событие | Когда срабатывает | Обязательные параметры |
|---|---|---|
| view_item | Открыт экран товара | item_id, category, price |
| add_to_cart | Товар добавлен в корзину | item_id, qty, value |
| begin_checkout | Начато оформление | cart_value, items_count |
| purchase | Оплата подтверждена | order_id, value, payment |
| search | Выполнен поиск | query, results_count |
Ключевой параметр — order_id для события покупки: именно он свяжет аналитику с заказом в 1С. Единый словарь на сайте и в приложении позволяет потом сравнивать каналы напрямую. Договоритесь о словаре один раз — и сэкономите месяцы на разборе несовместимых данных.
Воронка покупки в приложении
Собранные события складываются в воронку — последовательность шагов от открытия приложения до оплаты. Воронка показывает не абсолютные числа, а переходы: сколько процентов от просмотревших товар дошли до корзины, сколько от корзины — до оформления, сколько от оформления — до оплаты.
Именно на переходах видно узкое место. Если 60% теряются между корзиной и оформлением — проблема в шаге оформления: сложная форма, обязательная регистрация, неожиданная стоимость доставки. Если отваливаются на оплате — стоит проверить способы оплаты и стабильность платёжного экрана. Воронка не даёт ответа, но точно указывает, где копать, и это уже экономит недели.
- Смотрите переходы, а не абсолюты. Провал между двумя шагами важнее общего числа.
- Сегментируйте. Воронка новых и вернувшихся пользователей отличается радикально.
- Разделяйте платформы. iOS и Android часто ведут себя по-разному.
Когорты и удержание
Воронка отвечает на вопрос «где теряем в одной сессии», а удержание — «возвращаются ли вообще». Для приложения удержание критично: окупаемость установки зависит от того, вернётся ли пользователь за второй и третьей покупкой. Мерят это когортным анализом — группируют пользователей по неделе установки и смотрят, какая доля активна через 1, 2, 4, 8 недель.
Кривая удержания обычно резко падает в первые дни и выходит на плато. Высота этого плато — здоровье продукта: если через месяц возвращается заметная доля когорты, у приложения есть ядро лояльных клиентов. Если кривая падает в ноль — установки просто утекают. Дальше вы проверяете гипотезы удержания: онбординг, пуши о брошенной корзине, персональные подборки. Автоматизацию таких сценариев на стороне учёта удобно строить через автоматизацию на 1С, когда триггеры завязаны на реальный статус заказов.
Сквозная аналитика и связка с 1С
Самая частая ловушка — верить конверсии «в оформление». Оформленный заказ ещё не выручка: часть отменяется, часть не оплачивается, часть возвращается. Настоящая метрика — конверсия в отгруженный и оплаченный заказ, а эти данные живут в 1С, а не в аналитике приложения.
Чтобы соединить два мира, событие purchase должно нести тот же order_id, который уходит в 1С при обмене. Тогда вы джойните аналитическую воронку с фактами из учётной системы: какие заказы реально оплачены, отгружены, возвращены. Это превращает аналитику из «красивых процентов» в инструмент управления выручкой. Техническая сторона обмена и производительность интеграции — отдельная тема; смежные вопросы масштабирования и деплоя мы разбираем в статьях про хостинг и инфраструктуру для 1С-Битрикс и CI/CD и деплой для 1С-Битрикс.
Единый пользователь на сайте и в приложении
Клиент редко живёт в одном канале: посмотрел на сайте, докупил в приложении, вернулся за поддержкой на сайт. Без общего идентификатора аналитика считает это тремя разными людьми, и когорты, и LTV искажаются. Решение — сквозной идентификатор пользователя, который присваивается после авторизации и одинаков на всех платформах.
- До авторизации. Пользователь анонимен, привязан к устройству/браузеру.
- После авторизации. Анонимные события сшиваются с профилем по единому id.
- Единый словарь событий. Одинаковые имена и параметры на сайте и в приложении делают воронки сопоставимыми.
Технически сквозной id обычно совпадает с id клиента в учётной системе — тем самым, по которому идёт обмен заказами. Тогда аналитика, сайт, приложение и 1С говорят об одном и том же человеке.
Согласие и приватность данных
Сбор поведения — это персональные и квазиперсональные данные, поэтому аналитика начинается с согласия и политики конфиденциальности. Магазины приложений требуют раскрывать, какие данные вы собираете и куда передаёте, а рекламные идентификаторы устройства запрашиваются отдельно.
Практичный подход: обезличенные продуктовые события собирать по умолчанию (они нужны для работы продукта), а расширенную и рекламную аналитику включать по явному согласию. Храните минимум персональных данных, не тащите в аналитику лишние поля (телефон, адрес) и разграничивайте доступ к сырым событиям. Это не только требование закона, но и вопрос доверия клиента.
Инструменты: Метрика, веб-аналитика Битрикс, своё хранилище
Стек аналитики обычно многослойный, и у каждого слоя своя роль.
| Слой | Роль | Ограничение |
|---|---|---|
| Мобильная аналитика (события) | Воронки, когорты, дашборды из коробки | Агрегаты трудно пересчитать под новый вопрос |
| Яндекс Метрика / веб-аналитика | Единая картина с сайтом, цели, сегменты | Заточена под веб, приложение — через SDK |
| Своё хранилище сырых событий | Любые срезы, джойн с данными 1С | Дороже во внедрении и поддержке |
Для среднего и крупного магазина оптимальна связка: готовая мобильная аналитика для быстрых дашбордов плюс выгрузка сырых событий в собственное хранилище, где их соединяют с продажами из 1С. Тогда вы не упираетесь в лимиты внешнего сервиса и строите отчёты под свои вопросы. Инфраструктурную часть — приём и хранение потока событий — удобно закрыть аудитом и оптимизацией 1С и смежной интеграционной разработкой; про безопасность приёма данных полезна статья про безопасность REST и вебхуков в 1С-Битрикс.
Частые ошибки
- Внедряют без словаря событий. Разные имена и параметры на экранах — данные несопоставимы, воронку не построить.
- Собирают всё подряд. Сотни событий «на всякий случай» превращаются в шум, в котором тонет главное.
- Мерят «оформления», а не оплаты. Конверсия без связки с 1С завышена: отмены и возвраты не учтены.
- Нет сквозного пользователя. Один клиент считается несколькими, когорты и LTV искажаются.
- Игнорируют разницу платформ. iOS и Android смешаны в одной воронке, узкое место не видно.
- Забывают про согласие. Сбор без политики и согласия грозит блокировкой в магазине приложений.
- Не хранят сырые данные. Когда возникает новый вопрос, пересчитать агрегаты внешнего сервиса нельзя.
Чек-лист внедрения
- Определите вопросы. Выпишите, на какие бизнес-вопросы должна отвечать аналитика.
- Составьте словарь событий. Имена и обязательные параметры, единые для сайта и приложения.
- Заложите order_id и user_id. Событие покупки несёт id заказа для связки с 1С, авторизация — сквозной id клиента.
- Расставьте события в коде. Экраны и ключевые действия пути к покупке.
- Настройте согласие. Политика конфиденциальности, обезличенные события по умолчанию, реклама по согласию.
- Постройте воронку и когорты. Переходы между шагами и удержание по неделям установки.
- Свяжите с 1С. Джойн событий покупки с фактическими оплатами и отгрузками.
- Выгружайте сырые события. Собственное хранилище для срезов под новые вопросы.
Вывод
Аналитика мобильного приложения — это не дашборд ради дашборда, а способ перестать принимать продуктовые решения вслепую. Ключ к ней — событийная модель: вместо автоматических просмотров страниц вы осознанно расставляете события пути к покупке, описываете их единым словарём и связываете с реальными продажами в 1С.
Собранная так аналитика показывает, где рвётся воронка, возвращаются ли пользователи и какой канал приносит отгруженную выручку, а не красивые проценты. Начните с минимального набора событий и order_id для связки с учётом — и приложение из «чёрного ящика с установками» превратится в управляемый канал продаж.
