Цель может исправно срабатывать и при этом измерять не заявку, а нажатие кнопки. Человек нажал «Отправить», получил ошибку обязательного поля и ушёл; в отчёте уже появилась конверсия. До запуска рекламы важно проверить смысл события вместе с техническим путём его передачи.
Разберём условную форму обращения за услугой. Результатом считаем заявку, которую приложение сохранило и может показать ответственному сотруднику. Качество клиента и факт продажи проверяются позже. Сам разбор эффективности Директа через Метрику имеет смысл, когда это исходное измерение уже понятно.
Определите, какое действие считать результатом
Запишите условие: «Одна принятая заявка из этой формы создаёт одну запись и один сигнал сохранения». Для технического события можно выбрать идентификатор lead_saved. Отдельно оставьте клики по телефону, мессенджеру и начало заполнения: они помогают понять путь посетителя, но не подтверждают, что обращение принято.
Приложение должно подтверждать именно сохранение, а не только доставку письма или уведомления менеджеру. Если запись сохранена, а уведомление временно не ушло, это задача доставки уведомления. Если запись не появилась, успешная надпись на экране и HTTP-ответ 200 сами по себе не доказывают заявку.
Отметьте адрес формы, номер нужного счётчика, название и тип цели, идентификатор события или условие URL. Название для человека и идентификатор, передаваемый из кода, выполняют разные роли. Если обращения должны попадать в клиентский учёт, согласуйте где хранится рабочая история заявки.
Проверьте цель в зависимости от её типа
JavaScript-событие после подтверждённого сохранения
По справке Метрики, событие с сайта передаётся методом reachGoal. Сверьте номер счётчика и идентификатор с настройкой цели. Для одной формы используйте однозначное условие, чтобы похожее событие другой кнопки не попадало в тот же результат.
Точка вызова должна находиться в обработке подтверждённого успеха сервера. Общий обработчик клика или отправки формы выполняется раньше, чем становится известно, сохранилось ли обращение. Архивный разбор Яндекса о reachGoal в формах объясняет различие клика и отправки. Для нашей цели сохранённой заявки нужна следующая проверка — подтверждение приложения.
Ниже — фрагмент для разработчика при условном контракте API: ok: true означает сохранённую заявку, а leadId — её постоянный строковый идентификатор. Его вызывают после проверки ответа сервера и с номером уже установленного счётчика. Названия полей адаптируются к вашему приложению; идентификатор заявки используется локально и не передаётся в Метрику.
const reportedLeadIds = new Set();
function reportSavedLead(result, counterId) {
if (result.ok !== true ||
typeof result.leadId !== 'string' || !result.leadId ||
reportedLeadIds.has(result.leadId) ||
typeof window.ym !== 'function') {
return;
}
try {
window.ym(counterId, 'reachGoal', 'lead_saved');
reportedLeadIds.add(result.leadId);
} catch (error) {
return;
}
}
Фрагмент исключает повторный вызов для одной записи в пределах текущей страницы и не превращает ошибку аналитики в ошибку уже принятой формы. Он не гарантирует получение события Метрикой и не защищает сервер от создания двух заявок. При перезагрузке набор идентификаторов очищается: защита от повторного сохранения и сверка неизвестного результата должны быть предусмотрены в приложении.
URL-цель на странице подтверждения
Цель «Посещение страниц» проверяет адрес, а не запись в базе. Пройдите реальный переход после сохранения и сверяйте условие с фактическим адресом: домен, путь, завершающий слеш и параметры. Слишком короткое условие «содержит» может охватить другие страницы.
Затем откройте страницу подтверждения напрямую, обновите её и вернитесь к ней через историю. Если просмотр снова считается заявкой без нового сохранения, такая цель измеряет посещение страницы благодарности. Для учёта принятых обращений потребуется изменить сценарий сайта или выбрать явное событие сохранения. Само переименование цели не исправит её смысл.
Готовая цель отправки формы
Для цели «Отправка формы» Яндекс описывает требования к HTML и стандартному событию отправки. Справка также предупреждает: по умолчанию могут учитываться безуспешные попытки, например при ошибке валидации. Поэтому выполните отрицательный сценарий до того, как назовёте эту цель сохранённой заявкой.
Проверьте конкретную форму, включая её мобильный вариант и всплывающее окно, если они есть. Если автоматическая цель измеряет попытку отправки, она может оставаться диагностическим сигналом. Для основной цели принятого обращения нужен подтверждённый результат приложения.
Пройдите успешные, ошибочные и повторные действия
Используйте тестовые данные и согласованный способ проверки без реальных клиентских контактов. Для каждого сценария сохраните результат в приложении и число вызовов выбранного события. Таблица ниже относится к явному lead_saved; это ожидаемое поведение сайта, которое затем нужно проверить в Метрике.
| Сценарий | Записи заявки | Вызовы lead_saved | Что проверить |
|---|---|---|---|
| Открыть форму без отправки | 0 | 0 | Просмотр или начало заполнения не запускает событие сохранения |
| Отправить с ошибкой обязательного поля | 0 | 0 | Валидация показывает ошибку, основная цель не достигается |
| Получить отказ сервера без сохранения | 0 | 0 | HTTP-ответ и сообщение не маскируют отказ как успех |
| Успешно сохранить заявку | 1 | 1 | Сигнал следует за подтверждением той же записи |
| Повторно обработать ответ той же заявки | 1 всего | 1 всего на странице | Один ответ не запускается несколькими обработчиками |
| Потерять ответ после возможного сохранения | Состояние требует сверки | 0 до подтверждения | Сначала выясняется результат, повтор не создаёт дубль |
| Открыть или обновить страницу благодарности | Новых нет | Новых нет | URL-цель может учитывать просмотр; его нельзя выдавать за новую заявку |
| Создать две разные допустимые заявки | 2 | 2 | Защита от дублей не блокирует отдельную новую запись |
| Сохранить при недоступной аналитике | 1 | Может быть 0 или без доставки | Успех формы сохраняется, потеря сигнала отмечается отдельно |
| Отправить с телефона или клавишей Enter | 1 | 1 | Событие не зависит только от клика по одной кнопке |
Двойной клик требует двух проверок: приложение не должно создать лишнюю запись, а аналитика — повторно отчитаться за ту же запись. Если два запроса получили два разных идентификатора, локальная защита из примера их не объединит. Нужно исправлять приём заявки на сервере и поведение формы.
Проверьте, не отправляется ли одно событие одновременно из кода, системы управления тегами и стороннего виджета. Ограничение Метрики на частоту достижения одной цели не заменяет эту проверку: справка указывает не чаще раза в секунду. Смотрите вызовы сайта отдельно от итогового числа достижений и целевых визитов.
Сверьте сигнал сайта с отладчиком и отчётом
Официальная проверка цели использует параметр _ym_debug=2. Добавьте его к адресу через ? или &, если параметры уже есть, загрузите страницу и выполните действие. В панели выберите нужный счётчик; для JavaScript-события проверьте идентификатор во вкладках Events и Console.
Включённый фильтр «Не учитывать мои визиты» может мешать тесту; Яндекс предлагает приватный режим браузера. Отладочная панель требует нового кода счётчика; при старом коде справка описывает консоль и _ym_debug=1. Отсутствие панели ещё не доказывает, что заявка не сохранена.
Сверьте три свидетельства: запись в приложении, отправку события и появление достижения в отчёте после обработки данных. Если нет записи, исследуйте форму и сервер. Если запись есть, а вызова нет — обработчик успеха и доступность аналитики. Если вызов виден, а отчёт пуст — номер счётчика, условие цели, фильтры и доставку. Ограничения браузера или отсутствие разрешённого запуска аналитики могут оставить заявку без сигнала; обходить их для красивого совпадения чисел не нужно.
Повторите обычную отправку после исправления и сохраните дату проверки, страницу, выбранную цель и фактический результат. После смены формы, виджета или обработчика успеха повторите отрицательные сценарии. Для рекламной стратегии выберите проверенный результат, а диагностические клики рассматривайте отдельно.
Отделите настройку цели от доработки сайта
Бесплатный Yandex Metrica Advisor помогает проверить счётчики, права, цели и данные и объяснить, что требует исправления. Если нужна новая или изменённая цель, он поддерживает защищённый план создания или обновления одной JavaScript- либо URL-цели. Применение требует отдельного точного подтверждения, после чего настройка перечитывается из Метрики.
Изменение условия цели не переносит вызов из обработчика клика в обработчик сохранения. Такая доработка выполняется в коде сайта и принимается по таблице сценариев. Советник также не загружает CRM, звонки или офлайн-конверсии; подключение этих данных нужно оценивать отдельно. Исправление цели не пересчитывает прежнюю накопленную информацию.
Если форма сама теряет обращения или показывает ложный успех, начните с проверки пути посетителя до заявки и необходимых изменений приложения. Готовность измерения означает, что вы понимаете, какое действие считается результатом, видите подтверждение сохранения и знаете, где сигнал может потеряться.
Практический порядок решения
- Определите результат сохранённой заявки, счётчик и идентификатор цели.
- Сверьте JavaScript, URL или отправку формы с фактическим поведением.
- Проверьте успех, валидацию, повторные ответы и потерю доставки.
- После исправления сопоставьте записи, отправку сигнала и обработанный отчёт.
Источники и методология
Для проверки фактов и технических деталей использованы следующие материалы:
- Яндекс Метрика: цель JavaScript-событие и идентификатор
- Яндекс Метрика: цель посещения страницы
- Яндекс Метрика: отправка формы и безуспешные попытки
- Яндекс Метрика: отладчик и проверка достижения цели
- Яндекс: настройка reachGoal в формах
- Yandex Metrica Advisor: возможности и ограничения стабильного релиза
Проверьте, что измеряет ваша цель
Бесплатный советник поможет разобрать Метрику и подготовить контролируемое исправление одной поддерживаемой цели.
Проверить измерение бесплатным советником