В отчёте появилась «заявка», а менеджер не получил обращение. Бывает и наоборот: форма работает, но Метрика ничего не показывает. Разбираться нужно с условием цели: что именно сайт сообщает счётчику и в какой момент. Название цели не превращает нажатие кнопки в принятый заказ.
Мы в Гуси-Лебеди предлагаем начинать с пути посетителя: открыл форму, заполнил данные, отправил их, получил подтверждение. Затем отдельно проверить запись обращения и его дальнейшую обработку. Ниже разбираем, как настроить цели Яндекс Метрики, проверить их работу и принять результат без путаницы между кликами и продажами.
Что измеряет цель и какие действия выбрать
Цель фиксирует выполнение заданного условия. Для кнопки это может быть клик, для страницы благодарности её просмотр, для события сигнал из кода сайта. У каждого действия своя задача: открытие формы помогает изучать интерфейс, принятая заявка показывает результат отправки, подтверждённая продажа относится к следующему этапу работы с клиентом.
Сначала запишите, какое решение будете принимать по данным. Если нужно понять, где посетители бросают заполнение, одного события успешной отправки мало. Если оцениваете обращения, счётчик кликов по кнопке не заменяет проверку того, что данные действительно приняты. Для оценки качества лидов нужны согласованные критерии в системе обработки обращений.
| Действие | Что можно проверить | Что ещё не подтверждено |
|---|---|---|
| Открытие формы | Посетитель дошёл до обращения | Заполнение и отправка |
| Клик по кнопке отправки | Попытка отправить данные | Приём обращения |
| Подтверждённый приём | Обращение сохранено по правилам сайта | Соответствие условиям и продажа |
| Переход в мессенджер | Открыта ссылка на канал связи | Начало переписки |
| Клик по телефону | Нажат номер | Состоявшийся разговор |
Не складывайте разные этапы в общее «число заявок». Один посетитель может открыть форму, нажать кнопку и успешно отправить данные в рамках одного обращения. Полезнее видеть последовательность, чем получать сумму всех действий с красивым, но неверным названием.
Метрика различает достижения цели и целевые визиты: в одном визите возможны несколько достижений. Поэтому число срабатываний не обязательно равно числу людей или новых обращений. Определения показателей есть в справке о целях и конверсиях. При сравнении отчётов сначала убедитесь, что смотрите один и тот же показатель.
Как выбрать тип цели для страницы, кнопки и формы
Выбирайте тип под фактическое действие. «Посещение страниц» подходит для просмотра нужного адреса. «Клик по кнопке» нужен для взаимодействия с выбранным элементом. Готовая цель отправки формы помогает отслеживать формы, но её срабатывание всё равно нужно сопоставить с результатом вашей реализации. Если необходимо сообщать определённый момент из логики приложения, используйте целевое событие.
Страница благодарности удобна, когда она появляется после нужного действия. Однако сам её просмотр не всегда доказывает новую заявку: адрес может открываться повторно или по прямой ссылке. Проверьте оба сценария. Если форма отправляется без перехода на другую страницу, нельзя рассчитывать на новый URL как на единственный сигнал успеха.
Для формы с подтверждением от сервера заранее определите границу успеха. Считается ли обращение принятым после сохранения в базе, после передачи в CRM или после другого проверяемого ответа? Это решение должно быть одинаково понятно разработчику, аналитику и человеку, который принимает работу.
Для нескольких форм решите, нужен ли общий результат или отдельные события. Например, запрос консультации и отклик на вакансию решают разные задачи. Раздельные цели помогут не принимать рост откликов соискателей за рост обращений покупателей. Подробное устройство страницы разбираем в статье о структуре посадочной страницы.
Автоматические и вручную настроенные цели могут наблюдать близкие действия. Не удаляйте их только из-за похожего названия, но закрепите назначение каждой. В рабочем отчёте выбирайте ту цель, смысл и проверка которой соответствуют задаче.
Как настроить целевое событие и отправку заявки
Откройте нужный счётчик, перейдите к целям и добавьте цель типа «Целевое событие». Дайте ей понятное название и согласуйте идентификатор, который будет передаваться с сайта. Перед изменением проверьте уже существующие цели: второе имя для того же события может добавить путаницу в отчёты.
В задании разработчику укажите номер счётчика, идентификатор, точное условие успеха и место вызова. Фраза «поставить цель на форму» слишком расплывчата. Лучше написать: «Передавать событие после подтверждения сохранения обращения; не передавать при ошибке обязательного поля и отказе сервера».
Для передачи используется метод reachGoal. Общая форма вызова ниже показывает только синтаксис. COUNTER_ID нужно заменить номером счётчика, а lead_accepted это учебный идентификатор, который должен совпадать с настройкой вашей цели.
ym(COUNTER_ID, 'reachGoal', 'lead_accepted');Этот вызов относится к точке подтверждённого успеха, а не автоматически к любому нажатию «Отправить». Обычный обработчик клика может выполниться до проверки полей. Обработчик отправки формы может сработать до того, как сервер примет данные. Точное место зависит от кода формы и её API.
Не ориентируйтесь только на HTTP 200: в конкретном API такой ответ может содержать сообщение об ошибке. Проверьте договорённое поле результата, идентификатор сохранённого обращения или другой предусмотренный признак. Когда ответ потерян, браузер не должен объявлять успех на основании предположения. Нужна проверка состояния или согласованная безопасная повторная попытка.
Также не переносите создание заявки в обратный вызов аналитики. Он относится к передаче данных счётчику, а не к сохранению обращения. Сначала работает основная функция сайта, затем передаётся аналитическое событие. Недоступность аналитической библиотеки не должна мешать посетителю обратиться.
Если задача затрагивает формы, события и отчёты одновременно, её удобно собрать в единое задание на настройку аналитики сайта: исполнитель видит не отдельный тег, а весь путь, который предстоит проверить.
Почему цель срабатывает дважды или меняет смысл
Начните с карты обработчиков. Одно действие может одновременно запускать код на кнопке, обработчик формы, собственное событие успешного ответа и правило менеджера тегов. Если все они отправляют один идентификатор, источник повтора нужно искать в этих точках.
Проверьте двойное нажатие, повторный ответ, перезагрузку страницы и повторное открытие формы. В интерфейсах с динамическими компонентами посмотрите, не подключается ли обработчик повторно при появлении элемента. Проверка только первого успешного нажатия такие случаи не обнаружит.
Защита от повторного создания обращения и защита от двойного аналитического события решают разные задачи. Сервер должен корректно обрабатывать повтор операции по своим правилам. Локальный флаг в браузере не даёт гарантии между вкладками и после перезагрузки. Для учёта новых обращений нужны устойчивые записи в системе, где они обрабатываются.
Не пытайтесь исправить двойные достижения простым делением статистики пополам. Сначала воспроизведите сценарий, найдите источник повтора и проверьте исправление. Разные посетители могут попадать в разные условия, поэтому постоянный коэффициент легко скроет ошибку.
Если меняете условие существующей цели, запишите дату и содержание изменения. До исправления она могла считать попытки, после него принятые обращения. Такой ряд уже нельзя сравнивать как один неизменный показатель. При существенной смене смысла обсудите отдельную цель и понятные подписи в отчётах.
Как проверить цель через отладчик, отчёт и запись обращения
Проверяйте три уровня: событие отправилось с нужной страницы, попало в нужный отчёт и соответствует действию, которое произошло на сайте. Один уровень не заменяет остальные. Успешный тестовый вызов не доказывает, что все реальные формы подключены одинаково.
- Выберите форму, устройство и сценарий. Запишите время проверки.
- Откройте страницу с параметром
_ym_debug=2. Если параметры уже есть, добавьте его через&. - Выполните действие и найдите нужный счётчик и событие во вкладках панели отладки.
- Проверьте достижение в отчёте по нужной цели, учитывая обработку данных и фильтры.
- Сопоставьте результат с записью обращения в системе обработки.
Панель с _ym_debug=2 предназначена для нового кода счётчика. Для предыдущей версии или при отсутствии панели в официальной инструкции описана проверка через консоль с _ym_debug=1. Если включена опция «Не учитывать мои визиты», Яндекс рекомендует проводить проверку в приватном режиме. Подробности и актуальные шаги доступны в инструкции проверки цели.
Когда события нет, последовательно проверьте загрузку счётчика, его номер, идентификатор цели и выполнение обработчика. Затем посмотрите ошибки JavaScript и ограничения конкретного тестового браузера. Проверка в другом контролируемом окружении помогает отделить проблему сайта от блокировки счётчика расширением.
Когда событие есть, а нужного результата в отчёте нет, проверьте цель, период, сегмент и фильтры. Не делайте вывод по одному мгновенному обновлению отчёта. Когда расходится число обращений и достижений, сначала сопоставьте смысл показателей, а затем ищите пропущенные формы и повторы.
Источник перехода проверяйте отдельно. Корректная цель не исправляет потерянные параметры рекламной ссылки. Для этого пригодится наша инструкция по созданию и проверке UTM-меток.
Как принять настройку и выбрать цели для рекламы
Приёмка начинается с таблицы сценариев. В ней для каждой формы должны быть ожидаемое действие сайта, аналитическое событие и проверяемый результат. Исполнитель показывает, что происходит при успехе и при ошибке, а не только скриншот списка сохранённых целей.
| Проверка | Что ожидаем от сайта | Цель принятой заявки |
|---|---|---|
| Пустое обязательное поле | Ошибка и возможность исправить данные | Не достигается |
| Сервер отклонил отправку | Сообщение об отказе | Не достигается |
| Обращение принято | Подтверждение и сохранённая запись | Достигается по согласованному условию |
| Повтор той же операции | Обработка повтора по правилам сервера | Проверка отсутствия лишнего срабатывания |
| Страница благодарности открыта напрямую | Нет нового обращения | Не считать новой принятой заявкой |
| Отправка с телефона | Тот же проверяемый путь | Проверяется отдельно |
Вместе с результатом попросите словарь целей: название, идентификатор, условие, место отправки, способ проверки и ответственный. Сохраните протокол тестов и дату изменения. После обновления формы или переноса сайта эти материалы помогут быстро повторить проверку.
Какую цель выбирать для рекламы? Ту, которая соответствует согласованному результату и надёжно проверяется. Не называйте клик продажей ради удобства. Если нужно учитывать позднюю квалификацию или оплату, отдельно спроектируйте передачу этих сведений из системы обработки обращений.
Нужно ли сразу настраивать все возможные цели? Начните с действий, по которым действительно принимаете решения, и добавьте диагностические этапы для понятного пути. Большой список сам по себе не делает аналитику полезнее.
Почему Метрика не совпадает с CRM? Это повод проверить определения, период, фильтры, охват форм и повторы. Метрика фиксирует аналитические события, CRM хранит обращения и их статусы. Сравнение требует одинаковых условий, а не ожидания, что любые две цифры обязаны совпасть.
Мы в Гуси-Лебеди рекомендуем принимать работу по воспроизводимому пути от действия посетителя до записи и отчёта. Для существующего проекта начать можно с комплексной проверки сайта и точек обращения: сначала выяснить, что сейчас измеряется, затем согласовать исправления и повторить тесты.