Если фича не раскладывается на фича → поведение → метрика, это не A/B и не аналитика, это вера.
Типичная сцена: продакт приносит идею, вы быстро выбираете “главную метрику”, запускаете, через неделю получаете шум и спор на созвоне. Самое неприятное — спорят не про данные, а про смыслы: “пользователи стали вовлекаться” vs “они просто тыкали”. Цена ошибки тут не в том, что метрика не выросла. Цена — вы не знаете, что именно изменили, и не можете повторить успех или откатить вред.
Почему так ломается: между фичой и метрикой всегда есть цепочка намерений и действий. Если вы не зафиксировали, какое поведение должно поменяться, вы будете мерить суррогаты. А суррогаты легко улучшаются без реальной ценности: клики растут, а задача пользователя не решается; конверсия в шаг растёт, а качество падает; удержание “улучшилось”, потому что людей загнали в тупик.
Минимальный стандарт — impact map, которую можно проговорить за 5 минут и по которой можно написать требования к логированию:
- Актор: кто именно должен поменять поведение (не “пользователь”, а конкретный сегмент/роль).
- Цель: какую задачу он пытается закрыть в продукте, не “увеличить продажи”.
- Поведение: что он начнёт делать чаще/реже/быстрее/в другом порядке.
- Сигнал в данных: какое событие или последовательность событий это докажет. И какие свойства нужны (id, источник, вариант, контекст).
- Метрика и guardrail: чем измеряем эффект и чем ограничиваем “успех любой ценой” (качество, отмены, возвраты, ошибки, время, нагрузка, негативные исходы).
В правильной практике это выглядит так: сначала вы фиксируете цепочку актор → цель → поведение, потом проверяете, что сигнал вообще существует в логах и однозначно собирается, и только затем выбираете метрику. Обычно спорят про метрику, хотя спор должен быть про поведение и сигнал. Исключение простое: для чисто технических изменений без пользовательского поведения impact map превращается в “система → эффект → SLO”, и это нормально.
