Взгляд на A/B-тестирование со стороны тестировщика
Новые идеи, предположения — неотъемлемая часть развития любого продукта. Так происходит, что не каждая идея даст прирост аудитории, повысит конверсию и т.д. Тогда как же можно быстро проверять идеи, предложения и гипотезы? А/В-тестирование или проверка гипотез - это эксперимент, сравнивающий две версии чего-то, чтобы выяснить, что работает лучше. Забавный факт: А/В-тест был использован еще в 1900-х годах Уильямом Госсетом, статистиком Guinness, чтобы проверить, какой тип ячменя имеет лучший урожай для производства пива.
Кто они, заказчики A/B-тестирования на проекте?
- Продакт-менеджеры: могут тестировать те или иные новые фичи на проекте, чтобы проверить гипотезы и определить, какая версия лучше.
- Маркетологи: могут проводить тестирование элементов маркетинговой кампании или рекламы с точки зрения улучшения метрик.
- Дизайнеры: могут тестировать новые дизайнерские решения (например, цвет кнопки оформления заказа) или использовать результаты тестирования для того, чтобы перед внедрением определить, будет ли удобно пользоваться новой функцией.
Каким образом и как долго проводится?
Пользователи сервиса, все или какая-то часть, делятся на сегменты или сплиты. Один из сплитов остается без изменений — это контрольный сегмент, например “A”, на основе данных по этому сегменту оценивается эффект от вносимых изменений. Пользователям из сплита “B” показываем измененную версию продукта. А если у нас, предположим, будет три или четыре варианта измененной версии и необходимо заказчику определиться, какой же вариант показал себя лучше и его и оставить? Все абсолютно будет также, только добавится несколько больше фокус-групп. Зачастую, А/В-тестирование показывает результаты в течение нескольких недель при условии наличия стабильного трафика. Однако и есть случаи, когда A/B-тест может длиться ровно столько, сколько необходимо для того, чтобы его результаты достигли статистической значимости и имели достаточную надежность, чтобы использовать их для принятия решений.
Как тестировать фичи, которые завязаны на A/B-тесты?
При тестировании фичей, завязанных на A/B-тесты, стоит учитывать такие кейсы, как:
- проверка работоспособности продукта с ВЫключенным A/B-тестом (занимает первую позицию, очень важный пункт, когда необходимо срочно отключить фичу, а специалисты "забыли" проверить поведение приложения с отключенным тестируемым вариантом и в таком случае велики риски прямых потерь со стороны бизнеса);
- проверка работоспособности продукта с ВКЛюченным A/B-тестом;
- аналитика, которая работает должным образом и события отправляются как для клиентов, которые попали под тест, так и для клиентов, которые не попали под тесты;
- обратить внимание на появление артефактов при выключенном A/B-тесте с новой фичей.
Новые идеи, предположения — неотъемлемая часть развития любого продукта. Так происходит, что не каждая идея даст прирост аудитории, повысит конверсию и т.д. Тогда как же можно быстро проверять идеи, предложения и гипотезы? А/В-тестирование или проверка гипотез - это эксперимент, сравнивающий две версии чего-то, чтобы выяснить, что работает лучше. Забавный факт: А/В-тест был использован еще в 1900-х годах Уильямом Госсетом, статистиком Guinness, чтобы проверить, какой тип ячменя имеет лучший урожай для производства пива.
Кто они, заказчики A/B-тестирования на проекте?
- Продакт-менеджеры: могут тестировать те или иные новые фичи на проекте, чтобы проверить гипотезы и определить, какая версия лучше.
- Маркетологи: могут проводить тестирование элементов маркетинговой кампании или рекламы с точки зрения улучшения метрик.
- Дизайнеры: могут тестировать новые дизайнерские решения (например, цвет кнопки оформления заказа) или использовать результаты тестирования для того, чтобы перед внедрением определить, будет ли удобно пользоваться новой функцией.
Каким образом и как долго проводится?
Пользователи сервиса, все или какая-то часть, делятся на сегменты или сплиты. Один из сплитов остается без изменений — это контрольный сегмент, например “A”, на основе данных по этому сегменту оценивается эффект от вносимых изменений. Пользователям из сплита “B” показываем измененную версию продукта. А если у нас, предположим, будет три или четыре варианта измененной версии и необходимо заказчику определиться, какой же вариант показал себя лучше и его и оставить? Все абсолютно будет также, только добавится несколько больше фокус-групп. Зачастую, А/В-тестирование показывает результаты в течение нескольких недель при условии наличия стабильного трафика. Однако и есть случаи, когда A/B-тест может длиться ровно столько, сколько необходимо для того, чтобы его результаты достигли статистической значимости и имели достаточную надежность, чтобы использовать их для принятия решений.
Как тестировать фичи, которые завязаны на A/B-тесты?
При тестировании фичей, завязанных на A/B-тесты, стоит учитывать такие кейсы, как:
- проверка работоспособности продукта с ВЫключенным A/B-тестом (занимает первую позицию, очень важный пункт, когда необходимо срочно отключить фичу, а специалисты "забыли" проверить поведение приложения с отключенным тестируемым вариантом и в таком случае велики риски прямых потерь со стороны бизнеса);
- проверка работоспособности продукта с ВКЛюченным A/B-тестом;
- аналитика, которая работает должным образом и события отправляются как для клиентов, которые попали под тест, так и для клиентов, которые не попали под тесты;
- обратить внимание на появление артефактов при выключенном A/B-тесте с новой фичей.