Сообщить об ошибкеКороткий ответ
Нужно последовательно сравнить определения метрики (та ли формула, тот же ли фильтр по статусам/датам), часовые пояса и границы периодов, этапы ETL-пайплайна (дедупликация, фильтры, джойны) и момент снятия снимка данных (дашборд мог закэшироваться раньше, чем обновился источник).
Как это работает подробнее
расхождение почти никогда не возникает "само по себе" — оно всегда объясняется конкретным отличием в способе расчёта или моменте среза данных; задача диагностики — методично исключать гипотезы от простых (другой часовой пояс) к сложным (ошибка в логике трансформации).
Sanity check: пересчитать метрику дашборда вручную по тем же фильтрам и часовому поясу, что в первоисточнике — если числа сходятся, причина расхождения найдена и её нужно задокументировать для обеих сторон.
Пример кода
-- Первоисточник считает orders по created_at в UTC и включает все статусы
SELECT COUNT(*) FROM orders WHERE order_date >= '2024-06-01';
-- Дашборд может фильтровать отменённые заказы и использовать локальное время
SELECT COUNT(*) FROM orders
WHERE status != 'cancelled'
AND order_date_local >= '2024-06-01';Что использовать на практике
- Эффективный порядок проверки: (1) сравнить SQL-определение метрики на дашборде с определением в первоисточнике — часто разница в фильтре статусов заказа (включены ли отменённые/возвраты)
- (2) сравнить часовой пояс агрегации по дням — сутки по UTC и по локальному времени дают разные дневные суммы на границах
- (3) проверить время последнего обновления данных на дашборде против первоисточника
- (4) проверить, нет ли дублей/потерь на промежуточных слоях пайплайна (ETL-джойны, дедупликация). Полезно также автоматизировать регулярную сверку ключевых метрик дашборда с первоисточником (например, ежедневный alert при расхождении более чем на X%), чтобы обнаруживать подобные проблемы проактивно, а не по жалобе стейкхолдера.
Подводные камни
- Сразу объявлять источник данных "неправильным" без сверки формул и фильтров
- Игнорировать разницу часовых поясов при агрегации по дням, особенно для международных продуктов
- Не документировать найденную причину расхождения, из-за чего она повторяется на следующем отчётном периоде. Ещё одна ошибка — исправлять расхождение «по месту», подгоняя цифру на дашборде под первоисточник без исправления самой причины в пайплайне, из-за чего проблема возвращается при следующем обновлении данных.