Качество данных ecommerce-аналитики: аудит за один день

10 августа 2026 · 6 мин чтения

Аудит ecommerce-аналитики проверяет, что события действительно описывают путь покупателя и согласуются с заказами. Минимум нужно проверить просмотр товара, добавление в корзину, начало оформления, покупку и возврат, а для purchase — уникальный ID, сумму, валюту, товары, скидки и отсутствие дублей.

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

Коротко

За один день можно:

1. утвердить словарь событий;
2. выполнить набор контрольных сценариев;
3. проверить payload в браузере и отчёте;
4. сопоставить order ID с CMS/OMS;
5. найти дубли, пропуски и тестовые заказы;
6. проверить валюту, скидки и возвраты;
7. оценить расхождение за неделю;
8. назначить автоматические проверки качества.

Что является источником истины

Разные системы отвечают на разные вопросы:

Система	Основной вопрос
Веб-аналитика	Как пользователь дошёл до действия?
CMS/OMS	Какие заказы были созданы?
Платёжный провайдер	Какие операции оплачены или возвращены?
ERP/1С	Какие заказы исполнены и учтены?
CRM	Как обработаны лиды и клиенты?
Рекламные кабинеты	Как канал атрибутирует результат?

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

Шаг 1. Создайте словарь событий

Событие	Момент отправки	Обязательные поля	Исключения	Владелец
view_item	Карточка реально показана	SKU, название, цена	Боты/служебные просмотры	Analytics
add_to_cart	Товар добавлен	SKU, количество, цена	Ошибка добавления	Product
begin_checkout	Начато оформление	Корзина, сумма, валюта	Пустая корзина	Product
purchase	Заказ подтверждён по принятому правилу	order ID, сумма, валюта, товары	Тесты, дубли	Ecommerce
refund	Возврат подтверждён	order ID, сумма/товары	Отмена до оплаты	Finance

Самое важное — определить момент purchase. Это может быть создание заказа или подтверждение оплаты, но команда должна понимать различие и не сравнивать несовместимые цифры.

Шаг 2. Пройдите контрольные сценарии

Подготовьте маркированные тесты:

1. обычный заказ без скидки;
2. заказ с промокодом;
3. несколько единиц одного товара;
4. несколько разных товаров;
5. гостевой checkout;
6. авторизованный покупатель;
7. отмена до оплаты;
8. успешная тестовая оплата;
9. частичный возврат, если поддерживается;
10. повторное открытие страницы подтверждения.

Запишите ожидаемые события до теста. Иначе легко принять любой payload за корректный.

Шаг 3. Проверьте четыре уровня

В браузере

• событие отправляется один раз;
• названия и типы полей корректны;
• сумма не содержит форматированную строку;
• валюта передаётся явно;
• нет персональных данных, которые не должны попадать в аналитику;
• блокировщик или отсутствие consent обрабатываются ожидаемо.

На сервере или в tag manager

• событие не дублируется двумя контейнерами;
• версия схемы известна;
• повторный запрос можно определить;
• ошибки и отбрасывание видимы;
• тестовые операции маркируются.

В отчёте

• событие появилось после документированной задержки;
• order ID совпадает;
• товары и количество верны;
• сумма и скидка соответствуют правилу;
• канал и устройство выглядят ожидаемо.

В учётном контуре

• заказ существует;
• его статус понятен;
• платёж и возврат связаны;
• тест исключён из управленческого отчёта.

Шаг 4. Проведите недельную сверку

Проверка	Формула
Покрытие заказов	Уникальные purchase ID / созданные заказы по правилу
Дубли	Повторные purchase ID / все purchase
Расхождение суммы	Сумма аналитики − сумма OMS по сопоставимым ID
Неизвестные заказы	purchase ID без заказа в OMS
Пропущенные заказы	заказы OMS без purchase
Покрытие возвратов	возвраты в аналитике / возвраты учётной системы

Сегментируйте по устройству, браузеру, способу оплаты и версии сайта. Общее расхождение может скрывать полный провал одного сегмента.

Причины объяснимого расхождения

• блокировка скриптов;
• отказ в consent;
• закрытие страницы до отправки;
• разные часовые пояса;
• разные определения покупки;
• задержка отчёта;
• серверные и офлайн-заказы;
• возврат в другом периоде;
• валютная конвертация;
• тестовые и служебные заказы.

Объяснимое не значит игнорируемое. Зафиксируйте диапазон и следите за его изменением.

Автоматические контроли

Настройте сигналы, если:

• purchase исчезли при продолжающихся заказах;
• доля событий без order ID выросла;
• дубли превысили внутренний порог;
• валюта или сумма стали пустыми;
• число товаров в заказе неожиданно равно нулю;
• отношение purchase к заказам резко изменилось;
• после релиза перестал приходить шаг воронки;
• тестовый контрольный заказ не найден.

Сигнал качества данных должен отличаться от сигнала падения продаж.

Паспорт расхождения

Поле	Значение
Период
Определение заказа
Источники
Заказы OMS
Уникальные purchase
Дубли
Пропуски
Разница суммы
Затронутый сегмент
Известная причина
Владелец исправления
Дата следующей проверки

Типичные ошибки

• отправлять purchase при открытии страницы, которую можно обновить;
• использовать неуникальный order ID;
• не передавать возвраты;
• сравнивать созданные заказы с оплаченными;
• включать тесты в рекламу и ROI;
• менять схему без версии и журнала релиза;
• собирать лишние персональные данные;
• объявлять «данные точны», не сверяя их с заказами.

FAQ

Допустимо ли расхождение между аналитикой и OMS?

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

Где отправлять purchase — в браузере или с сервера?

Выбор зависит от архитектуры и требований к consent. Серверный сигнал устойчивее, но требует правильной атрибуции, дедупликации и защиты данных. Иногда используют оба с единым ID.

Как часто проводить аудит?

После изменений checkout, tag manager, consent и платёжной логики, а также по расписанию. Короткую сверку полезно выполнять еженедельно.

Источники

• Яндекс Метрика: передача данных электронной коммерции
• Яндекс Метрика: отчёты по электронной коммерции

Проверено: 10 августа 2026 года.

Далее: план непрерывности онлайн-продаж, управленческий дашборд и чек-лист после релиза.

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

Читайте также: Как принять сайт на поддержку: чек-лист студии · Что проверить после релиза сайта: чек-лист · Что входит в техническую поддержку сайта: чек-лист абонентки · Передача сайта другой студии: полный чек-лист · Бесплатно проверить сайт.