A/B-тестирование: сколько надо дней для успешного теста или что делать, если что-то пошло не так?

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

Сегодня я хочу обсудить другой, бизнесовый, аспект проведения A/B-тестов.

Цель любого A/B-теста это увеличение целевого показателя. И как это обычно бывает, гипотез о том, что можно было бы сделать намного больше, чем ресурсов у компании. Здесь мы должны принять некое компромиссное решение между двумя крайностями:
  • часто до запуска теста нужны доработки со стороны IT
  • разные тесты будут приносить разный выхлоп (объем результата)
Поэтому для бизнеса всегда важно делать приоритезацию тестов. Для приоритезации гипотез нужно как-то оценить возможный исход и количество необходимого времени.

Как мы уже выяснили из прошлого поста, до запуска теста нужно выполнить два предварительных условия:
  1. оценить прирост целевого показателя
  2. понимать какой объем трафика может понадобится
НО, намного удобнее, если бы мы могли оценивать тесты используя понятные маркетологу конечные показатели:
  • количество дней, которые необходимы для завершения эксперимента
  • разница в результате (в целом или на уровне дня) между двумя версиями
И вот недавно я наткнулся на такой инструмент. Сделала его компания booking.com. В booking.com есть 75(!) кросс-функциональных продуктовых команд, каждая из которых запускает десятки экспериментов в месяц. Поэтому этот вопрос они давно для себя решили и вот поделились частью своих наработок.

Что же примечательного в этом инструменте по сравнению с Evan's Awesome A/B Tools?

Booking Power Calculator (BPC)
https://bookingcom.github.io/powercalculator/

BPC имеет 3 конфигурационные вкладки:
  • Base Rate
  • Sample Size
  • Impact
Кроме этого, он содержит в себе набор графиков, которые позволяют оценить разные конфигурации теста.

(0) Оба инструмента позволяют при расчете минимально необходимой выборки указать два важных параметра:
  • 1-β : power, или говоря по-другому % случаев, когда тест найдет минимально необходимый эффект, когда такой имеет место быть
  • α : false positive rate, или говоря по-другому % случаев, когда тест найдет разницу в вариантах, в то время как ее нет
Важно отметить, что по умолчанию, BPC устанавливает % ложных срабатываний (p.value) на уровне 10%, а не 5%, как это обычно принято. Мы все же выставим этот показатель на классическом уровне 5% и двинемся дальше.

(1) Запуская тест, бизнес, как правило, не мыслит минимальным объемом выборки. Бизнес мыслит количеством дней, необходимых для принятия решения. BPC позволяет легко оценивать разные варианта развития событий.

Итак, предположим наша базовая конверсия 3%. У нас есть гипотеза, в результате которой конверсия может вырасти до 4%. Т.е. абсолютный прирост конверсии составит +1%.

Booking Power Calculator: Base Rate.

Booking Power Calculator: Impact.

Указав эти параметры теста мы сразу получаем три полезных показателя:
  • Metric Totals - общее количество конверсий, которые мы должны получить при базовой конверсии в 3% (317)
  • Incremental trials - какой прирост в конверсии мы должны наблюдать в целом по тесту (105)
  • Incremental trials per day - какой прирост в конверсии мы должны наблюдать на уровне дня (105)
Здесь важно отметить, что booking.com огромная компания, поэтому изначально калькулятор делает прикидку объема трафика так, чтобы тест закончился всего за 1 день.

Очевидно, что совсем немного компаний имеют такие объемы трафика, чтобы завершать тесты за 1 день.

Для тех, у кого нет такого объема трафика, BPC дает возможность это учесть.

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

Booking Power Calculator: Sample Size by volume.

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

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

Допустим, мы хотели бы, чтобы тест закончился за 2 дня. 

Booking Power Calculator: Sample Size by days.

Мы указываем этот период и BPC говорит, что нам понадобится 5,299 сессий в день. Отлично!

(2) Внизу BPC есть 6(!) видов интерактивных графиков, которые помогают понять возможные конфигурации вашего теста.

Приведу простой пример. Исходные параметры теста те же.
  • Базовая конверсия 3%
  • Абсолютный прирост +1%
  • Количество трафика в тесте 2000 сессий в день
Мы запустили тест, но видим, что наши ожидания по приросту конверсии были несколько оптимистичны. 

Мы ожидали, что конверсия вырастет на 1% в абсолютном выражении. BPC подсказал, что это равносильно тому, что наш прирост конверсий в день составит 17 конверсий.
Мы видим, что конверсия сдвинулась, но в день прирост составляет не более 13 конверсий. 

Booking Power Calculator: Inc. Trials per day.

Всего одно движение мыши на интерактивном графике и мы уже знаем, что с таким темпом нам понадобится не 6 дней (как мы изначально рассчитывали в BPC), а 10 дней. Дальше, бизнес принимает решение, готов ли он ждать такое количество времени или нет.

РЕЗЮМЕ:

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

Booking Power Calculator простой и удобный инструмент, который помогает маркетологу смоделировать идеальное развитие событий в тесте, а также скорректировать свои ожидания через нескольких дней после запуска (если ожидания не соответствуют реальности).

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

Popular posts from this blog

RF-матрица как альтернатива для работы с LTV

A/B-тестирование: смотреть на конверсию vs смотреть на продажи

LTV: классический подход прогнозирования Pareto/NBD