Итак, давайте разберемся, что же надо было делать в задачке из предыдущего поста.
Сразу оговорюсь, здесь нет и не может быть какого-то одного правильного ответа. Мои рассуждения были бы применимы к продуктам, с которыми я работала, возможно, у вас все будет иначе.
Так вот, прежде всего в самой задаче вас должно было напрячь "вроде как должно улучшить user experience". A/B тест не источник знаний о пользователе, это количественное исследование, которое должно подтвердить или опровергнуть гипотезу. То есть, на момент проведения теста у вас уже должны быть доказательства, что ваша фича что-то улучшает. Методы, конечно, сильно зависят от самого продукта, но возможность проверить в офлайне есть всегда - и это обязательно должно быть частью процесса! То есть, вы должны знать, что фича будет решением проблемы, ДО начала онлайн-тестов.
Вы хороший продакт, конечно же, все знаете и решаете запустить a/b тест. И вот как раз на этом этапе начинается самая веселуха.
Во-первых, потому что сам тест может быть настроен некорректно. Интересно, что сильное ухудшение заставит почти 80% менеджеров задуматься о поломке. В случае сильного же, но неожиданного улучшения все, скорее, побегут пить шампанское ;)
Во-вторых, сама фича может быть сломана – ну, например, как-то криво отображаться в одном из браузеров. В-третьих, фича может быть и отличной с точки зрения ux, но при этом просаживать функциональные характеристики системы. Условно говоря, выкатили вы распрекрасную фичу с анимацией, а она замедляет время загрузки страницы на 1 секунду. Казалось бы, фигня, но вот, например, для LinkedIn это стоило 10% некликнутых выдач (а это просто дико много, учитывая, что борьба обычно идёт за десятые доли процента) . Именно поэтому сейчас правильнее проводить, не a/b, а multivariate тесты, но об этом в другой раз.
В-четвёртых, если вдруг все вышеперечисленное с вами не случилось, надо исследовать пользователей, попавших в эксперимент. Даже если вы учитываете когорты, паттерны и сезонность, нужно думать ещё и о времени привыкания: будет ли достаточно продолжительности теста, чтобы люди осознали изменения и оценили их? Не так уж редко что-то хорошее отторгается только потому, что оно новое.
Я, на самом деле, ооооочень кратко прошлась по основным проблемам, их намного больше. **Но вот мой главный посыл: на основе a/b тестов нельзя принимать решение, что фича не нужна**. Они вполне подойдут для ее обкатки, дополнительной проверки, что в продакшене ничего не ломается, но не более. Толковый менеджер легко сможет трактовать прокраску в красное как в пользу выкатки фичи, так и в пользу ее отрыва. Из нашей же задачи: снизилась продолжительность сессий – пользователей отпугивают изменения в интерфейсе, они ничего не понимают и уходят / пользователи быстрее находят то, что им требуется, быстрее решают свою задачу. Так что исходите из стратегии развития продукта, из решения конкретных пользовательских проблем, а не +0,3% по случайной метрике в a/b-тесте.
Сразу оговорюсь, здесь нет и не может быть какого-то одного правильного ответа. Мои рассуждения были бы применимы к продуктам, с которыми я работала, возможно, у вас все будет иначе.
Так вот, прежде всего в самой задаче вас должно было напрячь "вроде как должно улучшить user experience". A/B тест не источник знаний о пользователе, это количественное исследование, которое должно подтвердить или опровергнуть гипотезу. То есть, на момент проведения теста у вас уже должны быть доказательства, что ваша фича что-то улучшает. Методы, конечно, сильно зависят от самого продукта, но возможность проверить в офлайне есть всегда - и это обязательно должно быть частью процесса! То есть, вы должны знать, что фича будет решением проблемы, ДО начала онлайн-тестов.
Вы хороший продакт, конечно же, все знаете и решаете запустить a/b тест. И вот как раз на этом этапе начинается самая веселуха.
Во-первых, потому что сам тест может быть настроен некорректно. Интересно, что сильное ухудшение заставит почти 80% менеджеров задуматься о поломке. В случае сильного же, но неожиданного улучшения все, скорее, побегут пить шампанское ;)
Во-вторых, сама фича может быть сломана – ну, например, как-то криво отображаться в одном из браузеров. В-третьих, фича может быть и отличной с точки зрения ux, но при этом просаживать функциональные характеристики системы. Условно говоря, выкатили вы распрекрасную фичу с анимацией, а она замедляет время загрузки страницы на 1 секунду. Казалось бы, фигня, но вот, например, для LinkedIn это стоило 10% некликнутых выдач (а это просто дико много, учитывая, что борьба обычно идёт за десятые доли процента) . Именно поэтому сейчас правильнее проводить, не a/b, а multivariate тесты, но об этом в другой раз.
В-четвёртых, если вдруг все вышеперечисленное с вами не случилось, надо исследовать пользователей, попавших в эксперимент. Даже если вы учитываете когорты, паттерны и сезонность, нужно думать ещё и о времени привыкания: будет ли достаточно продолжительности теста, чтобы люди осознали изменения и оценили их? Не так уж редко что-то хорошее отторгается только потому, что оно новое.
Я, на самом деле, ооооочень кратко прошлась по основным проблемам, их намного больше. **Но вот мой главный посыл: на основе a/b тестов нельзя принимать решение, что фича не нужна**. Они вполне подойдут для ее обкатки, дополнительной проверки, что в продакшене ничего не ломается, но не более. Толковый менеджер легко сможет трактовать прокраску в красное как в пользу выкатки фичи, так и в пользу ее отрыва. Из нашей же задачи: снизилась продолжительность сессий – пользователей отпугивают изменения в интерфейсе, они ничего не понимают и уходят / пользователи быстрее находят то, что им требуется, быстрее решают свою задачу. Так что исходите из стратегии развития продукта, из решения конкретных пользовательских проблем, а не +0,3% по случайной метрике в a/b-тесте.
