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

Передавайте идентификатор заказа из магазина

При ручной реализации ecommerce Matomo требует уникальный order ID и общую выручку заказа; для товарной позиции обязателен SKU. Обычно покупку передают на странице подтверждения после подтверждённой оплаты. Идентификатор должен соответствовать реальному заказу магазина, а не генерироваться заново при каждом открытии страницы.

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

Согласуйте смысл передаваемой суммы

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

Возьмите тестовый заказ с доставкой и скидкой, а затем сравните событие с заказом в административной части. Если данные дополнительно разворачиваются в таблицу позиций, избегайте повторного суммирования общего итога: этот случай разбирает материал о дублировании суммы заказа.

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

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

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

Сверяйте расхождения по отдельным заказам

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

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