TL;DR
- Server-Side GTM - это не “GTM на сервере вместо сайта”. Это отдельный серверный контейнер, который принимает HTTP-запросы, преобразует их в event data и отправляет дальше.
- В нормальной архитектуре есть два контейнера: web GTM на сайте и server GTM в облаке или своей инфраструктуре.
- Новая ключевая сущность sGTM - Client. Он принимает входящий запрос и превращает его в событие, с которым дальше работают triggers и tags.
- Custom domain или same-origin serving критичны. Дефолтный домен облачного провайдера дает меньше пользы, потому что работает не как полноценный first-party endpoint.
- sGTM дает контроль, но добавляет ответственность: стоимость, безопасность, monitoring, consent, версии, тестирование и права доступа.
1. Что такое Server-Side GTM
Обычный web GTM живет в браузере. Он слушает dataLayer, клики, формы, page views и запускает теги. Server-Side GTM живет в серверной среде. Он принимает запросы от сайта, приложения, backend или webhook, обрабатывает их и отправляет в Google Analytics, Google Ads, Meta, TikTok, CRM, BI или собственный API.
Главная идея: браузер не должен напрямую общаться с десятью внешними платформами. Он отправляет событие в один контролируемый endpoint. Дальше сервер решает, куда, что и в каком виде отправить.
2. Чем sGTM отличается от web GTM
| Область | Web GTM | Server-Side GTM |
|---|---|---|
| Где работает | Браузер пользователя | Cloud Run, App Engine, managed hosting, Docker |
| Главный вход | dataLayer.push() и DOM-события | HTTP request |
| Ключевые сущности | Tags, triggers, variables | Clients, tags, triggers, variables, transformations |
| Риск | Перегрузить сайт скриптами | Неправильно обработать данные или счет за облако |
| Privacy-контроль | Ограниченный | Выше: можно удалять, хэшировать, нормализовать |
| Стоимость | Обычно бесплатно | Нужна серверная инфраструктура |
Web GTM не исчезает. Он становится тонким слоем сбора событий. Server GTM становится маршрутизатором и фильтром.
3. Client: новая сущность, которую часто недооценивают
В web GTM тег сам знает, когда сработать. В sGTM сначала нужно понять, что за запрос пришел. Этим занимается Client.
Примеры:
| Client | Что принимает | Когда нужен |
|---|---|---|
| GA4 Client | GA4 Measurement Protocol / browser hits | Типовой старт sGTM |
| Google Analytics Client | Запросы Google tag / GA4 | Когда web GTM отправляет события в server container |
| Custom Client | Собственный формат HTTP-запроса | Когда backend или CRM шлет кастомные события |
| Vendor-specific Client | Формат конкретной платформы | Для специальных интеграций или templates |
Client превращает входящий request в normalized event data. После этого теги работают уже не с сырым HTTP, а с понятными полями: event_name, client_id, user_data, value, currency, page_location, consent_state.
4. Базовый поток события
В хорошей схеме sGTM не просто пересылает запрос. Он отвечает на вопросы:
- можно ли отправлять это событие с текущим consent;
- есть ли обязательные параметры;
- не является ли событие тестовым;
- не содержит ли оно PII;
- нужно ли добавить данные из cookie, CRM или backend;
- как дедуплицировать browser и server copy;
- какие vendor tags должны сработать.
5. Custom domain и first-party context
Google в документации отдельно подчеркивает: чтобы получить пользу от first-party context и server-set cookies, tagging server должен работать на вашем домене.
Плохой вариант:
Лучше:
Еще лучше для части сценариев:
| Вариант | Польза | Сложность |
|---|---|---|
| Default cloud domain | Быстрый старт, удобно для preview | Меньше first-party benefits |
| Subdomain | Хороший баланс | Нужно настроить DNS |
| Same-origin path | Максимально близко к сайту | Нужен CDN / load balancer / reverse proxy |
Если компания внедрила sGTM, но оставила дефолтный домен провайдера, она получила часть маршрутизации, но не всю архитектурную пользу.
6. Transformations: где появляется реальный контроль
Transformations нужны, чтобы менять event data до отправки в теги. Это один из самых сильных аргументов за sGTM.
Пример правил:
| Правило | Зачем |
|---|---|
Удалить iin, passport, card_number | Не отправлять чувствительные данные |
Хэшировать email и phone | Улучшить match quality без передачи plain text |
Удалить query params из page_location | Не утащить PII из URL |
Нормализовать currency | Не смешивать KZT, USD, RUB |
Отклонить событие без event_id | Не ломать дедупликацию |
| Отклонить события из test/staging | Не засорять рекламные кабинеты |
Для финтеха, EdTech, медицины, недвижимости и маркетплейсов этот слой важнее самого факта “server-side”.
7. Что отправлять через sGTM
Не нужно тащить на сервер каждый scroll и mousemove. Начните с бизнес-событий.
| Событие | Отправлять? | Почему |
|---|---|---|
page_view | Да, если нужен server-side GA4 / Ads | Базовая аналитика и session context |
view_item | Иногда | Полезно для e-commerce remarketing |
add_to_cart | Да для e-commerce | Сигнал намерения |
lead | Да | Критично для performance |
qualified_lead | Да | Лучше обычного лида для обучения |
purchase | Да | Главный conversion signal |
refund | Да в BI и иногда в ad platforms | Нужен для качества ROMI |
scroll_depth | Обычно нет | Часто шум, не стоит серверных расходов |
8. Роли в команде
sGTM нельзя качественно внедрить одним маркетологом “после обеда”. Нужны роли:
| Роль | За что отвечает |
|---|---|
| Маркетолог | Какие события нужны платформам и для каких кампаний |
| Веб-аналитик | Naming, dataLayer, event schema, GA4, QA |
| Frontend | dataLayer, web GTM, consent initialization |
| Backend / CRM | server events, IDs, statuses, webhooks |
| DevOps | hosting, DNS, Cloud Run / Docker, monitoring |
| Legal / DPO / ИБ | Consent, PII, retention, vendor risk |
Если одна роль отсутствует, проект обычно не останавливается сразу. Он просто становится хрупким.
9. Анти-кейсы
Анти-кейс 1. sGTM без custom domain
Команда создала server container, но оставила default domain. На схемах все красиво, но часть first-party преимуществ теряется. Потом команда удивляется, почему cookie durability и блокировки не улучшились так, как обещал подрядчик.
Анти-кейс 2. Все события подряд
В server container отправляют scroll, hover, visibility, timer events, debug events. Расходы растут, логи пухнут, а полезность для рекламы почти нулевая. sGTM становится дорогим мусоропроводом.
Анти-кейс 3. Нет ownership
Meta CAPI тег упал после обновления template. Никто не заметил месяц. Рекламные кампании просели, но команда винила креативы. Нужен monitoring, а не только первичная настройка.
10. Практический чеклист запуска
- Создан server container в GTM.
- Выбран hosting: Cloud Run, App Engine, Stape, другой managed provider или свой Docker.
- Настроен custom domain или same-origin path.
- Web GTM отправляет события в server container.
- Clients правильно распознают входящие запросы.
- Transformations удаляют PII и нормализуют event data.
- Теги Meta / Google / TikTok получают только нужные параметры.
-
event_idсохраняется для дедупликации. - Consent state учитывается до отправки vendor tags.
- Есть preview/debug, monitoring и владелец инцидентов.
11. Видео
12. Главный совет
Server-Side GTM - это не кнопка “улучшить трекинг”. Это middleware для маркетинговых данных. Относитесь к нему как к маленькому backend-сервису: схема, права, мониторинг, логи, тесты, владелец, стоимость и план отката.
Sources / Notes
- Google Developers: Google Tag Manager - Server-side
- Google Tag Manager Help: Client-side tagging vs. server-side tagging
- Google Developers: Custom domain configuration
- Google Developers: Set up server-side tagging with Cloud Run
- Google Developers: Consent mode overview