Цели Яндекс Метрики: как настроить учёт заявок с сайта

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

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

В Яндекс Метрике цель фиксирует действие по заданному условию. Её название придумывает владелец счётчика, поэтому слова «Заявка» или «Продажа» в отчёте ещё не объясняют, что произошло. Точный смысл нужно записать до настройки.

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

Запишите определение основной цели одной фразой. Например: «Сайт сохранил обращение из формы консультации и вернул его технический номер». Уточните, где именно хранится заявка: в базе сайта, очереди передачи в CRM или самой CRM. Ответ «успешно» должен подтверждать согласованный этап. Если сайт лишь попытался отправить письмо, это более слабое условие, которое тоже нужно честно описать.

Разделите открытие формы, попытку отправки и подтверждение

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

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

Используйте устойчивые технические идентификаторы, например consult_form_open и consult_request_accepted. Они описывают действие и сохраняют смысл после изменения текста кнопки.

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

Выберите способ, который соответствует устройству формы

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

Для цели «Отправка формы» Яндекс описывает зависимость от разметки и валидации. При некоторых реализациях засчитывается и неудачная попытка. Поэтому её корректность проверяют на конкретном сайте, особенно после изменения HTML. Само появление цели в списке не подтверждает точность учёта.

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

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

Вызывайте reachGoal после подтверждённого приёма

В разделе «Цели» добавьте цель типа «Целевое событие». Укажите понятное название, условие точного совпадения и согласованный идентификатор. Тот же идентификатор разработчик передаст из кода сайта. Проверьте номер счётчика: событие в чужом или тестовом счётчике не появится в нужном отчёте.

Метод reachGoal сообщает Метрике о достижении цели. Он не проверяет сохранение формы и не создаёт заявку в CRM. Нужное условие определяет приложение. Ответ сервера с кодом 200 тоже недостаточен, если внутри него может содержаться сообщение об отказе.

Ниже — условный фрагмент внутри обработчика ответа формы. В этом примере разработчик заранее договорился, что accepted: true возвращается только после сохранения обращения. COUNTER_ID — переменная с номером счётчика, а result — уже проверенный ответ сервера.

if (result.accepted === true && typeof ym === 'function') {
  ym(COUNTER_ID, 'reachGoal', 'consult_request_accepted');
}

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

Обратный вызов самого reachGoal относится к отправке аналитических данных. Он не является подтверждением приёма заявки вашим сервером. Показ сообщения об успехе и сохранение обращения должны работать независимо от доступности аналитики: блокировка счётчика у посетителя не должна ломать форму.

Уберите повторные вызовы и проверьте переходы без перезагрузки

Одна заявка иногда вызывает два события: первое отправляет код формы, второе — менеджер тегов. Другой частый источник — обработчик, который подключается заново при каждом открытии окна. Найдите все места вызова одного идентификатора, включая шаблон, подключаемые модули и настройки менеджера тегов.

На время отправки запроса блокируйте повторное нажатие и показывайте понятный статус ожидания. Этого мало для полной защиты: посетитель может обновить страницу или повторить запрос после обрыва связи. Создание дублей обращений должен предотвращать сервер. Для аналитического события разработчик отдельно задаёт правило: один вызов на один подтверждённый результат в пределах принятой схемы учёта.

Технический номер заявки можно использовать для контроля повторов в приложении. Такой контроль не должен запрещать следующую самостоятельную заявку того же человека.

В одностраничном приложении — SPA — экраны меняются без полной загрузки документа. Проверьте повторное открытие формы, переход вперёд и возврат назад: обработчик не должен подключаться повторно. Если цель зависит от просмотра виртуальной страницы, отдельно настройте передачу просмотров; для этого у Метрики есть метод hit. Изменение адресной строки и подтверждённая заявка остаются разными событиями.

Пройдите успешный и ошибочные сценарии

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

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

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

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

Проверьте событие в браузере и затем в отчёте

Для нового кода счётчика Яндекс предлагает режим отладки с параметром _ym_debug=2. Добавьте его к адресу формы и перезагрузите страницу. Если в URL уже есть параметры, используйте амперсанд перед новым параметром вместо второго вопросительного знака.

Выполните действие через интерфейс сайта и откройте панель отладки. На вкладках Events и Console проверьте номер счётчика и идентификатор события. Зафиксируйте, на каком шаге оно появилось. Ручной вызов reachGoal из консоли позволяет проверить отдельную передачу, но не подтверждает правильную связь с формой.

После этого найдите результат в отчёте «Конверсии». Учтите время обработки данных и фильтры счётчика. При включённой настройке «Не учитывать мои визиты» Яндекс рекомендует проверять в приватном режиме. Доступность самого счётчика в выбранном браузере тоже нужно проверить: расширение или настройки приватности могут блокировать запросы.

Если события нет, последовательно сравните номер счётчика, идентификатор цели и условие в настройках. Затем проверьте, выполнился ли нужный участок кода и нет ли ошибки JavaScript. Такой порядок рекомендует справка по неполадкам целей. Ошибку доставки формы и ошибку отправки аналитики фиксируйте раздельно, чтобы чинить нужную часть.

Отладчик показывает происходящее в текущем браузере. Для окончательной проверки сопоставьте три наблюдения: сервер принял тестовую заявку, приложение отправило нужное событие, цель появилась в отчёте.

Сверяйте Метрику с CRM по одинаковым условиям

Сначала уточните единицы сравнения. В отчёте «Конверсии» есть достижения цели и целевые визиты. В одном визите возможны повторные действия, поэтому эти показатели нельзя автоматически считать числом уникальных обращений. В CRM одна запись тоже может представлять несколько сообщений клиента или объединённые дубли.

Выберите одинаковый период и часовой пояс. Сравнивайте формы из согласованного списка, исключите тестовые обращения и проверьте задержку между приёмом на сайте и созданием записи в CRM. Телефонные звонки, ручной ввод менеджера и переписка из других каналов не должны случайно попадать в эту сверку.

Если Метрика показывает больше событий, проверьте повторные вызовы, клики без успешной отправки и повторное открытие страницы подтверждения. Если меньше — посмотрите альтернативные формы, ошибки счётчика и блокировки в браузере. При загрузке аналитики только после согласия посетителя события до её включения могут отсутствовать; тест должен учитывать принятую на сайте логику.

Полного совпадения браузерной аналитики и CRM обещать нельзя. Счётчик может не загрузиться из-за расширения, сетевого сбоя или настроек приватности; заявка при этом будет сохранена. Эти причины перечислены и в справке reachGoal. Разберите причины расхождений и проверьте, не появились ли новые после обновления формы.

Качество обращения оценивайте по согласованным признакам в CRM: нужная услуга, доступный контакт, подходящие условия работы. Чтобы результат не зависел от привычек менеджера, заранее определите этапы и правила воронки продаж. Передача дальнейших статусов в аналитику — отдельная настройка, которой не заменяют проверку исходной цели.

Оставьте команде понятную настройку и порядок повторной проверки

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

Если меняете событие, которое учитывает цель, предупредите аналитика до выпуска правки. Иначе один график объединит, например, прежние клики и новые подтверждённые заявки. Отметьте дату перехода и решите, нужна ли отдельная цель для сравнения периодов. До изменения сохраните необходимые отчёты и проверьте, где цель используется.

После обновления формы повторите успешный и ошибочные сценарии из чек-листа. Сверьте событие с фактом приёма обращения, затем проверьте отчёт и запись в CRM.

Для настройки в ШТАБ ИТ пришлите адрес формы и опишите, что сейчас считается заявкой. По этим данным можно определить нужное событие, проверить существующие цели и составить задание разработчику без догадок о работе сайта.