<b>Server-side tagging не чинит трекинг само по себе — вот что проверить до запуска</b>
Перенос тега на сервер полезен только тогда, когда вы понимаете, <i>что именно</i> уезжает в sGTM: идентификаторы, события, consent-статус, параметры ремаркетинга. Если на клиенте уже ломается dataLayer, сервер просто получит аккуратно упакованную ошибку.
Проверьте базовые вещи:
— client-side событие стабильно приходит в GTM и не дублируется;
— в payload есть нужные ключи для GA4, Ads и CAPI;
— не теряются gclid, fbclid, client_id, session_id;
— cookie domain и path согласованы между поддоменами;
— consent mode и блокировка рекламных хитов продуманы до маршрутизации.
Отдельно смотрите на логику триггеров. В server-side легко случайно отправить лишнее: page_view на каждый internal redirect, purchase без валидации суммы, user_data без нормализации. Самая частая ошибка — считать, что сервер заменяет контроль качества. На деле он лишь делает его обязательным. 🧩
Что делать на практике: сначала соберите карту потоков данных — от события в браузере до конечного эндпоинта. Затем тестируйте не «работает ли тег», а «какие поля дошли, что было обрезано, где потерялся идентификатор». Если это не проверять, server-side tagging превращается в дорогой ретранслятор мусора.
GTM & GA4 Deep
@gtm_ga4_deep
<b>Server-side tagging не чинит трекинг само по себе — вот что проверить до запуска</b>
Этот пост опубликован в Telegram-канале GTM & GA4 Deep. Подписаться можно по ссылке: @gtm_ga4_deep.