События иногда приходят на сервер не в том порядке, в котором пользователь совершал действия. Как правильнее строить 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 и контролировать задержки?Ещё вопросы по теме «Инструментация и качество данных»
- Вы проектируете `event taxonomy` для регистрации. Какой вариант `instrumentation` лучше всего подходит, чтобы считать конверсию в успешную регистрацию и понимать, через какой способ вошли?
- Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для `event taxonomy` и последующей аналитики?
- Вы настраиваете мониторинг `data quality` для платёжного флоу. Какой набор `invariants` наиболее практичен и устойчив к сезонности?
- После обновления SDK вы видите, что сумма по `purchase_succeeded` выросла почти в 2 раза, но платежный провайдер этого не подтверждает. Что наиболее вероятно и какое действие по `data quality` самое уместное?
- В мобильном приложении события могут копиться офлайн и отправляться позже. Какие поля времени лучше заложить в `logging`, чтобы корректно строить `user journey` и контролировать задержки?
- Все вопросы по «Инструментация и качество данных» →