Первый инстинкт при расхождении цифр в отчётах - списать всё на «грязные данные» в CRM. Это удобное объяснение, и оно же часть проблемы: оно останавливает анализ там, где он должен начинаться. Данные не бывают просто «грязными». Они пропущены или искажены по конкретной причине, и пока эта причина не классифицирована, любая правка отчёта - это гадание, а не диагностика.
Три типа пропущенных данных
В статистике missing-data theory Рубина и Литтла (её популяризировал Карл Андерсон в «Creating a Data-Driven Organization») различает три причины, по которым данные отсутствуют или расходятся между системами.
MCAR (Missing Completely At Random) - пропуск случаен и не связан ни с одной переменной. Webhook между формой и CRM изредка обрывается по таймауту, и это не зависит от источника лида, суммы сделки или менеджера. Такой пропуск можно просто дополнить средним или проигнорировать - он не искажает картину.
MAR (Missing At Random) - пропуск связан с наблюдаемой переменной. Например, лиды с одного конкретного канала систематически приходят без UTM-меток, потому что на посадочной странице этого канала не настроен проброс параметров. Пропуск не случаен, но его причина видна и объяснима через другое поле.
MNAR (Missing Not At Random) - пропуск связан с самим значением, которое не попало в систему. Менеджеры реже фиксируют причину проигранной сделки, если проигрыш связан с их собственной ошибкой в работе с лидом. Здесь пропуск - это сигнал, а не шум, и именно его чаще всего принимают за «грязные данные», хотя на деле это устойчивая закономерность.
Что даёт классификация на практике
Классический пример: GA4 показывает 150 лидов за период, CRM - 180 за тот же период. Первая реакция - решить, что одна из систем «врёт». Метод MCAR/MAR/MNAR предлагает другой порядок действий: сначала определить тип расхождения, и только потом решать, какой цифре доверять.
Если расхождение стабильно повторяется из месяца в месяц и коррелирует с конкретным источником трафика - это MAR, и оно объяснимо ограничениями трекинга. Если расхождение скачет без видимой закономерности - это ближе к MCAR, и достаточно расширить окно атрибуции или починить техническую цепочку. Когда причина классифицирована, работающее правило простое: CRM - это точка отсчёта, потому что она фиксирует реального человека, а не событие в браузере. Подробнее о том, почему GA4 и CRM в принципе считают разные вещи, мы разбирали отдельно на примере расхождения по конверсиям.
Кейс Facebook Ads и Amplitude
Классификация особенно важна там, где на кону не десятки лидов, а решения о бюджете. В задокументированном кейсе Ignatenko attribution case study (2026) собственные данные о событиях в Facebook Ads и данные продуктовой аналитики Amplitude расходились на 50-70% в худших сценариях - разные окна атрибуции, разное определение «события», разная обработка кросс-девайсных сессий.
Решение в этом кейсе не сводилось к выбору «более честной» платформы. Команда построила таблицу сверки на уровне источников: документ, где для каждой пары систем зафиксировано, что именно каждая из них считает событием, и в каких пределах расхождение ожидаемо. Это заменило практику доверять цифре из интерфейса одной системы в изоляции - решения по бюджету принимались только после сверки через эту таблицу.
Гигиена данных - это процесс, а не проект
Большинство B2B-команд обращаются с качеством данных CRM как с разовой задачей: нанять подрядчика, почистить дубли, объединить контакты, закрыть тикет. Через два-три месяца расхождения возвращаются, потому что причина не устранена - устранены были только её симптомы на конкретную дату.
Источники расхождений не статичны. Новый источник трафика без UTM, новый менеджер, который иначе заполняет поля, новая интеграция, которая переносит время синхронизации вместо времени события, - каждое такое изменение создаёт новый тип пропуска. Разовая чистка данных решает проблему на момент чистки и не решает процесс, который эту проблему производит.
Что делать вместо разовой чистки
Три практических шага, которые превращают гигиену данных в процесс. Первый: для каждого повторяющегося расхождения в отчётах фиксировать его тип - MCAR, MAR или MNAR - прежде чем что-либо исправлять руками. Второй: вести таблицу сверки между CRM и каждой внешней системой, которая поставляет данные в отчётность, - что считается событием в каждой системе и какой процент расхождения ожидаем. Третий: назначить владельца этого процесса на постоянной основе, а не привлекать его точечно перед советом директоров.
Отчёт, который не сходится, - это не повод исправить число. Это повод определить, к какому из трёх типов относится причина расхождения, и только потом решать, что с этим делать.