Server-side GTM для арбитража: архитектура, которая не ломается на первом сплите

Server-side GTM для арбитража: архитектура, которая не ломается на первом сплите

Если строите sGTM под арбитраж, не начинайте с «поставим один контейнер и посмотрим». Сначала разделите поток на 3 уровня: сбор, нормализация, отправка. На входе — web events из браузера, server events из CRM/бота/лендинга, на выходе — CAPI, TikTok Events API, Google Ads Enhanced Conversions.

Базовая схема простая:
— отдельный sGTM контейнер на домене первого уровня;
— Cloud Run или VPS за reverse proxy;
— cache для event_id и deduplication;
— маршрутизация по event_name и source;
— логирование payload до отправки в each destination.

Критичные поля, которые стоит тащить через сервер: fbp, fbc, client_ip, user_agent, external_id, hashed email/phone. Хешировать нужно только нормализованные значения: lowercase, trim, телефон в E.164, SHA-256. Для дедупликации задайте один event_id на весь путь Pixel + CAPI, а не генерируйте его заново в каждом теге.

Анти-кейс: когда всё отправляют через один общий tag без схемы, начинают дублироваться purchase, теряются source/medium, а EMQ падает из-за пустых user_data. Лучше держать отдельные правила для лидов, регистрации и покупки, чем пытаться одним маршрутом покрыть всё.

Итог: в арбитраже sGTM работает как роутер и очиститель данных, а не как «ещё один пиксель». Сначала архитектура и дедупликация, потом масштабирование.