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

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

Проксировать Pixel через sGTM имеет смысл, когда client-side события режутся браузером, но схема ломается на мелочах: не тот event_id, пустой fbp/fbc, разные таймстемпы.

Проверьте базу:
— event_id генерируется один раз и уходит и в браузер, и в серверный тег
— page_view, ViewContent, AddToCart, Purchase не переименованы между каналами
— fbp/fbc передаются как есть, без обрезки и переформатирования
— IP и User-Agent берутся с входящего запроса, а не из сохранённого профиля

Дальше смотрите на маршрут: сервер должен принимать только те события, которые реально нужны для атрибуции, а не весь поток подряд. Для Purchase и Lead обычно хватает малого набора полей, но они должны быть стабильны по всем касаниям. Если событие пришло дважды — Pixel и CAPI должны сходиться по event_id, иначе дедупликация не сработает.

Отдельный анти-кейс: когда в sGTM добавляют промежуточную логику и меняют payload «для удобства». После этого match_keys уже не совпадают с браузерной версией, а в отчётах растёт мусор. Сначала фиксируйте контракт данных, потом оптимизируйте.

Итог простой: проксирование работает только как копия с сохранением идентичности события, а не как «улучшенный» пересборщик.