<b>Server-side проксирование Pixel событий: чек-лист без потери дедупликации</b>

<b>Server-side проксирование Pixel событий: чек-лист без потери дедупликации</b>

Если проксируете браузерный Pixel через sGTM, первая ошибка — менять payload «как удобнее». Для browser и server части должен совпадать event_name и event_id, иначе deduplication начнёт считать дубли как отдельные конверсии.

Проверьте базу:
— event_id генерируется один раз и уходит в Pixel и CAPI
— fbp и fbc не теряются при проксировании
— user_data передаётся в одном формате: email_hash, phone_hash, external_id
— IP и User-Agent берутся из запроса, а не подставляются шаблонно

Дальше смотрите на routing. Если Custom Client режет query string или cookie headers, серверный запрос к Meta становится «беднее» клиентского. В итоге EMQ падает не из-за CAPI как такового, а из-за того, что вы потеряли контекст до отправки события.

Отдельно проверьте порядок обработки: сначала принять browser event, потом нормализовать данные, потом отправить server copy. Если на этом этапе есть ретраи, ставьте idempotency по event_id, иначе получите повторную отправку одного Purchase.

Практика простая: проксирование работает только когда сервер повторяет смысл client-side события, а не «улучшает» его. Сначала синхронизируйте идентификаторы и поля, потом уже оптимизируйте шаблоны и логику маршрутизации.