В табл. 7.1 показан набор гипотез в сочетании с экспериментами, которые могли бы помочь доказать их тем или иным способом.
Таблица 7.1. Набор гипотез и экспериментов для их проверки
Кроме того, гипотезы и эксперименты не всегда должны соответствовать друг другу напрямую. Вы можете – и часто должны – придумывать много идей для экспериментов, чтобы проверить гипотезу. Иногда это связано с тем, что вы ищете тот угол зрения, который наиболее эффективно проверит идею и выявит ее потенциал. Это также пригодится, если вы провели успешный эксперимент и хотите вернуться в начало и посмотреть, принесет последующий эксперимент дополнительные преимущества к достигнутой вершине оптимизации или успех уже достигнут. В табл. 7.2 показаны несколько экспериментов, которые являются возможными способами проверки исходных гипотез.
Итак, после того, как вы некоторое время поработаете над этим, у вас появится большая куча гипотез и еще более внушительная куча возможных экспериментов для проверки этих гипотез, из-за чего нам опять придется вернуться к расстановке приоритетов.
Вы быстро усвоите одну вещь: вы не можете тестировать все подряд. Вы не можете исследовать все подряд. Вы не можете ответить на все вопросы или беспокойства и не можете исключить риски. Но снижение риска (на жаргоне – дерискинг) является одной из основных задач экспериментов. Определение наиболее рискованных ставок в вашем списке и особенно – доступных способов снижения этого риска в конечном счете должно указывать, какие эксперименты вы проведете, а какие лучше отложить.
Например, настроить цвет кнопки таким образом, чтобы привлечь больше внимания, – это простая задача, которую можно просто сделать, ничего предварительно не тестируя, потому что существующий риск получить кнопку неидеального цвета невелик, и риск ошибиться также не поменяет правила игры.
Таблица 7.2. Два или более эксперимента для каждой гипотезы
Но теперь представьте, что у вас есть несколько важных целей, которые находятся в конфликте (что, кстати, у вас всегда происходит). Допустим, вам нужно увеличить рост, стимулируя регистрацию и улучшая удержание за счет бесплатных сервисов, но у вас также есть значительный поток доходов от импульсивных покупателей, который вам необходимо поддерживать, а в идеале увеличить. При таком сценарии можно было бы просто сделать опцию для регистрации и вовлечения в бесплатные сервисы гораздо более привлекательной и заметной, чем призыв к действию для импульсивных покупателей, но такой подход сопряжен с риском потери критически важного источника дохода. В таком случае торопиться с изменениями кажется рискованным делом, и эксперимент с небольшой частью вашего трафика поможет вам изучить компромисс, прежде чем сделать ставку на идеальный долгосрочный рост ценой заработной платы в следующем квартале.
Есть еще один фактор, усложняющий расстановку приоритетов в экспериментах, – это одновременное проведение более одного эксперимента в одной и той же области или потоке вашего продукта, потому что это приводит к получению нечетких, трудно интерпретируемых результатов. Таким образом, если эксперименты не противоречат друг другу, вы можете проводить их несколько одновременно, в зависимости от вашей способности отслеживать их и справляться с ними.
► ПОЛЕЗНЫЕ ЗНАНИЯ ОТ NETFLIX
Чтобы разобраться глубже, как проводить масштабное А/В-тестирование, ознакомьтесь с постом «Всё про A/B-тестирование: экспериментальная платформа Netflix»[40] (It’s All A/Bout Testing: The Netflix Experimentation Platform) в техническом блоге Netflix.
Вам захочется не только развивать ваш список гипотез и придуманных экспериментов, но и постоянно определять приоритеты предстоящих тестов и отслеживать уже запущенные проверки. Завершенный эксперимент с отрицательным или положительным результатом должен дать некоторые выводы о достоверности гипотезы (или по крайней мере об эффективности эксперимента). Эти выводы, накапливаемые с течением времени, совместно с остальными результатами исследований в идеале находятся в хранилище или инструменте отслеживания, которым пользуются команды UX и обработки данных.
Какой бы инструмент вы ни использовали (мне нравится использовать шаблон Airtable, который показан на рис. 7.2), вам потребуется разработать согласованный рубрикатор для ранжирования потенциальных экспериментов и выбора из них приоритетных для предстоящих спринтов. Факторы, которые следует учитывать, включают следующее:
• потенциальный охват эксперимента (сколько трафика проходит через зону тестирования);
• потенциальное влияние успешного эксперимента (несколько субъективно, но рассчитываете ли вы на улучшение отслеживаемого показателя на 10 %, 50 %, в 2 раза, в 5 раз?);
• усилия инженеров и других сотрудников, необходимые для выполнения эксперимента;
• насколько вы уверены в гипотезе и какие у вас есть доказательства в ее поддержку.
На рис. 7.2 показан шаблон Airtable для определения приоритетов, отслеживания и оценки экспериментов. Изначально я получил этот шаблон от эксперта по продукту и росту Джесси Авшаломова, и со временем он был доработан для разных проектов и клиентов. (Airtable – это инструмент для работы с реляционными базами данных с гибким пользовательским интерфейсом, который некоторые менеджеры продукта считают чрезвычайно пластичным и полезным при создании и отслеживании сложных движущихся систем.)
Airtable помогает вам оценивать эксперименты с точки зрения потенциальной отдачи, усилий, уверенности в гипотезе и некоторых других факторов. (Вы можете отменить оценку, когда решаете, что делать дальше, но она хорошо помогает нанести более грубые штрихи расстановки приоритетов.)
Рис. 7.2. Беглый взгляд на список, отслеживающий сотни экспериментов до, во время и после
Как провести A/B-тестирование
Возможно, вы помните, что не все эксперименты проводятся в форме A/B-тестов, которые тем не менее являются мощным инструментом в вашем наборе. И хотя общий формат этих видов тестирования не сильно меняется, особенности их управления и проведения варьируются в зависимости от сервиса. Некоторые команды используют сторонние инструменты на основе JavaScript, такие как Optimizely, другим нравятся инструменты, встроенные в аналитические пакеты, такие как Google Analytics, Amplitude, Mixpanel, Applytics и так далее. Третьи вручную запускают свои собственные тесты непосредственно в коде (что может привести к проблемам позже, если код не будет очищен должным образом).
При запуске групповых тестов (также известных как сплит-тесты, многовариантный тест, А/В-тест) следует учитывать следующие факторы:
• планирование;
• статистическая значимость;
• отдача;
• изучение;
• накопление.
Как в случае с любыми другими работами, включая создание и исправление, выполнение приоритетных тестов должно быть сопоставлено с другими задачами из списка и затем распределено по приоритетам в спринтах. Тесты во многих случаях выполняются дольше одного спринта, поэтому запуск теста, контроль за тем, что он выполняется правильно и без своих внутренних ошибок, а затем его завершение – это всё отдельные задачи, которые необходимо отслеживать отдельно.
Пока в тесты не будет включено статистически значимое число испытуемых, они не дадут значимых результатов, поэтому эксперименты требуют разного времени для выполнения. В зависимости от потока трафика в области проведения тестирования может потребоваться от одного дня до нескольких недель, чтобы собрать достаточное количество людей в каждом сегменте.
Как вы узнаете, что достигли статистической значимости? Существуют математические модели, помогающие это определить, а программные инструменты, облегчающие A/B-тестирование (такие как Amplitude), теперь включают в себя измерения статистической значимости, а также большую вероятность того, что результат верный. Обратите внимание, что согласно очень общему эмпирическому правилу[41] вам обычно требуется набрать не менее 2000 человек в каждую категорию, чтобы доверять результату.
Один из способов проверить результат, который может быть очень интересным, – это выполнить A/A-тест. По сути, вы настраиваете A/B-тест и помещаете новых пользователей в ту или иную группу, но предоставляете одинаковый интерфейс и одинаковую функциональность людям в каждой группе. Вот что вы можете увидеть на первом этапе, когда данные начнут поступать: B работает намного лучше, чем A, или наоборот – нет, подождите, – теперь они снова поменялись! Это похоже на то, как вы подбрасываете монету четыре или пять раз подряд и все время выпадает орел, но если вы сделаете это достаточно раз, то количество результатов «орел» и «решка» в итоге будет почти одинаковым (только если вы не играете в пьесе Тома Стоппарда[42]).
Следите за своим тестом и отмечайте, когда результаты приближаются к паритету и затем остаются довольно ровными, и не удивляйтесь, если эта стабилизация произойдет, когда в каждой группе будет около 2000 человек.
Прежде чем начинать тест, чрезвычайно важно определить время его окончания. В противном случае возникает соблазн «сорвать куш»[43] – завершить тест, когда результат, за который вы болеете, вырвется вперед.
Также важно завершить тест, когда он достигнет значимости, а не просто «давать ему поработать еще немного» в надежде, что ваша побежденная сторона еще возьмет верх в овертайме.
После того как вы завершите тест, у вас будет возможность оценить его результаты. Сделали ли люди из разнообразных групп больше того, что вы хотели от них? Или это все было потерей времени? Или результаты ниже ожидаемого? Любой результат – это свежая информация, которая приветствуется, но, конечно, победа лучше! В любом случае вам необходимо отслеживать и записывать эти результаты.