Ошибки в отчётах: как найти расхождение и перестать терять доверие к цифрам

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

Почему отчёты врут: восемь частых причин

Отчёт не врёт специально: он честно считает то, что ему написали в запросе. Почти каждое расхождение объясняется одной из причин ниже.

• Неверный знаменатель метрики: конверсию считают от всех регистраций, а не от подходящих.
• Потеря строк в INNER JOIN: заказы без платежа отрезаны, выручка ниже факта.
• Дубли после повторной загрузки: один заказ посчитан дважды.
• Разные периоды: календарный месяц против последних 30 дней.
• Часовые пояса: сервер пишет UTC, бизнес живёт по Москве.
• Возвраты и отменённые заказы: не вычли или вычли дважды.
• Тестовые аккаунты и боты проходят в отчёте как живые пользователи.
• Устаревшая витрина: загрузка упала, а отчёт ушёл руководству.

Проверка перед публикацией: чеклист самопроверки

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

• Проверка итога: сумма сверена с прямым запросом к первичным таблицам.
• Проверка соединений: COUNT(*) до и после каждого JOIN не вырос.
• Проверка пустот: в ключевых полях нет NULL там, где пустота — ошибка.
• Проверка дублей: GROUP BY по ключу HAVING COUNT(*) > 1 не даёт строк.
• Проверка периода: одинаковые границы дат и один часовой пояс.
• Проверка исключений: возвраты, отмены, боты и тесты обработаны по правилу.
• Проверка свежести: дата последней загрузки витрины не старше ожидаемой.

Типичные ошибки в SQL-расчётах

Большая часть ошибок в отчётах живёт в SQL. Вот шесть сюжетов, на которых спотыкаются и Джун, и опытный аналитик.

Дубли: SELECT order_id, COUNT(*) FROM orders GROUP BY order_id HAVING COUNT(*) > 1. Пропуски: SELECT o.order_id FROM orders o LEFT JOIN payments p ON p.order_id = o.order_id WHERE p.order_id IS NULL — так видны заказы без платежа. Проверку на NULL держите в WHERE, условие по датам — в ON.

• NULL в сравнениях: status <> 'paid' не вернёт строки с NULL — нужен IS DISTINCT FROM.
• Неявное приведение типов: в PostgreSQL запрос упадёт, в MySQL сравнятся не те строки.
• GROUP BY по неверной колонке: дата регистрации вместо даты заказа.
• COUNT(*) вместо COUNT(DISTINCT user_id): считает события вместо людей.
• Потеря строк в JOIN: условие по правой таблице в WHERE превращает LEFT JOIN в INNER.
• Округление на промежуточных шагах: ROUND в подзапросе копит ошибку.

Расхождение между отчётами: как искать

Два отчёта показывают разные цифры одной метрики. Спорить, кто прав, бесполезно — идите от итога к деталям.

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

Метрика посчитана верно, а вывод неверный

Запрос может быть безупречным, а вывод — ошибочным. Это самый неприятный класс ошибок: цифра защищена от проверки, а решение по ней уже принято.

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

Как защититься от повторения

Разовая правка не спасает от второй ошибки. Спасает процесс: одна формула метрики, автотесты и владелец витрины.

• Одна формула метрики в документации: одно определение, один источник, ссылка из дашборда.
• Автотест на полноту: число строк за день не падает ниже привычного коридора.
• Автотест на дубли по ключу и на разрывы дат в календаре загрузок.
• Автотест на аномалии: метрика ушла за порог — алерт в чат.
• Проверка свежести витрины перед публикацией отчёта.
• Алерт уходит владельцу витрины, а не в общий чат, где его не читают.

Как объяснить ошибку заказчику

Молча переписать цифру — худшее решение: заказчик уже принял решение по неверному числу, а после тихой правки перестанет доверять всем вашим отчётам.

Формула разговора: признать, показать влияние, назвать причину и срок, сказать, что сделали для защиты от повтора. Например: «В отчёте за март выручка завышена, возвраты не вычли. Бюджет по этой цифре лучше не планировать: причина — фильтр в витрине, поправлю сегодня до 18:00, тест на возвраты добавил».

• Что случилось: одна фраза без технических деталей.
• На что влияет: какие решения стоит пересмотреть.
• Когда исправят: конкретное время, а не «скоро».
• Что изменилось в процессе: тест, алерт или правка документации.

Культура работы с цифрами в команде

Ошибки в отчётах реже зависят от аккуратности одного человека и чаще — от того, как в команде договорились считать метрики.

Проверить себя в основах можно на тренажёре Proanalytics.tech: 1 443 вопроса с объяснением каждого ответа, 113 тем и 12 курсов. Профильные курсы: SQL (159 вопросов), базы данных (218), статистика и A/B-тесты (105), продуктовая аналитика и метрики (105), визуализация и BI (105), Python (105), Data Engineering (105).

• Правила именования: sale_dt вместо date1, понятные префиксы у витрин.
• Описания полей: смысл, единица измерения и владелец у каждой колонки.
• Версионирование расчётов: логика метрики меняется новой версией, а не молча.
• Владелец витрины: конкретный человек, а не «команда аналитики».
• Единый словарь метрик: спор решается ссылкой на определение.

Что сделать: короткий чеклист

• Сверьте итог с прямым запросом к источнику — сумма и число строк должны совпасть.
• Пройдите по каждому JOIN: COUNT(*) не должен вырасти.
• Поищите дубли по ключу: GROUP BY ключ HAVING COUNT(*) > 1.
• Проверьте NULL там, где пустота означает ошибку.
• Сравните границы периода и часовой пояс во всех блоках.
• Убедитесь, что возвраты, отмены, боты и тесты обработаны по правилу.
• Посмотрите дату последней загрузки витрины.
• Перечитайте выводы: среднее или медиана, размер групп, сезонность.

Где тренировать

Темы из гайда разобраны в тестах портала — каждый вопрос с объяснением ответа:

• Тесты по SQL с объяснением каждого ответа
• Продуктовая аналитика и метрики
• Визуализация данных и BI
• 12 курсов тренажёра
• Подписка и стоимость

Проверьте себя: пройдите бесплатную диагностику из 20 вопросов, а вводная тема каждого курса открыта без регистрации. Подписка — 590 ₽ в месяц, 3 990 ₽ в год или 7 490 ₽ навсегда, автоматических списаний нет. Proanalytics.tech — тренажёр для подготовки к работе с цифрами: 1 443 вопроса с объяснением каждого ответа, 113 тем, 12 курсов и уровни Джун, Мидл, Сеньор. Это не образовательная организация и не сертификация, гарантий трудоустройства нет.

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