Вы описываете event taxonomy для purchase_succeeded. Как лучше хранить сумму покупки в properties, чтобы избежать проблем data quality при агрегациях?
AХранить
amount='1990 RUB' строкой, чтобы сразу было красиво.BХранить
amount_minor=1990 и currency='RUB' отдельным свойством.CХранить
amount='1 990' со пробелами и разделителями, как в UI.DХранить только
currency, а сумму вычислять по истории корзины.Правильный ответ. Для аналитики лучше хранить числовое поле и валюту отдельно, чтобы избежать парсинга и неоднозначностей в
properties.Разбор
Строковые суммы легко ломаются из-за форматирования, пробелов и локалей, что создаёт ошибки в отчётах. Число в минимальных единицах удобно суммировать и сравнивать без плавающих ошибок, а currency отделяет контекст. Такой формат проще валидировать и поддерживать при изменениях. Это повышает надёжность logging и снижает стоимость последующей очистки данных.
Проверь себя · 1/3разбор после ответа
Вы описываете
event taxonomy для purchase_succeeded. Как лучше хранить сумму покупки в properties, чтобы избежать проблем data quality при агрегациях?Ещё вопросы по теме «Инструментация и качество данных»
- Вы проектируете `event taxonomy` для регистрации. Какой вариант `instrumentation` лучше всего подходит, чтобы считать конверсию в успешную регистрацию и понимать, через какой способ вошли?
- Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для `event taxonomy` и последующей аналитики?
- Вы настраиваете мониторинг `data quality` для платёжного флоу. Какой набор `invariants` наиболее практичен и устойчив к сезонности?
- После обновления SDK вы видите, что сумма по `purchase_succeeded` выросла почти в 2 раза, но платежный провайдер этого не подтверждает. Что наиболее вероятно и какое действие по `data quality` самое уместное?
- В мобильном приложении события могут копиться офлайн и отправляться позже. Какие поля времени лучше заложить в `logging`, чтобы корректно строить `user journey` и контролировать задержки?
- Все вопросы по «Инструментация и качество данных» →