Почему цифры в отчёте и в источнике не сходятся?

Чаще всего дело в фильтрах, соединениях или периоде. Проверьте: совпадают ли период и часовой пояс, не теряются ли строки в JOIN, нет ли дублей, учтены ли возвраты и тесты. Эталон даст прямой запрос к источнику.

Как проверить отчёт за пять минут?

Сверьте итог с источником, сравните COUNT(*) до и после соединений, поищите дубли по ключу, посмотрите NULL в ключевых полях, проверьте дату последней загрузки.

Что делать, если неверная цифра уже ушла заказчику?

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

Как понять, что ошибка в SQL, а не в источнике?

Сравните число строк на каждом шаге: после фильтров, после JOIN, после группировки. Если строки теряются или размножаются, дело в логике запроса. Если расходится источник — вопрос к витрине.

Нужны ли автотесты, если отчётов немного?

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

Ошибки в отчётах: как найти и исправить

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

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

Неверный знаменатель метрики: конверсию считают от всех регистраций, а не от подходящих.
Потеря строк в 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 517 вопросов с объяснением каждого ответа, 120 тем и 13 курсов. Профильные курсы: 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 там, где пустота означает ошибку.
Сравните границы периода и часовой пояс во всех блоках.
Убедитесь, что возвраты, отмены, боты и тесты обработаны по правилу.
Посмотрите дату последней загрузки витрины.
Перечитайте выводы: среднее или медиана, размер групп, сезонность.

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

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

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

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