Server-side GTM — сервер-прокси между браузером и аналитикой, который делает трекинг first-party и переживает блокировщики чуть дольше обычного тега. Это не волшебная кнопка «вернуть все потерянные данные» и не способ обойти согласие на cookies. Разбираю, кому это реально нужно, во что обходится контейнер и свою попытку поднять его на сайте услуг — зря потраченное время и деньги для такого трафика.
Последний год через каждую вторую конференцию по аналитике кто-то произносит «server-side tagging» с придыханием, как будто это решит проблему с данными, которые режут браузеры и блокировщики. Решает частично и не бесплатно. Разбираемся, что это реально такое и кому оно нужно, а не просёто модный термин в резюме маркетолога.
Что происходит технически, в двух словах
В обычной схеме браузер пользователя сам стучится к Google Analytics, Яндекс.Метрике, пикселю рекламной сети — напрямую, с домена третьей стороны. Браузер видит этот запрос как «third-party», и ITP в Safari, Enhanced Tracking Protection в Firefox и любой adblock режут его или урезают время жизни cookie.
В server-side схеме браузер стучится к твоему собственному серверу (поднятому обычно как контейнер GTM Server на Google Cloud Run или похожей платформе), а этот сервер уже сам, от своего имени, пересылает данные дальше в GA4, Метрику, рекламные платформы. Для браузера это теперь first-party запрос — на твой же домен. Cookie живут дольше, часть блокировщиков просто не видит повода резать трафик на собственный домен сайта.
Что это реально чинит
- Продлевает жизнь first-party cookies в Safari — вместо 7 дней ITP может позволить месяцы, если cookie ставит сервер, а не JS-скрипт с третьего домена.
- Часть adblock-листов (например EasyList) блокирует по доменным паттернам именно скриптов аналитики — собственный поддомен в эти списки обычно не попадает, пока ты сам не засветился как трекер.
- Даёт точку контроля для обогащения данных до отправки дальше — можно почистить PII, добавить серверные параметры, прежде чем данные уйдут в GA4 или рекламную сеть.
Что это не чинит — и тут обычно происходит разочарование
Server-side не отменяет требование согласия пользователя на обработку данных — если у тебя юридически нужен consent banner, он нужен и после перехода на server-side, ничего тут не меняется. Не восстанавливает данные от пользователей, которые реально отключили JS целиком или сидят с агрессивным блокировщиком, режущим вообще весь незнакомый JS на странице — такие теряются и при server-side тоже, просто чуть меньше, чем раньше.
И отдельно: это не бесплатно и не «поставил один раз и забыл». Контейнер — это отдельный облачный сервис, который надо администрировать, обновлять, следить за логами ошибок доставки. Для него нужен отдельный поддомен с DNS и SSL. Это инфраструктурный проект, не галочка в настройках GTM.
| Тип сайта | Нужен ли server-side | Почему |
|---|---|---|
| Сайт услуг, до 1000 визитов/мес, без рекламного бюджета | Нет | Потери данных из-за блокировщиков на таком объёме не критичны для принятия решений, инфраструктура не окупается |
| Интернет-магазин с активным Google Ads/Director и ретаргетингом | Да, стоит рассмотреть | Точность конверсий напрямую влияет на эффективность автостратегий в рекламных кабинетах — 10-15% потерянных конверсий ощутимо бьют по оптимизации бюджета |
| B2B-сайт с длинным циклом сделки и CRM-интеграцией | Зависит | Если CRM и так единый источник правды по сделкам — ценность server-side ниже, точность веб-аналитики вторична |
| Крупный сайт на Safari-тяжёлой аудитории (iOS-приложения, арабские/европейские рынки) | Да | ITP режет cookie особенно жёстко в Safari, доля такого трафика там часто выше 25-30% |
Сколько это стоит в деньгах
Сам контейнер на Google Cloud Run при небольшом трафике укладывается в первый бесплатный лимит облака или в единицы долларов в месяц. Дороже — не сервер, а время на настройку: перенести теги, протестировать сквозную доставку данных, не потерять события при миграции. Разовая настройка обычно занимает дни, не часы, если делать аккуратно и с тестированием на всех ключевых событиях сайта.
Для Яндекс.Метрики ситуация отдельная: у неё нет официального, широко задокументированного server-side клиента уровня Google-экосистемы. Для .by/.ru-бизнеса, где Яндекс часто даёт половину или больше органического трафика, server-side-проект почти всегда решает проблему только для Google-стороны аналитики (GA4, Google Ads), а Метрика продолжает жить по старой схеме. Это важно понимать заранее, иначе ожидания от проекта будут раздуты.
Моя попытка, которая была пустой тратой времени
Пробовал поднять server-side контейнер на сайте услуг с трафиком около 500 визитов в месяц — чисто из любопытства, хотелось пощупать руками технологию, про которую все говорят. Два дня настройки, отдельный поддомен, сертификат, перенос трёх основных тегов. Разница в точности данных — в пределах статистической погрешности при таком объёме трафика, её физически нельзя было отличить от шума. Для сайта с рекламным бюджетом в несколько тысяч долларов в месяц та же разница в точности конверсий реально меняет, куда автостратегия Google Ads льёт деньги. Для сайта услуг без рекламы — просто красивая строчка в портфолио навыков, не более.
У тебя в принципе стоит вопрос точности данных, или это просто модный термин, который хочется внедрить потому что «так делают все крупные»? Если рекламного бюджета с автостратегиями нет — вопрос себе задать стоит именно в такой формулировке, не в формулировке «а не отстаём ли мы от рынка».
Больше по теме настройки аналитики: GA4 через GTM, атрибуция в GA4 и Метрике и коллтрекинг без дорогого сервиса.