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

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

Базовый скелет один: web GTM остаётся на сайте, sGTM живёт отдельно на своём домене, а все критичные события летят на сервер первым хитом. Дальше сервер уже решает: отправить в Meta CAPI, Google Enhanced Conversions, TikTok Events API или сохранить в лог для дедупа и дебага.

Разделите потоки сразу:
— client-side: page_view, scroll, легкие микрособытия;
— server-side: purchase, lead, complete_registration, add_to_cart;
— transport: POST через fetch/beacon, а не только image-pixel;
— идентификаторы: event_id, fbp, fbc, click_id, hashed email/phone.

Ключевой момент — не дублировать ответственность. Если Pixel уже шлёт событие, сервер должен использовать тот же event_id для дедупликации, иначе получите «двойные» конверсии и грязный ROAS. Для арбитража это особенно больно: оптимизация уходит в мусор, а сплит-тесты становятся нечитаемыми.

Минимальная схема маршрутизации: /collect на sGTM, дальше триггер по event_name, затем отдельные теги на каждую платформу. Логи событий храните хотя бы с request_id, временем, user-agent и результатом ответа API. Это помогает быстро найти, где теряются события: на клиенте, в трансфере или на стороне рекламной платформы.

Если делать без лишней магии, sGTM даёт не «100% атрибуцию», а управляемый пайплайн: меньше потерь, чище дедуп и понятный контроль над данными. Начинайте с одного конверсионного события и только потом расширяйте схему.