RevOps в GA4: как связать маркетинг-аналитику с продажами без “ручного” CRM-колдовства

RevOps в GA4: как связать маркетинг-аналитику с продажами без “ручного” CRM-колдовства

Компания/бренд
B2B-сервис с циклом сделки 30–90 дней (лидогенерация → MQL → SQL → сделка), основной канал — поисковый спрос + контент, но лиды “размазывались” между формами, демо-страницами и документами. Часть команд жила в CRM, часть — в GA4, и ответственность за выручку ощущалась разной у маркетинга и sales.

Задача
1) Перестать мерить только верх воронки (лиды/сеансы), а начать мерить вклад маркетинга в SQL и выручку.
2) Упростить связку “событие в GA4 → идентификатор пользователя → запись в CRM” так, чтобы обновления UTM/кампаний не ломали отчётность.
3) Подготовить основу для privacy-first атрибуции (server-side сбор + более устойчивые модели, чем last-click).

Решение (рецепт по шагам)
1) Разделили события GA4 на 3 группы:
— Захват спроса: просмотр страницы с intent (например, кейс/интеграции), клик по CTA, старт заполнения формы
— Квалификация: отправка формы, просмотр pricing/демо, отправка документа “request”
— Коммерция: подтверждённый переход в “SQL-признак” (по сигналу из CRM, который подтягивается обратно в отчёты)

2) Ввели единый идентификатор в связке GA4 ↔ CRM:
— На стороне сайта при отправке формы формировали `lead_id` (или `session_to_lead_id`, если lead создаётся не сразу)
— Передавали его в GA4 вместе с событием отправки формы
— В CRM этот идентификатор сохранялся в поле/примечании к лид-объекту
Важно: UTM-метки фиксировали вместе с lead_id, а не “на лету” по текущей сессии.

3) Сделали server-side передачу (схема для 2026-реальности):
— Избавились от потерь при блокировках/перезагрузках
— Привели качество событий к одному стандарту (одинаковые названия событий и параметры, валидация на входе)

4) Собрали “маркетинг-метрики” не через догадки, а через связку с CRM:
— В отчётах GA4 по пользователям/сессиям строили покрытие: сколько захватов спроса дошло до отправки формы, сколько форм — в CRM, и какая доля квалифицируется в SQL-признак
— Отдельно смотрели time-to-qualify (в днях) по когортам кампаний: это помогло понять, где лид “созревает”, а где происходит ранний отвал

5) Настроили отчёты для RevOps (а не только для маркетинга):
— Дашборд: кампания → доля lead → SQL → win rate
— Разрез по типу контента (где люди чаще доходили до SQL)
— Контроль аномалий: скачки событий без соответствующего SQL (обычно это проблемы с качеством трафика или ошибками маркировки)

Конкретный результат
По итогам внедрения связки “GA4 → CRM” за квартал получили:
— Сократили долю лидов без корректного маркетингового признака (UTM/кампания/канал) в CRM примерно на 35% (меньше “серых” записей).
— Повысили долю кампаний, по которым можно посчитать путь до SQL, до ~90% (раньше было заметно меньше из-за потерь идентификатора).
— В отчетности RevOps появились стабильные срезы: маркетинг стал показывать не только количество лидов, но и конверсию в SQL по когортам кампаний — это уменьшило споры “кто кому должен”.

Урок для читателя (что взять в работу)
1) Не пытайтесь “угадать вклад”. Делайте связку по идентификатору (lead_id), иначе любое моделирование будет спорным.
2) UTM — это атрибут, а не фундамент. Фундамент — события + стабильный ключ, который переживает перезагрузки и переходы между каналами.
3) Для RevOps важны не только доли (конверсии), но и скорость созревания: time-to-qualify часто объясняет, почему одна и та же кампания “выглядит” по-разному на разных этапах отчётного цикла.

— @GA4cookbookRu