Заявка есть, источника нет: какие данные сайт должен передавать в CRM

Заявка попала в CRM: имя, телефон, комментарий. Менеджер перезвонил, уточнил задачу и через несколько недель закрыл сделку. Вроде бы всё сработало. Но на вопрос «какая реклама привела этого клиента?» система отвечает чем-то вроде «сайт» или вообще оставляет поле пустым.

Проблема обычно не в отсутствии Яндекс Метрики и не в том, что маркетолог забыл добавить UTM-метки. Между рекламным переходом и карточкой лида есть несколько отдельных систем: сайт, аналитика, форма, телефония, коллтрекинг и CRM. Каждая видит только свою часть пути. Чтобы источник не потерялся, сайт должен передать в CRM не одно условное поле «канал», а набор исходных данных, по которым путь можно восстановить и проверить.

Один условный путь клиента — четыре разных картины

Возьмём условный сценарий из B2B-услуг. Компания проектирует и монтирует вентиляцию в коммерческих помещениях. Представитель заказчика переходит из рекламного объявления на страницу услуги, изучает требования и примеры решений, закрывает сайт. Через несколько дней он возвращается из поиска, открывает контакты и звонит. Менеджер создаёт сделку в CRM, инженеры готовят расчёт, а оплата приходит через месяц.

В этой истории:

— рекламная система знает о первом клике;
— Метрика видит визиты и страницы входа;
— коллтрекинг фиксирует звонок;
— CRM знает, что сделка квалифицирована и оплачена.

Если системы не связаны идентификаторами, рекламный кабинет посчитает переход, Метрика — посетителя, коллтрекинг — звонок, а CRM — клиента «с сайта». Деньги при этом нельзя будет уверенно отнести ни к первой рекламе, ни к последнему поисковому визиту.

Поэтому нормальная разработка сайта для бизнеса (https://synchroweb.ru/razrabotka-sajtov/) включает не только страницы и форму. Ещё на этапе проектирования нужно решить, какие маркетинговые данные сайт собирает, как долго их хранит, через какие каналы передаёт и с какой сущностью связывает в CRM.

Что мы называем источником заявки

Источник — не одна строка. Это четыре слоя данных.

1. Откуда пришёл посетитель: UTM-метки, реферер, идентификатор рекламного клика.
2. Куда он пришёл: первая посадочная страница и полный URL входа.
3. Кто совершил действие с точки зрения аналитики: например, ClientID Яндекс Метрики.
4. Чем закончился контакт: форма, звонок или чат, квалификация лида, договор, оплата либо отказ.

UTM отвечает на вопрос, как была размечена конкретная ссылка. Реферер показывает адрес страницы, с которой браузер передал переход. Посадочная страница объясняет, какой материал или предложение встретил клиента. ClientID помогает связать действие вне сайта с визитом. А CRM сообщает итог, которого не знает страница: это был реальный запрос, спам, неподходящий клиент или оплаченная работа.

У Метрики есть важная особенность: источник визита определяется по метке, присутствующей в данных первого просмотра этого визита. Если метки там нет, используется реферер. Метка, появившаяся позже в том же визите, не обязательно переопределит источник. Поэтому нельзя рассчитывать, что аналитика сама восстановит любое касание после редиректов и внутренних переходов.

Минимальный набор данных для CRM

Названия полей в каждой системе могут отличаться. Важнее их смысл и правила обновления.

Данные Зачем сохранять Как обращаться
————————————————————- ——————————————————————— ——————————————————————
Полный URL входа Сохраняет путь, параметры и исходную разметку ссылки Записать при первом внешнем переходе без последующей перезаписи
Landing page Показывает первое предложение или материал в пути клиента Хранить отдельно от страницы, где отправлена форма
Referrer Помогает определить переход без UTM Сохранять исходное значение, даже если оно пустое
utm_source, utm_medium, utm_campaign, utm_content, utm_term Детализируют площадку, канал, кампанию, объявление и запрос Хранить сырые значения и нормализованную классификацию раздельно
ClientID Метрики Связывает заявку, звонок или статус CRM с визитами Получить на сайте и передать вместе с лидом
Идентификатор рекламного клика Помогает связать офлайн-результат с конкретным рекламным переходом Сохранять, если параметр присутствует в URL
Страница конверсии и ID формы Различает посадочную страницу, форму в контактах и повторный запрос Передавать в момент успешного создания лида
Канал обращения и время Отделяет форму, звонок и чат и помогает искать расхождения Фиксировать на стороне сервера или интеграции

Полезно также передавать код сайта или бренда, если одна CRM принимает обращения с нескольких доменов. Иначе одинаковые кампании и формы быстро смешиваются.

Сырые данные нельзя заменять красивой категорией

CRM удобнее показывать менеджеру понятное значение «Яндекс Директ», чем строку из пяти UTM-параметров. Но если при импорте заменить исходные данные этой категорией, проверить классификацию уже не получится.

Рабочая схема состоит из двух уровней:

— сырой слой — URL, реферер, UTM и идентификаторы ровно в том виде, в котором их получил сайт;
— нормализованный слой — канал, источник и понятная подпись кампании по правилам компании.

Например, `utm_source=vk`, `utm_medium=social` и `utm_campaign=ventilation_office` можно показать как «VK / социальные сети / вентиляция для офисов». Но исходные значения должны остаться рядом.

Это особенно важно из-за регистра: Метрика различает `VK`, `Vk` и `vk`. Поэтому до запуска рекламы стоит принять единый словарь значений — нижний регистр, один разделитель, стабильные названия каналов и кампаний. Для разовых ссылок удобно использовать генератор UTM-меток (https://synchroweb.ru/instrumenty/utm/), но сам генератор не заменяет правила именования внутри компании.

First touch, last touch и история касаний

В нашем условном сценарии первый рекламный переход познакомил заказчика с компанией, а последний поисковый визит предшествовал звонку. Какому источнику отдать сделку? Это не техническая ошибка, а два разных управленческих вопроса.

— First touch помогает понять, какой канал впервые привёл потенциального клиента.
— Last touch показывает последнее зафиксированное внешнее касание перед обращением.
— История касаний позволяет не выбирать один ответ заранее и анализировать весь доступный путь.

На сайте разумно хранить первый источник неизменяемым, а последний обновлять при новом значимом внешнем переходе. Внутренний переход с главной страницы на контакты не должен становиться новым источником. Если путь длинный и дорогой, касания лучше писать в отдельный журнал с датой, URL и идентификатором посетителя.

Это внутренняя модель CRM, а не замена моделям атрибуции Метрики. У аналитической системы свои правила, окно атрибуции и возможности кросс-девайс. В CRM нужны собственные прозрачные поля, чтобы отчёт не менялся неожиданно вместе с настройками внешнего сервиса.

Как не потерять источник в форме

Типичная ошибка — брать UTM непосредственно из адресной строки в момент отправки. Посетитель мог войти на одну страницу, перейти на ещё пять и заполнить форму в контактах, где меток уже нет. Поэтому параметры входа сохраняют при первом подходящем просмотре — в cookie, localStorage, серверной сессии или собственной записи визита — и подставляют в заявку позже.

ClientID Метрики можно получить через метод `getClientID` и поместить в скрытое поле формы. На сервер должны уйти и сам идентификатор, и маркетинговый снимок. Полагаться только на JavaScript тоже не стоит: скрипт может быть заблокирован, не успеть загрузиться или вернуть пустое значение. Заявка всё равно должна создаться, а отсутствие данных — фиксироваться как диагностируемое состояние, а не маскироваться словом «прямой».

Цель аналитики следует отправлять после фактического успеха: когда сервер принял форму и создал лид. Клик по кнопке «Отправить» ещё ничего не доказывает — валидация могла не пройти, сеть оборваться, а защита от спама отклонить запрос.

Главный принцип: форма передаёт в CRM не только контактные поля клиента, но и снимок контекста, в котором обращение было создано.

Редиректы и сторонние виджеты нужно проверять отдельно

Источник часто теряется до того, как посетитель увидит страницу. Например, рекламная ссылка ведёт на старый адрес, сервер перенаправляет её на новый, но не переносит параметры запроса. В результате в рекламной системе клик есть, а конечная страница открывается уже без UTM. Аналогичная проблема возникает при переходе между доменами, открытии мобильной версии или неверной настройке одностраничного интерфейса.

Виджет обратного звонка или форма внешнего сервиса могут корректно создавать обращения, но отправлять в CRM только имя и телефон. Наличие виджета на сайте ещё не означает наличие атрибуции. Нужно проверить, умеет ли он принимать скрытые поля, получать ClientID и передавать исходные значения через webhook или API.

Проверка проводится не по одному тесту из рекламного кабинета. Полезно открыть размеченную ссылку в новом браузере, пройти несколько страниц, отправить каждую форму, позвонить по подменному номеру и затем сопоставить URL, время и идентификаторы во всех системах. Такой контроль быстро показывает, на каком именно переходе цепочка обрывается.

Телефонный звонок требует отдельной связки

Если посетитель звонит, скрытые поля формы не помогут. Для привязки звонка к визиту используется динамический коллтрекинг: сервис показывает посетителю подменный номер, закрепляет его за сессией и передаёт сведения о звонке вместе с доступными идентификаторами.

По документации Метрики динамический звонок можно связать с ближайшим подходящим визитом. Статический номер не привязывается к конкретной сессии. Он может показать площадку или общий канал, если отдельный номер размещён только там, но это уже другая точность.

В CRM от коллтрекинга полезно передавать:

— ClientID и другие доступные идентификаторы;
— номер, на который поступил вызов;
— дату, длительность и статус звонка;
— страницу показа номера;
— признак первого или повторного обращения;
— ссылку на запись и итог разговора, если их обработка предусмотрена системой.

Менеджер не должен вручную выбирать источник из списка после разговора. Он может уточнить смысл обращения и качество лида, но технический источник должен приходить автоматически. Именно такие цепочки относятся к автоматизации бизнес-процессов (https://synchroweb.ru/avtomatizaciya-biznesa/): событие возникает в одной системе, проверяется и без ручного копирования создаёт связанную запись в другой.

CRM должна вернуть маркетингу итог, а не только принять заявку

Передать источник в CRM — половина работы. Вторая половина — вернуть в аналитику результат обработки.

Для условной монтажной компании путь может выглядеть так:

1. создано обращение;
2. менеджер связался с клиентом;
3. запрос квалифицирован;
4. назначен выезд или подготовлен расчёт;
5. подписан договор;
6. получена оплата.

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

Яндекс Метрика позволяет загружать из CRM клиентов, заказы и их статусы, а затем связывать их с онлайн-визитами. Для точной привязки документация рекомендует ClientID. Передавать заказы для первичной привязки нужно своевременно: в текущей документации указан период до 21 дня от даты загрузки. Это стоит учитывать, если сделки создаются в CRM не сразу или интеграция запускается пакетно.

В правильно спроектированной CRM или ERP-системе (https://synchroweb.ru/crm-erp/) маркетинговые поля связаны с лидом и сделкой, но не зависят от того, что менеджер видит в карточке. Отчёт строится по сохранённым данным и событиям: источник → квалификация → заказ → оплата.

Что смотреть в итоговом отчёте

Полезный отчёт начинается не с красивого дашборда, а с согласованных определений. Что считается обращением? Когда лид становится качественным? Как учитываются повторные звонки и дубли? К какой дате относится оплата?

Минимальный срез выглядит так:

— источник, канал и кампания;
— посадочная страница;
— число уникальных обращений;
— квалифицированные лиды;
— сделки и оплаты;
— выручка и, если данные доступны, прибыль;
— спам, отказы и необработанные обращения.

Такой отчёт отвечает не только на вопрос «откуда пришло больше заявок», но и на более полезный: «какие источники приводят подходящих клиентов, с которыми компания действительно работает и получает оплату».

Почему появляются direct и unknown

Прямой заход и неизвестный источник — не одно и то же.

Прямой заход может быть настоящим: человек ввёл адрес, открыл закладку или вернулся по сохранённой ссылке. Но Метрика также относит визит к прямым, когда источник не передан в реферере. `unknown` обычно является уже внутренней категорией CRM: данные отсутствуют, не распознаны или интеграция не смогла применить правило.

Перед тем как объединять всё в «прямые», стоит проверить:

1. пришли ли UTM в первый запрос;
2. не удалил ли их редирект;
3. сохранилась ли исходная landing page;
4. получен ли ClientID до отправки;
5. передал ли виджет данные в CRM;
6. не перезаписал ли скрипт первый источник пустыми значениями;
7. передаёт ли коллтрекинг идентификатор визита;
8. есть ли правило для нового значения UTM.

Честное `unknown` полезнее выдуманной точности. Оно показывает место, где цепочку нужно проверить.

Персональные данные: техническую схему нужно согласовать с правилами компании

Формы, телефоны, записи разговоров, аналитические идентификаторы и передача данных между сайтом, CRM и внешними сервисами затрагивают не только разработку. Для проектов, работающих с гражданами РФ, архитектуру обработки персональных данных следует проектировать вместе с профильным специалистом: определить цели и правовые основания, состав данных, сроки хранения, доступы, содержание политики и согласий, применимость уведомления Роскомнадзора и требования к базам данных. Универсального чекбокса, который автоматически делает корректной любую схему, не существует.

Отдельного внимания требует Вебвизор. Метрика умеет маскировать поля и позволяет запретить их запись классом `ym-disable-keys`. Для контактных и чувствительных полей безопаснее явно проверить настройки, а не полагаться только на автоматическое распознавание.

Короткий чек-лист перед запуском

— Принят единый словарь UTM-значений.
— Первый URL, landing page и referrer сохраняются до переходов по сайту.
— Форма передаёт UTM, ClientID, страницу и ID формы.
— Цель срабатывает после успешного создания лида, а не по клику.
— Первый и последний источники не перезаписывают друг друга.
— Сырые значения хранятся отдельно от понятных категорий.
— Коллтрекинг передаёт звонок и идентификаторы в CRM.
— CRM различает новый, качественный, оплаченный, отменённый и спамовый запрос.
— Дубли не считаются новыми уникальными лидами.
— Статусы и оплаты возвращаются в аналитику.
— Пустые источники видны в отдельном диагностическом отчёте.
— Схема обработки данных проверена для применимой юрисдикции.

Источник заявки сохраняется не ради ещё одного поля в карточке. Это связующая нить между страницей, рекламой, разговором менеджера и реальным результатом бизнеса. Если заложить её после запуска, придётся восстанавливать уже потерянные данные. Если спроектировать вместе с сайтом и CRM, компания получает проверяемую историю, а не догадку в отчёте.

Документация по теме

— Как Яндекс Метрика определяет источник трафика (https://yandex.ru/support/metrica/ru/general/sources-tracking)
— Как Метрика обрабатывает UTM-метки (https://yandex.ru/support/metrica/ru/general/source-tags)
— Отчёт «Страницы входа» (https://yandex.ru/support/metrica/ru/content/entry-pages)
— Загрузка данных из CRM (https://yandex.ru/support/metrica/ru/crm/about)
— Как отслеживать звонки в Метрике (https://yandex.ru/support/metrica/ru/data/calls)
— Модели атрибуции (https://yandex.ru/support/metrica/ru/reports/attribution-model)
— Настройка записи полей в Вебвизоре (https://yandex.ru/support/metrica/ru/webvisor/settings)