Server-side трекмастер: из каких блоков собрать стек, чтобы не чинить его каждую неделю

Server-side трекмастер: из каких блоков собрать стек, чтобы не чинить его каждую неделю

Базовый стек для sGTM обычно одинаковый: входной балансировщик, контейнер в Cloud Run или VPS, внешний DNS, логирование и отдельное хранилище секретов. Если чего-то из этого нет, дебаг превращается в гадание: запрос пришёл, но непонятно куда ушёл, кто его резал и где сломался payload.

Минимальная схема:
— DNS с отдельным поддоменом под трекинг
— HTTPS-сертификат и автоматическое обновление
— sGTM-контейнер с лимитами по CPU/RAM
— логирование запросов и ответов
— Secret Manager для токенов CAPI / Events API
— резервный endpoint на случай падения основного маршрута

Для performance-стека критично разделять transport и business logic. Transport отвечает за приём, ретраи, таймауты и заголовки. Logic — за нормализацию user data, матчинг, дедупликацию event_id и маршрутизацию в Meta, TikTok, Google Ads. Когда это смешано в одном шаблоне, любая правка тянет регрессию по всем интеграциям.

Ещё два правила: не хранить ключи в переменных контейнера без ротации и не отправлять вендорам весь сырой request body без фильтрации. В логах оставляйте только то, что нужно для разборов: event_name, status, latency, request_id, а PII — маскируйте.

Если стек собран модульно, вы чините один слой, а не весь пайплайн. Это и есть нормальная server-side архитектура: предсказуемый дебаг, контролируемая стоимость и меньше сюрпризов в проде.