Агрегатная таблица показывает 100k sessions за день, а расчет из сырых events дает 70k sessions. Что логичнее проверить первым?
AСразу выбрать число, которое больше, потому что оно выглядит оптимистичнее
BУмножить 70k на фиксированный коэффициент, чтобы «починить» расхождение
CСверить
definition sessions: правила sessionization, фильтры событий, time zone и deduplication на одном и том же срезе данныхDУдалить
aggregate таблицу и считать только из сырых данных без проверкиПравильный ответ. При
reconciliation агрегатов и сырых данных первым делом выравнивают definition и правила агрегации.Разбор
Разные правила sessionization и фильтры могут давать большие расхождения даже при корректных данных. Часто различаются time zone, способы дедупликации и набор событий, которые считаются сессией. Когда определения совпали, можно искать технические причины: missing data, duplicates или ошибки в конкретном шаге пайплайна.
Проверь себя · 1/3разбор после ответа
В отчете по странам доля
unknown резко выросла до 40 процентов, и региональные метрики стали «прыгать». Что проверить первым?Ещё вопросы по теме «Качество данных и инварианты»
- В ежедневном дашборде `DAU` и количество событий резко упали начиная с 02:00 и остаются низкими до конца дня. Что проверить первым, чтобы быстро понять, это `missing data` или реальный бизнес-эффект?
- Какой `invariant` наиболее уместно добавить в ежедневный отчет по воронке e-commerce, чтобы ловить ошибки данных?
- Выручка по событиям в продуктовой витрине на 5 процентов выше, чем в платежной системе за тот же день. Что логичнее всего проверить первым в рамках `reconciliation`?
- Вчера число событий `purchase` выросло в 2 раза, но число уникальных `order_id` почти не изменилось. Какой источник проблемы наиболее вероятен?
- Метрики за понедельник резко просели, а за вторник резко выросли, при этом сумма за 2 дня почти не изменилась. Какой `sanity check` лучше всего указывает на `time shift`?
- Все вопросы по «Качество данных и инварианты» →