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

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

Разбор

Если использовать только received_at, офлайн-события «переедут» на другие дни и исказят воронки. Если хранить только event_time, будет сложно мониторить задержки доставки и сбои в отправке. Пара event_time и received_at позволяет строить user journey по факту действия и одновременно следить за качеством доставки. Это базовая практика для data quality в мобильной instrumentation.

Проверь себя · 1/3разбор после ответа
Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для event taxonomy и последующей аналитики?
Тренировать продукт в Telegram

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