-
Заказ
Один стабильный идентификатор
-
Отправка
Код сайта, GTM и повторная загрузка
-
Событие
Параметры и повторяющийся ID
-
Сверка
Счётчик и оплаченные заказы
Если аналитика показывает больше покупок, чем магазин, сначала сопоставьте идентификаторы заказов. Повторное событие purchase, повторная оплата и два разных заказа — разные ситуации. Исправление начинается с конкретного заказа и момента отправки события, а не с отключения всех тегов подряд.
Для разработчика и маркетолога полезен один общий журнал: заказ, действие пользователя, источник отправки, ID транзакции и сумма. Проверка событий электронной торговли найдёт структурные ошибки и повторные ID в сохранённом JSON. Доставку в реальный счётчик проверяют дополнительно.
Четыре места, где возникает повтор
- Событие отправляют и код шаблона, и тег в менеджере тегов.
- Обработчик привязывается повторно при обновлении интерфейса.
- Страница благодарности отправляет покупку при каждом открытии.
- Браузер и сервер отправляют одну покупку без согласованной идентификации.
Добавляется и пятая причина: разные действия названы покупкой. Создание заказа, переход к оплате и подтверждённая оплата могут отправлять одинаковый event. Сначала договоритесь, что именно означает purchase в вашем проекте. Отдельные бизнес-этапы должны иметь различимые события и понятные правила отчёта.
Как собрать доказательства по одному заказу
Возьмите тестовый стенд или согласованный тестовый заказ. Откройте инструменты разработчика, сохраните последовательность dataLayer и сетевые запросы аналитики. Проверьте обычное завершение заказа, обновление страницы, возврат назад и повторное открытие ссылки. Не используйте реальные контакты клиента в публичном отчёте.
Для каждого события отметьте время, имя, ID и источник кода. Если в JSON две покупки с одним ID, это кандидат в дубль отправки. Но в отчёте аналитики второй экземпляр мог быть исключён механизмом дедупликации событий. Обратная ситуация тоже возможна: один заказ отправили с двумя разными ID, и простое сравнение идентификаторов его не обнаружит.
Что проверить в GA4
В GA4 покупка использует transaction_id. Он должен стабильно обозначать один заказ, не генерироваться заново при перезагрузке и не совпадать у разных заказов. Google описывает дедупликацию покупок по ID транзакции. Пустое или повторно используемое значение ломает смысл этой связи.
{"event":"purchase","ecommerce":{"transaction_id":"DEMO-42","currency":"RUB","value":2400,"items":[{"item_id":"SKU-7","price":1200,"quantity":2}]}}Это учебное событие: два товара по 1 200 ₽, сумма товаров 2 400 ₽. По формату GA4 стоимость доставки и налог не включают в value покупки. Не смешивайте цену до скидки и фактически оплаченные позиции. Названия и числовые типы полей также должны соответствовать формату.
Что проверить в Метрике
У Метрики другой объект: purchase находится внутри ecommerce, ID заказа — в actionField.id, товары — в products. Не переименовывайте несколько полей GA4 наугад: используйте документацию передачи ecommerce. Если одним контейнером пользуются разные системы, каждой нужен свой корректный формат.
{"ecommerce":{"currencyCode":"RUB","purchase":{"actionField":{"id":"DEMO-42","revenue":2400},"products":[{"id":"SKU-7","price":1200,"quantity":2}]}}}В примере revenue совпадает с суммой товаров. В вашем проекте в доход заказа могут входить другие составляющие. Поэтому расхождение требует сверки договора данных между магазином и аналитикой, а не автоматического исправления в сторону меньшей суммы.
Как исправлять без потери настоящих покупок
| Причина | Изменение | Проверка |
|---|---|---|
| Шаблон и GTM отправляют одно событие | Оставить одного владельца отправки | Один заказ проходит выбранный путь |
| Повторная привязка обработчика | Исправить жизненный цикл подписки | Несколько обновлений интерфейса не множат события |
| Новый ID при каждом открытии | Брать стабильный ID из заказа | Повторный просмотр сохраняет ID |
| Один ID у разных заказов | Исправить источник идентификатора | Два заказа различаются в событиях |
Не закрывайте проблему только флагом в localStorage. Другой браузер его не увидит, пользователь может очистить хранилище, а ошибочное раннее сохранение флага способно подавить единственную корректную отправку. Защита зависит от архитектуры доставки; стабильный ID нужен в любом случае.
Приёмка после исправления
Повторите исходный сценарий и проверьте новый заказ: сумму, товары, количество, валюту и источник. Сверьте сохранённые события с отладчиком, затем — с обработанным отчётом и CRM. Исправление отправки действует на будущие события; старую статистику нельзя считать автоматически восстановленной.
Отдельно проверьте частичный возврат и отмену. Повторный purchase не должен служить способом обновления статуса заказа. В акте приёмки сохраните тестовые ID и ожидаемый результат, чтобы проверку можно было повторить после обновления сайта.
