Server-side трекмастер: из чего обычно собирают рабочий стек без лишней магии
Базовая схема почти всегда одна: входящий трафик, sGTM как routing layer, storage для логов, очередь для буферизации и мониторинг. Если это один контейнер на Cloud Run без логов и алертов — это не инфраструктура, а точка отказа.
Минимальный стек:
— sGTM endpoint на отдельном домене
— Cloud Run или VPS для контейнера
— BigQuery / Postgres для сырых событий и дебага
— Pub/Sub / Redis Queue для ретраев
— Cloud Logging + алерты по 4xx/5xx и latency
— secret storage для токенов Meta/TikTok/Google
Практика такая: клиент шлёт event_id, fbp/fbc, user-agent, IP, затем сервер нормализует payload, хеширует PII и маршрутизирует в CAPI / Events API / Enhanced Conversions. Для дедупликации держите один event_id на браузер и сервер, иначе Pixel и CAPI начнут спорить между собой.
Самая частая ошибка — складывать всё в один tag template и надеяться на «потом разберём». Правильнее разделять: транспорт, трансформации, отправка в платформы, аудит. Тогда можно менять один кусок без риска положить всю схему.
Если стек не объясняется на одной схеме и не дебажится по request_id, он ещё не готов к продакшену.
Server Attribution — sGTM, CAPI, Privacy Sandbox
@server_attribution
Server-side трекмастер: из чего обычно собирают рабочий стек без лишней магии
Этот пост опубликован в Telegram-канале Server Attribution — sGTM, CAPI, Privacy Sandbox. Подписаться можно по ссылке: @server_attribution.