В продакшене изменили способ трекинга события purchase (например, добавили дедупликацию событий), из-за чего на временном ряду дашборда виден резкий разрыв в день изменения. Как вы будете это диагностировать и что сообщите пользователям дашборда?

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

Нужно подтвердить, что разрыв совпадает по дате с известным релизом (по логам деплоя/changelog), оценить размер скачка и явно сообщить на дашборде, что данные до и после этой даты не полностью сопоставимы, при необходимости рассмотрев пересчёт истории.

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

Резкий ступенчатый сдвиг именно в дату релиза (а не постепенный тренд) сильно указывает на изменение в логике трекинга, а не на реальное изменение поведения пользователей; сверка с датой деплоя подтверждает эту гипотезу.

Пример кода

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

-- PostgreSQL: сравнение дневных объёмов событий до/после даты изменения
SELECT event_date, COUNT(*) AS events_raw,
       COUNT(*) FILTER (WHERE is_deduplicated) AS events_dedup
FROM purchase_events
WHERE event_date BETWEEN '2024-05-01' AND '2024-05-10'
GROUP BY event_date
ORDER BY event_date;

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

• Применение. Сопоставьте точную дату/время сдвига с логами деплоя, оцените размер скачка в % для понимания влияния на исторические сравнения (YoY, тренд), добавьте видимую аннотацию на дашборде в эту дату, рассмотрите пересчёт истории по новой логике (если это технически возможно) либо явно разделите ряд на «до/после» с отдельными базовыми линиями.
• Проверка. если расхождение между сырыми и дедуплицированными событиями появляется в дату релиза, разрыв связан с новой логикой трекинга.

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

• Частые ошибки. Расследование скачка как реального бизнес-события вместо проверки изменений в трекинге; отсутствие пометки о разрыве на дашборде, из-за чего пользователи делают неверные выводы из YoY/трендовых сравнений; пересчёт истории без проверки, что старые сырые события поддерживают новую логику дедупликации, что вносит новые ошибки.