Server-side контейнер: когда остановиться и не плодить теги

Server-side контейнер: когда остановиться и не плодить теги

Все последние проекты в GTM начинаются одинаково: клиент хочет «нормальный server-side», как у людей. Поднимаем контейнер, ставим sGTM, переносим GA4 и пиксели. Дальше начинается зона, где большинство маркетологов теряет берега — и плодит теги по привычке из браузерного стека.

Практическое наблюдение: в среднем проекте после миграции в sGTM остаётся 35–45% тегов от исходного web-GTM. Остальное оказывается либо дубликатами (когда один и тот же пиксель отправлялся в браузере и через custom template, а потом ещё и в CAPI), либо мёртвым грузом — триггерами, которые стреляли раз в квартал по ошибке разработчика.

На что опираюсь, когда решаю, что оставлять в server-контейнере:

— **Бизнес-критичные конверсии.** Покупка, qualified lead, повторное обращение. То, по чему считают медиа-микс и оптимизируют бюджет. Их перенос даёт ощутимый прирост точности атрибуции.

— **События, завязанные на first-party данные.** Подписки, авторизации, обогащение профиля — всё, что требует стабильной передачи user_id и согласия. В браузере они теряются на каждом втором Safari.

— **Ретаргетинг и CAPI, если идёт реальный объём кампаний.** При бюджете от условных 300 тысяч в месяц на платформу server-event экономит на дублирующих сигналах и улучшает матчинг.

Что точно не стоит тащить в sGTM:

— **Микро-конверсии, которые никто не использует.** «Клик по соцсети в футере», «время на странице 60 секунд», «скролл 25%» — в браузере они хотя бы не нагружали инфраструктуру, а в server-контейнере начинают есть запросы.

— **Триггеры на DOM-элементы.** В server-контейнере нет страницы. Любой триггер по click classes или text остаётся в web-GTM, а в sGTM приходит только как уже подготовленное событие через Data Layer или Data Client.

— **Дублирование ради «подстраховки».** Один и тот же Purchase в GA4 + Meta CAPI + VK Pixel + ещё один внутренний endpoint — это не server-side, это четыре разных источника истины. Достаточно выбрать по одному каналу на платформу.

Отдельный момент про **consent mode v2** в 2026. Без нормальной передачи согласий из CMP в sGTM server-контейнер превращается в дорогой прокси. Пиксель всё равно получит ограниченные события, и выигрыша по точности не будет. Поэтому перед подъёмом server-side я всегда начинаю с аудита CMP — какие статусы отдаются, как обновляются, попадают ли они в sGTM через тег шаблона или руками.

Короткий чек-лист для самопроверки после миграции: откройте вкладку Tags в опубликованной версии web-GTM, выгрузите список, рядом поставьте список тегов в sGTM. Если в sGTM больше 60% от web-контейнера — скорее всего, вы перенесли привычки, а не архитектуру.

Server-side — это не про «больше событий». Это про меньше событий, но чище и ближе к источнику данных. Как только команда это принимает, тегов в контейнере становится неожиданно спокойно.

— @GTMrecipesRuPro