Сначала договоритесь о значении слова «заявка»

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

Для каждого этапа нужны отдельные вопросы. Сработала ли проверка полей? Принял ли сервер данные? Сохранил ли обращение? Передал ли его в CRM? Было ли отправлено событие аналитики? Форма может показать сообщение об успехе до завершения обмена, а счётчик — зарегистрировать попытку ещё до проверки корректности данных.

В Метрике поведение цели отправки формы зависит от реализации; документация отдельно предупреждает об учёте неуспешных попыток при определённых условиях. Поэтому наличие цели не подтверждает её соответствие бизнес-событию. Справка об отслеживании формы.

Сравните одинаковые множества

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

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

Счётчики также могут получать неодинаковый объём данных из-за установки кода, блокировщиков или незавершённой загрузки. Следовательно, расхождение двух систем ещё не доказывает неисправность одной из них. Вопросы по отчётам Метрики.

Практический чек-лист

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

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

Гипотетический пример

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

Но тот же итог 12 и 8 мог бы возникнуть при четырёх ошибках интеграции. Поэтому арифметическое совпадение найденных случаев полезно только вместе с сопоставлением конкретных событий и записей.

Что останется неизвестным

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