Несколько задачек про A/B-тесты

Задача №1: вы работаете над приложением, которое позволяет получать последнюю информацию по рейсам — статус, продолжительность, погода в точке прибытия. Недавно вы выкатили фичу “онлайн-регистрация на рейс”, что вроде как должно улучшить user experience, но A/B тест говорит об обратном: снизилась продолжительность сессий, возросло количество отказов. Что вы будете делать? Как будете принимать решение, оставлять ли фичу или отрывать?

Итак, давайте разберемся, что же надо было делать в этой задачке. Сразу оговорюсь, здесь нет и не может быть какого-то одного правильного ответа. Мои рассуждения были бы применимы к продуктам, с которыми я работала, возможно, у вас все будет иначе.

Так вот, прежде всего в самой задаче вас должно было напрячь “вроде как должно улучшить user experience”. A/B тест не источник знаний о пользователе, это количественное исследование, которое должно подтвердить или опровергнуть гипотезу. То есть, на момент проведения теста у вас уже должны быть доказательства, что ваша фича что-то улучшает. Методы, конечно, сильно зависят от самого продукта, но возможность проверить в офлайне есть всегда — и это обязательно должно быть частью процесса! То есть, вы должны знать, что фича будет решением проблемы, ДО начала онлайн-тестов.

Вы хороший продакт, конечно же, все знаете и решаете запустить a/b тест. И вот как раз на этом этапе начинается самая веселуха.

Во-первых, потому что сам тест может быть настроен некорректно. Интересно, что сильное ухудшение заставит почти 80% менеджеров задуматься о поломке. В случае сильного же, но неожиданного улучшения все, скорее, побегут пить шампанское ;)

Во-вторых, сама фича может быть сломана — ну, например, как-то криво отображаться в одном из браузеров.

В-третьих, фича может быть и отличной с точки зрения ux, но при этом просаживать функциональные характеристики системы. Условно говоря, выкатили вы распрекрасную фичу с анимацией, а она замедляет время загрузки страницы на 1 секунду. Казалось бы, фигня, но вот, например, для LinkedIn это стоило 10% некликнутых выдач (а это просто дико много, учитывая, что борьба обычно идёт за десятые доли процента) . Именно поэтому сейчас правильнее проводить, не a/b, а multivariate тесты, но об этом в другой раз.

В-четвёртых, если вдруг все вышеперечисленное с вами не случилось, надо исследовать пользователей, попавших в эксперимент. Даже если вы учитываете когорты, паттерны и сезонность, нужно думать ещё и о времени привыкания: будет ли достаточно продолжительности теста, чтобы люди осознали изменения и оценили их? Не так уж редко что-то хорошее отторгается только потому, что оно новое.

Я, на самом деле, ооооочень кратко прошлась по основным проблемам, их намного больше.

Но вот мой главный посыл: на основе a/b тестов нельзя принимать решение, что фича не нужна.

Они вполне подойдут для ее обкатки, дополнительной проверки, что в продакшене ничего не ломается, но не более. Толковый менеджер легко сможет трактовать прокраску в красное как в пользу выкатки фичи, так и в пользу ее отрыва. Из нашей же задачи: снизилась продолжительность сессий — пользователей отпугивают изменения в интерфейсе, они ничего не понимают и уходят / пользователи быстрее находят то, что им требуется, быстрее решают свою задачу. Так что исходите из стратегии развития продукта, из решения конкретных пользовательских проблем, а не +0,3% по случайной метрике в a/b-тесте.

Задача №2: вы недавно устроились на новую работу (понятно, что продакт-менеджером :). Но в компании не используются A/B-тесты. Будете ли вы их внедрять, для чего и как будете убеждать разработчиков/руководство, что эти тесты нужны?

Прежде всего, ab-тесты, как многие правильно отметили, — это инструмент. Инструмент чей? Именно, продакт-менеджера. Зачем он продакту? Чтобы использовать в своих целях (спасибо, кэп!). Нет, правда:

1) чтобы общаться с разработчиками и убеждать их в правильности выбранной стратегии. Пример: прихожу я к разработчику и говорю — а давай-ка зафигачим с тобой новую фичу? Он такой: а зачем? Я: ну вот по ожиданиям должны значимо уменьшить долю отказов. Он: ну ок, поехали. Фигачит-фигачит, запускает в продакшн — а дальше ничего. Ну потому что разработчиков много, хрен его знает, его или не его фича повлияла на отказы. Или, может, в общей массе вообще ничего не было заметно, мы что, зря фигачили? A/B тест позволяет измерить вклад в изменение метрик конкретно этой фичи конкретно этого разработчика;

2) соответственно, чтобы общаться с руководством. Когда компания большая, руководству трудно оценивать успехи каждого — нужны какие-то понятные и легко измеримые числа. A/B тест для этих целей подходит как нельзя лучше; эти циферки прекрасно можно привязать к OKR и затем по ним выплачивать премию;

3) ну и чтобы общаться с релиз-инженером. Большая компания — много фич делается одновременно; нельзя все это впихнуть в один релиз. Приоритеты расставляются именно исходя из профита, который мы ожидаем получить. Как доказать профит? Предъявить результаты A/B теста (но, конечно, только при условии, что релиз-инженер тоже верит в эффективность этих тестов :)

Кому все это надо? Исключительно большим компаниям. У многих проскальзывала мысль, что А/В-тесты не увеличивают стоимость и сроки разработки. Еще как увеличивают! Окей, если вы сравниваете зеленую и красную кнопку, то не особо. Но если, например, две новых формулы ранжирования или два новых дизайна сниппета — то вполне себе. Ну и, соответственно, время внедрения увеличивается на время проведения теста (а это минимум неделя-две). Никакому стартапу это не надо: здесь надо двигаться быстро, можно выкатываться в продакшн и смотреть на живых пользователях. Потому что у вас мало пользователей, мало разработчиков и мало времени. Вам не нужны инструменты оценки продуктивности членов команды, вам не нужны инструменты приоритизации — потому что у вас и так есть продакт вижн, стратегия развития, и в данный момент вы громадным топором просто пытаетесь отсечь все лишнее. У больших же компаний уже есть работающий продукт; его нужно лишь полировать и шлифовать — и при этом не портить. Вот тут-то на сцену и могут выйти A/B тесты.

Продакт может ошибаться, это нормально и ожидаемо. Люди вообще переоценивают свою способность к рациональным и правильным решениям. Ошибки — налог на развитие.
Улучшается только тот, кто знает о своих ошибках. Чтобы знать — надо мерять результат относительно своей намеченной цели.

A/B тест — один из лучших способов измерять профит от небольших изменений.

Если же вы маленький стартап, сделайте сначала хороший и работающий продукт, пожалуйста :)