Если число заявок в CRM не совпадает с Метрикой, сначала сравните смысл показателей, период и каналы обращения. Затем проследите несколько заявок от отправки формы до записи в CRM. Равенство общих чисел не является самостоятельной целью: нужно понять, где измеряются разные действия, а где действительно теряются или повторяются обращения.
Убедитесь, что сравниваете одинаковые сущности
В CRM могут считаться созданные лиды, уникальные контакты или сделки на определённом этапе. В Метрике — достижения цели, целевые визиты или посетители. Одна заявка может привести к нескольким событиям, а один человек — обратиться повторно.
Справка Метрики о целях различает связанные с целью показатели, а описание отчёта по цели помогает проверить, какие данные выбраны. Запишите названия показателей, а не только слово «заявки» над двумя числами.
| Проверка | Метрика | CRM |
|---|---|---|
| Какое действие считается | Например, событие принятой формы | Например, создание нового лида по этой форме |
| Какая дата используется | Дата учитываемого события или визита | Дата создания записи, а не перехода в другой статус |
| Какие каналы включены | Нужный сайт и конкретная форма | Та же форма, без звонков и ручных записей |
| Что исключается | Выбранные сегменты и фильтры отчёта | Тесты, спам, повторы — по описанным правилам |
Возьмите небольшой период и сохраните исходные данные
Начните с периода, в котором можно разобрать отдельные обращения. Уточните часовые пояса и границы дат. Отдельно отметьте задержку передачи и момент выгрузки: запись могла попасть в CRM позже события на сайте.
Сохраните исходные выгрузки до исправлений. В рабочую таблицу не переносите лишние персональные данные: для сверки предпочтительнее внутренний идентификатор и техническое время. Не публикуйте файл с реальными заявками и не передавайте телефоны или почту в открытых ссылках и параметрах целей.
Проведите тестовое обращение по всей цепочке
Отправьте одну заявку с явной тестовой пометкой. Запишите время и проверьте последовательно: принял ли запрос сайт, появилось ли обращение у получателя, создалась ли запись в CRM и зафиксировалось ли ожидаемое событие аналитики.
Не ограничивайтесь появлением надписи «Спасибо». При ошибке интеграции интерфейс может показать успех, хотя следующий сервис не получил запись. И наоборот: CRM может принять заявку, когда браузерное событие аналитики не было отправлено или учтено.
Для JavaScript-целей момент вызова события определяется реализацией сайта; устройство такого события описано в документации Метрики. Разработчику нужно проверить, что именно вызывает сигнал: нажатие кнопки, начало отправки или подтверждённый ответ сервера.
Разложите расхождения по причинам
Условный пример. В отчёте 120 достижений цели, а в CRM — 95 записей. Разница 25 не доказывает потерю 25 клиентов. Допустим, проверка обнаружила 15 повторных сигналов одной и той же отправки, шесть тестовых обращений и четыре события до фактического принятия формы. Это разные причины и разные исправления. Такое разложение допустимо только после проверки, а не как объяснение по умолчанию.
| Наблюдение | Что проверить | Кому передать задачу |
|---|---|---|
| Одна запись и несколько событий | Повторное срабатывание, обновление страницы, несколько обработчиков | Разработчику и аналитику |
| Событие есть, записи нет | Момент срабатывания, ответ сервера, журнал интеграции | Разработчику формы и интеграции |
| Запись есть, события нет | Канал создания записи, работу счётчика и условия отправки события | Аналитику и разработчику |
| Запись появилась позже | Очередь передачи, повторную доставку, используемую дату | Ответственному за интеграцию |
Зафиксируйте правило сверки до исправлений
Для каждой проверяемой ситуации запишите ожидаемый результат. Например: одна успешно принятая форма создаёт одну запись с внутренним номером; повторная доставка того же запроса не создаёт вторую запись; ошибка отправки не выдаётся за успех. Каким именно будет сигнал аналитики, согласуйте отдельно.
Не объединяйте все обращения с одним телефоном без разбора: человек мог сделать два самостоятельных заказа. Идентификатор отправки, контакт и бизнес-сделка описывают разные объекты.
Повторите проверку после изменений
Проверьте обычную отправку, исправление ошибочно заполненного поля, повторное нажатие и недоступность получателя. Для каждого сценария сохраните наблюдение и ожидаемый результат. После этого сравните рабочий период по тем же определениям, которые использовали до исправления.
Итог отчёта — перечень объяснённых расхождений и оставшихся неизвестных. Часть различий может сохраняться из-за разных способов учёта; важно не спрятать под этой фразой проверяемую техническую ошибку.
Если проблема относится к правилам создания и обработки записей, полезен материал об автоматизации продаж с помощью CRM. Для помощи со сверкой и настройкой измерения смотрите подрядчиков по веб-аналитике.
Вопросы и ответы
Должно ли число заявок в CRM и Метрике совпадать точно?
Только если заранее согласовано, что обе системы считают одно и то же действие в одинаковых границах. Например, все достижения цели нельзя без уточнений сравнивать с уникальными сделками. Задача сверки — объяснить различия и обнаружить ошибки передачи, а не добиться равенства любых двух итоговых чисел.
Считать ли повторное обращение клиента дублем?
Не автоматически. Повторная доставка одной отправки и новая самостоятельная заявка одного человека — разные ситуации. Сопоставляйте идентификатор обращения, время и содержание запроса. Правило объединения согласуйте с продажами, чтобы вместе с техническими дублями не удалить реальные новые потребности.
Что передать разработчику, если причина расхождения не найдена?
Подготовьте время проверки с часовым поясом, адрес формы, идентификатор тестового обращения, описание ожидаемого результата и фактические наблюдения по каждому этапу. Добавьте настройки сравниваемых отчётов и сведения об ответе интеграции, если они доступны. Передавайте рабочие данные по согласованному каналу и не включайте в общедоступные материалы контакты реальных клиентов.
Подрядчики по теме статьи
Маркетинговые агентства — компании в каталоге PROMOmi.
