Как проверить, что цель Метрики считает принятую заявку

Определите, что именно означает цель

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

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

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

Проверьте момент вызова reachGoal

Документация Яндекс Метрики описывает reachGoal как передачу достижения цели. Вызов метода сам по себе не проверяет вашу базу заявок. Связать его с подтверждённым сохранением должна логика сайта. Номер счётчика и идентификатор цели должны соответствовать рабочей конфигурации.

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

Не используйте callback аналитики как подтверждение сохранения обращения. Он относится к работе счётчика. Аналогично видимый экран «Спасибо» не является доказательством серверного результата, если его можно открыть напрямую или если он появляется до ответа приложения.

Составьте проверочную матрицу

Таблица проверяет определение цели «принятие». Для клика по кнопке можно завести отдельное диагностическое событие, если оно нужно анализу. Главное — не выдавать его за завершённую заявку и не смешивать оба события в основном отчёте.

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

Разберите сетевой повтор отдельно

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

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

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

Проверьте несколько мест отправки

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

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

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

Почему Метрика и база могут расходиться

У пользователя может не загрузиться счётчик из-за блокировщика или сети; эти причины перечислены и в документации Метрики. Поэтому база принятых обращений и браузерная аналитика не обязаны совпадать один к одному. Исправная заявка должна сохраняться независимо от доступности необязательного счётчика.

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

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

Что должно остаться после проверки

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

Для настройки веб-аналитики полезен именно такой протокол, а не один скриншот с достижением цели. Когда путь принятия подтверждён, можно предметнее оценивать рекламу и SEO и отдельно исследовать качество обращений. Этот материал описывает метод проверки; он не является отчётом об измерениях вашего рабочего счётчика.

Как использовать отладчик Метрики при проверке цели

В официальной инструкции проверки целей Яндекс описывает параметр _ym_debug=2 для нового кода счётчика. Добавьте его к адресу проверяемой страницы: через ? при отсутствии других параметров или через & после существующих. Выполните нужное действие, откройте панель отладки и проверьте выбранный счётчик, событие во вкладке Events и подробности в Console. Для предыдущего кода или отсутствующей панели инструкция предлагает консольный способ с _ym_debug=1.

Если включён фильтр «Не учитывать мои визиты», учтите рекомендацию Яндекса о приватном режиме. Отдельно проверьте появление достижения в отчёте после обработки данных. Запись в отладчике и строка бизнес-заявки — разные свидетельства: одно не заменяет другое.

Пример протокола одной проверки

Это вымышленный результат проверки на тестовом стенде. TEST-041 — внутренняя метка теста, а «счётчик стенда» должен быть заменён в рабочем протоколе его фактическим номером. Реальные обращения клиентов для такого упражнения не нужны.

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

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