Если у фичи нет цепочки поведение → сигнал → метрика, обсуждение A/B превращается в гадание
Типичная сцена: продакт говорит “делаем фичу, чтобы улучшить удержание”, аналитик подбирает метрику “ну пусть будет D7”, а потом тест либо “ничего не показал”, либо показал странное и спорят неделями. Цена ошибки не в одном эксперименте. Вы закрепляете привычку принимать решения по метрикам, которые не связаны с тем, что реально меняет фича.
Почему так ломается: фича меняет не метрику напрямую, а конкретное поведение конкретного актора в конкретном контексте. Если вы не описали это поведение и не договорились, как оно выглядит в данных, метрика становится прокси на прокси. А прокси без контроля качества и без guardrails быстро начинают “ехать” из‑за сезонности, маркетинга, багов логирования и изменений в продукте.
Минимальный стандарт, который спасает нервы и делает требования к данным очевидными, это impact map в 5 шагов:
- Актор: кто именно меняет поведение (новый пользователь, платящий, автор контента, саппорт).
- Цель: какую задачу он пытается закрыть, не “рост удержания”, а прикладную цель.
- Поведение: что он должен начать делать чаще/быстрее/реже, какая конкретная последовательность действий меняется.
- Сигнал в данных: какое событие или свойство однозначно фиксирует это поведение, какие поля обязательны, чем считаем “успех” и чем “попытку”.
- Метрика и guardrail: основная метрика про эффект и 1–2 ограничителя, чтобы не выиграть ценой деградации (ошибки, отмены, latency, жалобы, нагрузка).
Красные флаги:
- Метрика выбрана раньше поведения.
- “Сигнал” звучит как “посмотрим по дашборду”, без явного события и правил дедупликации.
- Нельзя отличить попытку от успеха или нет ключевого измерения (канал, платформа, сегмент).
- Guardrails “потом добавим”, потому что “это же маленькое изменение”.
В правильной практике impact map закрывает два спора заранее: про то, что именно считаем эффектом, и про то, какие логи должны появиться до запуска. А/B после этого становится проверкой гипотезы, а не поиском смысла в шуме. Граница применимости простая: для чисто технических изменений без пользовательского поведения impact map заменяется картой системных рисков и SLO, но логика “сигнал → метрика → guardrail” всё равно остаётся.
