Настройка целей Яндекс Метрики для B2B: карта от визита до сделки
Клик по кнопке ещё не заявка. Показываем, как собрать карту целей от первого действия до договора и проверить её на реальном сайте.
Когда я открываю новый счётчик Метрики, меня меньше всего интересует количество созданных целей. Двадцать зелёных строчек ещё не означают, что компания понимает, откуда пришли деньги.
В B2B между визитом и оплатой легко помещается несколько месяцев: человек прочитал статью, вернулся по прямой ссылке, позвонил, получил расчёт, согласовал условия с коллегами и только потом подписал договор. Если считать конверсией каждый клик по телефону и каждое открытие квиза, отчёт быстро становится красивым и бесполезным.
Я начинаю с карты пути: что сделал посетитель, какое обращение подтвердил сайт, что попало в CRM и какой коммерческий результат подтвердили продажи. Для первого запуска хватает пяти–семи событий. Главное, чтобы каждому из них команда доверяла.
Сначала нарисуйте путь на одной странице
Соберите маркетолога, человека, отвечающего за сайт, и руководителя продаж. Попросите их описать один и тот же путь клиента. Обычно уже на этом этапе обнаруживается разница в терминах: маркетолог называет заявкой отправку формы, CRM считает созданную карточку, а руководитель продаж — только подходящее обращение.
Запишите путь без названий инструментов:
- Человек посетил страницу услуги или отрасли.
- Начал содержательное действие: квиз, звонок, письмо или форму.
- Успешно отправил обращение.
- Обращение появилось в CRM.
- Менеджер подтвердил квалификацию.
- Компания отправила предложение, заключила договор или получила оплату.
Рядом с каждым шагом укажите систему-источник и связующий идентификатор. Если между формой и CRM нет общего ID, ещё одна цель в Метрике эту дыру не закроет. Сначала нужно сохранить связь, затем строить отчёт.
Какие цели настроить в Метрике для B2B
Я делю события на четыре уровня. Это помогает не путать интерес с заявкой, а заявку — с продажей.
1. Намерение
Человек открыл квиз, начал форму, нажал на телефон или перешёл в контакты. Такие события полезны для анализа интерфейса. Они показывают, где посетитель начал действие и где остановился.
Но клик по номеру не доказывает, что разговор состоялся. Открытая форма тоже не равна обращению. Я не использую эти события как главный показатель качества рекламы.
2. Подтверждённое обращение
Форма или квиз прошли проверку, сервер принял данные и вернул успешный ответ. Звонок подтвердил коллтрекинг. Письмо появилось в выбранной системе учёта.
Для сайта ConversOn мы выбрали именно такую логику. Цель
quiz_lead_submitted отправляется после успешного ответа API. Если посетитель
нажал кнопку, но не заполнил обязательное поле или сервер вернул ошибку, заявка
в Метрику не уходит.
У нас также подготовлена цель checklist_requested. Пока форма чек-листа не
размещена на странице, я не считаю эту цель действующим источником данных. Само
наличие кода или цели в интерфейсе ещё ничего не измеряет.
Стартовая карта может выглядеть так:
quiz_start— посетитель выбрал первый ответ. Отправляем после первого действия.quiz_complete— вопросы пройдены до формы контакта. Отправляем при переходе к контактному шагу.quiz_lead_submitted— сервер принял обращение. Отправляем после успешного ответа API.phone_click— посетитель нажал на номер. Отправляем в момент клика, но не считаем звонком.email_click— посетитель открыл почтовую программу. Отправляем в момент клика, но не считаем письмом.
Названия можно выбрать другие. Важнее, чтобы команда одинаково понимала смысл события и могла найти место, где оно отправляется.
3. Квалификация
Менеджер проверил продукт, регион, объём и роль покупателя. Теперь компания понимает, было ли обращение полезным для бизнеса.
Передавать квалификацию обратно в аналитику стоит после того, как менеджеры договорились о критериях. Если один сотрудник считает запрос целевым, а другой нет, автоматизация только закрепит спорные данные.
4. Коммерческий результат
Для длинной сделки я добавляю предложение, договор и оплату. Не каждое событие нужно сразу использовать для оптимизации рекламы. Эти этапы помогают сравнивать каналы на одинаковой глубине воронки.
Яндекс Метрика принимает офлайн-конверсии через веб-интерфейс или API и показывает, удалось ли привязать событие к визиту [1]. Для связи заранее сохраняют ClientID, UserID, YCLID или PurchaseID. Если идентификатор потерялся, загрузка договора не восстановит первый визит по догадке.
Почему цель нельзя отправлять по клику на кнопку
В официальной документации Яндекс показывает метод reachGoal для передачи
целевого события [2]. Сам вызов занимает одну строку. Сложность в другом: нужно
выбрать правильный момент.
Представьте обычную форму. Человек нажал «Отправить», но забыл телефон. Или сервер не ответил. Или пользователь нажал кнопку дважды. Если цель висит на клике, Метрика запишет конверсию, а отдел продаж не увидит заявки.
Мы отправляем бизнес-цель после подтверждения от сервера. Клики и начало формы можно измерять отдельно, но они не должны называться заявками.
Проверьте пять сценариев:
- Успешная отправка.
- Ошибка обязательного поля.
- Ошибка сервера.
- Повторный клик по кнопке.
- Возврат назад и повторное прохождение квиза.
Бизнес-цель должна появиться один раз только в первом сценарии.
Как проверить цель до публикации
Яндекс рекомендует добавить к адресу страницы параметр _ym_debug=2, выполнить
целевое действие и проверить событие в консоли и на вкладке Events [3]. Так
видно не настройку «на глаз», а фактический вызов цели.
После технического теста я прохожу путь как посетитель:
- открываю сайт в приватном окне;
- захожу с тестовой UTM-меткой;
- отправляю форму с явной пометкой «тест»;
- сверяю время и технический ID;
- проверяю доставку обращения и появление цели в отчёте.
Тестовую заявку заранее согласуйте с продажами. Иначе проверка аналитики превратится в ложный лид для менеджера.
Сохраняйте контекст обращения, но не контакты в Метрике
Одной цели мало для диагностики. Вместе с заявкой в разрешённом контуре полезно сохранить:
- страницу начала обращения;
- UTM-метки и рекламную кампанию;
- ClientID или другой разрешённый идентификатор;
- тип обращения;
- дату, время и часовой пояс;
- технический ID заявки.
Телефон, email и имя клиента не нужно помещать в параметры цели или URL. Они остаются в системе обработки заявок с подходящими доступами.
Проведите приёмочный тест по сценариям
Я веду простой журнал тестов. В нём видно, где именно сломалась цепочка, а не только итог «цель не работает».
- Квиз отправлен успешно. Метрика: одна цель; API сайта: успех; CRM: карточка создана. Результат — зачёт.
- Форма не прошла проверку. В Метрике нет бизнес-цели, запрос в API не отправлен, карточки в CRM нет. Результат — зачёт.
- Сервер вернул ошибку. В Метрике нет бизнес-цели, API вернул ошибку, карточки в CRM нет. Результат — зачёт.
- Клик по телефону. В Метрике есть
phone_click; API не применяется; результат в CRM зависит от телефонии. Не считать звонком. - Квалифицированная сделка. В Метрике — офлайн-цель, в CRM статус подтверждён. Результат нужно связать с визитом.
Пройдите эти сценарии на компьютере и телефоне, из рекламы с тестовой UTM-меткой и из прямого визита. После релиза повторите проверку на production.
Сверяйте Метрику и CRM каждую неделю
Я смотрю на три перехода:
- Цель обращения → запись в CRM.
- Запись в CRM → квалифицированная сделка.
- Квалифицированная сделка → предложение или договор.
Первый переход лучше сверять построчно. Для следующих двух используйте когорты по дате первого обращения, иначе договоры из старых заявок смешаются с новым рекламным трафиком.
Идеального совпадения может не быть. CRM объединяет дубли, звонки происходят после нескольких визитов, модели атрибуции смотрят на путь по-разному. Мне важно, чтобы команда объясняла расхождения и замечала новые группы ошибок.
Где здесь помогает ИИ
Модель может сравнить обезличенные выгрузки Метрики и CRM, сгруппировать несопоставленные строки и подсветить дни с необычным ростом ошибок. Я задаю ей фиксированные правила и запрещаю угадывать источник там, где идентификатора нет.
Ежедневную сверку надёжнее выполнять скриптом с прозрачными условиями. ИИ полезен при разборе исключений и подготовке объяснения для специалиста. Решение об источнике и качестве обращения принимает человек, который видит исходные данные.
Чек-лист карты целей
- ☐ У каждого события есть владелец и понятный бизнес-смысл.
- ☐ Клики и начало формы не называются заявками.
- ☐ Цель обращения отправляется после успешного ответа сервера.
- ☐ Источник и технический ID сохраняются в CRM.
- ☐ Квалификация описана одинаково для всех менеджеров.
- ☐ Офлайн-конверсии передаются с разрешёнными идентификаторами.
- ☐ После релиза выполнен production-тест.
- ☐ Метрика и CRM регулярно сверяются построчно.
Если путь нельзя нарисовать на одной странице, начинать с сотни целей рано. Мы в ConversOn сначала собираем карту событий, затем проверяем формы и только после этого связываем аналитику с CRM. На выходе у команды остаётся схема, которую можно проверить, а не ещё один красивый отчёт. Если хотите разобрать эту цепочку на своём проекте, можно обсудить аудит аналитики.