Рассмотрим следующую ситуацию. Мы открываем дашборд A/B-теста и видим красивую картинку: новая версия оформления заказа подняла конверсию в покупку, p-value < 0.05. Выкатываем?
Перед ответом на этот вопрос надо узнать, что с деньгами, возвратами и поддержкой? Потому что рост конверсии сам по себе ещё не доказывает, что продукту стало лучше.
Например, мы упростили оформление заказа. Пользователям стало легче дойти до оплаты, целевая метрика выросла. На первый взгляд, все отлично, но рядом могут происходить другие вещи:
- Показатель RPU (выручка на пользователя) просел, потому что пользователи стали чаще покупать дешевые товары.
- Возвраты выросли, потому что решение стало слишком быстрым и менее осознанным.
- Поддержка получила больше обращений, потому что новый сценарий хуже объясняет условия доставки.
- Повторные покупки не выросли, потому что первая покупка стала проще, но качество опыта не улучшилось.
Именно для отслеживания более широкого набора условий и ограничений нужны защитные метрики.
Защитные метрики отвечают не на вопрос «улучшилась ли фича?». Они отвечают на другой вопрос: «не сломали ли мы что-то важное, пока гнались за целевой метрикой?»
В нормальном эксперименте метрики обычно делятся на три слоя:
- Целевая метрика решает главный вопрос. Например: выросла ли недельная конверсия в первую покупку?
- Второстепенные метрики объясняют механизм. Например: выросло ли завершение оформления заказа, сократилось ли время до покупки?
- Защитные метрики не дают принять прирост по целевой метрике за успех. Например: не просел ли RPU, не выросли ли возвраты, обращения в поддержку, отмены, жалобы?
Излюбленная ошибка в индустрии — выбрать только одну красивую метрику и объявить тест успешным. Фича может делать действие проще, но приводить к уменьшению чека. Скорость оформления выросла, но ухудшилось качество и прозрачность операции и т. д.
Хороший A/B-тест должен строиться иначе. До запуска команда договаривается:
- По какой метрике принимаем решение;
- Какие метрики помогают понять механизм;
- Какие защитные метрики нельзя ухудшать;
- Какая просадка считается недопустимой;
- Что делаем, если целевая метрика выросла, а защитная метрика просела.
Последний пункт особенно важен! Защитные метрики нельзя придумывать после результата. Если сначала увидеть красивый p-value, а потом начать искать метрики, которые не мешают выкатке, это уже не анализ...
При принятии решений можно руководствоваться следующими правилами (на примере конверсии):
- Конверсия выросла, защитные метрики в норме: обсуждаем выкатку.
- Конверсия выросла, RPU просел: не выкатываем, дорабатываем.
- Конверсия выросла только в заранее важном сегменте: разбираем сегмент, не выкатываем всем автоматически.
- Данные по защитным метрикам сломаны: сначала чиним анализ, потом принимаем решение.
A/B-тест нужен не для того, чтобы принести красивый p-value. Он нужен, чтобы помочь команде принять правильное решение и не навредить продукту. Красивый показатель конверсии в тесте без учёта защитных метрик может быть не успехом, а дорогой ошибкой.