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

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

Первый риск — попытаться «перенести всё как есть» из web-container в server-container. Серверный слой не лечит грязные dataLayer-события: если client шлёт мусор, server просто аккуратно его доставит дальше. Сначала фиксируйте контракт события: name, обязательные параметры, типы, порядок заполнения.

Второй риск — смешать транспорт и бизнес-логику. В sGTM контейнер должен решать, куда и в каком виде отправить событие, а не заново вычислять revenue, user_id или attribution. Всё, что можно посчитать на клиенте или в backend, лучше подготовить до отправки. Иначе получите дубли, расхождения и очень дорогую отладку.

Третий риск — игнорировать observability. Для каждого важного события нужен понятный маршрут: client_id, event_id, source, timestamp, статус доставки. Без этого server-side tagging превращается в чёрный ящик, где «вроде отправилось» не помогает в разборе потерь.

Что делать на практике: заведите минимальную спецификацию событий, проверьте дедупликацию по event_id, включите тестовые логи на уровне каждого тега и отдельно документируйте, где живёт источник истины для revenue и user identity. Тогда sGTM будет не красивой обёрткой, а управляемым слоем доставки данных.