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

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

Разбор

При расширении схемы событий важно не сломать данные, которые уже идут со старых клиентов. Новое поле добавляют как необязательное (optional): новые сборки шлют его, старые продолжают слать событие без него — обратная совместимость сохраняется. Резкое переименование или удаление старого события создаёт пробел в исторических метриках. Удаление устаревших свойств одновременно с добавлением нового — отдельная задача, её делают через депрекацию. Обязательное поле для всех ломает сборки, которые ещё не обновились.

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

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