Выгрузка показывает 11 903 заказа, дашборд — 12 480: как найти, где расходятся цифры до презентации руководству

За день до отчёта собственнику маркетолог и руководитель отдела продаж открывают две системы и видят разные числа. Выгрузка из базы — 11 903 заказа. Дашборд — 12 480. Дельта в 577 строк, и до презентации непонятно, какому источнику верить и что отвечать на первый же вопрос про выручку.

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

Почему нельзя просто подогнать фильтр

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

Первый шаг — свести обе цифры к одинаковым параметрам

Пока источник и дашборд считают по разным условиям, сравнивать 11 903 и 12 480 бессмысленно. Я фиксирую для обеих сторон один набор: что именно считаем, период вплоть до минут, какие фильтры включены (тестовые сделки, отмены), в каком разрезе и на какой момент сделана выгрузка.

Здесь чаще всего вылезает классическая ошибка границ периода. Одна сторона берёт условие < '2026-03-31' и теряет последний день месяца, другая включает его целиком. На месячном отчёте это ровно одни сутки расхождения — и часть дельты снимается уже на этом шаге, до всякого разбора самих строк.

Характер дельты подсказывает причину

Форма расхождения экономит перебор гипотез. По ней я понимаю, куда смотреть дальше:

• Кратная дельта — умножение в ×2 или ×1,5 — это размножение строк при соединении таблиц или дубли.
• Маленькая дельта в 0,5–5% — разные фильтры: тестовые сделки, отмены, которые одна сторона учитывает, а другая нет.
• Дельта нарастает к концу периода — лаг между датой заказа и датой оплаты: заказ уже создан, оплата ещё не проведена, и системы фиксируют его в разные моменты.
• Ровный сдвиг со всплесками на стыках суток — источник и дашборд считают в разных часовых поясах. База хранит время в UTC, дашборд показывает в московском, и заказ, оформленный близко к полуночи, попадает в разные сутки.

Где строки задваиваются: дубли и размножение при соединении

Дубли ловятся тремя счётчиками по выгрузке: COUNT(*), COUNT(order_id) и COUNT(DISTINCT order_id). Если строк больше, чем уникальных идентификаторов, есть задвоение. В нашем разборе 577 лишних строк на 11 903 заказа — это 4,8% дублей. Такой доли достаточно, чтобы разъехались и количество заказов, и сумма выручки.

Отдельно раздувает деньги размножение при связывании таблиц один-ко-многим. Когда заказы соединяются со строками заказа, сумма по заказу повторяется на каждую позицию, и SUM считает её несколько раз. Проверяю это сравнением COUNT(*) против COUNT(DISTINCT parent_id) на результате соединения. Лечение — предварительная агрегация в отдельном подзапросе (CTE) до нужной гранулярности, а уже потом соединение. Так сумма по заказу остаётся одной строкой.

Обратная сторона — потеря строк. INNER JOIN выбрасывает несоединённые записи без предупреждения, LEFT JOIN сохраняет их со значением NULL. Когда я сравнил множества ключей и нашёл выпавшие заказы, я смотрю на них вручную и ищу закономерность: все ли это отмены, все ли с is_test=true, все ли одной конкретной даты. Закономерность и есть ответ, почему строки не соединились.

Одно имя, разные метрики

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

В связке сквозной аналитики Roistat с amoCRM или Bitrix24 корень расхождений обычно в качестве данных самой CRM. Сделки, заведённые менеджером вручную без источника. Дубли контактов, когда клиент попал в базу и как заявка с сайта, и как карточка после звонка. Сделки без суммы, которых для аналитики фактически не существует. Всё это искажает и выручку, и распределение по каналам. Похожая механика разбирается в материале о том, почему Директ, Метрика и CRM показывают разное число заявок — там разница живёт на стыке рекламных систем и карточки сделки.

Повторная отправка формы и повторный импорт данных способны раздуть воронку на 10–15% (эта оценка из веб-аналитики, на выгрузки из базы её переношу с осторожностью). Даже с поправкой вывод остаётся: расхождение в сотни заказов между двумя источниками объяснимо одними задвоениями, без всякой пропажи данных.

Что вынести к собственнику и как закрыть тему

Перед встречей я отвечаю на три вопроса. Меняется ли управленческий вывод из-за расхождения — если решение по бюджету одинаковое при 11 903 и при 12 480, дельта не блокирует отчёт. Какой цифрой пользуемся сегодня — одна согласованная, с оговоркой о доверительном интервале. Когда будет полный разбор — с датой. Эти три ответа дают защищаемую позицию даже с ещё не устранённой разницей.

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

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