Server-side tagging ломают не теги, а архитектуру: 5 мест, где теряются данные

Server-side tagging ломают не теги, а архитектуру: 5 мест, где теряются данные

Сама схема server-side не спасает трекинг, если на этапе сборки вы не закрыли базовые дыры. Чаще всего проблемы начинаются не в контейнере, а между браузером, сервером и конечной платформой.

— Не совпадают идентификаторы: client_id, session_id, user_id живут отдельно, а в отчётах потом «прыгают» сессии и конверсии.
— Не настроен устойчивый first-party домен: часть запросов уходит в серую зону, а cookies живут меньше, чем ожидается.
— Не проверены правила маршрутизации: один и тот же event улетает в несколько destination без явного контроля дедупликации.
— Не описан consent flow: сервер получает событие, но не понимает, можно ли отправлять его дальше.
— Нет логики retry и fallback: при ошибке на одном endpoint событие просто теряется.

Что важно: server-side tagging — это не «перенос GTM на сервер», а отдельный слой данных. Если в браузере шум, на сервер он тоже прилетит, только дороже и сложнее в отладке.

Что делать на практике: сначала зафиксируйте схему идентификаторов, consent и правила дедупликации. Потом уже подключайте отправку в рекламные и аналитические системы.