Back to archive
10.13Веб-аналитика и GTM

Инфраструктура sGTM: Google Cloud, Stape и собственный контур

TL;DR

  • Server-Side GTM требует серверов. Значит, появляются расходы, monitoring, autoscaling, DNS, логи, безопасность и владелец инфраструктуры.
  • Google рекомендует Cloud Run для нового server-side deployment. В документации Google указывает ориентир около $45 в месяц за один Cloud Run server и рекомендует минимум 2 instances для снижения риска потери данных.
  • Managed providers вроде Stape снижают порог входа: проще DNS, фиксированнее тарифы, готовые integrations, меньше DevOps.
  • Enterprise, финтех и regulated business часто не могут просто “поставить Stape” из-за ИБ, vendor risk, data residency и требований к логам.
  • Правильный выбор зависит не от моды, а от трафика, бюджета, чувствительности данных и способности команды поддерживать инфраструктуру.

1. Почему sGTM стоит денег

Web GTM кажется бесплатным, потому что работает в браузере пользователя. Server-Side GTM работает на сервере, который нужно где-то запустить. Каждый page view, event, script load, debug request и bot request может стать входящим запросом.

Сервер должен:

  • принять HTTP request;
  • найти подходящий Client;
  • создать event data;
  • применить transformations;
  • запустить tags;
  • отправить запросы в vendor APIs;
  • залогировать или не залогировать событие;
  • выдержать пик нагрузки;
  • обновляться и не падать.

Если команда думает о sGTM как о “еще одном теге”, она не планирует расходы. Если думает как о мини-сервисе, вопросов меньше.

2. Вариант 1: Google Cloud / Cloud Run

Google Cloud - естественный путь, потому что server-side GTM является продуктом Google Tag Manager, а документация Google подробно описывает Cloud Run setup.

Когда подходит

  • у команды есть DevOps или cloud engineer;
  • уже используется Google Cloud;
  • есть требования к контролю инфраструктуры;
  • нужен predictable scaling;
  • важно развернуть preview и production корректно;
  • есть бюджет на поддержку и monitoring.

Плюсы

ПлюсЧто дает
КонтрольВы управляете проектом, region, scaling, IAM, billing
Интеграция с GoogleДокументация и deployment path от Google
МасштабированиеCloud Run умеет масштабироваться по нагрузке
Enterprise governanceМожно встроить в существующие cloud policies

Минусы

МинусПочему важно
Нужен billing controlБез alerts можно получить неприятный счет
Нужно следить за logsRequest logs при большом трафике могут стоить денег
Нужны знания GCPIAM, Cloud Run, load balancer, DNS, regions
Не “один клик” для бизнесаМаркетолог без технической поддержки быстро упрется

Google в Cloud Run guide отдельно советует ставить billing alert. Это не декоративная рекомендация. sGTM видит каждый запрос, а в периоды распродаж, launch или bot traffic нагрузка может резко вырасти.

3. Вариант 2: Managed hosting, например Stape

Stape и похожие провайдеры продают managed hosting для server-side GTM. Они берут на себя серверную часть, DNS-инструкции, часть monitoring, templates, integrations и более понятный billing.

Когда подходит

  • малый и средний e-commerce;
  • performance-агентство;
  • EdTech или локальный сервис без сильного DevOps;
  • нужно быстро запустить Meta CAPI, GA4 server-side, TikTok Events API;
  • важна предсказуемая цена и простая поддержка.

Плюсы

ПлюсЧто дает
Быстрый стартМеньше cloud-настроек
Готовые integrationsПлагины, templates, managed features
Понятнее тарифыЧасто проще считать запросы и план
SupportЕсть команда, которая живет server-side tracking

Минусы

МинусПочему важно
Vendor riskВы доверяете третьей стороне часть маркетинговых данных
Ограничения тарифаRequest limits, features, отдельные containers
Не всегда подходит ИББанки и regulated business могут не пропустить
Нужно читать pricingВходящие hits, script loads и debug traffic тоже могут считаться

Stape в pricing описывает request как каждый incoming hit в server GTM container, включая tracking hits и script loads вроде gtm.js, gtag.js, analytics.js. Это важная деталь: считать нужно не только purchases.

4. Вариант 3: собственный контур / Docker / private cloud

Собственный контур нужен, когда данные слишком чувствительные или организация не может пропустить managed vendor.

Когда подходит

  • банк;
  • страховая;
  • telecom;
  • крупный marketplace;
  • enterprise с жестким vendor management;
  • проект с on-premise или private cloud политикой;
  • нужно хранить логи и traffic внутри контролируемого периметра.

Плюсы и минусы

ПлюсыМинусы
Максимальный контрольДорого по людям
Можно встроить в ИБ-процессыДольше запуск
Свои регионы, сети, логиНужно самостоятельно обновлять и мониторить
Лучше для sensitive dataОшибки DevOps могут стоить дороже тарифа Stape

Для локального банка фраза “поставим зарубежный SaaS, через него пойдут телефоны и события клиентов” может закрыть проект еще на security review. В таких случаях sGTM надо проектировать вместе с ИБ и юристами.

5. Как выбрать: decision matrix

КритерийGoogle CloudStape / managedСобственный контур
Скорость запускаСредняяВысокаяНизкая
Требования к DevOpsСредние/высокиеНизкие/средниеВысокие
Контроль инфраструктурыВысокийСреднийМаксимальный
Predictable pricingСреднийВысокийЗависит от команды
Подходит МСБИногдаДаОбычно нет
Подходит enterpriseДаИногдаДа
ИБ / complianceХорошо при настройкеНужно проверять vendorМаксимально гибко

6. Стоимость: что считать до запуска

Минимальная модель расчета:

monthly_requests =
page_views
+ analytics_events
+ ecommerce_events
+ script_loads
+ crm_webhooks
+ preview_debug_requests
+ bot_noise

Потом оцените:

  • сколько tags запускается на одно событие;
  • есть ли retry;
  • логируются ли request paths и query params;
  • будут ли пиковые нагрузки;
  • нужен ли multi-region;
  • сколько environments: preview, staging, production;
  • кто получает alerts.

7. Анти-кейсы

Анти-кейс 1. Запуск Cloud Run без billing alerts

Команда запускает sGTM перед распродажей. Трафик растет, autoscaling делает свою работу, но никто не смотрит billing. Через месяц приходит счет, который “внезапно” выше ожиданий. Проблема не в Cloud Run. Проблема в отсутствии capacity planning.

Анти-кейс 2. Stape без проверки данных

Маркетинг быстро запускает managed hosting, но никто не проверил, какие данные реально уходят в server container. В query params попадают email, phone или internal IDs. Managed hosting не освобождает от data minimization.

Анти-кейс 3. Собственный контур без ownership

Enterprise поднимает sGTM в private cloud, но назначает владельцем “отдел аналитики” без доступа к infrastructure logs. Через два месяца CAPI tag падает, и никто не может быстро понять, где ошибка: DNS, container, tag template, vendor API или CRM webhook.

8. Практический сценарий для локального e-commerce

Магазин с 150 000 visits в месяц, Meta + Google Ads + GA4, разработчиков мало.

Рациональный путь:

  1. Описать события и event_id.
  2. Проверить consent и dataLayer.
  3. Запустить managed sGTM hosting.
  4. Подключить custom domain metrics.shop.kz.
  5. Отправлять page_view, view_item, add_to_cart, lead, purchase.
  6. Настроить Meta CAPI и GA4 через server container.
  7. Сверять browser vs server events в первые 2 недели.
  8. Через месяц решить, нужен ли Cloud Run или managed достаточно.

Не рациональный путь: начинать с on-premise Kubernetes, если команда не умеет поддерживать обычный GTM.

9. Практический чеклист выбора

  • Посчитан примерный monthly request volume.
  • Определены пиковые сценарии: launch, распродажа, bots.
  • Понятно, какие данные проходят через server container.
  • Проверены privacy, consent, PII и vendor risk.
  • Выбран custom domain.
  • Есть billing alerts или fixed plan.
  • Есть monitoring успешности vendor tags.
  • Есть владелец DNS и владелец контейнера.
  • Есть план миграции, если выбранный провайдер станет дорогим или неподходящим.

10. Видео

Server-Side Tracking: Google Cloud vs Stape

11. Главный совет

Не выбирайте инфраструктуру sGTM по принципу “дешевле” или “так сказал подрядчик”. Выбирайте по риску. Для МСБ риск - не запуститься и утонуть в DevOps. Для банка риск - выпустить чувствительные данные в чужой контур. Для enterprise риск - не иметь владельца и monitoring.

Sources / Notes