Есть один типичный момент, который переживал любой аналитик.
Открываешь дашборд - так там цифра одна. Открываешь выгрузку из источника - цифра другая. В файле, который вчера ушёл руководству, цифра и вовсе третья. И дальше начинается самое бесполезное обсуждение на свете - "где правда?", "кто ошибся?", "а почему у вас не так, как у нас?".
Почти всегда правда у всех своя не потому, что кто-то плохой или кто-то сломал отчёт, а потому, что разные системы считают разные вещи под одним и тем же названием метрики. И хорошая новость в том, что это лечится довольно простыми проверками, которые занимают минуты - если идти по правильной последовательности.
Ниже - пять причин, которые встречаются чаще всего, и быстрые проверки, которые помогают почти сразу понять, в какой именно точке расходится расчёт.
Чек-лист на 10 минут: с чего начать
Если нужно быстро снять спор и найти источник расхождения, я всегда иду в одной и той же логике. Сначала проверяю не данные, а допущения, потому что в 8 случаях из 10 расхождение рождается именно там.
- Определение метрики - что мы считаем, а что исключаем
- Гранулярность и join - не размножили ли мы где-то строки
- Время - по какой дате считаем, какие таймзоны, есть ли временной лаг
- Полнота - дозревают ли данные задним числом
- Единицы и округления - рубли/копейки, проценты, правила округления
А теперь давайте разберемся по-подробнее.
Такие короткие проверки и приёмы я регулярно собираю в Telegram - чтобы аналитика быстрее превращалась в решения 📊
Причина 1. Разные определения одной и той же метрики
Это выглядит банально, но именно здесь иногда сгорают недели.
Один отчёт считает выручку как оплачено, второй - как выставлено, третий - как отгружено. Один отчет включает отмены в вал, другой их вычитает. Один отчет фильтрует тестовые заказы, другой нет. В итоге люди спорят не о цифрах, а о том, что вообще называется выручкой, просто не проговаривая этого вслух.
Предлагаю быструю проверку - вывести рядом структуру метрики по статусам, типам, категориям и сравнить ее состав. Если у них разный состав, итоговая цифра просто обязана быть разной - и это не ошибка, это разные условия расчёта. В этот момент спор кто прав обычно заканчивается, потому что становится видно, что вы сравниваете разное.
Причина 2. Разная гранулярность и раздувание сумм из-за join
Есть ещё одна классическая история: вроде всё правильно, формулы красивые, фильтры похожие - но после объединения таблиц сумма внезапно становится больше.
Чаще всего это из-за many-to-many. Заказ соединяют с кликами, клики - с кампаниями, и один заказ множится на несколько строк. В отчёте это выглядит как рост, а данные у вас раздуваются из-за того, что ключ перестал быть уникальным.
Быстрая проверка - до любого join смотреть на уникальность ключей и заранее понимать, какой тип связи вы делаете: one-to-one, one-to-many или many-to-many. А уже после join обязательно сравнивайте количество строк и количество уникальных ключей до/после. Если ключи перестали быть уникальными и строк стало больше - вы считаете не то, что думаете, даже если SQL формально правильный.
Причина 3. Время: разные окна, разные даты события, разные таймзоны
Причина похожа на первую в списке, но она настолько частая, что её стоит выделить отдельно.
Один отчёт строится по created_at, другой по paid_at, третий по posted_to_gl_at. Где-то берут дату в UTC, где-то в локальной таймзоне. А ещё бывает, что события доезжают с лагом и перезаписывают вчерашний день, особенно если в цепочке есть интеграции и асинхронные обработки.
Быстрая проверка - взять один конкретный день и посмотреть распределение событий по часам, желательно сразу по двум источникам. Если день у разных систем “начинается и заканчивается” в разные моменты, это будет видно мгновенно. Если есть лаги, вы увидите, что цифра дозревает - и тогда вопрос не почему скачет, а какой лаг считаем нормой и когда фиксируем финальный срез.
Причина 4. Полнота данных
Иногда все определения совпадают, join аккуратный, время синхронизировано, а цифры всё равно разные - потому что одна система показывает срез на сейчас, а другая работает как финальная витрина и обновляет прошлые даты.
Это очень частая история в реальных данных: вчера за день было 100, сегодня стало 112, послезавтра 115 - и это не баг, это эффект дозревания. Часть событий приезжает позже, часть записей корректируется, часть транзакций отменяется или подтверждается спустя время.
Быстрая проверка - посмотреть ревизии по D-1 и D-2. То есть взять один и тот же день и сравнить, как меняется цифра на следующий день, через два дня, через неделю. Если динамика есть - значит, ваш спор про ошибку на самом деле про правило: когда мы считаем день закрытым и какую версию данных используем в отчётах.
Причина 5. Единицы измерения и округления
Звучит мелко, но ломает отчёты с завидной регулярностью.
Рубли и копейки, проценты и базисные пункты, округление на уровне строк или на уровне итога. Сумма по строкам после округления может не совпасть с округлённой суммой, и это будет выглядеть как расхождение, хотя по сути это разные правила расчёта.
Быстрая проверка - выбрать контрольную выборку из нескольких записей и сравнить расчёт в деталях, а не в итого. В таких случаях проблема почти всегда видна на уровне строк: где-то округлили раньше, где-то позже, где-то умножили на процент до округления, а где-то после.
Вывод
Отчёты обычно не сходятся, потому что цифра в отчёте - это результат цепочки допущений при сборе или обработки данных: определение, гранулярность, время, полнота, единицы. И если вы не проверяете цепочку, вы неизбежно будете спорить о правде, хотя спорите о правилах.
Хорошая привычка аналитика - не искать виноватого и не переписывать отчёт по кругу, а пройтись по пяти проверкам сверху. Это занимает минуты, но экономит часы. И главное - помогает сделать так, чтобы BI был инструментом решений, а не поводом для бесконечной переписки в чатах.