Содержание 6 разделов
В отчёте Метрики есть достижения целей, реклама показывает результаты, а в CRM и у сотрудника, который отвечает на обращения, заметно тише. Я начинаю с вопроса: какое действие здесь назвали заявкой? Пока мы не знаем условие срабатывания цели, сравнивать её цифру с количеством обращений рано.
За названием «Заявка» может стоять открытие формы, нажатие «Отправить» или сохранение обращения. Я покажу, как проверить цели в Яндекс Метрике и найти расхождение. Для основной проверки нужны доступ к целям и человек, который видит поступившие заявки; писать код не понадобится.
Сначала выясняю, что считается результатом
После клика по телефону человек может закрыть приложение и не позвонить. Переход в мессенджер тоже не подтверждает отправку сообщения. Эти действия показывают интерес; факт разговора нужно проверять в соответствующем канале.
У формы свои этапы: открытие, попытка отправки, обработка данных, сохранение обращения. Продажа происходит после работы с клиентом. Для цели «Заявка принята» я предлагаю считать результатом сохранённое обращение в принимающей системе — например, в админке сайта или непосредственно в CRM.
В отчёте «Конверсии» различайте показатели. Достижения цели — сколько раз выполнено её условие. Целевые визиты — визиты хотя бы с одним достижением. Конверсия по визитам — доля таких визитов среди всех визитов выбранного отчёта. Несколько достижений могут относиться к одному визиту; визит не равен отдельному клиенту.
Учебный пример: посетитель открыл форму, ошибся в телефоне, исправил его и отправил обращение. Разные цели могут учитывать открытие, нажатие и сохранение. Несколько целей на этапах — нормальная воронка. Ошибка — складывать их достижения и выдавать сумму за количество уникальных обращений.
Почему цели и обращения расходятся
Сначала проверяю, не срабатывает ли цель слишком рано. Кнопка «Оставить заявку» может только раскрывать форму. Цель на эту кнопку учитывает открытие; название «Готовая заявка» не добавляет к нажатию сохранённых данных.
Тип цели «Отправка формы» в зависимости от реализации может учитывать нажатие и безуспешную попытку с невалидными полями. Проверьте конкретную форму с ошибками. Требования этого типа к HTML-форме и стандартной отправке не относятся ко всем способам передачи событий. Для цели «Целевое событие» важен момент вызова в коде.
Автоматическая цель тоже требует расшифровки: «Автоцель: Заявка» может относиться к нажатию кнопки. Я смотрю тип и условие, а при необходимости прошу специалиста показать, какое действие их выполняет.
Дубли целей Метрики разбираю по двум направлениям. Событие может повторно вызываться кодом: обработчик подключили несколько раз или отправку дублирует система управления тегами. Другой вариант — одно обращение достигает разных целей, которые ошибочно суммируют. Это разные причины; не каждый повторный вызов обязательно станет отдельным достижением в отчёте.
Если условие цели — посещение страницы благодарности, повторное открытие или обновление может снова выполнить условие без новой заявки. Просмотр страницы «Спасибо» нужно отдельно связать с новым сохранением.
УвеличитьНа схеме первичная запись хранится на сайте. Если она есть в админке, но отсутствует в CRM, проверяю передачу между системами. Если сотрудник не получил уведомления — его доставку. Счётчик наблюдает выбранный этап и не должен участвовать в доставке заявки.
Подробный разбор уведомлений я вынес в статью «Почему с сайта не приходят заявки на почту».
Если записи есть, но контакты оказываются бесполезными, посмотрите, как разобраться со спам-заявками. Сам факт сохранения обращения не гарантирует его качество.
Бывает наоборот: обращение есть, а события нет. Счётчик мог быть заблокирован, не загрузиться или не получить разрешения на запуск. Цель может охватывать только часть форм. Форма должна сохранять обращение независимо от аналитики; отсутствие события не доказывает потерю заявки.
Как проверить, работает ли цель в Метрике
Начните с одной формы и одной цели. Договоритесь с ответственным за обращения, где искать результат и как отличить контрольную запись от клиентской.
- В нужном счётчике откройте «Цели». Запишите название, ID, тип и условие выбранной цели. Для события из кода уточните момент вызова. Проверьте, охватывает цель эту форму или все формы сайта.
- Согласуйте контрольную отправку. Лучше использовать тестовую среду и счётчик. На рабочем сайте заранее договоритесь о пометке теста и его учёте; используйте свои контакты.
- Запишите адрес страницы, форму, время с часовым поясом и сценарий. Учебный образец: «Форма внизу страницы услуги, 15:20 МСК, неверный email, затем исправление».
- Выполните сценарий из таблицы. Сопоставьте событие выбранной цели с записью в системе приёма обращений. После успешной отправки найдите время и идентификатор записи, а не только надпись «Спасибо».
- Отдельно проверьте формирование и доставку уведомления сотруднику. В отчёте «Конверсии» дождитесь обработки данных: мгновенно пустой отчёт — ещё не окончательный ответ.
На телефоне сдвиньте таблицу влево, чтобы увидеть, где проверить результат. С клавиатуры: фокус на таблице и стрелки.
| Действие | Ожидаемый результат для цели | Где проверить |
|---|---|---|
| Открыть форму | Не достигается. | Событие цели; новых записей в системе приёма нет. |
| Отправить невалидные данные | Не достигается. | Ошибка у поля; новой записи нет. |
| Успешно отправить форму | Одно событие после подтверждения сохранения. | Запись в админке или CRM; затем событие цели. |
| Повторно нажать «Отправить» для той же заявки | Нет нового события без нового обращения. | Число записей и их ID; повторные вызовы события. |
| Снова открыть страницу благодарности | Не достигается без нового сохранения. | Новых записей и событий «Заявка принята» нет. |
| Ошибка сервера при сохранении — специалист, тестовая среда | Не достигается, если обращение не сохранено. | Тестовая система приёма, ответ сервера и журнал событий. |
Таблица описывает именно цель «Заявка принята». У «Открытия формы» первая строка будет другой. Повторное нажатие проверяют для той же операции; новое самостоятельное обращение — отдельный результат.
Серверную ошибку проверяет разработчик в тестовой среде, без отключения рабочей базы. Отдельный сценарий: запись сохранена, но ответ браузеру потерян. Повтор запроса не должен создавать дубль обращения.
Дополнительно для специалиста: отладчик и повторные вызовы
Параметр _ym_debug=2 в адресе страницы включает панель отладки для нового кода счётчика; альтернативный способ — консоль с _ym_debug=1. По Events и Console специалист сверяет счётчик и событие. Отладчик не исключает визит из статистики: среду и счётчик выбирают заранее.
Нужно найти вызовы reachGoal, проверить обработчики и систему управления тегами, сопоставить событие с сохранённой записью. Несколько строк консоли не равны нескольким учтённым достижениям. Отладчик проверяет аналитику; заявку подтверждает принимающая система.
Сверяю одинаковые данные
Затем возвращаюсь к общему отчёту. Сравнивайте один период и часовой пояс, одинаковые формы и источники. В CRM может быть весь поток, а в Метрике — рекламный сегмент. Дата создания сделки тоже может отличаться от даты отправки формы.
Проверьте фильтры, исключение собственных посещений и скрытые записи CRM. Уточните, считает система обращения или объединяет их в контакт. Я не ожидаю совпадения всех отчётов до единицы: полезнее найти объяснимую связь и конкретный участок расхождения.
Что менять после проверки
Для цели «Заявка принята» событие должно соответствовать подтверждённому сохранению в используемой системе. Если первичная запись в админке — её сохранению; передачу в CRM отслеживают дальше. Если принимает непосредственно CRM — её подтверждению. Почтовое уведомление остаётся отдельным этапом.
Событие не должно зависеть от повторного открытия страницы благодарности. Разработчик проверяет защиту от повторной обработки отправки. Промежуточные цели можно оставить: они показывают, где человек остановился. Их сумма не равна уникальным обращениям.
Не удаляйте массово старые и автоматические цели. Сохраните настройки и проверьте со специалистом, какие цели участвуют в оптимизации рекламы, отчётах и интеграциях. Согласуйте новую цель, контрольный период и дату перехода. Изменение условия не исправит старую статистику задним числом.
Перед запуском рекламы пригодится общая проверка перед рекламой. Публичная диагностика сайта не подтверждает закрытые настройки Метрики, записи CRM и доставку писем: нужна отдельная проверка с доступом к этим системам.
Что передать разработчику или специалисту по рекламе
Вместо «Метрика считает лишние заявки» я предлагаю отправить короткое описание проверяемого расхождения:
- Адрес страницы и какая именно форма проверялась.
- Название и ID цели, её тип и ожидаемое действие: например, сохранение обращения в админке.
- Время контрольной проверки с часовым поясом и выполненный сценарий.
- Что наблюдалось: цель сработала или нет, появилась ли запись, дошло ли уведомление. Если есть снимок, скройте клиентские данные.
Пароли и персональные данные клиентов не нужны. Разработчик сможет проверить код и журнал, рекламный специалист — использование цели и смысл показателя.
Если нужна помощь, напишите через форму обращения — я помогу проверить цели и путь заявки от формы до системы приёма обращений.
