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

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

Чаще всего команда поднимает sGTM как «ещё один контейнер», а потом удивляется: события дублируются, идентификаторы не сходятся, а атрибуция плывёт. Базовая ошибка — не определить, какие данные считаются каноничными: client_id, user_id, transaction_id, consent_state.

Перед запуском проверьте три слоя:
— источник события: web, app, CRM, offline
— правила дедупликации: по event_id или transaction_id
— маршрутизацию: что уходит в GA4, что в Ads, что хранится в BigQuery

На практике серверный слой нужен не для магии, а для контроля: скрыть чувствительные параметры, нормализовать payload, добавить собственную логику и уменьшить зависимость от браузера. Если тег на клиенте уже отправил событие, сервер не должен «дослать то же самое» без явного дедуп-ключа.

Отдельно проверьте согласия: consent mode, фильтрацию параметров и отказ от лишних cookies. Если сервер принимает всё подряд, вы просто переносите хаос с фронта на инфраструктуру. И да, логирование запросов на сервере важнее красивой схемы в презентации.

Server-side tagging работает только там, где есть понятная схема данных и правила, кто и когда может отправлять событие. Начните с одного критичного потока, опишите дедуп, затем масштабируйте на остальные интеграции.