TL;DR
- Server-side GTM - это не "обычный GTM на сервере", а отдельный контейнер, который принимает события, обрабатывает их и отправляет дальше.
- В sGTM есть важная сущность: client. Client понимает входящий запрос и превращает его в event data.
- Основная польза sGTM - контроль: меньше лишних скриптов в браузере, больше правил на стороне сервера, лучше privacy и качество данных.
- Самая опасная ошибка - думать, что sGTM сам решает архитектуру. Он только инструмент. Схему событий все равно нужно проектировать.
- Для продакшена нужен custom domain, preview/debug процесс, мониторинг, логи и понятный владелец инфраструктуры.
1. Что такое sGTM
В обычном Google Tag Manager контейнер живет на сайте. Он запускает теги в браузере: GA4, Google Ads, Meta Pixel, TikTok Pixel, Hotjar, пиксели партнеров и так далее.
В server-side GTM появляется второй контейнер. Он живет в облаке или у провайдера вроде Stape. Сайт отправляет события на ваш серверный endpoint, а server container решает, что делать дальше.
Простая метафора: web GTM - это курьер, который приносит пакет. sGTM - это сортировочный центр. Он открывает пакет, проверяет адреса, убирает лишнее, добавляет нужное и отправляет копии туда, куда нужно бизнесу.
2. Из каких частей состоит sGTM
| Элемент | Что делает |
|---|---|
| Server container | Основной контейнер в GTM типа Server |
| Tagging server | Облачная инфраструктура, где контейнер работает |
| Client | Принимает входящий запрос и превращает его в event data |
| Tag | Отправляет событие в конечную систему |
| Trigger | Решает, когда запускать tag |
| Variable | Достает значение из event data или запроса |
| Transformation | Меняет или чистит данные перед отправкой |
| Preview | Показывает, что реально пришло и что ушло |
Самая непривычная часть для маркетолога - clients. В web GTM вы обычно думаете тегами и триггерами. В sGTM сначала нужно понять, кто "заберет" входящий запрос. Например, GA4 client умеет распознавать GA4-запросы и создавать из них события для серверного контейнера.
3. Почему custom domain важен
Если server endpoint выглядит как сторонний домен, часть смысла теряется. Хорошая практика - использовать first-party поддомен: например, analytics.company.kz, collect.company.kz или sgtm.company.kz.
Это дает:
- больше контроля над cookies;
- меньше зависимости от сторонних доменов;
- более понятную privacy-модель;
- аккуратную настройку CSP;
- единый endpoint для отправки данных.
Но custom domain - это уже зона ответственности. Нужно настроить DNS, SSL, CORS, CSP и проверить, что запросы реально доходят до server container.
4. Как событие проходит через sGTM
В этой схеме важно не потерять бизнес-поля. Если в браузере был только purchase, а value, currency, order_id и user identifiers не доехали, сервер не сможет угадать их сам. Поэтому dataLayer, backend и CRM должны говорить на одном языке.
5. Что выносить на сервер
Не нужно переносить в sGTM все подряд.
Хорошие кандидаты:
- GA4 event collection;
- Google Ads conversions;
- Meta Conversions API;
- TikTok Events API;
- хеширование user data;
- фильтрация PII;
- отправка quality events из CRM;
- логирование запросов;
- нормализация value, currency, event names.
Плохие кандидаты:
- UI-аналитика без бизнес-смысла;
- теги, которым нужна DOM-логика;
- случайные пиксели партнеров без проверки;
- все, что не имеет владельца и документации.
6. Локальный контекст СНГ/РК
Для локальных команд sGTM часто становится мостом между маркетингом, IT и безопасностью. Маркетинг хочет больше сигналов. IT хочет меньше хаоса на фронтенде. Безопасность хочет понимать, какие данные уходят наружу.
В банках, страховании и финтехе sGTM может быть компромиссом: рекламные платформы получают события и хешированные идентификаторы, но сырые персональные данные не уходят из внутреннего контура.
В e-commerce и EdTech sGTM помогает связать online-событие с backend-статусом: заказ оплачен, курс начат, платеж не прошел, подписка продлена.
7. Ошибки
| Ошибка | Последствие |
|---|---|
| Нет владельца sGTM | Никто не чинит поломки |
| Нет naming convention | В контейнере быстро бардак |
| Не включили custom domain | Потеряли часть first-party преимуществ |
| Не проверили CSP/CORS | Сайт не может отправить запросы |
| Нет логов | Ошибки видны только по падению конверсий |
| Нет документации event data | Каждый тег собирает поля по-своему |
8. Чеклист запуска
- Создан server container в GTM.
- Выбрана инфраструктура: Google Cloud, AWS, Stape или другой провайдер.
- Настроен custom domain.
- Web container отправляет события на server endpoint.
- Проверен preview mode.
- Настроены первые tags: GA4, Google Ads или Meta CAPI.
- Добавлены transformations для PII и лишних полей.
- Есть логирование request/response.
- Есть документ с событиями и владельцами.
9. Видео
10. Главный совет
Не начинайте sGTM с "давайте перенесем все теги". Начните с одного потока, где потеря данных стоит денег: purchase, qualified lead или approved application. Если этот поток стабилен, масштабируйте архитектуру дальше.
Sources / Notes
- Google Tag Manager: Server-side tagging
- Google Developers: An introduction to server-side tagging
- Google Developers: Send data to server-side Tag Manager
- Stape: Server GTM container hosting