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