События иногда приходят на сервер не в том порядке, в котором пользователь совершал действия. Как правильнее строить user journey и при этом мониторить data quality?

AИспользовать порядок поступления received_at, потому что серверный порядок всегда корректный.
BУдалять события, которые пришли «слишком поздно», чтобы сохранить порядок.
CСортировать шаги по event_time, а received_at использовать для контроля лагов и алертов по задержкам/потерям.
DНе строить воронки и пути, если порядок иногда нарушается.
Правильный ответ. Для логики пути важен event_time, а received_at нужен для мониторинга задержек и сбоев доставки.

Разбор

В мобильной среде сеть нестабильна, события могут буферизоваться и отправляться пачками. Если опираться на received_at, вы исказите последовательность и время действий. Использование event_time позволяет восстановить реальный порядок, а сравнение с received_at даёт метрики задержек и качества доставки. Это типичная практика для устойчивой instrumentation и контроля data quality.

Проверь себя · 1/3разбор после ответа
В мобильном приложении события могут копиться офлайн и отправляться позже. Какие поля времени лучше заложить в logging, чтобы корректно строить user journey и контролировать задержки?
Тренировать продукт в Telegram

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