Как бизнесу проводить A/B-тестирования: мнение команды аналитики Яндекс 360

После изменений в продукте не всегда понятно, что повлияло на метрики: сработал новый баннер, цвет кнопки или результат связан с притоком трафика от рекламы. Чтобы разобраться в причинах, проводят A/B-тестирования. В Яндекс 360 их используют все команды: продуктовые проверяют интерфейсы и сценарии, маркетинг — креативы, ecommerce — карточки товаров и цены. 

Мы поговорили с руководителем направления аналитики Яндекс 360 Екатериной Бровиковой, чтобы узнать, как выстраивать полный цикл экспериментов.

Зачем бизнесу A/B-тестирование

Аналитики часто называют A/B-тестирование своим любимым исследованием. Расскажу почему. Мы все живём в сложно устроенном мире: на потребителей и продукт влияют новостной фон, погода и ещё множество внешних факторов. В каждой сфере есть ещё свои специфические сезонности. Например, в Яндекс Диске традиционно повышается активность 1 сентября, так как все фотографируют своих детей с букетами и потом сохраняют снимки в облаке. Получается, что любая важная метрика, которую мы смотрим в динамике, находится в нестерильной экосистеме и под её влиянием. А значит, результаты анализа метрики могут быть некорректными.

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

Обычно A/B-тесты используют, когда нужно:

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

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

Как создают эксперименты

A/B-тестирование проводят в несколько последовательных этапов.

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

В Яндекс 360 есть годовые цели на все ключевые метрики. Любой эксперимент запускается в рамках большого целеполагания, и у команды есть ожидания от того, как поменяется та или иная метрика. У нас ещё есть гигиенические метрики, за которыми мы должны следить в любом тесте, например сбои или скорость загрузки. Их цель — найти проблемы даже там, где мы, казалось бы, ничего не ломали.

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

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

Разбить пользователей на две группы случайным образом

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

Проверить соответствие аудитории условиям эксперимента

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

Настроить логирование

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

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

В первые часы теста команда проверяет только базовые технические вещи: 

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

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

Допустим, через две недели A/B-тестирования видны значимые изменения в метриках. Старая зелёная кнопка и новая красная получили одинаковое количество показов, но изменилась метрика CTR. Пользователи чаще кликали на новую кнопку, и дальше многие из них купили услугу или товар. Эксперимент оказался успешным, значит, изменения раскатывают на всю аудиторию. 

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

В идеальном сценарии всё проходит на отлично. Но есть миллион неидеальных ситуаций, когда планировалось, что метрика будет расти, а она не растёт. Перекрасили кнопку, но продаж больше не стало. А может быть, дело вообще не в цвете кнопки. 

Неидеальный результат теста — это нормально! В таком случае команда разбирается, почему итоги не совпали с ожиданиями: смотрит на целевые метрики, прокси-метрики и поведение пользователей внутри сценария. Строятся новые гипотезы, и A/B-тестирование выходит на второй цикл. Мой совет: не бойтесь делать ошибки, мы тоже их совершаем. Многие эксперименты у нас, в Яндексе 360, перезапускаются по 5–6 раз — такое тоже бывает. 

Какие инструменты Яндекс 360 помогут провести эксперимент

Расскажу, как мы это делаем в нашей команде аналитики. 

Гипотезы от разных команд собираем через чек-лист в Яндекс Формах. Команды отмечают, зачем нужен эксперимент и какую задачу он решает, в чём заключается гипотеза, какие метрики нужно проанализировать, сроки проведения, ограничения — например, по платформам, версиям приложения или аудитории. Гипотезы можно собрать через заявку на эксперимент — оформить её можно вот по такому примеру.

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

А ещё в Трекере можно увидеть полный список экспериментов и их статус: что запланировано, что уже запущено, какие тесты ждут анализа. Так проще распределять нагрузку, не допускать пересечения экспериментов и понимать, когда пора подводить итоги. 

Все результаты A/B-тестирований фиксируем также в Трекере. В отчёт включаем гипотезу, период теста, цепочку метрик, графики, ссылки и выводы: подтвердилось ли предположение и что делать дальше — раскатывать изменение, дорабатывать или закрывать гипотезу.

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

За полгода только в одной Почте проводится по 70 тестов. Мы проводим A/B-тестирования для десяти сервисов Яндекс 360, четырёх бандлов и ещё множества функциональных команд, например саппорта. Чтобы не потерять результаты и не запутаться в них, в тикете мы всегда всё фиксируем, прикладываем нужные ссылки и картинки. Можно вернуться к эксперименту спустя несколько лет и быстро вспомнить, что там было.