Почему данные Метрики, CRM и кассы не сходятся

Почему не сходятся данные Метрики и CRM: три причины

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

Разные приборы

Прежде чем сравнивать два числа, надо понять, какой прибор вообще должен был увидеть это событие.

Разные периоды

Человек зашёл на сайт 31 марта, записался 2 апреля, оплатил 10 апреля - и попал в три разных отчётных месяца. Реклама списала деньги в марте, выручка встала в апреле, и апрельская окупаемость выглядит подозрительно хорошей.

Добавляют разницы часовые пояса: источники отдают время по-своему, и ночные события уезжают на сутки.

Разные определения

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

Визит, обращение, запись и оплата - это четыре разных числа

Эти четыре слова в разговоре подменяют друг друга, а в отчёте обязаны стоять отдельно:

• Визит - факт посещения сайта.
• Обращение - звонок, форма или сообщение.
• Запись - место в расписании.
• Оплата - деньги в кассе.

Между соседними шагами есть конверсия, между дальними её нет: в числителе и знаменателе окажутся разные люди.

Расчёт на условных числах

Это пример, а не результат клиента.

Последние два числа расходятся на 150 000 ₽, и это норма. Сумма в карточке сделки - намерение, а не деньги: сделку могли выиграть, а человек не дошёл или купил другое.

Держать их надо двумя строками рядом - номинал в CRM и подтверждённое кассой, - а не выбирать, какая из них настоящая. Какую из них брать в расчёт окупаемости, разобрали в статье ROMI, ROAS, CPO и LTV: как считать.

Что нельзя делить друг на друга

Делить 180 записей на 4 000 визитов нельзя: больше половины обращений пришло не с сайта.

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

Горизонт данных: с какого дня выгрузке вообще можно верить

Сколько истории отдаёт сервис

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

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

Окно первой выгрузки

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

• Сделки CRM - полгода.
• Записи - полтора месяца.
• Рекламные расходы - месяц.

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

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

Дыры в синхронизации: почему всплеск в прошлом году это окно выгрузки, а не рост

Всплеск на дате подключения

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

Проверяется за минуту: если рост приходится на дату подключения, это артефакт импорта.

Источник замолчал посреди работы

Второй вид дыр опаснее. Телефония перестала слать события, истёк токен, сотрудник отозвал доступ, оператор приостановил услугу за неоплату.

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

Догнать такую дыру задним числом обычно нечем: если интеграция умеет только принимать события в момент появления, историю за время молчания сервис уже не отдаст. Что проверять после каждого подключения, разобрали в статье как внедрить сквозную аналитику.

Как ловить дыры

Двумя проверками:

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

Дубли: одна запись в системе учёта и две карточки сделки

Одно событие приезжает двумя путями

Звонок приходит и от телефонии, и заметкой из CRM. Идентификаторы у источников разные, и уникальный индекс такую пару не ловит. Мы склеиваем такую пару по последним десяти цифрам номера и окну в две минуты.

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

Одна беседа двумя строками

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

Удалять дубль нельзя: у него бывает связь со сделкой, которой нет у текстовой строки. Правильное решение - пометить, чей он дубль, и не считать второй раз.

Одна запись в системе учёта и несколько карточек сделки

Робот-интеграция заводит карточку на каждое событие, и одна запись тянет за собой две-три сделки, а в самом тяжёлом случае мы видели шесть. Считать надо по первоисточнику: одна запись в расписании - это одна единица, сколько бы карточек она ни породила в CRM.

Один человек двумя карточками клиента

Ключ личности - нормализованный номер телефона, и только он. По имени склеивать нельзя: два разных Ивана Иванова станут одним.

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

Сколько стоят дубли в конверсии

Пример на условных числах, не результат клиента. Записей в обоих случаях 180.

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

Доля клиентов без источника и как её честно показывать в отчёте

Откуда берутся клиенты без источника

Часть клиентов всегда останется без источника:

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

Чего делать нельзя

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

Честный ответ - строка «не определён» с числом. Стоять она должна в таблице каналов наравне с остальными. Как вообще решают, кому засчитать клиента, разобрали в статье про атрибуцию.

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

Как показывать долю неизвестного

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

Требовать нуля не стоит: сарафанное радио и офлайн машинным сигналом не подтвердить, а лампу, которую нечем погасить, перестают читать.

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

Почему прочерк с объяснением лучше красивого числа

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

Особенно опасно путать три причины нулевого расхода. В отчёте это три разных сообщения, а не один ноль:

1. Расхода действительно не было.
2. Расход был, но данные не приехали.
3. Расход есть, но вносится вручную, и за этот период его не внесли.

То же с пропущенными звонками. Сказать «не дозвонились» можно только по прямому признаку от телефонии: занято, не ответили, сброс.

Если длительность просто не приехала, честнее написать, что разговор мог быть и мы про него не знаем. Между «этого не было» и «мы этого не видим» - пропасть.

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

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

1. Журнал синхронизации. У каждого источника последнее успешное обновление свежее суток. Если данные не приехали, остальные шаги делать рано.
2. Касса против отчёта. Выручка за неделю из системы учёта и выручка в отчёте. Допуск - рубли, а не проценты.
3. Сумма по каналам против общей суммы. Если по каналам меньше, часть визитов выпадает из разбивки, и виноват отчёт, а не бизнес.
4. Звонки. Всего равно отвеченным плюс пропущенным. Ноль в пропущенных при живом потоке - поломка.
5. Расходы. Ручные строки помечены отдельно, и расхождение с кабинетом ровно на сумму ручной строки - это не сбой. Сверять лучше с платёжкой, а не с интерфейсом кабинета.
6. Доля «не определён». Записать число. Скачок за неделю почти всегда означает, что где-то слетела или поменялась метка.
7. Дубли. Сколько карточек клиентов делят один номер телефона.

Каждое расхождение записывайте одной строкой: дата, что с чем не сошлось, на сколько, причина. Через месяц выяснится, что половина строк - одна и та же причина, и её можно закрыть навсегда.

Ещё лучше, когда проверки крутит сама система: человек забывает, крон не забывает.

Частая причина расхождения с CRM - сделки без источника и бюджеты сделок вместо оплат; подробно - в статье сквозная аналитика и amoCRM.

Что из этого делает VM Analytics

Проверки по собственным данным

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

• Свежесть каждого потока.
• Импорты: зависшие и упавшие.
• Сходимость сумм: выручка и звонки по каналам против общей сводки.
• Правдоподобность.
• Справочник и метки: каналы вне справочника и нечитаемые метки на заявках.

Самопроверка идёт раз в час, и о сбое система сообщает нам сама.

Журнал и честные строки

В кабинете есть журнал обновлений (Кабинет, вкладка «Синхронизация»): когда, из какого источника, сколько строк пришло, сколько это заняло и была ли ошибка.

Источник, который не определился, остаётся «не определён» и не подменяется именем CRM или сайта. Номинал сделок в CRM и подтверждённое кассой стоят отдельными строками.

Что читаем

Читаем мы то, что отдают ваши сервисы: Яндекс Директ, Яндекс Метрику, Яндекс Бизнес, amoCRM, YCLIENTS, формы Tilda и вебхуки, МегаФон ВАТС и коллтрекинг Гудок, WhatsApp, Telegram и Instagram Direct*, плюс офлайн-расходы вручную. Как подключается каждый сервис, собрано на странице интеграций.

* Instagram принадлежит компании Meta Platforms Inc., деятельность которой признана экстремистской и запрещена на территории РФ.

Чего система не делает

• Не заменяет вашу кассу.
• Не придумывает источник там, где следа не осталось.
• Не дозагружает историю, которую сервис уже не отдаёт.

Наша работа - назвать причину и размер расхождения, а не подогнать одно число под другое.

Частые вопросы