Инструментация и качество данных: вопросы для собеседования (часть 3)
Трекинг событий, naming conventions, data contracts, валидация данных — от качества инструментации зависит качество всей аналитики. На собеседовании спрашивают, как спроектировать систему событий для нового фичи, что делать при расхождении данных между системами и как обнаружить проблемы с логированием.
Вопросы 11–15 из 20
11В мобильном приложении события могут копиться офлайн и отправляться позже. Какие поля времени лучше заложить в `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`.
12События иногда приходят на сервер не в том порядке, в котором пользователь совершал действия. Как правильнее строить `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`.
13В корзине пользователь может добавлять товар и менять количество. Какой дизайн `event taxonomy` обычно удобнее для аналитики и контроля `data quality`?
AЛогировать атомарные события вроде `cart_item_added` и `cart_item_removed` с `properties={'cart_id': 'c1', 'product_id': 'p7', 'quantity_delta': 1}`.
BЛогировать только `cart_updated` и передавать в `properties` всю корзину как большой текст.
CЛогировать только `button_click` на плюс/минус без `product_id`.
DЛогировать `cart_state` раз в день и не логировать действия пользователя.
Ответ: Атомарные события с понятными `properties` проще валидировать и использовать в воронках, чем огромные снимки состояния.
События с `quantity_delta` позволяют считать добавления, удаления и итоговые количества без тяжёлых парсингов. Их проще контролировать через `invariants`: обязательные поля, разумные диапазоны, отсутствие пустых идентификаторов. Полный снимок корзины текстом ухудшает `logging`, усложняет джойны и может ломаться при изменениях формата. Для аналитики пути пользователя атомарные события обычно дают более прозрачную картину.
14Вы заметили, что часть событий имеет `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`.
15Пользователь проходит онбординг до логина, а логин делает позже. Какой подход к `instrumentation` лучше, чтобы сохранить полный `user journey` и качество атрибуции?
AДо логина отправлять `anonymous_id`, после логина добавлять `user_id` и отправлять событие `identify`, связывающее `anonymous_id` с `user_id`.
BНе логировать события до логина, чтобы не было лишних данных.
CИспользовать только `device_id` как `user_id` и никогда не менять идентификатор.
DГенерировать новый `user_id` при каждом запуске приложения, чтобы не было ошибок.
Ответ: Связка `anonymous_id` до логина и `user_id` после логина плюс событие `identify` помогает сохранить непрерывный путь пользователя.
Если вы не логируете события до логина, вы теряете часть пути и не понимаете, что влияет на активацию. Если использовать только `device_id`, вы усложняете кросс-девайс сценарии и перенос аккаунта. Событие `identify` позволяет корректно «склеить» историю и повысить `data quality` в воронках. Важно, чтобы эта логика была описана в `event taxonomy` и проверялась инвариантами.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика