После изменения логики трекинга событий (например, перехода на новую систему аналитики) временной ряд метрики показывает резкий скачок, не связанный с реальным изменением в продукте. Как реконструировать сопоставимую историю в SQL и задокументировать допущения?

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

Сначала перечислите семантические отличия систем: момент события, фильтры, дедупликацию, identity resolution и часовой пояс. Затем на overlap-периоде сравните не только общий коэффициент, но и его стабильность по дням и ключевым сегментам.

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

Если отношение новой метрики к старой меняется по времени или платформе, один коэффициент непригоден. Можно построить сегментные коэффициенты, но это увеличивает предположения и требует достаточной выборки.

Храните исходное значение, скорректированное значение, версию метода и признак imputed. График должен отмечать дату смены, а сравнения через границу — ссылаться на методологию.

Пример кода

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

WITH paired AS (
  SELECT event_date, platform,
         SUM(old_value) AS old_value,
         SUM(new_value) AS new_value
  FROM tracking_overlap
  GROUP BY event_date, platform
)
SELECT event_date, platform, old_value, new_value,
       new_value / NULLIF(old_value, 0) AS ratio
FROM paired
ORDER BY platform, event_date;

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

• Сохраните raw. Реконструкция должна быть воспроизводимой и обратимой.
• Версионируйте метод. Укажите период оценки, сегменты, формулу и доверительный диапазон.
• Показывайте разрыв. Даже скорректированный ряд не должен скрывать смену источника.

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

• Коэффициент по одному дню. Он смешивает шум и систематическую разницу.
• Экстраполяция вне overlap. Состав трафика и качество трекинга могут меняться.
• Перезапись истории. Потеря исходных значений делает аудит и повторный расчёт невозможными.