Чтобы понять, откуда пришла заявка с сайта, нужно связать сведения о переходе с конкретным принятым обращением, а затем — с записью в CRM. Счётчик аналитики и UTM-метки помогают собрать эту цепочку, но сами по себе её не гарантируют. Отчёт о целях ещё не доказывает, что менеджер получил заявку, а источник последнего визита не всегда объясняет, где клиент впервые узнал о компании.
Для бизнеса полезен результат, в котором видно происхождение данных: какой переход зафиксирован, какое действие произошло, какое обращение принято и чем оно закончилось. Если часть пути неизвестна, это должно оставаться видно в отчёте.
Четыре разных события, которые часто смешивают
| Что учитываем | Что это подтверждает | Чего это не подтверждает |
|---|---|---|
| Визит с определённым источником | Аналитика зафиксировала посещение и доступные сведения о переходе | Что посетитель оставил заявку или впервые познакомился с компанией |
| Достижение цели | Выполнилось настроенное условие: например, клик или отправка события | Что сервер принял данные и в CRM появилась запись |
| Лид в CRM | Подтверждено создание или обновление записи об обращении в CRM | Что обращение целевое и клиент купит |
| Продажа | Выполнен согласованный критерий продажи, например подтверждена оплата | Что единственный указанный канал обеспечил весь результат |
Название цели не определяет её точность. Цель «Заявка» может срабатывать на нажатие кнопки до проверки полей. В Яндекс Метрике стандартная цель «Отправка формы» в некоторых сценариях засчитывает и попытку отправить невалидную форму. Если для отчёта нужны принятые обращения, разработчик должен отправлять отдельное целевое событие после подтверждения приёма заявки системой сайта. Это рекомендация к настройке, а не поведение любой формы по умолчанию.
Если CRM получает данные позже, эти два момента тоже разделяют: «сайт принял обращение» и «CRM подтвердила запись». Переход по номеру телефона не равен состоявшемуся звонку, а открытие мессенджера — начатому диалогу. Такие обращения требуют отдельного учёта и сопоставления.
Что дают UTM-метки для сайта
UTM-метки — это параметры размеченной ссылки. Они описывают размещение, по которому произошёл переход. Обычно в едином справочнике задают источник, тип трафика и кампанию; при необходимости добавляют вариант объявления и ключевую фразу. Например, utm_source отвечает за источник, utm_medium — за тип трафика, utm_campaign — за кампанию.
Учебный пример: для ссылки из рассылки используются значения utm_source = newsletter, utm_medium = email, utm_campaign = autumn_service. Это вымышленные обозначения, показывающие принцип, а не сведения о рекламе Студии Вебирус. Если посетитель оставит обращение, сохранённая разметка поможет связать его с этой рассылкой.
Заранее договоритесь о написании значений и о том, кто выдаёт разметку. В Метрике значения UTM различают регистр: два варианта написания могут разделить один источник на разные строки отчёта. Проверяйте готовую ссылку после всех перенаправлений: метки могут потеряться до загрузки счётчика.
UTM не удостоверяет личность и не восстанавливает всю историю человека. Если размеченную ссылку переслали другому человеку или сохранили в закладках, при последующем переходе её параметры остаются прежними. Вы знаете разметку использованной ссылки; фактическое место, где человек увидел её в этот раз, может быть другим.
Разметка также не гарантирует, что поля автоматически появятся в заявке. Это отдельная часть интеграции: сайт получает нужные значения, сохраняет их по согласованным правилам и передаёт вместе с обращением.
Какой источник считать источником заявки
Один клиент может взаимодействовать с несколькими каналами. Поэтому перед отслеживанием источников заявок нужен ответ на управленческий вопрос: вы оцениваете первое зафиксированное знакомство, последний переход перед обращением или вклад нескольких взаимодействий?
Учебная ситуация: человек впервые попал на сайт из рекламы, позже вернулся из поиска, а заявку оставил после прямого захода. В истории, если эти визиты удалось связать, есть три разных источника. Правило первого зафиксированного перехода выделит рекламу, последнего — прямой заход. Правило, которое относит обращение к предыдущему значимому источнику, может выделить поиск. Различие результатов само по себе не означает ошибку: системы отвечают на разные вопросы.
В Метрике это регулируется моделью атрибуции. Доступные модели и их условия меняются, поэтому для сравнения отчётов нужно фиксировать выбранную модель, период и учитываемые цели. Значение «источник» в CRM может быть результатом собственного правила сохранения сайта и не совпадать с атрибуцией отчёта Метрики.
Для заявки можно хранить раздельно первый зафиксированный переход и сведения о переходе перед обращением, если оба нужны бизнесу. При этом у каждого поля должны быть понятные правила: когда оно заполняется, что считается новым переходом, когда значение обновляется и сколько хранится. Нельзя незаметно перезаписывать первое касание последним и продолжать называть поле «первый источник».
Отдельная тонкость: Метрика определяет источник визита по меткам и рефереру его первого просмотра. Новая метка, появившаяся позже в том же визите, не меняет источник всего визита. Поэтому текущие параметры ссылки в форме и источник визита в отчёте иногда различаются даже при исправной передаче.
Что передавать вместе с обращением
Согласуйте небольшой перечень данных с ответственным за CRM и аналитику. Для связи обычно нужны:
- Уникальный идентификатор принятого обращения. Он позволяет найти ту же заявку в системе сайта и CRM, проверить повторную передачу и отличить её от другого обращения этого посетителя.
- Время приёма, форма и страница обращения. Они помогают разобраться, какое действие произошло и где искать его в отчёте. Часовой пояс должен быть согласован.
- Разрешённые значения разметки и сведения о входе. Передавайте только нужные UTM-поля, очищенный путь посадочной страницы и при необходимости источник перехода. Для первого и последнего касания используйте отдельные поля.
- Идентификатор аналитики, если он доступен и нужен для сопоставления. Например, ClientID Метрики. Его отсутствие должно быть допустимым состоянием: заявка важнее возможности записать её в статистику.
ClientID идентифицирует браузер, а не заявку и не гарантированно одного человека. У одного посетителя могут быть разные ClientID в разных браузерах; после удаления cookies история может начаться заново. UserID задаёт сам сайт, например для авторизованного пользователя. Это другой идентификатор, который нельзя просто заменить номером телефона.
Телефон, имя и содержание обращения нужны для работы с клиентом в системе заявок, но не должны без необходимости попадать в метки, адрес страницы или параметры обычных событий аналитики. Яндекс запрещает передачу идентификационной информации за пределами специально предусмотренных функций. Сохраняйте только разрешённые параметры: полный адрес перехода может содержать лишние данные.
Скрытые поля формы доступны для изменения посетителем. Сервер должен проверять их формат и допустимые значения. Если разметка отсутствует или некорректна, обращение всё равно принимают, а состояние источника отмечают отдельно.
Передача этих данных, подтверждение записи и связь с идентификатором обращения относятся к задаче интеграции сайта с CRM. Если проблема в том, какое событие считать обращением и как показывать его по каналам, требуется настройка веб-аналитики.
Где источник теряется
Не все пробелы означают неисправность сайта. Часть данных недоступна из-за условий посещения:
- ссылка не размечена, а сервис перехода не передал реферер — сведения о предыдущей странице;
- метки удалились при перенаправлении или были составлены неправильно;
- счётчик отсутствует на странице входа, заблокирован или не успел загрузиться;
- человек сменил устройство, браузер или удалил cookies;
- обращение произошло по телефону или в другом канале, где нет настроенной связи с посещением сайта.
Кросс-девайс-атрибуция помогает учитывать переходы с разных устройств, но не отменяет потери данных. Нельзя обещать, что она восстановит путь каждой заявки. Связь по доступным идентификаторам и правилам сервиса нужно проверять на фактических данных.
«Прямой заход» в Метрике включает не только ввод адреса и закладки, но и переходы без переданного источника. Поэтому рост этой категории сам по себе не доказывает рост узнаваемости бренда. А отсутствие UTM не делает посещение прямым: источник может определяться по другим доступным сведениям.
В CRM полезно отличать отсутствие меток, недоступный идентификатор и ошибку передачи. Не заполняйте все такие обращения значением «органика» или «прямой»: это создаёт уверенность, которой данные не дают. Зафиксируйте неизвестный источник и причину, если она установлена.
Как проверить связь на тестовой заявке
Проверка нужна от входа до записи в CRM. Одинаковые общие числа в двух отчётах не доказывают, что сопоставлены именно те обращения.
- Создайте учебную размеченную ссылку и откройте её в отдельном тестовом сеансе. Заранее запишите ожидаемые значения. Убедитесь, что после перенаправлений они дошли до страницы входа.
- Перейдите на другую страницу и отправьте форму. Проверьте, что нужные сведения сохранились до обращения. Сайт должен подтвердить приём и присвоить ему идентификатор.
- Найдите ту же запись в CRM. Сверьте идентификатор обращения, время, страницу, UTM-поля и доступный ClientID. Сходства имени или времени недостаточно для надёжного сопоставления.
- Проверьте цель в аналитике. Убедитесь, что нужное событие относится к успешному приёму. Для сравнения источников выберите согласованную модель атрибуции; учитывайте задержку появления данных в отчётах.
- Повторите проверки ошибок. Невалидная форма не должна давать событие успешного приёма. Повторная отправка одной и той же заявки не должна создавать второй лид. Обращение без меток или при недоступном счётчике должно приниматься с явным пробелом в аналитических данных.
Если передача в CRM прервалась, проверьте восстановление связи после повторной попытки: исходный идентификатор и сведения об источнике должны сохраниться. Правила такой передачи подробнее разобраны в статье о заявках с сайта в CRM.
Для регулярной сверки используйте один период, часовой пояс и определение обращения. Сравнивайте принятые заявки, результаты передачи и квалифицированные лиды раздельно. Причиной расхождения могут быть дубли, тестовые обращения, фильтры аналитики, разные модели атрибуции и даты: посещение, приём формы и продажа происходят в разные моменты.
Что требовать от готовой настройки
Попросите показать одну конкретную тестовую заявку от размеченного входа до CRM и объяснить каждое поле источника. Затем проверьте обращение без меток и неудачную отправку. В результате должны быть понятны правила атрибуции, подтверждены связи между записями и видны ситуации, в которых источник установить нельзя.
При оценке рекламы смотрите также на качество обращений и подтверждённые продажи. Канал, к которому отнесли цель, ещё не равен каналу прибыльных сделок. Рабочая система позволяет проследить доступную часть пути и принять решение с учётом пробелов, а не скрывает их за обещанием определить источник любой заявки.
