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

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

Самая частая ошибка — Pixel и CAPI живут с разными event_id. Браузер шлёт один идентификатор, сервер генерирует другой, и платформа видит две конверсии вместо одной. Вторая проблема — серверный хит приходит раньше клиентского, а затем окно дедупликации не срабатывает так, как ожидали.

Проверьте базовую схему:
— event_id генерируется один раз на клиенте и прокидывается в sGTM;
— один и тот же event_id уходит в Pixel и CAPI;
— для Purchase/Lead не создавайте новый id при каждом ретрае;
— если есть retries, не меняйте payload, только повторяйте отправку.

Ещё один источник дублей — разные названия событий и разные правила маппинга. Например, client-side шлёт Purchase, а server-side уходит как CompletePayment; платформа не склеит их автоматически. То же касается custom events: без жёсткого соглашения по имени и полям deduplication становится лотереей 🔧

Лучший тест — открыть один и тот же event_id в логах браузера, в sGTM и в CAPI-ответе. Если хотя бы на одном этапе значение меняется, дедупликация будет гулять.