Одна из самых больших опасностей A/B-тестирования заключается в «шлифовке локального максимума», когда вы максимально оптимизируете что-либо, не замечая гораздо более ценные возможности (рис. 7.3).
Рис. 7.3. Из-за шлифовки локального максимума можно не заметить гораздо более ценные возможности
В дополнение к тому, что вы отслеживаете количественные показатели по целевым метрикам, полученным с помощью каждого теста A/B, вам также необходимо провести качественную оценку их значения. Подтвердили ли они правильность теста, частично или полностью? Выявили ли недостатки гипотезы (или самого теста)? Дают ли основание для проведения дальнейших гипотез или дополнительных тестов для проверки?
Это часть интеллектуального арсенала вашего продукта, и наращивать ее с течением времени даже важнее, чем «выигрывать» текущие тесты, которые вы проводите.
Это правда, что вы учитесь даже на тестах, не подтверждающих результаты, к которым вы стремились. И некоторые люди готовы утверждать, что, как правило, на отрицательных результатах вы учитесь больше, чем на положительных (хотя я считаю это верным, только если вы принимаете положительный результат как должное и отказываетесь изучать его и обдумывать так же тщательно, как неудачи).
Однако выигрывать – это лучше!
И как только вы одержите победу, вы можете завершить свой тест[44] и «закрепить его». И тогда пользу от улучшения, обнаруженного в ходе тестирования, может почувствовать каждый, а не только половина ваших пользователей или половина из 10 % ваших новых пользователей.
Затем наступает время посмотреть, возможно ли добавить еще несколько выигрышей поверх первого. Был ли тест чрезмерно агрессивным или вы подстраховали свои ставки, чтобы избежать нарушения других показателей? Может ли последующий тест поднять ситуацию на новую ступень? Если нет никакого простого варианта успешного теста, который можно было бы попробовать, то как насчет других экспериментов в списке по приоритетности в стеке? Попробуйте один из них! В некоторых случаях вы можете возвращаться к одному и тому же источнику несколько раз и превращать 20-процентное увеличение в 100-процентное, или пятикратное улучшение в десятикратное.
Поражения учат вас чему-то, но вот зафиксированные победы могут остаться с вами навсегда.
A/B-тесты – это блестящая вещь, которая привлекает специалистов по продукту. Они кажутся простыми для объяснения и понимания, но могут вводить в заблуждение и вселять в вас ложное чувство уверенности.
Помимо риска, который, как вы уже видели, связан со шлифовкой локального максимума, существует несколько других серьезных ловушек, кроющихся в использовании этого типа тестирования для принятия решений.
Большинство из них сводятся к двум основным идеям:
• нет способа узнать наверняка, повлияли ли внешние факторы на ваш тест и приведет ли повторное его проведение уже при других обстоятельствах к таким же результатам;
• в лучшем случае вы узнаете, что именно происходит, но на вопрос «почему?» A/B-тест не дает ответа.
Первая группа проблем связана с приданием тестированию слишком большого значения. В некотором смысле статистически значимый тест искажает окружающие его догадки. (По крайней мере, когда у вас есть простые «направляющие» сигналы, вы вынуждены относиться ко всему скептически, проверять закономерности и исследовать потенциальные причины наблюдаемого поведения.)
Вторая группа проблем связана с прогнозированием субъективных качественных интерпретаций данных без их подтверждения. Как и в случае со многими другими доступными для вас сигналами метрик, такими как удовлетворенность клиента или показатель лояльности клиентов, отзывы пользователей, оценки и обзоры, количество жалоб в службу поддержки и так далее, реальная задача состоит в том, чтобы провести ваши исследования, опросить пользователей и глубже понять, почему эти вещи происходят именно таким образом, а не только изучать сами явления.
ИСТОРИИ ИЗ ЖИЗНИ
Еще одна проблема, связанная с A/B-тестами, заключается в том, что их не всегда можно провести за пределами продуктов массового потребления с прямыми продажами. Как объяснил Клемент Као в своем описании дня из жизни менеджера по продуктам B2B, проблема не в том, что пользовательская база многих бизнес-продуктов слишком мала, но и в том, что клиенты – это не анонимные точки данных, а конкретные предприятия и люди, вовлеченные в чувствительные отношения. «Экспериментировать» с этими клиентами, показывая половине из них один интерфейс, а половине другой, – это разрушительный дохлый номер.
Као сказал: «В B2B вы на самом деле не можете провести A/B-тестирование, потому что кто-то пытается использовать ваш продукт для ведения своего бизнеса. Если нужно обучить одну когорту пользователей запускать один рабочий процесс, а другую – второй, то вы определенно не сможете это сделать. Точно так же бесполезно нанимать случайного „корпоративного пользователя“, если вы работаете с конкретными клиентами из компании».
Что есть кроме A/B-тестов
У менеджеров продукта есть плохая привычка приравнивать все эксперименты к A/B-тестированию (так же как некоторые сводят все UX-исследования к юзабилити-тестированию). Помните, что эксперименты вплетаются в работу по продукту на каждом уровне. Если более конкретно, то какие другие формы экспериментов, кроме популярного группового теста, следует рассмотреть?
• Разновидности A/B-тестов
• «Консьерж» (Concierge)
• «Волшебник из страны Оз» (Wizard of Oz)
• Претотипы (Pretotypes)
• Smokescreen-тестирование (Smokescreen)
• «Фальшивая дверь» (Fake door)
• «Разбитое стекло», или «Жесткий тест» (Broken glass, или Hard test)
• Внутреннее тестирование (Dogfooding)
• Частичное развертывание (Partial rollouts)
• Бета-версии программ (Beta programs)
• Режим удержания (Holdover, или Holdback)
• Эксперименты с продажами
• Технологические эксперименты
Вы можете найти хорошую схему по всем этим методикам в «Руководстве по тестированию идей продукта» (Testing Product Ideas Handbook) Итамара Гилада (для доступа требуется бесплатная подписка на рассылку новостей), рис. 7.4.
Эта диаграмма разграничивает «эксперименты» от других форм проверки идей, но большинство методов в его наборе тестов – это эксперименты в том смысле, который подразумевается в этой главе.
Рис. 7.4. Хорошая визуализация многочисленных форм экспериментов, тестирования и валидации
Поскольку A/B-тест имеет свои ограничения, то перед его использованием вам следует познакомиться с другими похожими экспериментами, такими как A/B/C-тесты и многовариантное тестирование. В A/B-тесте A – это обычно контроль (существующий интерфейс), а B – тестируемый вариант в сравнении с А. В A/B/C-тесте вы разделяете трафик на три группы одинакового размера и сравниваете контроль с двумя разными вариантами.
Мультивариантный тест еще сложнее. В этом случае вы пытаетесь протестировать сразу несколько вещей. Чтобы использовать тривиальный пример, рассмотрим цвет кнопки, форму и текст.
Мультивариантный тест разбивает пользователей на несколько групп. Итак, часть пользователей будет видеть красную кнопку с закругленными углами, на которой написано «Заходи сюда!», а другие – зеленую кнопку также с закругленными углами и словами «Начни сегодня», и так далее. Каждая комбинация всех возможностей требует еще большего трафика, чтобы получить статистически значимые цифры, а интерпретация результатов является сложной и запутанной задачей.
Если команды одновременно проводят несколько A/B-тестов, то часто на самом деле они выполняют неорганизованные мультивариантные тесты, не осознавая этого.
В консьерж-эксперименте предоставляемая услуга обрабатывается не программным алгоритмом, а реальным человеком за кулисами (иногда стажером).
► ДВА ЗНАЧЕНИЯ СЛОВА «КОНСЬЕРЖ»
Слово «консьерж» не стоит путать с «функциями консьержа», например с чат-ботом, который помогает вам найти и запустить опции в продукте.
Роль этого человека может быть явной или завуалированной, но цель консьерж-теста состоит в том, чтобы узнать, какие ценности клиента, процессы, последовательности действий, язык и другие варианты работают лучше всего. Как только вы определите это, вы запустите написанный код, который будет исключать людей из рабочего процесса предоставления услуг, что позволит расширить функциональность и обслуживать большее количество пользователей, чем вручную.
Если вы заранее расскажете, что услуга предоставляется человеком, то, как сказал Том Кервин, «ведя диалог и решая проблемы в реальном времени, вы получите смехотворное количество практических данных и опыта».
Кстати, родственная концепция «механический турок» (англ. Mechanical Turk) (не путать с краудсорсинговым сервисом поиска работы от Amazon), вероятно, скоро станет новым термином. А название ее произошло от устройства для игры в шахматы в XVIII веке, где в механизме прятался человек-оператор.
Тестирование «Волшебник из страны Оз» очень похоже на консьерж-тестирование, но в нем предоставляется убедительный пользовательский интерфейс и не раскрывается тот факт, что на другом конце печатает и выполняет задания человек.
ИСТОРИИ ИЗ ЖИЗНИ
Том Кервин: «Прошлым летом у меня был потрясающий опыт проведения для MVP „Волшебника страны Оз“ с небольшой командой. Всего за восемь дней мы сформировали команду, внедрили продукт с определенной ценностью и получили реальных клиентов. Затем мы повторяли это еженедельно. Первая отправка заняла три дня ручной работы у всей команды. Каждую неделю инженеры устраняли наиболее неприятную ошибку, и примерно через восемь недель весь процесс сократился до 15 минут».