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

Короткий ответ

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

Как это работает подробнее

расхождения между дашбордом и источником почти всегда объясняются разными определениями одной и той же метрики (разные фильтры по статусу, разный часовой пояс, разный момент снятия снэпшота), а не ошибкой в данных.

Пример кода

revenue_check.sqlКопировать

-- Источник (PostgreSQL): считаем выручку по оплаченным заказам за день
SELECT date_trunc('day', paid_at) AS day, SUM(amount) AS revenue
FROM orders
WHERE status = 'paid'
GROUP BY 1;

Что использовать на практике

• Применение. проверяю по порядку: совпадают ли фильтры (период, статус, страна), совпадает ли определение метрики (валовая или чистая выручка, с НДС или без), не стоит ли на дашборде кэш/устаревшее обновление, не отличается ли часовой пояс агрегации суток.
• Проверка или пример. Дашборд при этом мог агрегировать по created_at и включать заказы со статусом pending. Проверка: сравниваю SQL-определение метрики на дашборде (если доступно) с ручным запросом к источнику за один конкретный день; если цифры сходятся после выравнивания фильтров — расхождение объяснено определением, а не ошибкой.

Подводные камни

• Частая ошибка. сразу писать стейкхолдеру «данные неправильные» без собственной проверки — это создаёт панику и подрывает доверие к отчётности; тратить много времени на самостоятельное расследование без разумного дедлайна и не сообщать о проблеме вовремя, если корень не находится быстро.