Типовой стек server-side трекмастера: что должно быть в базе, а что ломает сбор

Типовой стек server-side трекмастера: что должно быть в базе, а что ломает сбор

Server-side инфраструктура для трекинга редко ломается из-за одного «плохого тега». Обычно проблема в стеке: нет очереди, нет нормального логирования, нет разделения transport / routing / enrichment, и потом CAPI начинает терять события на ровном месте.

Базовый набор выглядит так: sGTM контейнер, отдельный endpoint под first-party домен, логирование запросов, буферизация пиков и хранилище сырых событий. Для production лучше сразу разделять входящий payload и обогащение: сначала принять, валидировать и положить в очередь, потом уже отправлять в Meta CAPI, TikTok Events API или Google Enhanced Conversions.

Из практики самый частый провал — пытаться делать все в одном request handler. Так проще на старте, но потом любое внешнее API замедляет ответ, растет timeout, и часть конверсий просто не доезжает. Минимум, который нужен для диагностики: `event_id`, `timestamp`, `source`, `user_agent`, `ip`, `trace_id`, статус отправки и причина ошибки.

Еще один слой, который часто забывают, — observability: алерты по 4xx/5xx, процент дублей, доля невалидных user data, разница между pixel и server count. Если этого нет, вы не понимаете, где именно теряются события: в браузере, на edge, в очереди или уже на стороне рекламной платформы.

Нормальный стек не обязан быть сложным. Но он обязан быть разложен по функциям: прием, очередь, enrichment, доставка, контроль качества. Если эти пять частей видны отдельно, sGTM перестает быть черным ящиком и начинает вести себя как инфраструктура, а не магия.