Метрики эксперимента: ключевая, прокси, guardrail
Пиццерия запустила акцию «вторая пицца −50%»: заказы выросли — а маржа? Половина провалов A/B — не в статистике, а в том, ЧТО измеряли. Одна метрика почти никогда не описывает эффект честно: что-то выросло, а что-то незаметно просело. Поэтому в дизайне эксперимента подбирают не одну, а согласованный набор метрик с разными ролями.
Решение принимают по ОДНОЙ ключевой метрике, но только если guardrail-метрики не просели. Прокси ускоряет тест, но рост прокси без роста ключевой — ловушка. Информационные метрики объясняют «почему», но по ним не решают.
Ключевая метрика (OEC) — одна, прямо отражает гипотезу и цель. Меняем кнопку оформления → ключевая метрика «конверсия в заказ». Именно по ней принимают решение, и именно под неё считают размер выборки. Если ключевых несколько и они тянут в разные стороны — решение становится произвольным.
Что это значит
Какое решение это меняет
Выбор ключевой метрики — само по себе решение: что вы готовы ухудшить, а что нет. Без guardrails «победа» может молча оплатиться оттоком.
Хороший дизайн всегда начинается с вопроса «по какой ОДНОЙ метрике мы примем решение и какие метрики не дадим просадить». Без guardrail легко внедрить изменение, которое подняло клики, но снизило выручку или выжгло удержание.
Прокси-метрики — мощный ускоритель, но и главный источник самообмана: команда радостно двигает прокси, а настоящая цель стоит. Поэтому связь «прокси → цель» проверяют на исторических данных, а не принимают на веру.
Где это встречается
Крупные продукты держат набор стандартных guardrail (скорость загрузки, краши, жалобы, отписки), которые проверяются в КАЖДОМ эксперименте автоматически — независимо от темы теста.
Поисковые и ленточные продукты особенно осторожны с прокси: «время в приложении» легко поднять залипательным мусором, поэтому рядом всегда держат долгосрочное удержание как guardrail.