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

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

Первый провал — пытаться «просто перенести» web-теги на сервер. На клиенте можно жить с шумом, на сервере всё всплывает: дубли, пустые user_id, разъехавшиеся event_name и разные ключи у одних и тех же параметров.

Что проверить до запуска:
— единый контракт событий: название, обязательные параметры, идентификаторы;
— кто формирует event_id и как он проходит через web, server и ad platforms;
— где лежит truth source для client_id, user_id, consent и deduplication.

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

На практике удобнее держать один слой нормализации: привести параметры к одному словарю, отрезать мусор, добавить source/medium только там, где это действительно нужно, и писать все отклонения в лог. Тогда вы видите не «почему упал пиксель», а «какое поле пришло битым».

Что делать: сначала описать схему событий и правила дедупликации, потом запускать серверный трекинг. Иначе вы не усиливаете измерение, а просто переносите хаос с браузера в дата-центр.