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