Типовой стек server-side трекинга: что должно быть до CAPI и Events API
Server-side не начинается с тега Meta CAPI. Рабочий стек — это прием, нормализация, дедупликация и маршрутизация событий. Без этого sGTM становится прокси, который пересылает грязные payload’ы дальше.
Минимальный набор:
— Web container: event_id, consent, fbp/fbc, gclid/gbraid/wbraid;
— Server container: валидация schema, IP, User-Agent;
— Identity layer: email/phone в SHA-256 после нормализации, external_id;
— Raw log: событие до отправки в Meta/Google/TikTok;
— Monitoring: 4xx/5xx, latency, dedup rate, missing match keys.
Правило для event_id: генерировать один раз на клиенте и тащить через Pixel + CAPI. Не пересоздавать на сервере, иначе платформа увидит два похожих события без надежной дедупликации.
Отдельно держите mapping: внутреннее событие → vendor event. order_paid может уходить как Purchase в Meta, purchase в GA4 и CompletePayment в TikTok. Это снижает хаос в тегах.
Хороший стек не обещает «вернуть все события». Он дает контроль: что приняли, чем обогатили, что отправили и где потеряли.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
Типовой стек server-side трекинга: что должно быть до CAPI и Events API
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.