GTM-рецепт: server-side событие «заявка отправлена» через Data Layer + тайм-аут подтверждения

GTM-рецепт: server-side событие «заявка отправлена» через Data Layer + тайм-аут подтверждения

Если в воронке B2B (MQL/SQL, а в 2026 всё чаще под RevOps — ответственность за выручку) лиды иногда «пропадают» из аналитики, причина обычно не в креативе, а в том, что GTM фиксирует событие до фактического ответа сервера. Решение: привязать трекинг к Data Layer и сделать подтверждение с тайм-аутом.

Шаги на этой неделе

1) Убедитесь, что на форме есть стабильный триггер в момент успешной отправки
— На вашем фронтенде найдите участок кода, где обрабатывается success-ответ (после получения статуса от API/endpoint формы).
— После success выполните пуш в Data Layer с уникальным идентификатором запроса. Пример структуры (без привязки к языку):
— event: "lead_submit_success"
— lead_id: "UUID или хэш"
— form_id: "ID формы"
— lead_source: "utm или вручную заполненное поле"
— value: (если есть, иначе не передавайте)

2) Настройте Data Layer в GTM (Web)
— В контейнере GTM создайте переменные Data Layer:
— Переменная lead_id (тип: Data Layer variable)
— Переменная form_id
— Переменная lead_source
— (опционально) Переменная value
— Создайте триггер типа Custom Event:
— Event name: lead_submit_success
— Проверка: включите фильтр, чтобы event срабатывал только один раз на один lead_id (см. п.4).

3) Сделайте тег «Lead submitted» через server-side
Важно: отправляйте событие не напрямую в аналитическую платформу, а в ваш server-side контейнер.
— В GTM Web создайте тег (например, Custom Event / или событие для вашей связки с server-side) который отправляет:
— event_name = lead_submit_success
— параметры: lead_id, form_id, lead_source, value
— Включите отправку именно на endpoint вашего server-side (через конфигурацию “Server container” в настройках тега).

4) Защитите от дублей и гонок: тайм-аут подтверждения
Иногда success-ответ приходит, но событие уже сработало, либо пользователь успел повторить клик.
— Создайте переменную/логику «уже отправлено этот lead_id или нет».
— Практика в GTM:
— Используйте Cookie/Local Storage переменную (скриптовый шаг через Custom HTML не нужен, делайте через встроенные средства GTM, если они доступны у вас).
— При обработке события записывайте lead_id в хранилище на короткий TTL (например, 7–30 дней достаточно).
— Триггер ставьте на условие: если lead_id отсутствует в хранилище — пропускать, иначе блокировать.

5) Добавьте аварийный сценарий на случай, если success не пришёл
— Если у вас есть известный момент «клик по submit» (до ответа), не отправляйте лид “как факт”.
— Вместо этого шлите событие “lead_submit_clicked” без параметров lead_id.
— Тогда вы сможете отличить «не дошло до сервера» от «сервер подтвердил лид».

6) Проверьте корректность в режиме Preview и в server-side
— Включите Preview для Web контейнера и смотрите Payload.
— В server-side контейнере проверьте, что:
— lead_id приходит
— событие не дублируется при повторной отправке
— параметры соответствуют выбранной форме и источнику (utm/поле).

Почему это работает именно сейчас
В privacy-first и при вытеснении last-click возрастает цена точного события “лид подтвердился сервером”. Такой подход повышает качество данных для атрибуции и для RevOps-дашбордов, а не “угадывает” результат по клику.

Если скажете, какая у вас связка (GA4/Яндекс Метрика/СRM + server-side платформа) — адаптирую рецепт под конкретные типы тегов в GTM.

— @GTMrecipesRu