
Конверсия показывает событие, которое выбрано в настройках
Если в Метрике есть достижение цели, а менеджер не получил обращения, сначала проверяю смысл этой цели. Клик по кнопке, попытка отправить форму, успешная обработка данных и запись в CRM отвечают на разные вопросы. Название «Заявка» само по себе не делает событие подтверждением получения контактов.
Я разделяю проверку на две части: что именно посчитал счётчик и что произошло с обращением после действия посетителя. Это помогает не искать проблему в рекламе, когда причина находится в измерении или доставке. Ниже разбираю учёт; подробный маршрут получения данных описан отдельно в статье заявка с Tilda не дошла.
Проверяю условие цели, а не только её название
Открываю настройки конкретной цели и выясняю, чем она запускается. Это может быть посещение страницы, нажатие кнопки, автоматическое отслеживание формы или событие, которое отправляет код сайта. Затем сопоставляю настройку с действием на странице.
Если цель привязана к кнопке «Рассчитать», она может фиксировать открытие окна с формой. Посетитель ещё ничего не отправил. Если условие связано со страницей благодарности, отдельно проверяю, доступна ли она без отправки и не засчитывается ли её повторное открытие. Это сценарии для проверки, а не утверждение, что любая такая цель настроена неправильно.
В справке Яндекса целевое событие описано как способ передать выбранное действие через reachGoal. Сервис получает событие, предусмотренное разработчиком. Я проверяю место вызова: иначе одинаковые названия целей на двух сайтах могут означать совершенно разные действия.
Развожу клик, попытку отправки и успешную обработку
Для управленческого отчёта полезно заранее договориться о значении каждого этапа. Я составляю короткую карту событий и проверяю её на работающей странице.
| Этап | Что он подтверждает | Чего ещё не подтверждает |
|---|---|---|
| Открытие формы | Посетитель начал сценарий | Контакты введены и отправлены |
| Нажатие отправки | Пользователь попытался продолжить | Поля прошли проверку, сервер принял данные |
| Успешный ответ обработчика | Обработчик сообщил об успехе | Менеджер увидел обращение и связался с клиентом |
| Запись в CRM или получение данных | Обращение найдено у получателя | Контакт целевой и готов обсуждать заказ |
| Квалификация обращения | Сотрудник оценил обращение по правилам бизнеса | Сделка завершена и оплачена |
В документации автоматической цели отправки формы Яндекс отдельно предупреждает о валидации: безуспешная попытка также может попасть в достижения. Поэтому я не считаю наличие стандартной цели достаточной проверкой. Для собственного обработчика выбираю событие после подтверждённого результата и проверяю, что означает его успешный ответ.

Ищу повторные события и пересечения целей
Одно обращение может отразиться в нескольких целях: общей отправке, отправке конкретной формы и открытии страницы благодарности. Такая детализация удобна для диагностики. Но сумма этих достижений не равна числу разных обращений.
Я проверяю, не отправляет ли одно событие одновременно код страницы и диспетчер тегов, нет ли повторной подписки на обработчик и что происходит при двойном нажатии. Если пользователь возвращается к форме, выясняю, действительно ли он создал новое обращение. Повторное действие нельзя автоматически объявлять ни ошибкой, ни новым клиентом.
В итоговом отчёте выбираю одну согласованную основную цель. Детализацию форм использую для разбора, не прибавляя её к общей цели. Если бизнесу нужны уникальные обращения, сверяю их с записями получателя по внутреннему идентификатору, а не пытаюсь получить это число сложением всех конверсий.
Сверяю отчёт и журнал обращений на одинаковых условиях
Перед сравнением записываю период, часовой пояс, счётчик, цель и источник трафика. Обращение поздно вечером может оказаться на соседней дате в системе с другим часовым поясом. Отчёт по всем посещениям также нельзя напрямую сравнить с выборкой только из рекламы.
Отдельно уточняю, сравниваю ли число достижений, визитов с целью или записи в CRM. Это разные единицы учёта. Если Метрика показывает несколько событий, а в CRM найдено одно обращение, сначала проверяю эту разницу в определениях и только затем делаю вывод о сбое.
Для локальной сверки сохраняю минимально необходимую информацию: время, страницу, форму, технический идентификатор и результат получения. Не переношу телефон или почту посетителя в публичные отчёты, адрес страницы или параметры аналитики. Скриншот с личными данными клиента тоже не нужен для объяснения общей причины.

Учитываю ограничения измерения
Если аналитика включается только после согласия на cookie, часть реальных отправок может отсутствовать в счётчике. На измерение также могут влиять блокировщики и ошибки загрузки скрипта. Поэтому отсутствие достижения цели не доказывает отсутствие обращения, а точное совпадение всех систем не является обязательным условием работы формы.
Я фиксирую дату изменения способа измерения. Например, после введения согласия сравнение с прежним периодом требует оговорки: изменился охват аналитики, а не обязательно число посетителей или спрос. Если данных недостаточно, сохраняю это ограничение вместо объяснения снижения случайной причиной.
Проверяю один сценарий от начала до конца
После чтения настроек провожу согласованную контрольную проверку конкретной формы. Использую отмеченные тестовые данные, сохраняю время и сверяю результат в аналитике и у получателя. Настоящие обращения посетителей не заменяю собственными повторными отправками.
Проверка полезна, если позволяет ответить на четыре вопроса: какое действие произошло, какой код отработал, где появились данные и как событие отражено в отчёте. Если цель сработала раньше успешного результата, исправляю условие. Если событие соответствует результату обработчика, но данные потерялись дальше, разбираю доставку отдельно.
Для нового проекта я могу разработать многостраничный сайт, предусмотрев понятные формы и события аналитики. На существующем сайте сначала выясняю текущую схему. Другие причины отсутствия обращений рассматриваю в материале посетители есть, заявок нет.
Частые вопросы
Цель на клик нужно обязательно удалить?
Нет. Клик полезен как промежуточное действие, если он так и назван. Я не выдаю его за полученную заявку и отделяю от основной цели отчёта.
Можно ли по одной цели оценить качество рекламы?
Достижение выбранного действия помогает анализировать воронку. Для оценки качества обращений нужны также данные о получении и разборе запросов. Целевой клиент и техническое событие не являются одной величиной.
Нужно ли сразу переделывать форму?
Сначала проверяю условие цели, обработчик и доставку. Если ошибается только измерение, замена внешнего вида формы не решит проблему. Объём доработки выбираю по найденной причине.

