Серверный GTM для B2B: как снизили «потери» конверсий в CRM и получили чистую воронку MQL→SQL

Серверный GTM для B2B: как снизили «потери» конверсий в CRM и получили чистую воронку MQL→SQL

Компания: SaaS-провайдер для среднего бизнеса (B2B), продажи — через сайт + демо, учет лидов в CRM, дальнейшая квалификация в продажах (MQL → SQL).
Задача: после внедрения privacy-first подхода (баннеры, ужесточение трекинга в браузерах, рост доли “пустых” сеансов) команда заметила две проблемы:
— лиды приходили в CRM, но часть действий на сайте не матчилась обратно в аналитике;
— отчеты по воронке “демо → MQL → SQL” расходились с данными продаж.
Нужно было восстановить прослеживаемость: какие действия пользователей реально приводят к демо/заявкам, и как корректно сопоставлять визит с лидом в CRM.

Решение: собрали измерение в связке “сайт → server-side GTM (сервера) → CRM”.
Что сделали по тэгам и тегированию:
— В GTM оставили только легкие события на клиенте: отправка событий (например, view_content, start_demo_form, submit_demo_form) с минимальным набором данных.
— Перенесли сбор и ретрансляцию в server-side GTM: где возможно, храним/добавляем параметры в момент отправки на сервер, а не в браузере.
— Для матчинга с CRM ввели единый идентификатор лида:
— после отправки формы на сайте серверный слой записывал “lead_key” (генерируется при подтверждении события submit);
— передавали lead_key в CRM-процесс (через интеграционный API), чтобы потом SQL мог быть “склеен” с событием на сайте.
— Настроили конверсии так, чтобы не было двойного учета:
— submit_demo_form считался как конверсия “заявка/демо” только один раз (защита от дублей через lead_key);
— события “успех/ошибка” фиксировались отдельно, чтобы не засчитывать непрошедшие формы.
— Провели аудит триггеров: убрали лишние page_view-конверсии и оставили конверсии только на факт submit и (при необходимости) на подтверждение успешной записи.
— Для атрибуции подключили модель сравнения каналов на уровне “вход в воронку”: опирались на server-side события и корректный lead_key, а не на last-click “в вакууме”.

Конкретный результат (что обычно фиксируют в таких проектах, и что у них получилось по данным продаж):
— доля конверсий, которые перестали матчиться в CRM, уменьшилась: лиды с сайта стали значительно стабильнее отражаться в отчетности по MQL→SQL;
— воронка перестала “плыть” от недели к неделе: разница между маркетинговыми событиями и данными продаж сократилась за счет устранения дублей и корректного lead_key;
— появились рабочие отчеты для RevOps (общая ответственность маркетинга, sales и customer success за выручку): маркетинг мог объяснить, какие шаги до демо сильнее всего связаны с прохождением квалификации в продажах.

Урок для читателя (практика GTM, которую стоит повторить):
— если конверсия живет в CRM, главный фокус не на “еще один пиксель”, а на ключ для матчинга (lead_key) и дедупликацию;
— server-side GTM полезен не как “модная настройка”, а как способ стабилизировать события и управлять данными в момент отправки;
— конверсии в GTM ставьте на событие реального действия (submit/confirm), а не на прокси (клик, просмотр, переход), иначе точность в воронке MQL/SQL неизбежно будет проседать.

Если хотите, в следующем посте разберу шаблон структуры переменных в GTM под lead_key: какие параметры хранить, где генерировать, и как защищаться от дублей на submit.

— @GTMrecipesRu