Какие properties полезно добавлять почти ко всем событиям, чтобы быстрее диагностировать проблемы instrumentation после релизов?
AДостаточно только
user_id, остальные поля не нужны.BДобавлять
app_version, platform и sdk_version (или build_number), чтобы локализовать баги по версиям и окружению.CУбирать
app_version, чтобы данные были единым массивом без сегментации.DЛогировать пароль пользователя, чтобы проще было воспроизводить ошибки.
Правильный ответ. Поля версии и платформы в
logging помогают быстро понять, где именно сломалась instrumentation.Разбор
Если метрика падает после релиза, первый вопрос: это реальное поведение или сломанные события в конкретной версии. App_version и platform позволяют сегментировать и увидеть резкие разрывы, а sdk_version помогает отделить баг SDK от кода приложения. Без этих полей диагностика превращается в гадание и долгие переписки. Это один из самых дешёвых способов улучшить data quality.
Проверь себя · 1/3разбор после ответа
Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для
event taxonomy и последующей аналитики?Ещё вопросы по теме «Инструментация и качество данных»
- Вы проектируете `event taxonomy` для регистрации. Какой вариант `instrumentation` лучше всего подходит, чтобы считать конверсию в успешную регистрацию и понимать, через какой способ вошли?
- Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для `event taxonomy` и последующей аналитики?
- Вы настраиваете мониторинг `data quality` для платёжного флоу. Какой набор `invariants` наиболее практичен и устойчив к сезонности?
- После обновления SDK вы видите, что сумма по `purchase_succeeded` выросла почти в 2 раза, но платежный провайдер этого не подтверждает. Что наиболее вероятно и какое действие по `data quality` самое уместное?
- В мобильном приложении события могут копиться офлайн и отправляться позже. Какие поля времени лучше заложить в `logging`, чтобы корректно строить `user journey` и контролировать задержки?
- Все вопросы по «Инструментация и качество данных» →