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