GTM и server-side контейнер: где чаще всего теряются события и параметры

GTM и server-side контейнер: где чаще всего теряются события и параметры

Потери обычно начинаются не в коде, а на стыке контейнеров. Если web GTM отправляет событие, а серверный контейнер получает его без client_id, transaction_id или consent state, дальше ломается атрибуция, дедупликация и связка с CRM. Аналитика — это не гадание, а интерпретация метрик.

Проверьте три слоя: 1) dataLayer на клиенте — есть ли нужные поля в момент пуша; 2) теги в GTM — не перезаписываются ли параметры в триггерах и переменных; 3) endpoint серверного контейнера — совпадают ли названия событий и структура payload. Любое расхождение на этом пути дает «тихий» брак в данных.

Отдельно аудитируйте идентификаторы: user_id, client_id, session_id, order_id. Они должны жить одинаково в web и server контуре, иначе один и тот же пользователь превращается в несколько сущностей. Для покупок и лидов обязательно проверяйте дедупликацию по стабильному ключу, а не по названию события. Проверим в системе трекинга.

Полезная схема простая: сначала логируйте исходный payload, затем ответ сервера, затем выгрузку в аналитическую систему. Если событие видно в одном слое и пропадает в следующем, ищите не «ошибку платформы», а разрыв в маршрутизации. Безопасность и полнота данных — наш приоритет при проектировании инфраструктуры.