Deduplication в CAPI ломается не из-за Facebook, а из-за event_id, который живёт своей жизнью

Deduplication в CAPI ломается не из-за Facebook, а из-за event_id, который живёт своей жизнью

Если Pixel и CAPI отправляют один и тот же Purchase, но dedup не срабатывает, почти всегда проблема в идентификаторе. Частые ошибки:
— event_id генерится отдельно на клиенте и на сервере;
— клиент шлёт UUID, сервер — order_id;
— событие уходит повторно при refresh/retry, но с новым id;
— event_name совпадает, а payload уже другой.

Правило простое: один источник истины для event_id. Для e-commerce чаще всего это order_id или отдельный transaction_id, созданный до отправки Pixel и CAPI. Этот id должен попасть и в браузерный тег, и в серверный запрос без преобразований. Если передавать его через dataLayer, проверьте, что он не пересобирается на каждом рендере страницы.

Второй слой проблем — тайминг и дубли на уровне ретраев. Если серверный endpoint отвечает с задержкой, SDK или GTM могут повторить отправку. Тогда deduplication не спасёт, если повтор ушёл с новым event_id. Ещё один анти-кейс: в одном потоке события называются Purchase, в другом — purchase.

Проверка перед продом: 1) сравнить event_id в Pixel и CAPI, 2) убедиться, что timezone и timestamp не пляшут, 3) посмотреть, не создаёт ли GTM Server новый id на каждом триггере. Если dedup rate низкий, сначала ищите расхождение в идентификаторах, а не в payload.