Вы заметили, что часть событий имеет event_time в будущем относительно received_at, особенно у пользователей из разных стран. Что наиболее вероятно и как исправлять?

AВременные поля не нужны, просто удалите event_time из logging.
BНужно округлять event_time до дня, тогда проблема исчезнет.
CНужно переводить received_at в локальную зону пользователя и использовать только его.
DСкорее всего event_time пишется в локальном времени без учёта таймзоны; лучше отправлять event_time в UTC или вместе с timezone_offset и валидировать разумные диапазоны.
Правильный ответ. Сдвиги времени часто возникают из-за локального времени устройства без таймзоны, поэтому важно стандартизировать event_time и хранить смещение.

Разбор

Если разные клиенты пишут время по-разному, user journey ломается, появляются события «из будущего» и неверные дневные отчёты. Решение — единый стандарт времени (например, UTC) и явное поле смещения или зоны, чтобы при необходимости восстанавливать локальный контекст. Плюс полезны invariants: например, проверка, что разница received_at - event_time не выходит за разумный коридор. Это повышает доверие к данным и ускоряет поиск проблем в instrumentation.

Проверь себя · 1/3разбор после ответа
Вы описываете event taxonomy для purchase_succeeded. Как лучше хранить сумму покупки в properties, чтобы избежать проблем data quality при агрегациях?
Тренировать продукт в Telegram

Ещё вопросы по теме «Инструментация и качество данных»