Почему данные Метрики, CRM и кассы не сходятся
Данные Метрики, CRM и кассы не сходятся почти всегда, и это чаще всего не поломка. Метрика считает визиты браузеров, CRM считает карточки, которые кто-то завёл, касса считает деньги, которые реально пришли. Три разных прибора меряют три разные величины в три разных момента времени, и точное совпадение у них было бы случайностью.
Правильный вопрос не «сходятся ли цифры», а «объяснимо ли расхождение». У нормального расхождения есть имя и размер: столько-то обращений было по телефону, столько-то записей перенесли на следующий месяц. Чинить надо не разницу, а незнание о её причине.
Почему не сходятся данные Метрики и CRM: три причины
Разные приборы. Счётчик на сайте (у большинства это Метрика) видит только то, что открыли в браузере: человека, который позвонил по номеру с вывески или пришёл по рекомендации, там нет вовсе. CRM видит то, что в неё завели руками или роботом, касса - только состоявшиеся оплаты. Прежде чем сравнивать два числа, надо понять, какой прибор вообще должен был увидеть это событие.
Разные периоды. Человек зашёл на сайт 31 марта, записался 2 апреля, оплатил 10 апреля - и попал в три разных отчётных месяца. Реклама списала деньги в марте, выручка встала в апреле, и апрельская окупаемость выглядит подозрительно хорошей. Добавляют разницы часовые пояса: источники отдают время по-своему, и ночные события уезжают на сутки.
Разные определения. «Заявка» у маркетолога - отправка формы, у администратора - человек, с которым поговорили, у собственника - тот, кто дошёл. Половина расхождений лечится не кодом, а одной страницей, где записано, что считается обращением.
Визит, обращение, запись и оплата - это четыре разных числа
Эти четыре слова в разговоре подменяют друг друга, а в отчёте обязаны стоять отдельно четырьмя числами. Визит - факт посещения сайта, обращение - звонок, форма или сообщение, запись - место в расписании, оплата - деньги в кассе. Между соседними шагами есть конверсия, между дальними её нет: в числителе и знаменателе окажутся разные люди.
Порядок расчёта на условных числах (это пример, а не результат клиента):
- Счётчик за месяц: 4 000 визитов.
- Обращений 300: 120 форм с сайта, 140 звонков, 40 сообщений в мессенджерах.
- Склейка по номеру телефона и дню: 300 обращений сделали 265 человек, часть написала и потом позвонила.
- Записей в системе учёта: 180.
- Дошли и оплатили: 150 человек, касса 900 000 ₽.
- Сумма сделок в CRM за тот же месяц: 1 050 000 ₽.
Последние два числа расходятся на 150 000 ₽, и это норма. Сумма в карточке сделки - намерение, а не деньги: сделку могли выиграть, а человек не дошёл или купил другое. Держать их надо двумя строками рядом - номинал в CRM и подтверждённое кассой, - а не выбирать, какая из них настоящая.
Делить 180 записей на 4 000 визитов нельзя: больше половины обращений пришло не с сайта. Если у вас есть онлайн-запись, через которую люди записываются сами, минуя администратора, то и конверсия обращений в записи станет выдумкой. Две дорожки, которые не вложены друг в друга, ведут рядом и не делят одну на другую.
Горизонт данных: с какого дня выгрузке вообще можно верить
При подключении система забирает историю настолько глубоко, насколько её отдаёт сам сервис. У систем записи это обычно годы, у телефонии - месяцы, у мессенджеров нередко только то, что пришло после подключения. Данные, которых источник не отдал, дозагрузить позже нельзя: у него их уже нет.
У самой выгрузки тоже есть окно. Первый импорт берёт не всё, а последние месяцы: по умолчанию у нас это полгода по сделкам CRM, полтора месяца по записям и месяц по рекламным расходам. Глубину можно задать больше, но выше потолка самого сервиса не прыгнешь. До этой даты данных не мало, их нет вообще: график, уходящий левее, показывает пустоту, а не спад.
Практическое правило: у отчёта должна быть записана дата, раньше которой сравнивать нечего. У каждого источника она своя, поэтому и записывать её надо отдельно по каждому.
Дыры в синхронизации: почему всплеск в прошлом году это окно выгрузки, а не рост
На графике за прошлый год виден резкий подъём, и его принимают за сезонность или результат кампании. На деле подъём стоит ровно на границе окна первой выгрузки: слева данных нет, справа есть. Проверяется за минуту - если рост приходится на дату подключения, это артефакт импорта.
Второй вид дыр опаснее: источник замолкает посреди работы. Телефония перестала слать события, истёк токен, сотрудник отозвал доступ, оператор приостановил услугу за неоплату. В отчёте это выглядит не как ошибка, а как красивый ноль или скромное снижение - тихая цифра, под которой нет ни одной записи.
Догнать такую дыру задним числом обычно нечем: если интеграция умеет только принимать события в момент появления, историю за время молчания сервис уже не отдаст.
Ловятся дыры двумя проверками: возраст последних данных по каждому источнику и правдоподобность цифр. Ноль пропущенных звонков при двух сотнях входящих - не заслуга администраторов, а признак того, что события о неотвеченных до системы не доезжают.
Дубли: одна запись в системе учёта и две карточки сделки
Первый вид: одно событие приезжает двумя путями. Звонок приходит и от телефонии, и заметкой из CRM, идентификаторы у источников разные, уникальный индекс такую пару не ловит. Мы склеиваем такую пару по последним десяти цифрам номера и окну в две минуты. На одном подключении таких пар нашлось 177, и каждая вдобавок расшифровывалась дважды: двойной счёт в отчёте и двойной расход на расшифровку.
Второй: одна беседа двумя строками. Из CRM приезжает факт разговора с привязкой к сделке, тексты приходят от другого сервиса, общего идентификатора между ними нет. Удалять дубль нельзя, у него бывает связь со сделкой, которой нет у текстовой строки; правильное решение - пометить, чей он дубль, и не считать второй раз.
Третий: одна запись в системе учёта превращается в несколько карточек сделки. Робот-интеграция заводит карточку на каждое событие, и одна запись тянет за собой две-три сделки, а в самом тяжёлом случае мы видели шесть. Считать надо по первоисточнику: одна запись в расписании это одна единица, сколько бы карточек она ни породила в CRM.
Четвёртый: один человек двумя карточками клиента. Ключ личности - нормализованный номер телефона, и только он: по имени склеивать нельзя, два разных Ивана Иванова станут одним. Мусор вроде «12345» не должен превращаться в номер, иначе два таких значения совпадут и сольют разных людей в одного.
Порядок расчёта на условных числах (пример, не результат клиента):
- В отчёте 300 обращений и 180 записей. Конверсия: 180 ÷ 300 = 60 %.
- Схлопнули звонки и сообщения одного человека за день: обращений стало 265.
- Убрали дубли карточек по одной записи: минус 20 строк, остаётся 245.
- Конверсия: 180 ÷ 245 = 73 %.
Тринадцать процентных пунктов ниоткуда - это и есть цена дублей. Пока они не вычищены, сравнение месяцев меряет качество синхронизации, а не работу людей.
Доля клиентов без источника и как её честно показывать в отчёте
Часть клиентов всегда останется без источника: человек позвонил по номеру с вывески, пришёл по рекомендации, набрал название в поиске и зашёл напрямую. Отдельная и самая частая причина - клиент был у вас ещё до подключения системы. Его визиты и деньги видны, а то, как он когда-то пришёл, не восстановить.
Главное правило здесь одно: не подменять незнание именем системы, через которую приехал сигнал. Если записать в источник «сайт», «телефония» или название CRM, в отчёте появится несуществующий канал, по которому нельзя принять ни одного решения. Честный ответ - строка «не определён» с числом, и стоять она должна в таблице каналов наравне с остальными.
Раскидывать неизвестные визиты по каналам пропорционально известным тоже нельзя, хотя так таблица выглядит полной. Это умножение догадки: каналы с хорошей разметкой получают чужие заслуги и растут в отчёте быстрее, чем в жизни.
Долю надо показывать рядом с каждым отчётом об окупаемости: источник известен у стольких-то процентов выручки. Два отчёта с разной долей неизвестного между собой несравнимы.
Требовать нуля тоже не стоит: сарафанное радио и офлайн машинным сигналом не подтвердить, а лампу, которую нечем погасить, перестают читать. Долю уменьшают метки на всех ссылках, отдельные номера для рекламных каналов и привычка спрашивать, откуда человек про вас узнал.
Почему прочерк с объяснением лучше красивого числа
Пустая ячейка без пояснения читается как поломка, и владелец идёт чинить не то. У каждого прочерка должна быть причина, написанная словами: текста нет, потому что источник не отдал сообщения; расход нулевой, потому что кампания работает по оплате за конверсию и конверсий в этот день не было.
Три причины нулевого расхода путать особенно опасно. Первая - расхода действительно не было. Вторая - расход был, но данные не приехали. Третья - расход есть, но вносится вручную, и за этот период его не внесли. В отчёте это три разных сообщения, а не один ноль.
То же с пропущенными звонками. Сказать «не дозвонились» можно только по прямому признаку от телефонии: занято, не ответили, сброс. Если длительность просто не приехала, честнее написать, что разговор мог быть и мы про него не знаем. Между «этого не было» и «мы этого не видим» - пропасть.
Как устроить недельную сверку, чтобы расхождения ловились сами
Сверку делают по закрытой неделе, а не по текущей: данные приезжают порциями, и последние сутки всегда неполные. Порядок из семи шагов, по времени около двадцати минут:
- Журнал синхронизации: у каждого источника последнее успешное обновление свежее суток. Если данные не приехали, остальные шаги делать рано.
- Касса против отчёта: выручка за неделю из системы учёта и выручка в отчёте. Допуск - рубли, а не проценты.
- Сумма по каналам против общей суммы. Если по каналам меньше, часть визитов выпадает из разбивки, и виноват отчёт, а не бизнес.
- Звонки: всего равно отвеченным плюс пропущенным. Ноль в пропущенных при живом потоке - поломка.
- Расходы: ручные строки помечены отдельно, и расхождение с кабинетом ровно на сумму ручной строки это не сбой. Сверять лучше с платёжкой, а не с интерфейсом кабинета.
- Доля «не определён» - записать число. Скачок за неделю почти всегда означает, что где-то слетела или поменялась метка.
- Дубли: сколько карточек клиентов делят один номер телефона.
Каждое расхождение записывайте одной строкой: дата, что с чем не сошлось, на сколько, причина. Через месяц выяснится, что половина строк - одна и та же причина, и её можно закрыть навсегда. Ещё лучше, когда проверки крутит сама система: человек забывает, крон не забывает.
Что из этого делает VM Analytics
Система прогоняет проверки по собственным данным и говорит, где им нельзя верить. Среди них: свежесть каждого потока, зависшие и упавшие импорты, сходимость сумм - выручка и звонки по каналам против общей сводки, правдоподобность, каналы вне справочника и нечитаемые метки на заявках. Самопроверка идёт раз в час, и о сбое система сообщает нам сама.
В кабинете есть журнал обновлений (Кабинет, вкладка «Синхронизация»): когда, из какого источника, сколько строк пришло, сколько это заняло и была ли ошибка. Источник, который не определился, остаётся «не определён» и не подменяется именем CRM или сайта; номинал сделок в CRM и подтверждённое кассой стоят отдельными строками. Данные обновляются несколько раз в день, а не в реальном времени.
Читаем мы то, что отдают ваши сервисы: Яндекс Директ, Яндекс Метрику, Яндекс Бизнес, amoCRM, YCLIENTS, формы Tilda и вебхуки, МегаФон ВАТС и коллтрекинг Гудок, WhatsApp, Telegram и Instagram Direct, плюс офлайн-расходы вручную.
Чего система не делает: не заменяет вашу кассу, не придумывает источник там, где следа не осталось, и не дозагружает историю, которую сервис уже не отдаёт. Наша работа - назвать причину и размер расхождения, а не подогнать одно число под другое.
Instagram принадлежит компании Meta Platforms Inc., деятельность которой признана экстремистской и запрещена на территории РФ.
Что почитать дальше
Покажем, что видно снаружи: счётчики, коллтрекинг, онлайн-запись, метки источников. Без доступов и без контактов.
Проверить сайт