Каждый день в отчёте последние 2 часа выглядят как ноль событий, но на следующий день эти часы «дозаполняются». Какое объяснение наиболее вероятно?
Дубликаты, пропуски, нарушенные инварианты, расхождения между таблицами — проблемы качества данных, с которыми аналитик сталкивается ежедневно. На собеседовании дают датасет с ошибками и просят найти их. Умение быстро обнаружить проблему в данных экономит часы работы и защищает от ложных выводов.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
1В ежедневном дашборде `DAU` и количество событий резко упали начиная с 02:00 и остаются низкими до конца дня. Что проверить первым, чтобы быстро понять, это потеря данных или реальный бизнес-эффект?
AСразу написать в поддержку и попросить объяснить падение, не сверяя число строк по часам и `max(event_time)` источников
BОткатить все релизы за последние сутки без анализа сырых событий, числа строк по часам и `max(event_time)` по дням
CСделать базовую проверку полноты: сравнить число строк по часам и `max(event_time)` с предыдущими днями по сырым событиям
DСменить метрику в дашборде на другую, чтобы график выглядел стабильнее, не сверяя сырые события и `max(event_time)`
Ответ: Первым делом делают базовую проверку на полноту логов и корректность временных меток событий.
Резкий обрыв ровно с конкретного часа часто указывает на сбой в записи событий или загрузке данных. Сравнение числа строк по часам и `max(event_time)` с предыдущими днями быстро показывает, что данные перестали поступать или начали отставать. Если в сырых данных тоже виден провал, это сильный сигнал потери данных, а не бизнес-изменений. Поэтому переписывать дашборд или откатывать релизы до проверки полноты — преждевременно.
2Какой инвариант наиболее уместно добавить в ежедневный отчёт по воронке e-commerce, чтобы быстро ловить ошибки данных?
AСредний чек `avg_order_value` обязан колебаться в коридоре до одного процента в сутки, иначе данные `orders` собраны с ошибкой
BДоля сессий с `device_type = 'ios'` обязана сохраняться на уровне 50 процентов в сутки, иначе данные `sessions` загружены с ошибкой
CДневная выручка `revenue` обязана делиться на 100 без остатка по таблице `orders`, иначе расчёт по чекам выполнен с ошибкой
DЧисло `orders` ≤ `checkouts` ≤ `add_to_cart` ≤ `product_views` в одном окне времени, иначе нарушены отношения шагов воронки
Ответ: Логические отношения между шагами воронки — сильный инвариант для поиска багов в данных.
Количество пользователей или событий на более позднем шаге не должно превышать предыдущий шаг, если определения согласованы. Нарушение такого инварианта часто означает дубликаты, неверную дедупликацию или смешение разных окон времени между шагами. Это быстрый способ поймать ошибки ещё до интерпретации результата эксперимента или отчёта. Дистракторы про средний чек, долю iOS или целое число выручки — это не инварианты, а нормальные колебания.
3В отчёте одновременно упали почти все метрики: число сессий, событий, выручка, и падение начинается ровно с 14:00. Какое наблюдение лучше всего подтверждает гипотезу о пропусках в данных?
AПадение совпало с выходными, поэтому это сезонное снижение активности пользователей и обычные суточные колебания трафика
BПадение есть только у одного канала привлечения, а у остальных каналов поведение метрик стабильное и без аномалий по дням
CВ сырых данных почасовое число строк резко становится близким к нулю после 14:00 и не восстанавливается до конца суток
DСредний чек заметно вырос за тот же период, поэтому данные точно корректны и проблема в реальном поведении пользователей
Ответ: Резкий «обрыв» числа строк в сырых логах в конкретный час — характерный признак пропусков в данных.
Системные сбои сбора и доставки данных часто дают ступеньку в определённый момент времени. Сравните число строк по часам и `max(event_time)` с контрольными днями, проверьте мониторинги доставки. Если провал есть в сырых данных, дальнейшая статистика по бизнес-эффектам до восстановления данных будет некорректной.
4Вы подозреваете дубли в событиях из-за повторных отправок. Какая проверка адекватности самая прямая?
AПосчитать долю повторов как отношение `count(event_id)` к `count(distinct event_id)` и сравнить с базовым периодом
BПосмотреть только сумму выручки и игнорировать число событий, считая что бизнес-метрика по умолчанию защищена от дублей
CСравнить только недельное среднее значение метрики и не анализировать распределения, ожидая что дубли усреднятся в итоге
DПерезаписать таблицу заново без проверки уникальности, чтобы «обновить данные», и потом смотреть на свежий снимок отчёта
Ответ: Проверка уникальности `event_id` напрямую ловит дубли и даёт понятный сигнал качества.
Если `event_id` должен быть уникальным, то отношение `count(event_id)` к `count(distinct event_id)` должно быть близко к 1. Рост этого показателя означает массовые повторы, часто из-за повторных отправок или повторной обработки. Далее полезно посмотреть, одинакова ли полезная нагрузка у дублей и есть ли кластеры по времени загрузки.
5Какая проверка согласованности наиболее полезна, чтобы поймать «тихую» неполную загрузку дневной партиции, когда данные частично не приехали?
AПроверять, что число строк больше нуля и что `max(event_time)` попадает в ожидаемый конец дня для каждой суточной партиции
BПроверять только среднее значение метрики за неделю и игнорировать суточные показатели объёма и временного окна загрузки
CПроверять, что график на дашборде выглядит гладким, без числовых проверок объёма строк и временного покрытия партиции
DБрать случайные 10 строк из суточной партиции и считать, что этого достаточно для оценки качества загрузки данных за день
Ответ: Проверки числа строк и `max(event_time)` на уровне суточной партиции помогают быстро выявить неполноту загрузки.
Частичная загрузка может не обнулить данные полностью, но сдвинет объём и конец временного окна. Если `max(event_time)` неожиданно ранний, это сигнал, что хвост дня не приехал, а если число строк резко меньше нормы, вероятно пропуск данных. Такие проверки хорошо автоматизируются и дают быстрые оповещения. Глаз на дашборде и случайная выборка из 10 строк такие сдвиги обычно не ловят.