Почему количество целей отличается от количества заявок

Согласуйте предмет сравнения

В одном отчёте может быть число достижений цели, в другом — визиты с целью, а в CRM — уникальные обращения после объединения дублей. Эти значения не обязаны совпадать. Запишите название каждого показателя, правила включения, период и часовой пояс. Уточните, считаются ли тесты, спам, удалённые и объединённые записи.

Также проверьте состав каналов. В CRM могут поступать звонки и письма, которых нет в выбранной цели формы. Один заказ может создавать несколько внутренних сущностей. До поиска технического сбоя составьте схему соответствия. Иначе команда будет исправлять нормальную разницу определений вместо реальной потери данных.

Пройдите цепочку по этапам

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

Проверьте момент вызова цели

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

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

Учебный пример завышенной цели

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

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

Сопоставляйте безопасные идентификаторы

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

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

Завершите разбор контрольным протоколом

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

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

Почему разница в восемь не означает восемь лишних заявок

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

Бизнес-записей получается 80 + 20 = 100. Уникальных наблюдаемых операций — 80 + 10 = 90, а с повторами — 108 вызовов. Разность 108 − 100 = 8 скрывала одновременно повторы, ненаблюдаемые заявки и события без найденной записи. Удаление восьми строк не исправит эту картину.

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

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

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