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

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

Разбор

В офлайн-сценариях события могут лежать в буфере устройства часами и приходить позже, поэтому одного времени недостаточно. event_time фиксирует, когда действие произошло (его берут для построения пути и воронок), а received_at показывает момент приёма сервером и позволяет считать задержку доставки и контролировать офлайн-буфер. Только received_at ломает порядок действий пользователя при поздних отправках, только event_time не даёт измерить задержку, а отказ от времени делает анализ невозможным при перемешанных пакетах.

Тренировать продукт в Telegram

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