В событие покупки со временем добавили новое поле discount_code внутри properties (JSON), но не все старые события его содержат. Как учесть это при трансформации данных в аналитическую витрину?

Короткий ответ

Нужно извлекать поле через безопасный JSON-экстрактор, который возвращает NULL для событий без этого поля, явно документировать дату появления поля в схеме события и не путать «скидки не было» с «поле ещё не существовало».

Как это работает подробнее

Эволюция схемы событий — обычная ситуация при добавлении новых возможностей продукта; большинство современных инструментов трекинга хранят properties как полуструктурированный JSON именно для того, чтобы схема могла расширяться без миграции всей таблицы.

Пример кода

example.sqlКопировать

-- PostgreSQL, properties — jsonb
SELECT
  event_id,
  event_ts,
  properties ->> 'discount_code' AS discount_code,
  CASE WHEN event_ts < '2024-03-01' THEN 'legacy_schema' ELSE 'current_schema' END AS schema_version
FROM events_raw
WHERE event_name = 'purchase';

Что использовать на практике

• На практике. При трансформации используют функции вроде JSON_EXTRACT_SCALAR / ->> с проверкой на отсутствие ключа, и дополнительно можно завести поле-признак «схема событий версии N» или просто ориентироваться на дату, когда поле стало доступно, чтобы корректно интерпретировать NULL в историческом периоде.
• Проверка. построить долю non-null discount_code по дням и убедиться, что резкий скачок доли ровно в дату релиза поля — ожидаемый технический эффект, а не реальный рост скидочных заказов.

Подводные камни

• Частые ошибки. Интерпретируют NULL в discount_code как «скидки не было» для всего исторического периода, хотя на самом деле до определённой даты поле просто не передавалось — это завышает/занижает долю заказов со скидкой в прошлом относительно настоящего.