Гайд по A/B тестированию. Как делать A/B тесты в 2025м году. Часть 1.

AB тестирование это основа экспериментов. Этот метод широко используется маркетологами, веб-разработчиками, менеджерами по продукту, UX дизайнерами.

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

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

A/B тест обычно состоит из следующих шагов:

Проведение регулярных A/B тестов имеет множество эффектов:

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

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

Маркетинговые команды используют A/B тесты в том числе для улучшения эффективности своих рекламных кампаний в различных каналах.

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

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

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

Разберем распространенные варианты A/B тестирования, которые применяются сегодня

При сплит тестировании аудитории направляются на разные или разделенные URL адреса. Само разделение скрыто от пользователей.

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

Мультивариантное тестирование (или MVP) - это методология A/B тестирования, которая позволяет одновременно тестировать несколько вариантов в ходе одного эксперимента.

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

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

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

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

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

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

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

Хотя А/B тестирование и основано на статистических методах, не обязательно хорошо разбираться в статистике, чтобы проводить A/B тесты. Однако, знание некоторых основ поможет проводить тесты лучшего качества. Методы A/B тестирования основаны на двух основных статистических методах. Каждый из которых подходит для своих случаев использования.

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

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

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

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

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

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

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

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

Однако есть и недостатки, такие как невозможность проведения сложных тестов, невозможность тестирования мобильных приложений. Также такие тесты могут привести к замедлению загрузки сайтов или эффекту мерцания на странице, невозможность сбора некоторых данных ( например данных которые попадают под стандарт защиты данных как ITP).

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

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

С помощью A/B тестов можно протестировать практически что угодно. Весь вопрос в том, как это будет протестировано.

На стороне клиента можно эффективно тестировать элементы браузера такие как:

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

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

Несколько примеров что можно тестировать на сервере:

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

Регулярное проведение A/B тестов помогает компаниям расти и в основном оправдывает затраченные инвестиции.

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

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

Для определения команды для проведения A/B тестирования можно опираться на одну из следующих структур.

Централизованная структура. Для всей компании определяется единая стратегия тестирования, которая и применяется в каждой команде. Одна команда проводит тестирования исходя из общих приоритетов и задая.

Децентрализованная структура. Команда собирается из экспертов в разных командах. Такая децентролизованная команда проводит тестирования в нескольких проектах одновременно.

Гибридная структура. Выделяется один юнит для экспериментов, тестирование проводят эксперты из разных команд.

Продолжение напишу во второй части статьи.