От рекламного перехода до подтверждённой сделки
Интеграция CRM и Google Analytics 4 сохраняет источник обращения, передаёт в CRM статус и стоимость сделки и возвращает подтверждённые конверсии в рекламные системы. До настройки определяют поля, идентификаторы, правила согласия, дедупликацию и источник финансового результата.
Разрыв обычно возникает в момент передачи заявки. Рекламный кабинет знает о клике, сайт получает UTM и идентификаторы перехода, а менеджер открывает карточку лида без этих данных. В отчёте остаётся количество заявок. Квалификация, отказ, договор и оплата живут отдельно в CRM. Руководитель сравнивает расходы с верхним уровнем воронки и не видит стоимость клиента по каналу.
Сначала выберите событие, по которому бизнес принимает решение. Для отдела продаж это может быть квалифицированная заявка или оплаченная сделка. Для подписного продукта дополнительно нужен LTV. Для кампаний с ценностью конверсии используют выручку, валовую прибыль или другой согласованный финансовый показатель. Название события, формула и ответственный должны совпадать в CRM, аналитике и рекламном кабинете.
| Поле | Источник | Для чего нужно | Условие хранения | Проверка |
|---|---|---|---|---|
| Landing page и referrer | Первый просмотр страницы | Проверка входной страницы и предыдущего источника | Срок задаётся политикой компании | Поля заполнены в тестовой заявке |
| UTM source, medium, campaign, content, term | URL рекламного перехода | Разрез по источнику, кампании, объявлению и запросу | Единый регистр и справочник названий | Значения совпадают с медиапланом |
| GCLID или GBRAID/WBRAID | Google Ads при разрешённом сценарии измерения | Сопоставление офлайн-конверсии с рекламным взаимодействием | Каждый идентификатор хранится в отдельном поле | Тестовая загрузка проходит диагностику Google Ads |
| Client ID и Session ID GA4 | Google tag или Google Tag Manager | Сопоставление серверного события с браузерной сессией | Client ID не используется как идентификатор человека | Событие видно в DebugView и отчётах GA4 |
| Внутренний User-ID | Авторизация на сайте или в приложении | Анализ действий одного авторизованного пользователя | Без email, телефона и других персональных данных в значении | Одинаковый ID передаётся после входа пользователя |
| Email и телефон | Форма, звонок или CRM | Обработка обращения и разрешённые сценарии enhanced conversions | Согласие, ограничение доступа и подготовка по требованиям платформы | Передача соответствует политике и настройкам согласия |
| ID лида, заказа и звонка | CRM, форма и коллтрекинг | Дедупликация и сверка обращения со сделкой | Уникальное значение для каждой сущности | Повторная отправка не создаёт вторую сделку |
| Версия и время согласия | Форма и менеджер согласий | Подтверждение разрешённого состава данных | Хранится вместе с карточкой обращения | Версия совпадает с опубликованным текстом согласия |
Разделяйте метки кампании и идентификаторы
UTM описывают источник, кампанию, объявление и поисковый запрос по правилам компании. GCLID, GBRAID и WBRAID относятся к Google Ads и используются в поддерживаемых сценариях атрибуции офлайн-конверсий. Client ID относится к Google Analytics 4 и обозначает экземпляр браузера или приложения. Session ID указывает сессию. Внутренний User-ID применяется после авторизации и не должен содержать email или телефон.
Эти значения выполняют разные задачи. Одно поле source не заменяет отдельные поля для UTM, click ID, Client ID, заявки и заказа. CRM должна хранить исходное значение без ручного редактирования менеджером. Для нормализации используют отдельные вычисляемые поля и справочник названий каналов.
Google Ads auto-tagging добавляет рекламный идентификатор в подходящих переходах. Скрипт сайта считывает доступные параметры до отправки формы и передаёт их вместе с заявкой. Способ хранения выбирают по архитектуре сайта, требованиям безопасности и принятому механизму согласия. Универсальная запись всех идентификаторов в localStorage создаёт лишний риск и не решает проблему блокировок сама по себе.
Для звонков нужен идентификатор коллтрекинга и правило передачи номера, источника, записи и результата разговора. Для чатов и мессенджеров нужен собственный ID диалога. Все входы должны создавать карточку обращения с одинаковым набором обязательных полей: источник, входная страница, время, контакт, ответственный и текущий статус.
Передача заявки в CRM
amoCRM, Битрикс24, HubSpot и RetailCRM поддерживают API, вебхуки или готовые коннекторы, но поля и методы меняются. Перед разработкой составляют карту соответствий: поле формы, поле CRM, формат, обязательность, источник и обработка ошибки. Точную конечную точку API берут из действующей документации выбранной CRM.
При отправке формы сервер или проверенный коннектор создаёт лид и возвращает его ID. Следующая отправка с тем же ID формы или заказа должна обновить существующую запись по утверждённому правилу. Это защищает отчёт от дублей после повторного клика по кнопке, обновления страницы или повторной доставки вебхука.
Статусы CRM формулируют через действия отдела продаж: Новая заявка, Связались, Квалифицирована, Назначена встреча, Договор, Оплачено, Отказ. Для отказа нужен справочник причин. Статус Оплачено дополняют суммой, валютой и временем. Если компания использует частичные оплаты или возвраты, правила стоимости события записывают до запуска.
Офлайн-конверсии Google Ads
Для новой интеграции Google рекомендует Data Manager и enhanced conversions for leads. С 15 июня 2026 года новые загрузки офлайн-конверсий переводятся на Data Manager API. Доступ к прежнему UploadClickConversions сохраняется только у части ранее активных developer tokens. Новую разработку на старом методе начинать рискованно.
Событие загрузки содержит время конверсии и допустимый идентификатор: GCLID, GBRAID/WBRAID или разрешённые first-party данные. При наличии передают несколько доступных идентификаторов. Уникальный Order ID защищает от повторного учёта. Для продажи добавляют значение и валюту. Google отдельно рекомендует регулярно проверять Offline data diagnostics, потому что принятый запрос ещё может содержать событие, которое не прошло сопоставление.
Квалифицированный лид и продажу лучше оформить как разные действия конверсии. Рекламная стратегия должна получать тот этап, который имеет достаточный объём и подтверждается CRM. Переключение ставок проводят после стабильной загрузки и одного-двух завершённых циклов конверсии. Резкая смена цели сразу после первой передачи искажает сравнение периодов.
Обработка загруженной конверсии обычно занимает менее 12 часов. Для событий с GBRAID или WBRAID задержка может достигать 72 часов. Поэтому отчёт Google Ads сравнивают с CRM по времени конверсии, часовому поясу, названию действия и результатам диагностики.
CRM-статусы для Meta Ads
Meta Conversions API принимает события с сайта, сервера, CRM, приложений, звонков и офлайн-точек. Для лидогенерации CRM может возвращать последующие статусы, например квалифицированную заявку или продажу. Meta рекомендует использовать Conversions API вместе с Pixel для web-событий и передавать события в действующий dataset.
Интеграцию Meta нельзя строить на одном fbclid. Состав параметров зависит от источника события, выбранного способа настройки и разрешённых данных. Перед запуском проверяют dataset, название события, время, источник действия, параметры сопоставления и диагностику Events Manager. Если одно web-событие приходит через Pixel и сервер, разработчик настраивает дедупликацию по требованиям текущей реализации.
Google Analytics 4 и Measurement Protocol
Measurement Protocol передаёт серверные и офлайн-события в GA4 через HTTP. Google определяет его как дополнение к автоматическому сбору через Google tag, Google Tag Manager или Firebase. Браузерная разметка остаётся обязательной для большинства функций и корректного контекста сессии.
Для web-события передают корректный Client ID. Session ID нужен, если событие должно относиться к определённой сессии. User-ID применяется для авторизованных пользователей по правилам компании. Один Client ID не объединяет человека на всех устройствах. Кросс-девайсный сценарий требует собственного User-ID и корректной авторизации.
До production payload отправляют на validation server. Он сообщает путь поля, описание и код ошибки. Успешная валидация структуры не проверяет api_secret, поэтому после запуска дополнительно сверяют DebugView, Realtime, обычные отчёты и CRM. Для финансового события проверяют название, валюту, стоимость, время и ID заказа.
| Система | Событие из CRM | Идентификаторы | Защита от дублей | Где проверять |
|---|---|---|---|---|
| Google Ads | Квалифицированный лид или оплаченная сделка | GCLID, GBRAID/WBRAID, разрешённые first-party данные | Уникальный Order ID и правило повторной отправки | Data Manager и Offline data diagnostics |
| Google Analytics 4 | Серверное событие с согласованным названием | Client ID, Session ID, при необходимости внутренний User-ID | ID заказа или события в CRM | Validation server, DebugView и отчёты GA4 |
| Meta Ads | Квалифицированная заявка, продажа или другой принятый статус | Параметры действующей настройки Conversions API | Правило дедупликации Pixel и серверных событий | Dataset и Events Manager |
Регламент проверки
Маркетолог отвечает за UTM, названия кампаний и соответствие расходов. Разработчик проверяет доставку форм, вебхуков и API. Руководитель продаж следит за обязательными статусами и причинами отказа. Аналитик сопоставляет расходы, квалифицированные заявки, сделки, выручку и задержку загрузки.
Частота зависит от объёма заявок и цены ошибки. После запуска тестовую заявку проводят через все статусы в тот же день. Затем регулярно проверяют необработанные события, пустые поля, дубли и расхождения по каждому типу конверсии. Единый допустимый процент расхождения для всех компаний не применяется: формы, звонки, возвраты и часовые пояса проверяют отдельно.
Три частые причины потери данных:
- Разный регистр и названия UTM в кампаниях.
- Форма создаёт лид без click ID, Client ID или ID заказа.
- CRM меняет статус, но событие не попадает в Data Manager, GA4 или dataset Meta.
FAQ
Сколько времени занимает интеграция CRM и аналитики?
Срок рассчитывают после проверки форм, звонков, CRM API, правил согласия и способа передачи офлайн-конверсий. Сначала настраивают и проверяют полный маршрут: рекламный переход, заявка, статус CRM и подтверждённая сделка.
Нужен ли серверный Google Tag Manager?
Выбор зависит от архитектуры сайта, требований к данным и доступных интеграций. Серверный контейнер даёт дополнительный контроль, но не восстанавливает сведения, которые сайт не собрал.
Какие идентификаторы нужно сохранять в CRM?
Набор зависит от рекламной системы. Обычно раздельно сохраняют UTM, landing page, GCLID или GBRAID/WBRAID, Client ID GA4 и разрешённые first-party данные.
Как передавать подтверждённые продажи в Google Ads?
Используйте Data Manager или поддерживаемое подключение, передавайте время и значение конверсии, допустимый идентификатор и Order ID для дедупликации. Диагностику загрузки проверяйте регулярно.
Может ли Measurement Protocol заменить GA4 на сайте?
Нет. Measurement Protocol дополняет браузерный сбор данных и передаёт серверные события. Для web-события нужны корректные Client ID и параметры сессии.
Передача данных из рекламы в CRM
Метриум проверит источники заявок, статусы CRM и передачу подтверждённых конверсий, затем подготовит план интеграции.
