Цифры в отчётах не сходятся: как за один вечер найти, где расходятся данные

Собственник открывает три вкладки — рекламный кабинет, веб-аналитику и CRM — и видит три разных числа по одному и тому же периоду. Дальше начинается спор: маркетолог верит своей аналитике, РОП верит воронке, а бюджет на следующий месяц надо утверждать сегодня. Я разбираю такие расхождения регулярно и почти всегда нахожу причину за один вечер. Она лежит в понятных местах.

Почему три системы показывают разное

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

Разрыв в пять–десять процентов между системами держится в пределах нормы (по материалам о качестве данных в аналитике). Если расхождение больше — есть конкретная причина: пропущенные события, дубли или сбой интеграции. Такую причину можно локализовать, и это важно по деньгам: от неё зависит доверие к ROMI, к привязке сделок к источникам и к решению, куда направить рекламный бюджет.

Начинаю со сверки периодов, таймзон и окон атрибуции

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

Второе — окна атрибуции. Рекламные площадки по умолчанию берут разные окна: где-то семь дней по клику и один день по показу, где-то тридцать дней по клику. За один и тот же период это даёт разное число конверсий даже при технически исправном сборе данных. Российские кабинеты — Яндекс Директ и ВК Реклама — имеют собственные настройки по умолчанию, их стоит проверить отдельно, а не переносить зарубежные значения на веру.

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

Где веб-аналитика систематически недосчитывает

От пятнадцати до тридцати процентов трафика теряется в веб-аналитике из-за блокировщиков и отказа от файлов cookie (по данным материалов о качестве данных). Сами сделки при этом фиксируются в CRM. Получается устойчивый перекос вниз на стороне аналитики: обращение есть, продажа есть, а веб-аналитика этот визит не увидела.

Вторая частая причина — битые UTM-метки. Редирект обрезает параметры, источник сбрасывается в «(not set)», и расходы перестают привязываться к продажам. Канал приносит заявки, но в отчёте они висят без источника, и окупаемость этого канала посчитать нельзя.

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

Качество данных в CRM определяет потолок сквозной аналитики

Отчёт в сквозной аналитике (Roistat и подобных) не поднимется выше качества данных в CRM. Ручные сделки без источника, дубли контактов и декоративные статусы воронки напрямую ломают атрибуцию.

Дубли — типичная механика завышения. Одна заявка создаёт две карточки в amoCRM или Битрикс24, и воронка показывает больше обращений, чем было на самом деле. Цена заявки в отчёте занижается, потому что делится на раздутое число.

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

Ещё один источник разнобоя — разное понимание этапов воронки менеджерами. Один двигает сделку в «Переговоры» после первого звонка, другой — после встречи. Данные складываются несопоставимые, и отчёт по этапам врёт, хотя каждый менеджер по-своему прав.

Разбор за один вечер: десять сделок из CRM

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

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

Дальше причину я устраняю автоматизацией, а не устной договорённостью с отделом продаж. Источник подставляется при создании сделки автоматически. Дубли схлопываются по номеру телефона и почте без ручной чистки. Поля суммы и причины отказа становятся обязательными на этапе закрытия — сделку нельзя закрыть, пока они пустые. Так данные перестают зависеть от того, вспомнил менеджер заполнить поле или нет. Именно на этой логике я собираю дашборды, которым можно доверять при распределении бюджета.

Что сходящиеся цифры дают по деньгам

Когда источник расхождения найден и закрыт, ROMI и привязка сделок к каналам считаются на согласованных данных. Бюджет идёт в каналы, которые действительно приносят оплаты, потому что их показатели совпадают между кабинетом, аналитикой и CRM. Цена заявки и поток сделок считаются на одних и тех же фактах, и решение о перераспределении денег опирается на них, а не на разницу трёх вкладок.

Расхождение цифр — это диагностируемая инженерная задача с понятным порядком проверки. Если хочется увидеть более узкий разбор похожих ситуаций, я отдельно писал, как найти, где именно расходятся выгрузка и дашборд перед показом руководству, и как свести расходы Roistat с кабинетом Яндекса до факта.