Сообщить об ошибкеКороткий ответ
Резкий скачок или провал метрики, который начинается точно в день релиза/изменения в системе трекинга (а не постепенно) и не сопровождается аналогичным изменением в смежных, независимо собираемых метриках — явный признак технического разрыва, а не реального поведенческого изменения.
Как это работает подробнее
изменение способа сбора данных (новая версия SDK, смена атрибуции событий, фильтр ботов, изменение логики дедупликации) может резко сдвинуть абсолютные значения метрики, при этом реальное поведение пользователей не изменилось.
Пример кода
SQL-запрос
-- PostgreSQL: сравнение дневного количества событий с разбивкой по версии трекинга
SELECT event_date, tracking_version, COUNT(*) AS events
FROM raw_events
WHERE event_date BETWEEN '2024-05-01' AND '2024-05-15'
GROUP BY event_date, tracking_version
ORDER BY event_date;Что использовать на практике
- На практике. первый шаг диагностики — сопоставить дату скачка с журналом релизов и деплоев (не только продуктовых, но и инфраструктурных/аналитических). Второй шаг — проверить, согласуется ли изменение с независимым источником (например, если выручка по данным платёжного шлюза не изменилась, а «выручка» по внутренней аналитике скакнула — проблема в трекинге). Третий шаг — посмотреть, меняется ли структура данных (появились новые значения в полях, изменился формат event_name), что часто выдаёт техническую причину. Также полезно держать отдельный журнал всех изменений логики трекинга с датами, чтобы при анализе любого исторического ряда можно было быстро свериться с возможными причинами разрывов.
- Пример. Sanity check: если events резко падает ровно в день смены tracking_version с одновременным ростом событий новой версии, это подтверждает техническую природу разрыва, а не реальное снижение активности.
Подводные камни
- Частые ошибки. сразу интерпретировать скачок как продуктовый эффект и начинать искать «причину роста» в поведении пользователей, не проверив технические изменения; сравнивать метрики до и после разрыва как единый непрерывный ряд в отчётах, создавая ложное впечатление тренда; не документировать известные разрывы трекинга, из-за чего ошибка повторяется в будущих анализах. Ещё одна ошибка — «склеивать» данные до и после разрыва трекинга простым коэффициентом пересчёта без проверки, что коэффициент одинаков для всех сегментов и типов событий.