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

Представим отчёт за месяц. Рекламный кабинет показывает 50 заявок. В CRM нашлось 38 карточек из того же источника. Маркетолог считает стоимость обращения по первой цифре, коммерческий директор по второй. Оба отчёта выглядят правдоподобно, но отвечают на разные вопросы.

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

Сначала определите, что именно считает каждая система

Слово «заявка» часто скрывает несколько разных событий:

• рекламный кабинет получил сигнал о выполнении цели;
• веб-аналитика зафиксировала отправку формы, звонок или сообщение;
• CRM создала лид, контакт или сделку;
• менеджер подтвердил, что обращение соответствует критериям компании;
• клиент подписал договор или оплатил счёт.

Пять событий описывают один маршрут, но не обязаны давать одинаковые суммы. Форма может отправиться дважды. Один контакт может создать несколько обращений. Менеджер может объединить дубли или отклонить спам. Часть клиентов звонит после нескольких визитов и меняет устройство.

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

Почему цифры расходятся

Системы по-разному определяют конверсию

Рекламная платформа применяет свою модель и окно атрибуции. Веб-аналитика использует собственные правила. CRM чаще показывает дату создания карточки и источник, записанный интеграцией или сотрудником.

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

В цепочке нет общего идентификатора

Для построчной сверки недостаточно подписи «Яндекс Директ» в поле источника. Нужна связка идентификаторов: UTM-метки, ClientID веб-аналитики, идентификатор обращения и ID записи в CRM.

В официальной документации Яндекс Метрики сквозная аналитика строится на четырёх действиях: разметить объявления UTM-метками, загрузить расходы, сохранить ClientID в CRM и передать в Метрику данные о клиентах и заказах [1]. Если ClientID исчезает между формой и CRM, позднюю сделку уже нельзя надёжно связать с исходным визитом.

Интеграция теряет или задерживает обращения

Форма сработала, но карточка не появилась. Причиной может быть изменение названия поля, ошибка сценария автоматизации, недоступность API или очередь повторной отправки.

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

Дубли обрабатываются по-разному

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

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

Источник меняется вручную

Менеджер создал карточку после звонка и выбрал ближайший источник из списка. Интеграция записала кампанию в свободное текстовое поле. В одном месяце появились варианты «Директ», «Яндекс», yandex/cpc и «контекст».

Для человека это один канал. Для отчёта это четыре разных значения. Справочник источников и автоматическая запись меток уменьшают расхождение, но старые данные всё равно придётся нормализовать.

Первичная сверка за один час

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

1. Выберите один узкий участок

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

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

2. Зафиксируйте определения

Запишите рядом три формулировки:

• что рекламный кабинет называет конверсией;
• какое событие веб-аналитика считает обращением;
• в какой момент CRM создаёт новую запись.

Если определения различаются, сравнивать итоговые суммы напрямую нельзя. Сначала приведите события к одному уровню воронки.

3. Выгрузите записи для построчного сравнения

Для каждой записи соберите доступные поля:

• дату и время события с часовым поясом;
• источник, кампанию и UTM-метки;
• ClientID или другой технический идентификатор;
• обезличенный идентификатор контакта;
• ID карточки CRM;
• статус квалификации и сделки.

Контактные данные для сверки не нужны. Телефон и email можно заменить устойчивым хешем или внутренним ID до передачи файла аналитику.

4. Сопоставьте записи

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

Каждой несопоставленной записи присвойте одну причину:

• дубль;
• задержка передачи;
• потеря идентификатора;
• техническая ошибка;
• другое определение события;
• ручное изменение источника;
• причина пока не установлена.

Так итог «не сходится на 12 заявок» превращается в список задач с владельцами.

5. Проверьте направление разрыва

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

Если обе записи существуют, но кампании различаются, сравните модель атрибуции, окно, часовые пояса и правила перезаписи источника.

Шаблон таблицы для сверки

Суммарный отчёт стройте после построчной проверки. В нём полезно разделить три перехода:

1. рекламный кабинет → подтверждённое обращение на сайте или в телефонии;
2. обращение → карточка в CRM;
3. карточка → квалифицированная сделка и деньги.

Каждый переход ломается по своим причинам. Один общий процент скрывает место потери.

Как понять, требует ли расхождение вмешательства

Универсального допустимого процента для пары «рекламный кабинет — CRM» нет. Результат зависит от каналов обращения, длины цикла, правил дедупликации и выбранной модели атрибуции.

Соберите собственную базовую линию за несколько сопоставимых периодов. Проверка нужна, когда:

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

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

Где ИИ ускоряет сверку

ИИ полезен после того, как команда определила события и ключи сопоставления. Он сокращает ручную работу с таблицами. Идентификаторы и правила атрибуции по-прежнему задаёт команда.

Разбор обезличенных выгрузок

ИИ-ассистент с анализом файлов может сравнить выгрузки, сгруппировать несопоставленные строки по признакам и найти дни с необычным ростом потерь. Для разовой проверки подойдут ChatGPT или Claude с обезличенным CSV. В корпоративном контуре ту же задачу можно поручить внутреннему агенту, который получает только разрешённые поля.

Рабочий запрос к ассистенту:

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

Поиск аномалий

ИИ может каждый день проверять долю записей без источника, неожиданные изменения названий кампаний и всплески несопоставленных обращений. Алерт должен содержать строки, на которых основан вывод. Сообщения вида «обнаружена аномалия» без примеров не помогают исправить систему.

Подготовка запросов и правил очистки

Ассистент поможет написать SQL-запрос, формулу для таблицы или правило нормализации источников. Специалист проверяет результат на копии данных и только после этого переносит правило в рабочий процесс.

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

Как перейти от ручной сверки к системе

Регулярный контроль строится в четыре слоя:

1. Единые идентификаторы проходят от рекламного визита до CRM.
2. Интеграция хранит необработанные события и журнал ошибок.
3. Ежедневная сверка сопоставляет записи по фиксированным правилам.
4. Алерт сообщает о новом отклонении относительно базовой линии компании.

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

[1] Сквозная аналитика — Яндекс Метрика: официальная документация описывает разметку рекламных ссылок UTM-метками, загрузку расходов, сохранение ClientID в CRM и передачу данных о клиентах и заказах обратно в Метрику. Состав интерфейсов и доступные способы интеграции нужно проверять перед внедрением.