Deduplication в CAPI ломается не из-за API, а из-за event_id и дисциплины передачи

Deduplication в CAPI ломается не из-за API, а из-за event_id и дисциплины передачи

Если Pixel и CAPI считают один и тот же Purchase как два разных события, проблема обычно в том, что event_id генерится в разных местах или меняется по дороге. Второй частый сценарий — client-side шлёт одно имя события, server-side другое, а дедупликация в платформе завязана именно на пару event_name + event_id.

Что проверять в первую очередь:
— event_id создаётся один раз на клиенте и уходит и в Pixel, и в CAPI
— event_name совпадает до символа
— один и тот же order_id не переиспользуется для разных покупок
— в серверном слое нет повторной генерации event_id при ретраях

Отдельная ловушка — SPA и повторные отправки при обновлении страницы. Если событие инициируется на каждом рендере, deduplication rate падает, даже когда payload выглядит “правильно”. Для checkout лучше привязывать event_id к бизнес-объекту: заказу, лида, подписке. Тогда повторный POST не превращается в новый event.

Финальная проверка простая: один источник истины для event_id, одинаковое имя события, логирование дублей на сервере. Если это соблюдено, CAPI перестаёт раздувать конверсии и начинает нормально склеиваться с Pixel.