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

AДостаточно одного user_id в свойствах события: остальные поля раздувают объём и усложняют разбор инцидентов после релиза
BДобавлять app_version и platform к каждому событию, чтобы локализовать баги по версиям и окружению пользователя продукта
CДобавлять только country и language: эти поля задают сегмент пользователя без необходимости знать версию сборки или платформу
DУбирать поле app_version из событий: данные становятся единым массивом без сегментации по сборкам и проще ложатся в отчёт
Правильный ответ. Поля версии и платформы в логировании помогают быстро понять, где именно сломалось инструментирование событий.

Разбор

Базовый набор служебных полей в каждом событии — версия приложения, платформа и версия SDK или номер сборки. Это позволяет в первые минуты после релиза увидеть, в какой именно сборке поломалась отправка или появилась аномалия в метрике, и не тратить часы на корреляцию с релиз-нотами. Только user_id не даёт разрезать данные по сборкам. Только страна и язык — полезные сегменты, но не помогают локализовать инцидент. Удаление app_version лишает аналитику ключевого инструмента диагностики после релизов.

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

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