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

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

Проксирование через sGTM не спасает от плохой схемы данных. Если события шлёт Pixel, а сервер просто ретранслирует их дальше, сначала проверьте основу: event_id, user_data, consent, transport.

— Один event_id на пару Pixel + CAPI, иначе deduplication развалится.
— Передавайте минимум fbp, fbc, client_ip, user_agent, external_id, а PII хешируйте SHA-256 после нормализации.
— Не теряйте event_name и event_time: без них разбор воронки и дедупликация становятся шумом.
— Сверяйте payload на клиенте и на сервере: если параметр есть в Pixel, но исчезает в прокси, ищите обрезку в Custom Client или Tag template.

Отдельно проверьте источники трафика. Если click_id не доживает до сервера, атрибуция начнёт расползаться по Direct и Organic. Для CAPI это особенно заметно на Purchase и Lead: событие отправлено, но матчинг слабый, потому что серверу не хватает идентификаторов.

После запуска не смотрите только на количество хитов. Сравните:
— долю deduped событий;
— расхождение между клиентским и серверным объёмом;
— наличие ошибок 4xx/5xx в логах sGTM;
— стабильность event_time и timezone.

Если на стороне сервера payload стал «чище», а отчётность хуже — проблема обычно в фильтрации, а не в атрибуции. Сначала чинят передачу и дедупликацию, потом уже оптимизируют routing и enrichment.