События в базе записаны в UTC (всемирное координированное время), а продукт в основном в Москве. Вы строите дневную time series по orders. Что важно для корректной агрегации по дням?
AАгрегировать по дню в
UTC (всемирное координированное время), потому что это всегда стандартBАгрегировать по дню на стороне клиента, игнорируя серверное время
CСначала отсортировать заказы по сумме, затем группировать
DПреобразовать время в нужный часовой пояс (например,
Europe/Moscow) перед агрегированием по днюПравильный ответ. Для дневной
granularity важен часовой пояс, иначе границы дней смещаются.Разбор
Если агрегировать в UTC (всемирное координированное время), часть заказов «уедет» в соседний день по локальному времени. Это искажает пики, дни недели и сравнения типа WoW.
Проверь себя · 1/3разбор после ответа
У метрики выраженная недельная
seasonality (выходные ниже). Какое окно rolling average чаще всего логично, чтобы сгладить именно недельный цикл?Ещё вопросы по теме «Временные ряды»
- Промо-акция шла только 2 дня (пт–сб). Хотите увидеть её эффект на заказах на графике `time series`. Какая `granularity` наиболее уместна?
- Вы строите график выручки магазина как `time series` по дням. Какую агрегацию по дням выбрать для `revenue`?
- В ежедневной `time series` событий один день трекинг был сломан: данных нет, но пользователи были. Как корректнее отобразить этот день на графике?
- Сегодня среда. Вы делаете `WoW` (Week-over-Week — неделя к неделе) сравнение продаж 'эта неделя vs прошлая'. Чем опасно сравнивать неполную текущую неделю с полной прошлой, и что делать?
- Дневная метрика `DAU` (Daily Active Users) сильно шумит. Какой приём поможет показать тренд, не потеряв исходные значения?
- Все вопросы по «Временные ряды» →