Какие цели настроить в Яндекс Метрике, чтобы отличать заявки от попыток связаться

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

Какие цели нужны сайту услуг для оценки заявок

Для сайта услуг отдельно учитывайте подтверждённый приём формы и попытки связаться. В руководстве по выбору цели Яндекс предлагает ориентироваться на действие посетителя. Ниже мы называем основной целью подтверждённый приём обращения, а микроконверсией — вспомогательный сигнал интереса. Это рабочее разделение для задания и отчёта.

Действие	Способ учёта	Что можно заключить
Открытие формы	Событие открытия или просмотр страницы, по устройству сайта	Посетитель увидел форму
Попытка отправки	«Отправка формы»	Посетитель попытался передать данные
Подтверждённый приём	«Целевое событие» после согласованного ответа системы	Получено выбранное подтверждение успеха
Просмотр страницы благодарности	«Посещение страниц»	Открыт подходящий URL
Взаимодействие с телефоном	Цель по телефону	Посетитель взаимодействовал с номером
Переход в мессенджер	Цель по мессенджеру	Посетитель перешёл в канал связи

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

Название показателя должно отвечать на вопрос: что именно произошло?

Если вы наблюдаете только нажатие кнопки, так и назовите показатель. Подпись «Принятая заявка» оставьте для согласованного подтверждения приёма.

Почему отправка формы в Метрике ещё не означает принятую заявку

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

В той же документации указаны технические условия: элемент form, кнопка submit внутри него и стандартное событие onSubmit при обработке через JavaScript. Внешний вид формы не позволяет проверить эти условия. Нужен просмотр её разметки и обработки отправки.

Представим форму запроса расчёта. Посетитель заполняет поля, нажимает кнопку и видит ошибку в телефоне. Затем исправляет значение и повторяет отправку.

Попытка уже была; приём ещё предстоит подтвердить.

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

Как описать событие подтверждённого приёма заявки

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

Документация reachGoal описывает вызов ym(номер_счётчика, 'reachGoal', 'идентификатор_цели'). Разным событиям назначают разные идентификаторы. Одно действие в разных местах сайта можно объединить общим идентификатором.

Пример формулировки для ТЗ: «После подтверждения успешного приёма формы расчёта передать согласованное событие. При ошибке полей или сбое отправки событие приёма не передавать».

Уточните границу успеха: данные получил обработчик сайта или запись уже сохранилась в системе назначения?

Это разные условия приёмки.

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

Что показывают цели по телефону и мессенджерам

Цели по телефону и мессенджерам помогают учитывать взаимодействие с каналами связи. Сохраните этот смысл в названиях: «Взаимодействие с телефоном» и «Переход в мессенджер». Для показателя «Принятое обращение» предусмотрите отдельную проверку результата в выбранном канале. Её способ нужно согласовать до оценки заявок.

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

Цель по мессенджерам фиксирует переход. Подтверждения отправленного сообщения такое событие не даёт.

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

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

Когда страница благодарности подходит для цели

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

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

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

Один просмотр ещё не объясняет путь посетителя.

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

Что подготовить перед настройкой целей

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

Подготовку удобно пройти по шагам:

1. Определите нужный счётчик Метрики.
2. Перечислите формы, телефонные ссылки и мессенджеры.
3. Выберите наблюдаемое действие для каждого элемента.
4. Согласуйте названия целей и идентификаторы событий.
5. Опишите успех, ошибку и повторное действие.
6. Назначьте тестовые значения и получателя.

Названия должны помогать найти элемент: «Форма расчёта в подвале» понятнее, чем «Форма новая».

Решение об объединении одинаковых форм принимайте по вопросу бизнеса. Нужно сравнить места размещения или достаточно общего результата? Зафиксируйте ответ до настройки.

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

Как проверить срабатывание цели в Метрике

Проверка должна показать, какое событие получил нужный счётчик после тестового действия. Заранее согласуйте тестовый контур или получателя, который не запустит обработку реальной заявки. Отдельно назначьте сотрудника, способного подтвердить сохранение записи. Наблюдение в Метрике и проверку получателя внесите в протокол разными пунктами.

В инструкции Яндекса описан следующий порядок:

1. Добавьте _ym_debug=2 к адресу: через ? без других параметров или через &, если параметры уже есть.
2. Выполните проверяемое действие.
3. Проверьте Events/Console и номер счётчика.
4. Если панели нет, используйте консоль браузера.

Панель отладки поддерживает новый код счётчика. При фильтре «Не учитывать мои визиты» документация рекомендует приватный режим браузера.

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

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

Какие сценарии проверить до приёмки настройки

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

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

Ошибка валидации. Форма должна предложить исправить данные. По предложенному заданию событие подтверждённого приёма в этом случае отсутствует. Учёт попытки отдельно оцените с учётом ограничения цели «Отправка формы», описанного выше.

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

Повторный клик. Включите в задание защиту от лишнего события приёма во время отправки. Проверьте полученные события. Это требование к реализации сайта.

Повторный просмотр страницы благодарности. Откройте адрес заново и обновите страницу. Сопоставьте результат с согласованной логикой учёта.

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

После исправления повторите сценарий с расхождением.

Что включить в ТЗ и как читать результат после настройки

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

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

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

В ТЗ не закладывайте гарантии доставки обращения или полного совпадения Метрики с CRM. Лучше назвать доступные проверки и обозначить этапы, которые ещё предстоит подтвердить.

Частые вопросы

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

Что делать, если у нас пока нет доступа к системе приёма заявок?

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

Кто должен согласовать названия целей?

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

Нужно ли передавать настоящие контакты для проверки?

Для предложенного плана проверки настоящие контакты не нужны. Согласуйте тестовые значения и получателя, чтобы не создавать реальное обращение.

Источники

Документация ниже подтверждает выбор цели, условия учёта отправки формы, передачу события и порядок отладки. Ссылки на описание телефонных целей, мессенджеров и посещения страниц приведены в соответствующих разделах. Условия приёмки, примеры ТЗ и сценарии тестирования — практический план работы; документация Яндекса не предписывает эту организацию процесса.

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