Data-driven не приживается, если метрики живут как отчётность, а не как система решений.
У аналитика это видно за пару недель: вас зовут “посчитать цифры”, но цифры ни на что не влияют. Команда тратит время на дашборды, а не на ясность. Итог предсказуемый: решения принимаются по интуиции, а данные используются как постфактум-оправдание или как оружие в споре.
Механика поломки простая. Data-driven — это не про наличие BI и трекинга. Это про договорённости: кто за что отвечает, какие события считаются правдой, какие метрики имеют приоритет, и что происходит после решения. Если этих договорённостей нет, система распадается на разрозненные отчёты, а доверие к данным умирает после первой же “почему цифры не сходятся”.
Красные флаги в процессах, которые обычно видит аналитик:
- Метрики существуют только для регулярного отчёта, но не встроены в планирование и разбор результатов.
- Нет владельцев метрик и данных: все “смотрят”, но никто не отвечает за определение, качество и изменения.
- События и атрибуты не определены письменно: разные команды трекают одно и то же по-разному, а спор решают голосом.
- Решения принимаются без явного ожидания эффекта и без пост-анализа: сделали фичу, побежали дальше, выводов нет.
- Любая цифра обсуждается через “а у меня в другом отчёте иначе”, потому что нет единого источника правды и версий.
Минимальный план изменений, который обычно вытягивает ситуацию без “большой трансформации”:
- Зафиксировать словарь: определения ключевых событий, метрик, срезов, окна времени, правила дедупликации и атрибуции.
- Назначить владельцев: продукт владеет метрикой, аналитика/данные владеют способом расчёта и качеством, инженерия владеет поставкой событий.
- Ввести 2 артефакта: one-pager на решение (гипотеза, метрики успеха, риски) и короткий post-analysis (что ожидали, что получили, что меняем).
- Поставить ритуалы: еженедельный разбор результатов и отдельный слот на data quality, где чинят причины, а не “подкручивают запрос”.
- Запретить “метрику дня”: одна целевая метрика на контекст, остальное — диагностическое, без прыжков от графика к графику.
В правильной практике аналитик перестаёт быть отчётчиком и становится частью контура управления: договорённости → решение → измерение → вывод → обновление правил. Обычно спорят про скорость: “некогда фиксировать определения”. На деле дороже обходится бег по кругу и вечное недоверие к данным. Граница применимости простая: если трафика мало или продукт в режиме выживания, делайте минимум — словарь и post-analysis, остальное можно нарастить позже.
