Алёрт по метрике: это аномалия в продукте или вы просто потеряли трекинг?

Самый частый фейл on-call аналитика: сразу делать вывод про продукт, когда на самом деле сломался сбор, доставка или модель. Цена ошибки простая: команда “чинит” несуществующую проблему, а реальная дыра в данных разрастается и заражает отчёты, эксперименты и SLA.

Механика почти всегда одна: продукт и трекинг меняются асинхронно. Релиз, фича-флаг, новый источник, правка схемы, лаг в очереди, падение джобы, смена правил дедупликации или атрибуции. В итоге “просела конверсия” выглядит так же, как “у нас перестали приезжать события”.

Минимальный triage-плейбук, чтобы отличить продукт от поломки:

1. Сначала определите радиус: один продукт/платформа/страна/источник или везде. Если “везде и сразу” — это почти всегда пайплайн или трекинг.
2. Сведите метрику к базовым контрольным: объём событий, число уникальных пользователей, доля активных устройств, распределение по источникам трафика, по версиям приложения, по платформам.
3. Проверьте “события против пользователей”. Падает только событийность при стабильных пользователях — подозрение на конкретные ивенты, SDK, схему. Падают и события, и пользователи — подозрение на ingestion, фильтры, блокировки, авторизацию, общее отключение логирования.
4. Сверьте сырьё и витрины: есть ли события в raw, но нет в моделях. Если raw живой, а витрина мертва — ищите дыру в трансформациях, джойнах, дедупе, партициях, расписании.
5. Сегментируйте по версии и источнику: скачок проблемы с конкретной версией или конкретным источником почти всегда указывает, где копать. Если провал совпал по времени с релизом или изменением конфигов — это не “случайность”.

Что эскалировать сразу, без долгой аналитики: нули или резкие обрывы по ключевым событиям, пропавшие партиции/таблицы, всплеск ошибок в загрузке, внезапный рост неизвестных значений, массовые null в критичных полях, сильный лаг доставки, несовпадение счётчиков между raw и витриной, изменение схемы без обратной совместимости.

В правильной практике у вас есть короткий runbook: какие контрольные метрики считаются “живыми”, где смотреть здоровье пайплайна, кто владелец трекинга, кто владелец витрин, как оформляется инцидент и как делается backfill. Обычно спорят про пороги, но важнее другое: алёрт должен приводить к локализации места поломки, а не к гаданию про продукт. Граница применимости простая: на малом трафике не пытайтесь “ловить всё” — увеличивайте окна и опирайтесь на более грубые сигналы живости.