A/B тестирование: как провести, пошаговый алгоритм тестов и инструменты

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

Сегодня A/B-тестирование широко используется не только в продуктовом менеджменте, но и в маркетинге, медицине и других областях. Одно же из первых появлений самого термина связано с личностью сэра Рональда Фишера — британского генетика и статистика. Сама идея проведения экспериментов появилась в результате случая, что произошел с Фишером в его работе, на сельскохозяйственной исследовательской станции. Как-то раз он налил своей коллеге Мюриэль Бристол чашку чая. Но она неожиданно отказалась пить его, сославшись на то, что Фишер сначала налил молоко, а только затем чай. Она же пьет только тот чай, где молоко было налито на 2-м этапе. Фишер задумался над тем, действительно ли она может безошибочно определить, был ли сначала добавлен чай в чашку или же молоко. Он решил провести эксперимент, в рамках которого предложил коллеге 8 случайно упорядоченных чашек чая: в 4 из них сначала был добавлен чай, а в другие 4 — молоко. Это исследование вылилось в серьезный труд — в 1935 году вышла его книга «The design of experiments», которая считается фундаментальной работой в области экспериментального проектирования.

Несмотря на то, что работам Фишера уже почти 100 лет, а применение A/B-тестов становится все шире, многие продакт-менеджеры и команды все еще сталкиваются с ошибками, цена которых порой очень велика. Поэтому мы хотим подробнее рассмотреть:

• Как результаты A/B-тестов влияют на бизнес;
• Как сегодня проводят A/B-тесты;
• С какими ошибками сталкиваются команды и как их избежать.

<<rozova-guide-img>>

Использование в бизнесе

Для продакт-менеджеров необходимо подтверждение своих гипотез для внедрения изменений. Мы начинаем что-то менять в продукте тогда, когда в соответствии с выбранной стратегией ставятся задачи, например, по его росту, по улучшению пользовательского опыта и так далее. Как не ухудшить то, что уже есть, своими нововведениями? С какой вероятностью мы достигнем целевых показателей после внедрения изменений? Какие риски нас ожидают, если внедрить изменения? Ответить на эти вопросы помогают результаты А/В-тестирования.

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

Вот они:

• Изменения в функциональности продукта, влияющие на метрики выручки. Чаще всего это воронка до продажи клиенту, повторные покупки. Актуально для лендингов, сайтов, e-commerce-платформ, интернет-магазинов, paywall в сервисах и приложениях.
• Изменения в продукте, влияющие на активность пользователей и retention. Этими показателями в большей степени (но не ограничиваясь) озадачены приложения, Saas-продукты, интернет-магазины, EdTech.

В рамках этих изменений обычно тестируются:

1. Влияние изменений дизайна на поведение пользователей: от цвета кнопок до изменения пути пользователя или, например, время отклика приложения.
2. Влияние изменения в системе монетизации: от офферов на paywall до его цветов и порядка экранов.
3. Результативность связок между маркетинговыми инструментами и путем пользователя внутри приложения. Здесь тестируется и визуал, и маркетинговые сообщения, и тексты внутри продукта.

Куда смотрит бизнес

Задача бизнеса — правильно проинвестировать ресурсы, чтобы получить наилучший результат в заданные сроки. A/В-тесты помогают проверить влияние изменений и получить данные для принятия управленческих решений.

Тесты проектируются по определенной структуре, о которой мы расскажем ниже. Здесь же пока отметим основные показатели, за которыми следит бизнес.

1. Показатели выручки/дохода для каждого варианта теста.
2. ROI разных гипотез при маркетинговых активностях и изменениях в продукте.
3. Показатели конверсий для разных тестовых групп.

Полученные результаты помогают оценить, насколько внедрения изменений окупятся, в какой срок и какие риски могут появиться для бизнеса и пользователей в связи с обновлениями.

Что еще можно узнать в процессе A/B-тестов

Кроме прямых задач бизнеса на определенном отрезке времени всегда есть задачи по сбору информации о пользовательском поведении, которые актуальны столько, сколько существует продукт. Чем больше данных мы собираем, тем больше срезов могут сделать аналитики и тем более точными могут быть выводы и неожиданными инсайты.

1. Реакция разных сегментов пользователей на не только тестируемые изменения, но и на весь путь пользователя. Например, как влияет на user flow на шагах X и Y, которые в тесте не участвовали, увеличение конверсии на шаге А, которое исследовали с помощью А/В-тестирования.
2. Предпочтения юзеров в дизайне. Например, одна из команд, с которыми мы общались, выяснила, что на мобильной версии продукта анимация убивает путь пользователя дальше. После этого вопрос с экспериментами над анимацией в мобильном приложении решен. Теперь ее там нет🙂
3. Уменьшение оттока пользователей, например, после прохождения определенного paywall. Эта метрика не тестировалась напрямую, но на длинной дистанции после окончания теста проявился и такой результат.

Когда A/B-тесты неприменимы

A/В-тесты удобны для принятия решений, но применимы они не всегда. Ниже мы выделили 5 пунктов, когда их использовать рано или вообще неуместно.

1. Небольшой трафик. Когда у вас недостаточно посетителей на сайте или в приложении, результаты теста могут быть недостоверными или статистически незначимыми. Чем больше трафика, тем более чувствительный результат.
2. Особенности бизнес-модели. Например, если в B2B-продуктах проведение A/B-тестирования связано со сложностью, что конечные решения о продукте и его приобретении принимают одни люди, а пользователи системы — другие люди, поэтому тестирование на этой аудитории может быть не так важно.
3. Нет централизованного процесса А/В-тестирования и снятия результатов. Часто из-за отсутствия централизованного процесса A/B-тестирования смежные команды не в курсе экспериментов друг друга. Это приводит к дублированию тестов, использованию одних и тех же пользователей в разных группах, что в итоге искажает результаты всех экспериментов.
4. Высокие затраты на разработку и внедрение. Затраты на проектирование и запуск теста должны быть меньше, чем ожидаемая сейчас или впоследствии выручка от него. Нет смысла проводить исследование, если его запуск и проведение обходится дороже, чем потенциальная выгода от него.
5. Баги платформ. Когда невозможно точно и равномерно разделить пользователей на контрольную и тестовую группы, из-за этого анализ может дать недостоверные данные.

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

Как спроектировать А/В-тест — пошаговый алгоритм

Шаг 1: определить цель и гипотезу

На 1-м шаге нам требуется определить цель проведения исследования, а также сформулировать нулевую и альтернативную гипотезы.

• Нулевая гипотеза (H0) — обычно предположение о том, что между группами A и B нет статистически значимых различий.
• Альтернативная гипотеза (H1) — предположение, противоположное нулевой гипотезе (считаем, что есть значимые различия между группами).

Шаг 2: определить целевые метрики для проверки

• Целевая метрика, также известная как OEC (overall evaluation criteria), — это ключевой показатель, на который мы хотим повлиять и можем измерить его во время проведения теста. Например, ARPU или CR в ключевое действие.
• Guard-метрики — взаимосвязанные метрики для проверки результатов, показывающие, что остальные части продукта работают, как мы ожидаем.

Шаг 3: разработать тестовый вариант изменений

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

Шаг 4: определить критерии точности теста

На данном шаге мы определяем уровень эффекта, который сможем наблюдать при проведении A/B-теста (или же определиться, какие ошибки I и II рода мы готовы допустить). Это необходимо, чтобы затем корректно определить размер выборки для теста:

• Допустимый уровень значимости (α — альфа) — вероятность ошибочно принять альтернативную гипотезу (и отвергнуть нулевую), когда на самом деле нет статистически значимых различий между двумя группами. Поэтому α также является параметром, который отвечает за уровень ошибки I рода (False Positive). Обычно α устанавливают равным 0.05 (5%).
• β (бета) — вероятность ошибочно принять нулевую гипотезу (и отклонить альтернативную), когда на самом деле есть статистически значимые различия между двумя группами. Поэтому β также является параметром, который отвечает за уровень ошибки II рода (False Negative). Обычно β устанавливают равным 0.2 (20%).
• Мощность теста — вероятность, что тест покажет различия между результатами в том случае, если они действительно есть. То есть чем мощнее тест, тем результаты меньшего масштаба мы способны обнаружить. Важно помнить, что чем больше наблюдений в выборке, тем выше мощность теста. Она определяется как 1 — β = 0.8.
• MDE (Minimum Detectable Effect) — минимальный размер эффекта, который мы хотим уметь зафиксировать при заданных значениях мощности и допустимого уровня значимости.

Шаг 5: определить группы и размер выборки

Для того чтобы критерии, обозначенные на предыдущем шаге, были выполнимы, нам необходимо определить минимальный размер контрольной и тестовой групп (выборки). Мы не будем углубляться в математические расчеты, которые требуются для подсчета размера выборок. Для начала вы можете воспользоваться калькулятором Evan Miller. Чуть позже мы покажем пример, как это делать.

1. Выборка — количество пользователей, которым покажут разные версии продукта.
2. Размер выборки — количество участников в каждой группе тестирования, требуемое для достижения статистической значимости.
3. Контрольная группа — пользователи, которым показывается текущая версия продукта без изменений.
4. Тестовая группа — пользователи, которым показывается новая версия продукта с внесенными изменениями для проверки через A/B-тест.
5. Репрезентативность выборки — свойство выборки, при котором ее характеристики (например, возраст, пол, географическое положение участников) соответствуют общим характеристикам всей аудитории. Выборка должна быть репрезентативной, значит, представлять всю целевую аудиторию продукта (= генеральную совокупность).

Шаг 6: определить критерии остановки теста

На данном шаге мы определяем критерии остановки теста. Обычно тест останавливается тогда, когда мы набрали необходимое количество пользователей в каждой группе, чтобы иметь возможность заметить эффект между результатами в них, если он есть. Поэтому длительность теста зависит от требуемого количества пользователей в каждой группе, а также от среднего ежедневного трафика.

Решение о принятии/отклонении нулевой гипотезы мы принимаем, используя значение установленного α и полученного p-value.

• P-value — вероятность получить такие или более выраженные различия между результатами контрольной и тестовой групп, когда на самом деле верна нулевая гипотеза. То есть это вероятность возникновения условий, описанных в альтернативной гипотезе, в «мире», где работает нулевая гипотеза.

Очень рекомендуем посмотреть это видео, где очень просто объясняется, что такое p-value. Важно помнить, что p-value, который меньше α, не является критерием для остановки теста.

Шаг 7: провести тест

В процессе исследования мы должны помнить о паре важных моментов:

1. Во время проведения A/B-теста мы не подсматриваем за предварительными результатами, так как p-value может колебаться и уходить ниже границы α. Но это не является критерием для остановки теста.
2. Мы должны быть уверены, что параллельно не проводятся тесты, которые используют этих же пользователей или же близких к ним по характеристикам, так как это может исказить результаты нашего теста.

Шаг 8: завершить тест и проанализировать результаты

Для анализа результатов нам необходимо:

1. Определить распределение данных.
2. Выбрать статистический критерий, подходящий для текущего распределения и объема выборки. Статистическим критерием является определенное математическое правило, в соответствии с которым принимается или отвергается та или иная статистическая гипотеза, используя заданный уровень значимости.
3. Посчитать статистику критерия.

Шаг 9: принять решение

Когда p-value < α, мы отклоняем нулевую гипотезу и принимаем альтернативную. Если же p-value ≥ α, то мы принимаем нулевую гипотезу.

Для изучения отдельных нюансов А/В-тестирования рекомендуем ознакомиться с гайдом из интенсива Wannabelike, а мы разберем несколько подробных примеров A/B-теста для метрик, имеющих различные распределения.

Пример №1 — А/В-тест на конверсию

Наш продукт — сервис прослушивания аудиокниг по подписке. Перед тем как новые пользователи приобретают платную подписку, они пробуют trial-версию. Прослеживается четкая взаимосвязь между количеством пользователей, которые согласились попробовать бесплатную версию, и количеством дальнейших платных подписок.

Шаг 1: определить цель и гипотезу

Цель: увеличить конверсию пользователей на этапе выбора trial-версии.

Гипотеза H0: если мы изменим условия бесплатной подписки с уже имеющегося «7 дней прослушивания аудиокниг бесплатно» на «месяц бесплатно, а далее 159 р. по подписке», то никаких изменений конверсии в использование trial-версии не будет.

Гипотеза H1: если мы внесем эти изменения, то увеличим конверсию в использование trial-версии.

Шаг 2: определить целевые метрики для проверки

Целевая метрика: конверсия из новых пользователей в использование trial-версии.

Guard-метрики:

1. Конверсия в подписку. Если она станет меньше из-за большого количества бесплатного времени в приложении, значит, мы получили обратный результат для бизнеса.
2. Среднее время в приложении при использовании бесплатной версии. Нужно обратить внимание, что если количество проведенного пользователем времени за месяц заметно упадет, это может повлиять на дальнейшую конверсию в покупку.

Шаг 3: разработать тестовый вариант изменений

Команда разработки предоставит новое предложение на странице мобильного приложения (в нашем продукте большинство пользователей используют его, поэтому здесь тест станет более показательным).

Если будет принята альтернативная гипотеза, то команда изменит предложение для подключения бесплатной версии уже на всех платформах.

Шаг 4: определить критерии точности теста

Предположим, что сейчас конверсия из новых пользователей в использование бесплатной версии равна 7%. Также мы хотим установить следующие критерии точности для данного теста:

• MDE = 2% (замечать изменения в конверсии в размере 2%)
• α = 5%
• β = 15%

Шаг 5: определить группы и размер выборки

Так как мы определились с критериями точности теста, теперь можем определить размеры выборок, используя эти вводные. Для этого воспользуемся калькулятором Evan Miller:

Видим, что для проведения теста нам потребуется 3050 человек в каждой группе. Всего — 6100 пользователей.

Шаг 6: определить критерии остановки теста

Остановить тест мы сможем тогда, когда в каждой из групп наберется по 3050 человек.

Шаг 7: провести тест

Предположим, что результаты теста следующие:

• Контрольная группа (A) — конверсия = 8%
• Тестовая группа (B) — конверсия = 10%

Шаг 8: завершить тест и проанализировать результаты

Для анализа результатов в случае сравнения конверсий можно использовать как z-test, так и chi-squared test. Мы применим chi-squared test.

Снова воспользуемся калькулятором Evan Miller.

Получаем в данном случае p-value = 0.00635.

Шаг 9: принять решение

Так как допустимый уровень значимости α мы установили равным 5%, нам необходимо сравнить полученный p-value с α: p-value < α, следовательно, мы можем отклонить нулевую гипотезу и сделать вывод о наличии в нашем A/B-тесте статистически значимых различий между бесплатной подпиской на 7 дней и 1 месяц.

Если с guard-метриками нет никаких проблем, мы можем раскатывать данное изменение на всех пользователей.

<<rozova-trial>>

Пример №2 — А/В-тест на среднее количество игр за сессию

В приложении пасьянса «Косынка» мы решили добавить новую возможность автоматического переноса карты по двойному клику. Карта переходит на подходящее место, если она соответствует цвету и рангу на нужной позиции.

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

Шаг 1: определить цель и гипотезу

Цель: увеличить среднее количество партий, завершенных игроками.

Гипотеза H0: после добавления новой функции автоматического перенесения карты на нужную позицию при двойном клике среднее количество игр за одну сессию не изменится.

Гипотеза H1: новая функция автоматического перенесения карты на нужную позицию при двойном клике изменит среднее количество игр за сессию.

Шаг 2: определить целевые метрики для проверки

Целевая метрика: среднее количество игр, завершенных за одну сессию. Распределение метрики нормальное.

Мы измеряем среднее количество игр на каждого игрока в течение дня.

Текущее значение метрики: 5.25 игры. Стандартное отклонение = 2 игры.

Guard-метрики:

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

Шаг 3: разработать тестовый вариант изменений

Команда разрабатывает версию продукта, в которой при двойном нажатии карта переносится в подходящее для нее место. Изменена сама механика игры, но команда не тратила время на дальнейшие изменения анимации. Они будут в том случае, если гипотеза подтвердится. Таким образом, мы сокращаем время и деньги на разработку тестового варианта.

<<prodakty-telegram-kanal>>

Шаг 4: определить критерии точности теста

Для данного теста мы установим следующие критерии точности:

• α = 5%
• β = 20%
• MDE = 5% (на настоящий момент среднее количество игр = 5.25, мы хотим определить чувствительность изменения на 5%)

Шаг 5: определить группы и размер выборки

Выборка: воспользовавшись калькулятором, получаем размер выборки — 6281 пользователей в каждой из групп. Общее количество пользователей: 12562.

1. Контрольная группа (А): игроки используют стандартную версию приложения без новой функции.
2. Экспериментальная группа (В): игроки используют версию приложения с новой функцией автоматического перенесения карты.

Шаг 6: определить критерии остановки теста

Остановить тест мы сможем тогда, когда в каждой из групп наберется по 6281 человек.

Шаг 7: провести тест

При проведении теста мы замеряем среднее количество завершенных игр на пользователя каждой версии, пока варианты не будут показаны выборкам пользователей.

Предположим, что результаты теста следующие:

• Контрольная группа (A). Среднее количество игр = 5.25. Стандартное отклонение = 2 игры.
• Экспериментальная группа (B). Среднее количество игр = 6.73. Стандартное отклонение = 2 игры.
• Размер обеих групп — по 6281 пользователю.

Шаг 8: завершить тест и проанализировать результаты

Мы завершаем исследование, когда тестируемые варианты будут показаны рассчитанным группам.

Далее определяем, является ли результат статистически значимым. Так как данные имеют нормальное распределение, воспользуемся t-критерием Стьюдента. Что нам нужно для этого сделать:

1. Посчитать t_score для данного критерия.
2. Посчитать количество степеней свободы (df).
3. Найти соответствующее значение p-value в таблице с критическими значениями t, используя результаты, полученные на 1-ом и 2-ом шагах.

Проведем необходимые расчеты.

1. Расчет t-значения для независимого 2 sample t-теста будет следующим:

  В формуле: 

• X1 и X2 — средние значения для каждой из групп
• s — дисперсия
• n1 и n2 — размеры групп

2. Степени свободы (df) рассчитываются как n1 + n2 — 2 (где n1 и n2 — размеры групп):

6281 (группа A) + 6281 (группа B) — 2 = 12560

3. Теперь обратимся к статистической таблице с критическими значениями t score. Возьмем рассчитанное значение df (= 12 560) и значение t_score (= 41.47) и найдем в таблице значение p-value, соответствующее полученным результатам.

Наше значение t_score в таблице отсутствует, но самое близкое к нему t = 3.291⇒ p-value = 0.001. Так как наше значение t_score > 3.291, то наше p-value < 0.001.

Также можем воспользоваться калькулятором Evan’s Awesome A/B Tools для выполнения расчетов, а также для проверки правильности наших результатов:

Тут также видим, что p-value < 0.001. Следовательно, наши расчеты сделаны корректно.

Шаг 9: принять решение

Так как допустимый уровень значимости α мы установили равным 5%, нам необходимо сравнить полученный p-value с α: p-value < α, следовательно, мы можем отклонить нулевую гипотезу и сделать вывод о наличии в нашем A/B-тесте статистически значимых различий между старой версией игры и вариантом с новой функцией автоматического перенесения карты на нужную позицию при двойном клике.

Если с guard-метриками нет никаких проблем, то мы можем раскатывать данное изменение на всех пользователей.

Пример №3 — А/В-тест на средний чек

В интернет-магазине косметики одной из целевых метрик является размер среднего чека. Допустим, сегодня средний чек у нас составляет $50. Мы хотим растить средний чек и предполагаем, что добавление списка рекомендаций к просматриваемой карточке товара его увеличит. В связи с этим мы хотим провести A/B-тест, где:

• Контрольная группа пользователей будет видеть текущую версию без рекомендаций.
• Тестовая группа пользователей — тестируемую версию со списком рекомендаций для просматриваемых карточек товара.

Шаг 1: определить цель и гипотезу

Цель: увеличить средний чек в интернет-магазине косметики.

Гипотеза H0: статистически значимые различия в среднем чеке у контрольной и тестовой групп отсутствуют.

Гипотеза H1: наблюдаются статистически значимые различия в среднем чеке у контрольной и тестовой групп.

Шаг 2: определить целевые метрики для проверки

Целевая метрика: средний чек.

Guard-метрики:

1. Средняя сумма стоимости товаров в корзине на одного пользователя.
2. Количество товаров в избранном у пользователя.
3. Конверсия в повторную покупку со стороны пользователя.

Шаг 3: разработать тестовый вариант изменений

Команда разрабатывает версию продукта с рекомендациями, где при просмотре карточки товара внизу будет отображаться список товаров, также рекомендуемых к покупке.

Шаг 4: определить критерии точности теста

Для данного теста мы установим следующие критерии точности:

• α = 1%
• β = 20%
• стандартное отклонение для генеральной совокупности — $30

Шаг 5: определить группы и размер выборки

Так как мы определились с критериями точности теста, теперь можем определить размеры выборок, применив эти вводные. Воспользуемся калькулятором:

Видим, что для проведения теста в каждой группе нам потребуется 969 пользователей. Всего — 1938 человек.

Шаг 6: определить критерии остановки теста

Остановить тест мы сможем тогда, когда в каждой из групп наберется по 969 человек.

Шаг 7: провести тест

Предположим, что результаты теста следующие:

• Контрольная группа (A) — средний чек = $52
• Тестовая группа (B) — средний чек = $59

Шаг 8: завершить тест и проанализировать результаты

Для анализа результатов в случае сравнения данных, имеющих распределение, отличное от нормального, можно использовать Mann-Whitney U test. У него есть определенные проблемы и ограничения, но мы будем применять его, чтобы воспользоваться еще одним критерием.

Перейдем в калькулятор:

Получаем в данном случае p-value = 1.013e-11.

Шаг 9: принять решение

Так как допустимый уровень значимости α мы установили равным 1%, нам необходимо сравнить полученный p-value с α: p-value < α, следовательно, мы можем отклонить нулевую гипотезу и сделать вывод о наличии в нашем A/B-тесте статистически значимых различий между версией без рекомендаций и версией с рекомендациями.

Если с guard-метриками нет никаких проблем, то мы можем раскатывать данное изменение на всех пользователей.

#chatbot

Основные ошибки и как их избежать

1. Планирование и дизайн теста

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

Ошибка: расплывчатая гипотеза или ее отсутствие

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

Запуск теста без ясного утверждения гипотезы может отвлечь нас на интересные, но несущественные метрики. Например, вы можете сосредоточить внимание на том, что пользователи проводят больше времени на странице, вместо той метрики, которая действительно важна.

Как избежать: определите, изменение в какой метрике вы хотите обнаружить при проведении A/B-тестирования.

Ошибка: тестирование нескольких гипотез одновременно

Может показаться, что тестирование нескольких элементов одновременно экономит время, но это не так: при тестировании нескольких элементов на странице вы можете получить искаженные и недостоверные результаты из-за неконтролируемого влияния и роста ошибок I и II родов).

A/B-тестирование предполагает изменение одного элемента на странице и сравнение его с другой версией того же элемента. Для тестирования более одного элемента одновременно нужно использовать многовариантное тестирование (поговорим ниже).

Как избежать: один тест — одна гипотеза. Так получится оценить, какой результат дает конкретное изменение.

2. Технические аспекты и контроль качества

Ошибка: не отслеживать метрики здоровья и ухудшать другие показатели тестом

Guard-метрики, или метрики здоровья, — это ключевые бизнес-показатели, которые нужно отслеживать на предмет негативных изменений во время проведения A/B-тестов.

Как избежать: определить метрики здоровья на этапе проектирования A/B-теста и следить за их изменениями. Примеры: количество посетителей на сайте, базовая конверсия, среднее время на странице и тому подобное.

Ошибка: невнимание к техническим ошибкам

При запуске теста важно убедиться, что версии не имеют критических багов и аудитория разделена правильно.

Как избежать: провести A/A-тест перед А/В-тестом, чтобы проверить, что инструмент настроен правильно. Результаты A/A-теста должны показать равенство.

Ошибка: слишком раннее завершение теста

Часто очень хочется завершить тест сразу после достижения статистической значимости, особенно если вы были уверены в своей первоначальной гипотезе. Важно помнить, что сокращение длительности теста может привести к некорректным результатам. Чем больше данных вы собираете, тем точнее будут ваши результаты.

Как избежать: держитесь. Вы не для того рассчитывали размер выборки и длительность теста, чтобы прервать его раньше времени и получить недостоверный результат.

Ошибка: слишком позднее завершение теста

Обрадовавшись отличному результату, можно забыть остановить тест. Он продолжит работать и отдавать более слабый вариант половине аудитории.

Как избежать: заканчивать тест, когда наберется запланированная выборка и закончится выделенное на проверку гипотезы время, которое рассчитано на этапе дизайна теста. Чем дольше выполняется тест, тем больше вероятность, что на него начнут влиять другие внутренние и внешние события и результаты не будут достоверными.

3. Анализ результатов

Ошибка: игнорирование результатов, которые противоречат вашим убеждениям

Интуиция важна при выборе того, что тестировать, но следует также принимать результаты тестов даже в том случае, если они не соответствуют нашим предположениям. Тесты — хороший инструмент в том числе для того, чтобы лучше узнать своих пользователей, так как их вкусы или поведение могут отличаться от ваших предположений. Запускать тесты бесполезно, если вы не готовы внедрять изменения на основе выигравшей версии.

Как избежать: установите четкие правила и действия до проведения теста.

Ошибка: отсутствие документации

Эта ошибка заключается в недостаточной внимательности к результатам A/B-тестов, особенно к тем, которые не подтверждают исходные гипотезы. Отсутствие документации по уже проведенным тестам может привести к упущению важных уроков и непониманию того, что не сработало в эксперименте. Важно извлекать максимум знаний из каждого теста.

Как избежать: создайте шаблон для документирования тестов и не игнорируйте его заполнение. В него нужно включить первоначальный дизайн и результаты теста, а также список дальнейших действий.

Вариации А/В-тестов

А/А- и А/А/B-тесты

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

1. A/A-тестирование — подход, при котором мы показываем не 2 различные версии, а только старую, но двум разным группам. Цели такого подхода:

• Проверка корректности платформы для тестирования. Мы предполагаем, что если при запуске такого эксперимента результат одной группы будет статистически значимо отличаться от результата другой, значит, есть проблемы с дизайном тестирования.
• Определение базового уровня целевой метрики и ее доверительного интервала, внутри которого она изменяется только под воздействием случайных факторов, и они не являются сигналом к внедрению изменений.
• Определение минимального размера выборки для A/B-тестирования. Это можно сделать, запустив A/A-тест и дождавшись момента, когда результаты начнут выравниваться.

2. A/A/B-тестирование — подход, при котором A/A- и A/B-тесты проводятся одновременно. Трафик делится на 3 части, где 1-я и 2-я группы являются контрольными, и мы показываем им старую версию, а 3-ей (тестовой) — новую. Такой подход применим, когда нет ограничений в трафике. Благодаря ему мы можем:

• Повысить точность теста, показывая старую версию группам 1 и 2 (A и A), — так мы будем оценивать результат 3-й группы (B) тогда, когда результат групп A и A выровняется.
• Ускорить процесс тестирования, потому что оно будет запущено сразу для 3 групп.

Многовариантное тестирование (MVT)

Многовариантное тестирование (оно же множественное) — это такой вид исследования, где могут сравниваться одновременно несколько версий одного и того же элемента (версия A, версия B, версия C...), а также комбинации различных элементов.

Обычно многовариантное тестирование команды проводят по нескольким причинам.

1. Команда хочет протестировать 4 версии одного и того же элемента (например, кнопки). И делает это одновременно в одном тесте, чтобы снизить влияние недельной/месячной сезонности.
2. Команда хочет протестировать 2 версии двух различных элементов и их кумулятивное воздействие на продуктовые метрики. Например, показ пользователям опции BNPL с возможностью сплитования стоимости на 4/6 частей, а также кнопки с возможностью выбора пункта получения с максимально быстрой доставкой.
3. Заказчик хочет максимально быстро и дешево протестировать все элементы и получить ответ.

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

1. Не всегда удается провести такое исследование быстро и дешево, так как требуется больше трафика для разделения пользователей на группы.
2. Когда аудитория разбивается более чем на 2 подгруппы, вероятность получения ошибки I рода (FP) растет экспоненциально. Об этом и хочется поговорить подробнее далее.

Контроль ошибок I рода

Предположим, мы хотим одновременно протестировать 4 версии одного и того же элемента на странице. Имеем α = 5%, β = 20%, количество гипотез = 4. Вроде, никаких проблем. Но на деле оказывается, чем больше гипотез мы проверяем, тем выше риск получить ошибку I рода. Так, в нашем случае ее общая вероятность (FWER) будет следующей:

И чем больше у нас гипотез, тем выше будет вероятность ошибки. Теперь посмотрим совсем немного теории, чтобы понять, как данный механизм работает в общем.

FWER (Family-wise error rate) — групповая вероятность ошибки I рода.

Так как в рамках многовариантного тестирования мы делаем несколько сравнений и можем допустить ошибку I рода несколько раз, FWER показывает вероятность совершить ее хотя бы единожды и рассчитывается по формуле:

В формуле α — заданный уровень статистической значимости, m — количество гипотез.

Как мы можем контролировать FWER?

1. Метод Бонферрони или поправка Бонферрони

Самый простой и интуитивный способ контроля FWER — это использование метода Бонферрони.

Мы помним, что наша ошибка растет с числом проверяемых гипотез. Поэтому идея метода Бонферрони заключается в том, что мы занижаем уровень значимости пропорционально числу гипотез:

Вот так это будет выглядеть на графике:

Тогда в нашем случае для каждой гипотезы мы получим следующее значение α, которое и будем использовать далее:

Так мы действительно можем контролировать FWER, но проблема данного подхода заключается в том, что мы можем пропускать истинные эффекты. Иными словами, мощность эксперимента будет уменьшаться с ростом числа гипотез.

2. Метод Холма

Данный способ частично решает проблему метода Бонферрони и позволяет корректировать значения p-value, сохраняя мощность на более высоком уровне.

Тут мы корректируем p-value в соответствии со следующим алгоритмом:

1. Упорядочиваем значения p-value по возрастанию

2. Упорядочиваем соответствующие гипотезы

3. Принимаем решение по гипотезе в соответствии с неравенством:

где i — номер гипотезы в отсортированном списке.

4. Алгоритм останавливается тогда, когда p_value ≥ α. В этот момент принимается основная нулевая гипотеза на шаге i (H0_i), при этом принимаются и все последующие нулевые гипотезы из отсортированного списка.

Применим метод Холма к нашему примеру. Предположим, что p-value, полученные для каждой из гипотез, следующие:

Далее действуем по шагам — сначала сортируем значения p-value по возрастанию:

Затем упорядочиваем соответствующие гипотезы. То есть сначала берем 4-ю, затем 2-ю, 1-ю и 3-ю.

Определяем уровень значимости для каждой из гипотез.

• Для 4-ой гипотезы отклоняем 4-ю нулевую гипотезу (H0_4).

• Для 2-й гипотезы отклоняем 2-ю нулевую гипотезу (H0_2).

• Для 1-ой гипотезы принимаем 1-ю и 3-ю нулевые гипотезы (H0_1 и H0_3).

FDR (False Discovery Rate) — еще один вариант контроля ошибок. С помощью FDR мы можем рассчитать ожидаемую долю ложных отклонений от всех отклоненных нулевых гипотез. Основное отличие FDR от FWER в том, что FDR учитывает ошибку II рода, но не так жестко контролирует ошибку I рода.

Вот несколько методов для контроля FDR:

1. Метод Бенджамини-Хохберга
2. Метод Бенджамини-Иекутели

Когда стоит контролировать FWER, а когда FDR?

• Когда хочется отобрать наиболее интересные гипотезы, лучше использовать FDR: мы будем пропускать меньше реальных различий между выборками, учитывая ошибку II рода. При этом строгость в отношении ошибки I рода для нас не будет очень важна.
• Когда мы проверяем фичу, способную оказать сильное влияние на ключевую метрику, лучше использовать FWER, так как этот подход является более строгим в отношении ошибок I рода.

Многорукий бандит

Если подход с использованием A/B-тестов, рассмотренный в этом гайде, является статичным, то алгоритм многоруких бандитов — динамическим. Этот метод позволяет сразу после начала эксперимента определять наиболее эффективные версии (или же ручки) и направлять туда больше трафика.

Для определения наилучшей версии используется несколько метрик:

• вероятность выбора оптимального действия;
• среднее вознаграждение за действие;
• суммарное вознаграждение;
• метрика потерь.

Для использования этого подхода можно применить инструмент Visual Website Optimizer (VWO). Подробнее инструменты рассмотрим ниже.

Инструменты

В сфере A/B-тестирования существует множество инструментов, каждый из которых обладает уникальными особенностями и преимуществами. Эти инструменты можно условно разделить на несколько категорий:

• Платные инструменты и сервисы (third-party tools);
• Нативные решения для мобильных платформ (Product Page Optimization для iOS и Google Play Console (GPC/Google Analytics);
• Собственные разработки (internal tools).

Собственные разработки часто предоставляют большую гибкость и интеграцию с внутренними системами, но требуют время и другие ресурсы компании на создание и поддержание. Со временем они позволяют сократить стоимость запуска тестов до минимальной. Тогда как сторонние решения предлагают широкий спектр готовых к использованию функций из коробки, но могут быть слишком дороги в применении при большом объеме трафика.

Нативные инструменты для мобильных платформ оптимизированы для конкретных экосистем, в то время как универсальные решения предназначены для более широкого применения, и стоит обратить на них внимание, если ваша компания занимается разработкой разных продуктов с применением разных технологий.

Инструменты для А/В-тестирования не существуют в вакууме и должны быть интегрированы с системами аналитики, процессами поставки новых версий систем и внутренней инфраструктурой компании. Важно учитывать все эти факторы, а также общую стратегию компании, чтобы определиться с выбором инструментов и обеспечить их эффективное использование.

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

Выбор подходящего инструмента для A/B-тестирования зависит от множества факторов, включая:

• Специфические задачи бизнеса;
• Технологии, используемые для разработки (мобильные, веб, десктоп);
• Количество и виды выполняемых тестов;
• Доступные ресурсы (люди, стоимость);
• Аккредитация;
• Время на интеграцию;
• Компетенции команды.

Решение «build vs buy» может быть непростым, и окончательный выбор лучше делать после тестирования инструмента и детального изучения его спецификаций и тарификаций под ваши нужды. В нашем сравнении мы сфокусируемся на популярных инструментах общего назначения, доступных на рынке.

Среди представленных инструментов отдельно отметим следующие:

• Optimizely — лидер на рынке и один из самых популярных инструментов с визуальным редактором. Подойдет крупным компаниям и тем, которые хотят комплексно подойти к тестированию.
• Posthog — open source, можно использовать бесплатно, если трафик менее 1 млн. Многие компании-стартапы, в том числе YCombinator, используют данный инструмент. Стоит обратить на него внимание, если в команде есть разработчики, которые смогут заниматься интеграцией и поддержкой.
• Convert — доступный и удобный инструмент для проведения различных типов тестирования. Позволяет интегрироваться с многими другими системами, как внутренними так и third-party.
• Visual Website Optimizer — инструмент, набирающий популярность. Он предлагает ряд качественных и количественных исследований, подойдет в том числе компаниями с разным бюджетом. Есть пакет «Free Starter», который позволяет полностью исследовать возможности инструмента, прежде чем переходить на более дорогой план.

Скачайте полную версию обзора инструментов для A/B-тестирования

Резюме

Гайд получился длинным, но мы постарались собрать базу, которую применяют в своей работе менеджеры продуктов, ежедневно решающие задачи тестирования, в том числе А/B.

Основные мысли, которые мы бы хотели, чтобы остались как резюме:

• Начинайте с проектирования теста: гипотеза, метрики, ограничения. Без ТЗ результат сами знаете.
• Решение по гипотезам для тестирования принимайте исходя из контекста задачи и продукта. Интуиция и вера — прекрасно, но их надо подкрепить данными.
• Определяйте допустимые для себя погрешности для оценки результатов. Это ваш тест, затем ваши решения и, как следствие, риски.
• Если есть возможность, проконсультируйтесь с аналитиками на предмет корректности дизайна теста и выборки.
• Не переживайте, у вас все получится😃

Спасибо нашим респондентам, которые нашли время в своем плотном графике и поделились собственным опытом проведения А/В-тестов, примерами и внутренней кухней решения этих задач.

Полезные ссылки по проведению A/B-тестов

1. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing, by Ron Kohavi and Ya Xu
2. Коллекция примеров проведенных a/b исследований и их результатов
3. Статистическая и практическая значимость
4. Statistics made easy book
5. t-test
6. Lenny’s podcast: The ultimate guide to A/B testing | Ronny Kohavi (Airbnb, Microsoft, Amazon)
7. Seven rules of thumb for web site experimenters
8. Отчет Optimizely: Lessons learned from running 127,000 experiments
9. Not A/B testing everything is fine
10. The 7 deadly sins of research
11. Подробнее про возможное нарушение этических норм при проведении A/B-тестов

#subscribe