Основная метрика и guardrail в A/B-тесте: что считать успехом

Коротко

Primary metric — главный показатель, по которому принимают решение по гипотезе. Secondary metrics помогают понять механизм. Guardrails защищают продукт от побочных эффектов: их не обязательно улучшать, но нельзя ухудшать сильнее заранее заданного порога.

• Выбирайте primary metric ближе к пользовательской или бизнес-ценности, а не к самому частому клику.
• Guardrail должен быть связан с реальным риском изменения и иметь понятный порог.
• Не превращайте двадцать показателей в двадцать основных метрик.
• Фиксируйте направление и окно расчёта до запуска.

Три слоя метрик

Удобно разделить показатели на три слоя. Primary отвечает, достигнута ли цель гипотезы. Secondary показывает, почему результат мог появиться: например, больше людей начали onboarding и быстрее дошли до первого отчёта. Guardrails ловят цену изменения: ошибки, возвраты, отписки или нагрузку на поддержку.

Как выбрать primary metric

Начните с решения, которое должна поддержать гипотеза. Если изменение обещает уменьшить friction в checkout, primary — успешная оплата среди пользователей, которые начали checkout, а не количество кликов по кнопке. Если меняется onboarding для B2B, может быть честнее смотреть создание первого рабочего объекта в течение семи дней, а не открытие подсказки.

Метрика должна быть чувствительной к изменению, но не настолько близкой к интерфейсу, чтобы её можно было улучшить без реальной ценности. Проверьте также задержку: показатель, который созревает через месяц, может быть плохим единственным primary для короткого цикла.

• Назовите единицу анализа: пользователь, аккаунт, заказ или сессия.
• Опишите знаменатель одним предложением.
• Зафиксируйте окно: в той же сессии, 24 часа, 7 дней или другой срок.
• Проверьте, что изменение действительно может повлиять на метрику.

Guardrail должен защищать, а не пугать

Если добавить в guardrails весь дашборд, команда никогда не сможет принять решение: любой шум будет выглядеть как риск. Оставьте показатели, на которые изменение действительно может повлиять и которые нельзя пропустить. Для checkout это ошибки и возвраты; для push — отписки и жалобы; для поиска — время ответа и нулевая выдача.

Как принять решение по набору метрик

Перед запуском напишите короткое правило. Например: «Релизуем, если primary вырос не меньше чем на 1 п.п., 95%-й интервал не пересекает ноль, а refund rate не увеличился более чем на 0,5 п.п. Secondary используем для диагностики, но не меняем ими критерий после просмотра результата». Такое правило снимает спор о том, какая цифра сегодня важнее.

Primary, secondary и guardrail: роли не смешиваются

Primary metric отвечает на главный вопрос эксперимента. Secondary metrics помогают понять путь к результату: например, не только завершённая покупка, но и добавление в корзину или время до оформления. Guardrail защищает от побочного ущерба: возвратов, ошибок, отписок, жалоб или ухудшения маржи. Один и тот же показатель нельзя без объяснения считать то основным, то защитным.

Если команда выбирает пять primary metrics, она фактически оставляет несколько возможностей объявить победу. Это усложняет интерпретацию и повышает риск случайного сигнала. Выберите один основной outcome, а спорные показатели переведите в secondary или guardrails с заранее записанными порогами.

Три равноправные основные метрики — это три двери для победы, 14% вместо 5%

Соблазн записать несколько главных показателей «чтобы посмотреть шире» живёт дольше любых договорённостей о ролях. У этого решения есть цена, и она считается. Три независимые проверки при пороге 0,05 дают 1 − 0,95³ = 14% вероятности, что хотя бы одна покажет победу при полном отсутствии эффекта. Пять проверок — 23%. Вопрос не в статистике, а в том, сколько у теста дверей, через которые он способен выйти победителем.

Если от двух показателей действительно не уйти, порядок спасает лучше поправок. Иерархическая схема: вторую метрику читают только тогда, когда первая прошла свой порог. Не прошла — вторая не обсуждается. Суммарный риск остаётся на уровне 5%, потому что дверь по-прежнему одна, просто за ней стоит ещё одна проверка. Порядок записывают до запуска: какая метрика первая, что означает её неудача и можно ли вообще в этом случае что-то раскатывать.

Второй способ — свести цели в одно число заранее. Для checkout это может быть не «оплаты» и «возвраты» по отдельности, а маржа на начатую сессию: успешный заказ добавляет 600 ₽, возврат вычитает их вместе со стоимостью обработки. Получается один показатель, внутри которого компромисс уже посчитан, и читать его нужно один раз. Цена подхода — обменный курс между целями приходится назвать вслух и защитить до теста, а не после.

Отдельный случай — когда спорят две продуктовые метрики, и ни одна не защитная. Новая сортировка каталога поднимает конверсию на 1,2 п.п. и снижает средний чек на 4%. Без обменного курса спор неразрешим: выручка на сессию — способ сложить эти два числа. Посчитайте её заранее и сделайте основной метрикой, а конверсию и чек оставьте вторичными. При расчёте проверьте отношение сумм и единицу назначения: средний чек на заказ и выручка на сессию отвечают на разные вопросы. Тогда тест отвечает на один вопрос, а не предлагает команде выбрать удобный ответ из двух.

Ограничивать число показателей в отчёте не нужно — ограничивать нужно число показателей, которые дают право на решение. Двадцать метрик на дашборде помогают понять механизм и найти риск; право сказать «работает» остаётся у одной из них плюс у заранее записанного набора ограничителей.

Выбирайте guardrail по механизму риска

Защитный показатель не должен быть случайным списком всего, что есть в продукте. Свяжите его с механизмом изменения. Если ускоряете checkout, возможен рост ошибочных заказов и возвратов. Если меняете рекомендации, риск — в нулевой выдаче, скрытии продавцов или снижении разнообразия. Если увеличиваете push-коммуникации, следите за отписками и жалобами, а не за каждым кликом в приложении.

Хороший guardrail имеет понятный знаменатель и окно. «Ошибки выросли» недостаточно: нужно знать, сколько ошибок на тысячу попыток и когда они считаются. Иначе большой поток пользователей сам создаст больше абсолютных ошибок, хотя доля станет ниже.

• Запишите, каким способом изменение может навредить пользователю или бизнесу.
• Выберите показатель, который отражает именно этот риск.
• Определите минимально заметное ухудшение до запуска.
• Проверьте, что событие guardrail собирается одинаково в обеих группах.
• Назначьте владельца расследования при пересечении порога.

Знаменатель важнее красивого числа

Primary и guardrail должны считаться на сопоставимых популяциях. Например, refund rate среди оплаченных заказов нельзя напрямую сравнить с ошибками оплаты среди всех посетителей checkout. Разные знаменатели отвечают на разные вопросы, и смешивание уровней может создать иллюзию компромисса.

Заранее решите, кто входит в анализ: все назначенные пользователи, только увидевшие вариант или только достигшие промежуточного шага. Intent-to-treat обычно сохраняет преимущества рандомизации, а анализ только «дошедших» пользователей может быть полезен для диагностики, но вводит selection bias.

Как читать конфликт между метриками

Самый сложный результат — primary растёт, а guardrail ухудшается. Здесь нельзя автоматически выбрать одну цифру. Сравните масштаб эффекта, стоимость риска, сегменты и устойчивость по времени. Иногда +4% к оплатам с +18% к возвратам — очевидно плохой компромисс. Иногда небольшой рост ошибок на новом потоке компенсируется большой маржой, но это должно быть решением бизнеса, а не случайностью эксперимента.

Разложите конфликт на сегменты: устройство, новый или возвращающийся пользователь, тип товара, способ оплаты. Если риск сосредоточен в одной группе, staged rollout может быть безопаснее полного отката. Если ухудшение системное, лучше остановить релиз и вернуться к механизму, а не искать сегмент, где цифра выглядит удобнее.

Ограничитель пересёк порог: четыре проверки до того, как остановить раскатку

Paywall поднял долю платящих на 1,4 п.п., а отмены в первые семь дней выросли на 0,8 п.п. при записанном пороге 0,2 п.п. Ограничитель сработал, и дальше у команды два одинаково плохих рефлекса: откатить сегодня же или списать на шум. Между ними четыре проверки, каждая занимает меньше дня.

Первая — зрелость окна. Метрика отмен за семь дней требует, чтобы у пользователя эти семь дней прошли. Если тест идёт десять дней, полное окно есть только у части оплат: например, у 4 100 из 6 200 в тестовой группе. Считайте по ним и по такой же зрелой части контроля, иначе группы сравниваются на разной длине наблюдения, и часть «ухудшения» окажется просто разной датой оплаты.

Вторая — неопределённость. Четыре ограничителя при пороге 0,05 дают 1 − 0,95⁴ = 19% шанса, что хотя бы один покажет ухудшение без причины. Поэтому у защитной метрики читают интервал, а не точку. Прирост +0,8 п.п. с интервалом от +0,1 до +1,5 — это ухудшение выше порога; тот же прирост с интервалом от −0,3 до +1,9 держать раскатку не должен, но и откатывать по нему рано: его закрывает ещё одна неделя данных, а не решение.

Третья — состав. Paywall впустил в оплату людей, которых раньше там не было, и доля отмен может вырасти без того, чтобы кто-то стал отменять чаще: в знаменателе другая публика. Проверка прямая — посчитать отмены внутри однородных групп: по давности регистрации, по тарифу, по способу оплаты. Если внутри каждой группы отмены на месте, а общее число выросло, сработал сдвиг состава, и решение про paywall тут другое: он привёл аудиторию, которая отменяет чаще, и вопрос в обещании для этой аудитории.

Четвёртая — механизм. Найдите действие, которое ведёт к вреду: экран, на котором пользователь не увидел условия, способ оплаты с автопродлением, текст оферты. Механизм превращает сигнал в точечную правку. Без него выбор ограничен двумя грубыми вариантами — оставить всё как есть или откатить целиком.

Соберите результат в одну строку для владельца метрики: порог, факт, интервал, сегмент, механизм, предложение. Откат без этих четырёх проверок стоит команде столько же, сколько неоправданная раскатка: в обоих случаях никто не узнал, что именно произошло, и следующая гипотеза начнётся с того же места.

Decision rule до запуска

Запишите правило в одну-две фразы и покажите его команде до начала теста. Например: «Релизуем, если primary вырос не меньше чем на 1 п.п., 95%-й интервал не пересекает ноль, refund rate не увеличился более чем на 0,5 п.п., а ошибки оплаты не выросли более чем на 5%». Secondary остаются диагностикой и не меняют критерий задним числом.

Правило не обязано предусмотреть каждый исход. Его задача — убрать спор о том, какая цифра сегодня важнее, и заранее назначить следующий шаг. Для промежуточного решения добавьте staged rollout, повторную проверку и список владельцев.

Не выбирайте метрику, на которую изменение не влияет

Primary должна быть достаточно близко к механизму изменения, но не настолько близко, чтобы превращаться в технический прокси. Если команда меняет порядок экранов, промежуточный клик может вырасти сразу, хотя покупка не изменится. Если изменение влияет на ассортимент, одной конверсии недостаточно: нужно понять, не ухудшилось ли качество и разнообразие результата.

Проверьте причинную цепочку до запуска: какое действие меняется первым, какой следующий шаг оно должно улучшить и где появляется бизнес-эффект. Secondary metrics помогают пройти эту цепочку. Guardrails должны защищать реальные риски, а не быть коллекцией всех доступных показателей.

Порог guardrail должен быть обоснован

Фраза «guardrail не должен ухудшиться» слишком строгая для шумного показателя и слишком расплывчатая для решения. Определите допустимый диапазон: сколько дополнительных ошибок или возвратов бизнес готов принять ради primary-эффекта? Порог может быть связан с экономикой, SLA, договором или пользовательским риском.

Не делайте guardrail настолько чувствительным, что любой случайный шум блокирует релиз. Для редких событий полезно смотреть абсолютное число и интервал, а также использовать staged rollout. Для критического риска, наоборот, небольшой рост может быть достаточным поводом остановиться. Порог — это договорённость о действии, а не магическое статистическое число.

После победы всё равно нужен rollout

Статистически убедительный результат на тестовой аудитории не означает, что можно мгновенно включить изменение всем. Staged rollout помогает проверить, сохраняется ли эффект на новом объёме, не появляется ли нагрузка на инфраструктуру и не меняется ли поведение команды. Для каждого этапа заранее назначьте критерии продолжения и отката.

На rollout повторно следите за primary и guardrails, но не называйте каждый новый срез отдельным A/B-тестом. Сравнивайте фактический эффект с экспериментом, проверяйте технические метрики и записывайте отличия аудитории. Если результат исчез, исследуйте причину: это может быть эффект новизны, взаимодействие с другими релизами или изменение трафика.

• 10–25% трафика: проверить техническую стабильность и критические риски.
• 50% трафика: сравнить эффект с исходным экспериментом.
• 100%: оставить мониторинг и дату post-launch review.
• Откат: заранее определить владельца и допустимое время реакции.

Мини-кейс: primary растёт, а опыт становится хуже

Представим, что команда упростила checkout и получила +4% к оплатам. Одновременно refund rate вырос на 18%, а обращения в поддержку — на 12%. Если смотреть только на primary, релиз кажется победой. Если связать метрики с экономикой и опытом, становится видно, что часть пользователей завершает заказ, не понимая условий доставки или итоговой цены.

Правильное решение здесь не выбирает одну цифру. Сначала нужно разобрать сегмент, тип товара, способ оплаты и причины возврата. Возможно, проблема локальна и staged rollout с изменённым текстом решит её. Возможно, механизм изменения слишком агрессивен и нужно откатить его. Guardrail даёт сигнал для расследования, а не автоматически отвечает за всю причинность.

До запуска такой сценарий должен быть описан в decision rule. Например: «Раскатываем при росте paid order rate минимум на 1 п.п., если refund rate не увеличился более чем на 0,5 п.п. и complaint rate не превысил baseline на 3%». Тогда итоговый вывод не зависит от того, какая цифра первой попалась в презентации.

Guardrail как часть бизнес-решения

Guardrail полезен только тогда, когда понятно, кто и что делает при его ухудшении. Для ошибок оплаты это может быть инженерный владелец, для возвратов — команда коммерции, для жалоб — support. Запишите owner рядом с порогом, иначе аналитик обнаружит риск, но решение застрянет между командами.

После теста не ограничивайтесь сравнением среднего. Посмотрите, как guardrail связан с unit economics и пользовательским опытом. Небольшой рост возвратов у дешёвых заказов может иметь другой смысл, чем такой же рост у дорогой категории. Защитная метрика помогает задать направление расследования, а не отменяет бизнес-контекст.

Сделайте guardrail наблюдаемым

Порог бесполезен, если его нельзя увидеть вовремя. Добавьте на дашборд текущий уровень, baseline, интервал, дату последнего обновления и owner. Для отложенных возвратов покажите, какая часть окна уже созрела. Иначе команда примет решение по неполному guardrail и обнаружит риск позже.

• Текущее значение и baseline.
• Порог внимания и порог отката.
• Зрелость окна и свежесть данных.
• Ответственный за расследование.

Проведите post-launch review

Через несколько дней после rollout сравните не только результат теста, но и фактический опыт пользователей. Проверяйте ошибки, возвраты, обращения и нагрузку на операционную команду. Guardrail может сработать с задержкой, поэтому дата окончательного review должна быть частью плана, а не случайным напоминанием.

Если риск не проявился, сохраните это как подтверждение границы, а не как доказательство вечной безопасности. Если проявился — зафиксируйте сегмент, причину и решение: откатить, изменить интерфейс или оставить ограниченный rollout. Так защитные метрики превращаются в память продукта.