Server-side tagging ломается не в GTM, а в логике событий и идентификаторов

Server-side tagging ломается не в GTM, а в логике событий и идентификаторов

Если переносите трекинг на сервер, не начинайте с «поставить контейнер». Сначала проверьте, какие события вообще должны идти через server-side, какие параметры нужны на выходе и чем вы будете матчить пользователя между web, app и CRM.

Что важно:
— единый event_id для дедупликации;
— стабильный client_id / user_id;
— понятная схема consent, чтобы не слать лишнее;
— список обязательных параметров для GA4, Ads и BigQuery.

Типовая ошибка — отправлять на сервер «сырой» веб-хит без нормализации. В итоге в аналитике появляются дубли, теряются атрибуция и источники, а в дебаге всё выглядит «почти правильно». Ещё одна проблема — когда серверный контейнер становится просто прокси для client-side, без фильтрации, enrichment и контроля качества.

Что делать на практике: опишите контракт события до настройки GTM. Для каждого события зафиксируйте имя, обязательные поля, источник истины и правило дедупликации. Если этого нет, server-side tagging ускорит не аналитику, а размножение ошибок.