Красный флаг в продуктовой аналитике: вы трекаете «всё», но не можете назвать решения, которые это должно менять.
Сценарий знакомый: разработка поставила десятки событий, в BI сотни метрик, дашборды пухнут. А дальше начинается магия: «посмотрим, что выстрелит», «потом разберёмся». Цена ошибки простая и дорогая: вы перестаёте доверять данным. Потому что любое обсуждение скатывается в спор про то, что считать, где сломалось, почему не сходится, и что вообще означают эти числа.
Почему так происходит: трекинг начинают строить от возможностей (что можем собрать) или от интерфейса (что есть на экране), а не от решений. В итоге метрики живут своей жизнью, события — своей, и связь «что поменять в продукте» теряется. Чем больше «на всякий случай», тем больше мусора: дубли, разные определения, половина событий без владельца, непонятные названия, отсутствие версий, тихие поломки после релизов.
Простой фреймворк, который режет хаос: решение → сигнал → метрика → событие.
-
Решение. Одной фразой: что мы будем делать по итогу? Запускать фичу, откатывать, менять порог, усиливать канал, чинить шаг. Если решения нет — метрика не нужна.
-
Сигнал. Как выглядит «стало лучше/хуже» для этого решения. Не 10 показателей, а 1–2 наблюдаемых эффекта, которые реально сдвигаются и интерпретируются без гадания.
-
Метрика. Одна метрика на сигнал с чётким срезом: для кого, где, за какой период, какой атрибут важен. И сразу договоритесь о guardrails: что нельзя ухудшать, даже если целевая растёт.
-
Событие. Минимальный набор событий и параметров, чтобы посчитать метрику и разложить её на причины. Если событие не участвует ни в одной метрике и ни в одной диагностике — удаляйте или не внедряйте.
В правильной практике трекинг выглядит скучно: мало событий, у каждого есть владелец, тесты на качество, договорённые определения, и понятная трассировка от решения до клика. Исключение одно: исследовательская фаза, когда вы сознательно собираете временный расширенный лог, но с датой удаления и отдельным контуром, чтобы не превратить прод в свалку навсегда. Обычно спорят про «а вдруг потом пригодится» — пригодится ровно то, что привязано к решениям.