Guardrail-метрики (контрольные, защитные) в A/B тесте — это метрики, которые не должны ухудшиться, пока вы гонитесь за ростом основной. Их задача не расти, а держаться на месте: латентность страницы, доля отписок, churn, доля ошибок. Если основная метрика выросла, но guardrail пробил порог, эксперимент считается неуспешным даже при значимом плюсе.
Что такое guardrail-метрика простыми словами?
Когда вы оптимизируете одну метрику, легко случайно навредить другой. Типичный пример: агрессивные пуши поднимают открытия приложения (primary), но разгоняют отписки и удаления. Guardrail-метрика работает как ограничитель: она отслеживает потенциальный вред и говорит «стоп», если он превысил допустимый уровень.
В эксперименте обычно задают три типа метрик:
- Primary (основная) — то, ради чего запускали тест. Хотим значимого роста.
- Guardrail (контрольная) — то, что должно остаться в границах. Хотим НЕ ухудшить.
- Counter-metric (контр-метрика) — то, что почти наверняка меняется в обратную сторону и показывает цену изменения.
Guardrail бывают двух видов: продуктовые (churn, отписки, конверсия в оплату) и технические (латентность, доля 5xx-ошибок, крэши, время загрузки). Вторые часто важнее: медленный интерфейс убивает опыт незаметно для продуктовых дашбордов.
Зачем нужны контрольные метрики в эксперименте?
Основная причина — локальная оптимизация вредит системе в целом. Модель ранжирования может поднять клики за счёт кликбейта и одновременно уронить долгосрочное удержание. Без guardrail вы увидите зелёный primary и раскатите изменение, которое медленно съедает базу.
Что защищают guardrail:
- Пользователя — от роста ошибок, тормозов, спама.
- Бизнес — от каннибализации выручки, всплеска отписок, падения ретеншена.
- Валидность теста — сюда входят проверки целостности данных, прежде всего SRM (о ней ниже).
Практическое правило: primary у теста один (максимум два), а guardrail — фиксированный набор из 3-7 метрик, одинаковый для всех экспериментов команды. Тогда их не подбирают задним числом под удобный результат.
Чем guardrail отличается от primary и counter-метрик?
| Тип метрики | Чего хотим | Пример | Что делаем, если сдвинулась |
|---|---|---|---|
| Primary | Значимого роста | Конверсия в покупку | Раскатываем, если значимо вырос |
| Guardrail | Не ухудшить (в пределах порога) | Латентность p95, churn, отписки | Блокируем раскатку, если пробит порог |
| Counter-metric | Понять цену изменения | Средний чек при росте частоты покупок | Смотрим на баланс, не блокирует напрямую |
Ключевое отличие — в логике решения. Для primary нуль-гипотеза «эффекта нет», и мы рады её отвергнуть. Для guardrail всё наоборот: мы хотим убедиться, что вреда нет, то есть проверяем на неухудшение. Часто по guardrail ставят одностороннюю проверку и более мягкий порог значимости, потому что цена ложной тревоги (заблокировать хороший тест) высока.
Как выбирать guardrail-метрики?
Хороший набор отвечает на вопрос «что здесь может сломаться, даже если основная цифра растёт». Ориентиры:
- Стабильность вне экспериментов. Guardrail должна быть спокойной на A/A-тестах. Шумную метрику вы будете пробивать случайно.
- Чувствительность к реальному вреду. Отписки, churn, ошибки, латентность напрямую отражают ухудшение опыта.
- Достаточная мощность. Редкое событие вроде отписки трудно поймать на маленькой выборке. Иногда берут прокси-guardrail с большей частотой событий.
- Единый набор на команду. Список фиксируется заранее и не меняется под конкретный тест.
Не путайте guardrail с диагностическими метриками. Диагностика (например, распределение трафика по устройствам) помогает объяснить результат, но не блокирует раскатку.
SRM как guardrail: что проверять первым?
SRM (Sample Ratio Mismatch) — расхождение фактического распределения пользователей по группам с задуманным. Если планировали 50/50, а на большой выборке получили 51.8/48.2, это почти наверняка баг: кривой сплиттер, потерянные логи, редирект, который асимметрично отсекает часть пользователей. При SRM результатам теста доверять нельзя — искажённой может оказаться любая другая метрика.
SRM проверяют критерием хи-квадрат: сравнивают наблюдаемые и ожидаемые размеры групп. Статистика:
^2 = Σ_i ((O_i - E_i)^2) / (E_i)
где O_i — фактическое число пользователей в группе, E_i — ожидаемое. Порог тревоги ставят жёстким: p-value < 0.001. При таком уровне ложная тревога редка, а реальный SRM ловится уверенно.
Посчитать распределение можно прямо в SQL:
SELECT
variant,
COUNT(DISTINCT user_id) AS users
FROM ab_assignments
WHERE experiment_id = 'checkout_v2'
GROUP BY variant;
-- дальше сравниваем users с ожидаемым сплитом
-- и считаем хи-квадрат (числа условные)Если группы должны быть равны, а получилось 50 000 против 48 000 при суммарных 98 000, это уже повод считать хи-квадрат и, скорее всего, останавливать анализ.
Как посчитать SRM руками?
Числа ниже иллюстративные. Запланирован сплит 50/50, всего 100 000 пользователей, ожидаем по 50 000 в группе. Факт:
- Control:
O_A = 50 900 - Treatment:
O_B = 49 100 - Ожидаемо:
E = 50 000в каждой
Считаем статистику:
^2 = ((50900 - 50000)^2) / (50000) + ((49100 - 50000)^2) / (50000)
^2 = (810000) / (50000) + (810000) / (50000) = 16.2 + 16.2 = 32.4
При одной степени свободы критическое значение для p = 0.001 равно примерно 10.83. Наши 32.4 намного больше, p-value < 0.001 — SRM подтверждён. Разница в 1.8% на глаз кажется мелочью, но статистически это громкий сигнал: анализ надо остановить и искать причину рассинхрона до любых выводов по primary.
Тот же подход работает для продуктового guardrail. Допустим, primary (конверсия) в treatment вырос с 4.0% до 4.3%, но guardrail «доля отписок» поднялась с 1.0% до 1.6% при заранее заданном пороге «не более +0.3 п.п.». Порог пробит — раскатывать нельзя, несмотря на плюс по конверсии.
Частые ошибки
- Нет guardrail вообще. Смотрят только на primary и раскатывают изменение, которое роняет ретеншен через месяц.
- Guardrail подбирают после теста. Набор должен фиксироваться до старта, иначе это подгонка под удобный вывод.
- Игнорируют SRM. Красивый лифт по primary при наличии SRM — артефакт, а не результат. Проверяйте SRM до всего остального.
- Одинаковый порог значимости для primary и guardrail. У guardrail другая логика: цена ложной тревоги высока, поэтому пороги и односторонность продумывают отдельно.
- Слишком много guardrail. 15 контрольных метрик почти гарантируют случайное срабатывание из-за множественных сравнений. Держите короткий стабильный список и при необходимости корректируйте на множественность.
- Путают guardrail с counter-metric. Counter показывает цену изменения (её ждём), guardrail сигналит о недопустимом вреде (его быть не должно).
Что запомнить
Guardrail-метрики — это страховка эксперимента: они не дают выкатить изменение, которое улучшает одну цифру ценой вреда в другом месте. Минимальный набор — технический guardrail (латентность, ошибки), продуктовый (churn, отписки) и обязательная проверка SRM как метрики целостности данных.
Потренируйте расчёты долей, хи-квадрата и агрегаций на реальных сценариях в SQL-тренажёре и Python-песочнице, а логику разбора A/B-результатов — в блоке кейсов. Если готовитесь к интервью, соберите вопросы про эксперименты в разделе собеседований и посмотрите разбор расчёта результатов A/B-теста в SQL.