Временные ряды: вопросы для собеседования (часть 4)
Line chart — стандарт для визуализации временных рядов: DAU, revenue, конверсия по дням. На собеседовании спрашивают, как показать сезонность, тренд и аномалии на одном графике, нужна ли ось Y с нуля и как сравнить несколько метрик с разными масштабами. Временные ряды — самый частый тип визуализации в аналитике.
Вопросы 16–20 из 20
16В метрике выраженная годовая `seasonality` (праздники, отпускные месяцы). Какое сравнение чаще корректнее для оценки роста?
AТолько `MoM`, потому что годовая сезонность не влияет
B`YoY`: сравнить с тем же периодом прошлого года
CСравнить с предыдущим днём
DСравнить с максимальным значением за год
Ответ: При годовой `seasonality` чаще выбирают `YoY`, чтобы сравнить сопоставимые периоды.
`MoM` может быть обманчив, если соседние месяцы сильно разные из-за календаря. `YoY` лучше отделяет сезонный паттерн от тренда, если период выбран сопоставимо.
17События в базе записаны в `UTC` (всемирное координированное время), а продукт в основном в Москве. Вы строите дневную `time series` по `orders`. Что важно для корректной агрегации по дням?
AАгрегировать по дню в `UTC` (всемирное координированное время), потому что это всегда стандарт
BАгрегировать по дню на стороне клиента, игнорируя серверное время
CСначала отсортировать заказы по сумме, затем группировать
DПреобразовать время в нужный часовой пояс (например, `Europe/Moscow`) перед агрегированием по дню
Ответ: Для дневной `granularity` важен часовой пояс, иначе границы дней смещаются.
Если агрегировать в `UTC` (всемирное координированное время), часть заказов «уедет» в соседний день по локальному времени. Это искажает пики, дни недели и сравнения типа `WoW`.
18Сегодня среда. Вы делаете `WoW` (Week-over-Week — неделя к неделе) сравнение продаж 'эта неделя vs прошлая'. Чем опасно сравнивать неполную текущую неделю с полной прошлой, и что делать?
AОпасности нет: `WoW` (Week-over-Week — неделя к неделе) корректен независимо от полноты периода
BНужно сравнить текущую неделю со средним за прошлый месяц
CНужно сравнивать только месяцы, недели слишком шумные
DСравнивать одинаковую часть периода: например `пн–ср` текущей недели с `пн–ср` прошлой
Ответ: Сравнивайте одинаковые по длине и составу периоды.
Полный прошлый период почти всегда больше неполного текущего, и это даёт искусственный 'провал'. Для честного `WoW` (Week-over-Week — неделя к неделе) выравнивайте по числу дней и учитывайте `seasonality` по дням недели.
19Две фичи запустили в разные даты, и вы хотите сравнить, как у них растёт использование после запуска. Как корректнее построить `time series` для сравнения?
AНаложить линии по календарным датам и сравнить напрямую
BСравнить только последний календарный месяц для обеих фич
CВыровнять по 'возрасту' фичи: день 0 = запуск, и показать `index` от `baseline` в день 0
DПостроить `cumulative` за всё время без выравнивания
Ответ: Для сравнения запусков выравнивайте по времени от события и используйте `index` от `baseline`.
Календарное наложение смешивает разные этапы и внешние эффекты. Выравнивание по дню запуска позволяет честно сравнить первые 7/30 дней после релиза.
20Вы сравниваете `cumulative` выручку текущего месяца с прошлым месяцем и видите, что текущая линия ниже. Сегодня 20‑е число. Что важно для корректного сравнения?
AСравнивать текущие 20 дней с полным прошлым месяцем
BСравнивать только итог месяца, не смотря на текущие дни
CСравнивать с любым месяцем прошлого года, это всегда лучше
DСравнивать одинаковый 'день месяца' или одинаковое число дней (например, 1–20), учитывая календарь и `seasonality`
Ответ: Для `cumulative` сравнивайте одинаковую 'длину' периода и календарный контекст.
Неполный период почти всегда проигрывает полному, что создаёт ложное ощущение отставания. Сравнивайте 1–20 с 1–20 и помните, что дни недели и праздники влияют на форму кривой.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Визуализация данных