Цели сайта и заявки в CRM не совпадают: как сверить данные и найти причину

Цель в аналитике и запись в CRM могут описывать разные действия. Нажатие кнопки «Отправить» ещё не подтверждает, что сервер сохранил обращение. Открытие мессенджера показывает намерение связаться, но само по себе не доказывает отправку сообщения. Если такие действия входят в общий отчёт о заявках, сравнение с CRM будет неоднозначным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Услуга студии «Аналитика и колл-трекинг» включает схему измерения, настройку целей и событий, проверку передачи данных из форм и звонков и отчёты для регулярного контроля. Глубина сверки с CRM зависит от доступных данных, возможностей выбранной системы и отдельно согласованного состава интеграций.

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