Когда одна покупка отправляется из браузера и с сервера, рекламная система может посчитать две конверсии. Для объединения обе копии должны иметь одинаковый тип события и стабильный event_id, относящийся к одной бизнес-операции.

Создавайте event_id на сервере в момент формирования операции и передавайте его браузеру вместе с подтверждением. Не генерируйте два случайных UUID независимо на клиенте и backend.

Что сделать в первую очередь

  • Выберите одну тестовую покупку и найдите обе копии события.
  • Сравните event name, event_id, время, сумму, валюту и order id.
  • Проверьте, не отправляется ли браузерное событие при каждом обновлении страницы.
  • Определите источник истины для статуса успешной оплаты.

Почему возникает проблема

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

  • Клиент и сервер создают разные event_id.
  • Server-side событие отправляется до подтверждения бизнес-операции.
  • Retry генерирует новый id и выглядит как новая конверсия.
  • Пиксель привязан к просмотру страницы благодарности без защиты от повторов.

Пошаговая диагностика

  • Постройте таблицу order id, browser event_id и server event_id.
  • Проверьте журнал приемки событий в рекламной платформе.
  • Сравните timestamp с фактическим временем подтверждения оплаты.
  • Повторите refresh и возврат назад на странице успеха.
  • Смоделируйте сетевой таймаут и повтор server-side отправки.

Как исправить

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

  • Создавайте неизменный event_id на одну бизнес-конверсию.
  • Передавайте тот же id в dataLayer или ответ API для браузерного пикселя.
  • Храните статус отправки и повторяйте событие с тем же идентификатором.
  • Запускайте purchase после подтверждения оплаты, а не открытия URL.
  • Передавайте возвраты отдельным поддерживаемым событием или корректировкой.

Как проверить результат

  • Одна покупка видна как одно дедуплицированное событие.
  • Refresh страницы и сетевой retry не увеличивают число конверсий.
  • Сумма и валюта совпадают с заказом после скидок.

Как не допустить повторения

  • Храните event_id рядом с order id и журналом отправки.
  • Сверяйте число оплаченных заказов и принятых конверсий ежедневно.
  • Тестируйте отмену, частичный возврат и повторную оплату.

Частые вопросы

Нужно ли отправлять событие и из браузера, и с сервера?

Не всегда, но это повышает устойчивость измерения. Главное — единая идентичность и правила момента конверсии.

Можно ли использовать номер заказа как event_id?

Можно, если он уникален, не содержит лишних персональных данных и одна операция не требует нескольких отдельных событий.

Когда стоит обратиться за помощью

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

Итог

Дедупликация строится вокруг одной бизнес-операции и одного event_id. Я могу связать браузерный пиксель с server-side отправкой и настроить сверку конверсий без двойного учета.