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

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

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

Составьте паспорт проверяемой цели

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

В учебном паспорте цель lead_accepted означает: приложение подтвердило сохранение новой заявки на сайте. Она не означает поступление денег и не гарантирует обработку менеджером. Проверка доставки заявки в CRM относится к другой границе процесса.

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

Подготовьте среду, в которой тест наблюдаем

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

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

В официальной инструкции проверки целей используется параметр _ym_debug=2. Панель предназначена для нового кода счётчика; для прежнего кода описан режим _ym_debug=1 с консолью. Если действует исключение собственных визитов, инструкция рекомендует приватный режим. При этом дополнительно проверьте, что сам браузер в выбранном режиме не блокирует счётчик.

https://example.com/service/?_ym_debug=2

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

Проверьте три слоя отдельно

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

Успех одного слоя не заменяет остальные. Заявка способна сохраниться при заблокированной аналитике. Событие может отправиться до ошибки сервера. Событие в отладчике может не совпасть с условием цели. Именно такое разделение позволяет локализовать дефект вместо бесконечного «переустановите Метрику».

Для программной цели проверьте тип «Целевое событие» и условие идентификатора. Точное совпадение предпочтительнее слишком широкого условия «содержит», если измеряется один конкретный исход. Название lead не должно случайно охватить одновременно lead_error и lead_accepted.

Минимальная матрица для заявки

• Корректная отправка. Одна новая заявка сохранена; ожидается одно логическое достижение успеха.
• Ошибка обязательного поля. Заявки нет; цель успеха отсутствует, даже если кнопка была нажата.
• Отказ сервера. Интерфейс показывает ошибку; цель успеха отсутствует.
• Неопределённый сетевой результат. Сначала выясняется состояние операции, затем проверяется правило события; тайм-аут сам по себе не означает ни успеха, ни отказа.
• Повторное нажатие и обновление страницы. Для той же принятой операции нового достижения успеха не возникает по правилам проекта.
• Вторая самостоятельная заявка. Законное новое обращение учитывается; защита от повторов не блокирует все дальнейшие обращения посетителя.
• Другой путь. Отправка клавишей Enter, мобильная форма и модальное окно измеряются по одному смысловому правилу.

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

Для других типов цели меняется доказательство

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

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

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

Как разбирать типичные расхождения

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

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

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

Что считать принятой настройкой

Цель принимается, когда совпали её смысл, точка вызова и результат во всех согласованных положительных и отрицательных сценариях. Неразрешённые ограничения перечислены явно: например, часть браузеров блокирует аналитику, а подтверждение заявки в CRM измеряется отдельно.

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