Вы хотите добавить новое свойство promo_code в событие checkout_started. Какой подход лучше с точки зрения data quality и совместимости?

AПереименовать событие в checkout_started_v2 и удалить старое событие сразу.
BУдалить из события старые свойства, чтобы не раздувать properties.
CДобавить promo_code как необязательное свойство, обновить event taxonomy и валидаторы, сохранив обратную совместимость.
DПоменять тип существующего user_id с строки на число, чтобы всё было единообразно.
Правильный ответ. Безопасная эволюция схемы обычно означает добавление необязательных properties и обновление контрактов event taxonomy.

Разбор

Резкие переименования и удаление старых полей ломают отчёты и пайплайны, особенно если разные версии приложения живут параллельно. Добавление необязательного свойства позволяет плавно раскатить изменение и сохранить историческую сопоставимость. Валидации помогут контролировать заполнение нового поля и выявлять платформенные расхождения. Изменение типов существующих полей — частая причина поломок в logging и запросах.

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

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