Как построить продуктовую аналитику приложения: события от каталога до повторной покупки

28.10.2026 Эксперт 24 мин чтения

---

Схема сбора данных, сквозные номера заказов, правила против двойного счёта и первый набор показателей.

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

Продуктовая аналитика приложения: что это и что она показывает

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

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

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

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

Какие решения бизнеса закрывает аналитика приложения

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

• Что доработать в следующей версии приложения. Приоритет расставляется по объёму потерь на шаге: число покупателей на входе в шаг, умноженное на долю ушедших и на средний чек.
• Нужен ли ещё один способ оплаты. Решение опирается на долю заказов, не оплаченных с первой попытки, и на распределение попыток по способам оплаты. Как устроена сама механика, разбирали в материалах про встроенный платёжный чекаут и бесшовные платежи.
• Работает ли программа лояльности. Сравнивается доля вторых заказов у участников программы и у остальных покупателей за один и тот же период. Механики для удержания клиентов в fashion-ритейле и метрики геймификации считаются по этим же событиям.
• Какие товары покупатель не находит. Нужна доля поисковых запросов без результата и список таких запросов. Он же становится входом для поиска по каталогу с языковой моделью.
• Какие сценарии уведомлений запускать. Решение опирается на события брошенной корзины, смены статуса заказа и возврата в приложение после уведомления.
• Окупается ли приложение как канал. Нужны выручка по заказам из приложения и доля повторных покупок. Подход к расчёту до старта работ мы описывали в материале про окупаемость мобильного приложения.

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

Архитектура сбора: три слоя данных

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

Три слоя сбора событий и характерные поломки

Источники денежных событий

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

Инструменты под объём и команду

Инструменты выбираются под объём и под команду. Для сбора в мобильном приложении подходят готовые библиотеки — например, журналирование событий в Firebase Analytics; для хранения миллиардов строк — колоночные базы вроде ClickHouse; точку приёма и обогащения чаще пишут на серверном фреймворке, который уже используется в проекте, например на Django. Выбор клиентского стека на поток событий почти не влияет: критерии мы разбирали в материале Flutter или нативная разработка. Если каналов продаж несколько, слой приёма проектируется сразу под них — об этом материал про омниканальную архитектуру для ритейла.

Карта событий: от каталога до повторной покупки

Карта событий — это таблица, которая описывает каждое событие, момент срабатывания, обязательные параметры и источник отправки. Такая таблица заменяет переписку и становится заданием для разработчиков. Вот рабочая карта для приложения интернет-магазина.

Карта событий приложения интернет-магазина: от входа до повторного заказа

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

Параметры событий и единый словарь свойств

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

• Одна сущность — одно имя. Если товар в приложении называется item_id, он называется так же в событиях сайта и в выгрузках. Пара product_id и goods_id в одном потоке означает, что отчёт по товарам придётся собирать вручную.
• Деньги в минимальных единицах. Сумма хранится в копейках целым числом, валюта — отдельным полем. Дробные значения с плавающей точкой дают расхождения в суммах по тысячам заказов.
• Время в UTC по стандарту ISO 8601. Локальное время покупателя остаётся отдельным параметром, иначе ночные заказы попадают в соседние сутки.
• Имена на латинице в нижнем регистре через подчёркивание. Это требование не стилистическое: имена событий и параметров попадают в названия колонок хранилища.
• Словарь свойств как документ. На каждое событие и параметр описаны тип, обязательность, пример, кто отправляет и в каком отчёте используется. Документ версионируется, у каждого события есть владелец, который его чинит.

Проверяемый пример того, как выглядит одно событие на приёме:

{
  "event_id": "9f1c7a62-4e2b-4a71-9b55-7d0f3a2c1e88",
  "event_name": "purchase",
  "occurred_at": "2026-10-19T08:41:12Z",
  "received_at": "2026-10-19T08:41:13Z",
  "user_id": "u_480231",
  "anonymous_id": "a_0d9ae1f4",
  "app_version": "3.14.0",
  "platform": "android",
  "order_id": "ORD-2026-0481233",
  "amount_minor": 1249000,
  "currency": "RUB",
  "payment_method": "sbp",
  "items": [
    { "item_id": "i_77120", "sku": "77120-BLK-42", "quantity": 1, "price_minor": 1249000 }
  ]
}

Разумный размер карты событий

По нашей практике первой версии приложения хватает 15–25 событий. Каждое следующее событие добавляется под конкретный вопрос, на который сейчас нет ответа. Логирование каждого нажатия даёт обратный эффект: хранилище растёт, схема перестаёт проверяться, а на вопрос о потерях в оформлении заказа по-прежнему никто не отвечает. Полезное правило — раз в квартал смотреть, какие события не попали ни в один отчёт, и выводить их из карты.

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

Сквозные идентификаторы покупателя и заказа

Склейка данных держится на трёх идентификаторах покупателя и одном идентификаторе заказа. Их роли не взаимозаменяемы:

• device_id — установка приложения на конкретном устройстве. Живёт до переустановки, после переустановки становится новым.
• anonymous_id — покупатель до входа в учётную запись. Отправляется в каждом событии, включая события после входа.
• user_id — покупатель с учётной записью. Один и тот же на всех его устройствах и на сайте.
• order_id — сквозной номер заказа. Создаётся один раз той системой, которая создаёт заказ, и дальше используется без изменений.

Связывание анонимного покупателя с учётной записью

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

Номер заказа как точка сведения отчётности

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

Ограничения: персональные данные и устройства

Ограничение по персональным данным. Телефон, электронная почта, адрес и имя в поток событий не попадают — события несут идентификаторы, а не контакты. Хранение контактов в аналитическом хранилище создаёт обязательства по закону № 152-ФЗ «О персональных данных» и расширяет круг систем, которые придётся защищать. Если отчёту нужны данные покупателя, он получает их по user_id из основной базы в момент построения.

Ограничение по устройствам. Метрики по device_id систематически занижают повторные покупки: переустановка приложения превращает одного покупателя в двух, поэтому повторные заказы считают только по user_id. При переходе с готового приложения на собственное этот момент закладывают в перенос истории.

Дедупликация: правила против двойного счёта

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

Источники повторов и правила, которые их закрывают

Идентификатор события и окно проверки

Идентификатор события удобно формировать в формате UUID — он описан в RFC 4122 и не требует согласования между устройствами. Индекс идентификаторов на приёме держат за окно, которое перекрывает реальную задержку доставки: суток обычно достаточно, потому что локальная очередь редко живёт дольше. За пределами окна повторы ловит уникальное ограничение в хранилище — например, уникальный индекс в PostgreSQL:

CREATE UNIQUE INDEX uniq_app_events_event_id
    ON app_events (event_id);

CREATE UNIQUE INDEX uniq_purchase_per_order
    ON app_events (order_id)
    WHERE event_name = 'purchase';

Хранение помеченных повторов

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

Контроль качества данных

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

Проверки качества потока событий

Организационные условия проверок

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

Проверка перед выпуском новой версии

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

Воронки и когорты: разные вопросы и разные ответы

Воронка и когорта отвечают на разные вопросы, и подмена одного другим даёт неверные выводы.

Воронка: шаги и окно наблюдения

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

Когорта: группа по дате входа

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

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

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

Метрики первого набора

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

Первый набор метрик приложения интернет-магазина

Порядок чтения метрик

Последняя строка в этой таблице стоит не для полноты списка. Пока доля принятых событий не вышла на стабильный уровень, остальные показатели читать рано. Когда набор устоялся, к нему добавляют выручку канала и стоимость привлечения покупателя — для них данные берут из рекламных кабинетов и платёжных отчётов, и это отдельный контур сверки, как показывает пример использования транзакционных данных в рекламной аналитике. Готовить отчёты по этим метрикам помогают и инструменты поверх таблиц — например, помощник для работы с данными в Excel и Google Sheets, — но источником цифр остаётся хранилище, а не выгрузка.

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

• Карта событий без решений. Логируется всё подряд, отчётов нет. Лечится обратным порядком работы: сначала список решений, потом события под них.
• Оплата приходит только с устройства. Выручка в отчётах расходится с учётной системой на величину потерянных и подделанных событий. Денежные события отправляет серверная часть.
• Переименование события без версии. История рвётся, график обнуляется с датой выпуска новой версии. Старое имя поддерживается до тех пор, пока в строю прежние версии приложения.
• Нет идентификатора события. Повторная отправка очереди превращается в двойную выручку, и заметно это обычно в отчёте за распродажу.
• Контакты покупателя в параметрах. Телефон или почта в потоке событий расширяют периметр защиты данных без пользы для отчётов.
• Разные имена сущностей в приложении и на сайте. Омниканальные отчёты не склеиваются, и каждый свод приходится собирать руками.
• Формула метрики меняется вместе с продуктом. Сравнение «до и после» теряет смысл. Формулы фиксируются до запуска и меняются с явной отметкой даты.
• Нет проверки после релиза. Сломанное событие обнаруживается через месяц, когда данные за этот месяц уже не восстановить.

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

Итог: чек-лист внедрения

Порядок работ, при котором аналитика начинает приносить решения с первого месяца:

• Составить список решений, которые нужно принимать по данным, и назвать ответственного за каждое.
• Описать карту событий на 15–25 событий с обязательными параметрами и источником отправки.
• Зафиксировать словарь свойств: имена, типы, единицы измерения денег и времени, обязательность.
• Развести источники: просмотры и корзина — с устройства, оплата, статусы и возвраты — с серверной части.
• Ввести идентификатор события и ключ повторного вызова по номеру заказа, добавить уникальные ограничения в хранилище.
• Сделать связывание анонимного покупателя с учётной записью в хранилище, а не в приложении.
• Запустить ежедневные проверки качества и отдельную таблицу для отклонённых событий.
• Собрать базовую линию за четыре–восемь недель и только после этого ставить цели по метрикам.
• Включить прогон карты событий в проверки перед каждым выпуском новой версии приложения.

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

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

Ссылки на документацию в материале проверены 19 октября 2026 года. Рейтинги, среднерыночные нормы и отраслевые бенчмарки здесь не приводятся: по этим показателям нет публичных данных с описанной методикой, которые можно проверить на дату публикации.