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

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

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

Что должно быть в прокси-цепочке:
— Pageview/Purchase идут в один и тот же endpoint
— В payload сохраняются event_name, event_time, event_id
— Для CAPI передаются user_data: email_hash, phone_hash, ip, user_agent, fbp, fbc
— Хеширование только SHA-256, с нормализацией lower-case, trim, E.164 для телефона

Дальше смотрите на порядок запросов. Если server-event приходит сильно раньше Pixel, часть систем может выбрать не тот источник для дедупликации. Рабочий паттерн: генерировать event_id на клиенте, а в sGTM только прокидывать его дальше без переименования и без «умного» преобразования.

Отдельный чек: не теряйте query-параметры click_id на редиректах и не режьте cookies на уровне прокси. Если fbc/fbp пустые, EMQ и match rate падают даже при идеальном роутинге.

Итог простой: сначала стабилизируйте event_id и user_data, потом уже оптимизируйте маршрутизацию. Если дедупликация не сходится, прокси не лечит атрибуцию — он только ускоряет поломку.