Чек-лист по правильному A/B-тестированию

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

Про статистику и про то, как делать А/В-тесты, информации в изобилии, но в большинство источников фокусируются на «технике», подсчете выборки, проблеме подглядывания, правильной интерпретации p-value… А вот практических советов по менеджменту А/В-тестов не так уж и много.

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

Зачем нужны чек-листы

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

План чек-листа:

1. Формулировка гипотезы
2. Нужен ли А/В-тест?
3. Определяем метрики
4. Определяем путь разделения на группы
5. Определяем целевую группу
6. Определяем ключевую метрику
7. Определяем размер выборки
8. Утверждаем критерии успеха и действий по итогам
9. Описываем необходимый трекинг для оценки теста
10. Проверка технической реализации функционала
11. Запуск теста
12. Проверка теста после запуска
13. Следим за метриками
14. Выявляем типичные временные эффекты в рамках изменений
15. После набора выборки принимаем решение
16. Закрываем тест
17. Оцениваем полезность теста
18. Заносим характеристики и результаты теста в историю

Рассмотрим каждый пункт детальнее.

✓ Формулировка гипотезы

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

Построение гипотезы строится следующим образом:

✓ Нужен ли А/В-тест?

Аргументы за:

Тестирование дает наиболее точную оценку внесенных изменений.

Основной альтернативой является анализ динамики, то есть сравнение периодов до и после применения изменений. Такой метод подходит для определенных случаев, однако сталкивается с проблемами в некоторых ситуациях:

• Множество факторов одновременно влияют на метрики. Чем больше факторов воздействуют на метрики вашего продукта, тем актуальнее оценивать внесенные изменения с помощью А/В-тестирования. Факторы могут включать постоянные изменения в структуре пользователей по ключевым параметрам (пол, возраст, источник трафика и т.д.), а также одновременное проведение других тестов в вашем продукте или других продуктах компании. Даже тщательное наблюдение за динамикой по всем сегментам не гарантирует, что именно затрагиваемое изменение повлияло на метрику, а не другой фактор. Вы никогда не будете владеть всей информацией о всех факторах, оказывающих влияние на продукт в данный момент. Случайное распределение групп в А/В-тестах позволяет избежать влияния всех факторов, даже тех, которые непосредственно не видны.
• От внесенных изменений ожидается минимальное влияние на метрики, которое может быть незаметным в динамике из-за естественной волатильности метрики. БОльшая часть тестов на продуктах, особенно на более поздних стадиях развития, именно таковы. Проводя десятки подобных тестов, можно сдвинуть общую динамику в плюс или минус, не понимая при этом, что именно привело к этому и как продолжать работу. На графике ниже представлен гипотетический пример выручки продукта, где было 5 изменений без А/В-теста в разное время, но из-за общей волатильности невозможно определить, какие именно из них привели к снижению выручки:

При использовании А/В-тестирования для оценки изменений на аналогичном графике с добавлением разделения по группам можно было бы увидеть, что отрицательную динамику вызвали только два изменения, от которых следовало отказаться (синяя линия – контрольная группа, желтые – группы с примененными изменениями):

А/В-тестирование позволяет с уверенностью отказаться от неудачного изменения, которое может нравиться команде, но не пользователям.

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

Тестирование облегчает работу аналитика при оценке внесенных изменений.

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

В рамках А/В-тестирования значительно упрощается поиск ошибок и несоответствий заложенной изначально логике изменений.

Без проведения тестов существует высокая вероятность того, что мы не узнаем:

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

Аргументы против:

• Тестирование усложняет разработку.
• Если изменение небольшое, могут быть израсходованы лишние ресурсы (хотя не всегда очевидно, что изменение малозначительное – любое изменение в области продукта с большим количеством посетителей стоит считать важным).
• Если выборка слишком мала или недостаточно релевантна, А/В-тест не предоставит надежный или долгосрочно актуальный результат. Либо потребуется слишком много времени на тестирование, что приведет к потере возможностей альтернативного решения в течение этого периода.
• Долгосрочная концепция продукта основана на рассматриваемом изменении и не предполагает альтернатив в зависимости от результатов.

✓ Определяем метрики

Метрика А/В-теста – это показатель, с помощью которого оцениваются результаты и доказательство гипотезы.

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

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

✓ Определяем путь разделения на группы

• Разделение на две равные группы: 50% пользователей с изменением и 50% контрольная группа без изменений. Это разделение является наиболее быстрым с точки зрения получения результатов, но сопряжено с риском, если изменение значительное, и если тест включает пользователей, которые уже ранее использовали продукт.
• Разделение на неравные группы: например, 5% пользователей с изменением и контрольная группа из 95% пользователей. Такой подход часто используется, когда хотим подвергнуть риску изменений лишь небольшую часть пользователей. Также многие тесты стоит проводить не менее одной недели, независимо от выборки, чтобы учесть особенности изменения с учетом вариативности по дням недели, характерной для большинства продуктов. Долгосрочная оценка (2-3 недели и более) требуется для тестов, в которых функционал оказывает влияние на более поздних этапах пользовательского опыта. В таких условиях может быть рискованно надолго подвергать изменениям значительную часть аудитории, и даже на проектах с меньшей аудиторией порой оправдано выделить 5-10% пользователей для группы с изменением.

✓ Определяем целевую группу для А/В-теста (сегментация)

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

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

✓ Определяем ключевую метрику и место в продукте, на котором происходит разделение логики

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

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

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

✓ Определяем необходимый размер выборки

Контрольная и экспериментальная группы — пользователи, принимающие участие в эксперименте. Можно проверять как на всех пользователях, так и на группах, объединенных по определенным характеристикам: местоположение, пол, возраст и т.д.

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

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

Продолжительность тестирования — количество дней, в течение которых будет проводиться эксперимент. Этот показатель зависит от минимального объема выборки и текущего трафика. Продолжительность тестирования можно рассчитать по формуле: выборка / трафик = количество дней. Допустим, минимальный объем выборки для статистически значимых результатов теста составляет 10 000 уникальных посетителей. Сайт имеет в среднем 1 000 посетителей в день. Тогда продолжительность теста составит 10 дней.

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

• Точку чувствительности (ключевую метрику), включая жизненный цикл пользователя, следует рассчитывать на основе той доли пользователей, которая доходит до места изменения.
• Принимать во внимание важные сегменты, в рамках которых мы хотим проверить влияние — каждый сегмент рассматриваем как отдельный тест со своей выборкой, ошибками первого и второго рода и так далее, но делать это осторожно, чтобы не привести к p-hacking-у, о котором упоминалось в предыдущей статье. Необходимо обязательно вносить статистические поправки при таком анализе (например, поправку Бонферрони: делить выбранный уровень значимости (5%) на количество сравнений в тесте).
• Учитывать минимальный эффект влияния на метрику, который можно обнаружить тестом (minimum detectable effect). Чем больше влияния мы ожидаем, тем меньше выборка потребуется. Если вы не ожидаете конкретного влияния, а лишь хотите получить лучший результат от изменения, можно определить другие приемлемые параметры, включая количество пользователей, на сбор которых готовы потратить время и узнать минимальную степень влияния, которую на момент завершения фактически сможете уловить, проведя тест. Если на этот момент разница между вариантами теста окажется больше, чем фактический эффект, который может обнаружить статистически значимое изменение – тест проведен успешно, минимальная выборка точно набралась и можно смотреть на результат. В противном случае можно увидеть только отсутствие статистической значимости.
• Принимать во внимание количество дней недели, которые нужно охватить тестом для получения данных по метрикам, показывающим волатильность в зависимости от дня недели. Иногда продукт может собрать внушительную выборку за полдня, но для получения объективной картины по дням недели его все равно лучше проводить не менее 7 дней.

✓ Принимаем окончательное решение, нужен ли А/В-тест, утверждаем критерии успеха и действий по итогам

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

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

✓ Описываем необходимый трекинг для оценки теста

Какие новые данные нужно записывать по событиям продукта:

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

✓ Проверка технической реализации функционала

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

✓ Запуск теста

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

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

✓ Первая проверка после запуска или как выявлять технические недоработки / аномалии сразу после запуска

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

Проверяем:

• Наличие и правильность запланированного трекинга.
• Соответствие назначенных групп вариантам логики.
• Равномерное распределение выборки по вариантам, как было запланировано (например, 50/50). При достаточно большой выборке между группами не должно быть статистически значимого различия в фактическом распределении количества пользователей относительно запланированного (sample ratio mismatch) — как для всей выборки, так и в рамках точки чувствительности.

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

✓ Следим за метриками по сегментам и по общей динамике. Когда нужно останавливать тест досрочно

Смотрим не только на обобщенные метрики, но и на конкретные примеры использования функционала, распределение значений метрик и выбросы. Досрочное закрытие теста (до набора достаточной выборки) может быть оправдано в следующих случаях:

1. Тест работает неправильно.

2. Тест работает правильно, но:

• Показывает явно плохой результат. Границу между «явно плохим» и «допустимым» вы определяете самостоятельно для каждого случая. Разумеется, разница должна быть определенной на выборке адекватного размера и сопоставлена с историческим значением метрики и ее обычной волатильностью. Если есть сомнения, ждите заранее определенного размера выборки и принимайте решение. Здесь речь идет в основном о случаях, когда рискованный тест показывает явно плохой результат именно там, где его логично было ожидать, а на положительное влияние нет намека. В таких случаях вы готовы отказаться от изменений, не получая полноценный отчет со всеми плюсами и минусами.
• Обычные изменения и добавление новых дополнительных функций редко дают сильно хорошие/плохие результаты. Как только замечаем такие результаты в динамике теста, следует рассматривать их как потенциальную ошибку и искать проблему. Если проблему найти не удается, но результаты вызывают подозрения, можно провести новый тест с другим разделением групп, при этом важно найти логическое обоснование для неожиданно сильного воздействия.
• Функционал может проявить себя хорошо, но обойти изначально запланированную логику. Например, ошибочные дубликаты уведомлений могут привести к краткосрочному положительному эффекту и крайне негативному долгосрочному влиянию. Или же функционал может показать себя плохо не из-за своей сути, а из-за негативного влияния на производительность и другие факторы, которые могли бы быть исправлены.
• Ложноотрицательный результат (вероятность того, что вы не увидите статистически значимый результат там, где он на самом деле есть, зависит от выбранной мощности теста; по умолчанию она равна 80%, то есть в 80% случаев мы увидим статистически значимый результат, если он есть, но в 20% таких случаев будем ошибаться) может скрыть от вас потенциально перспективные направления развития продукта.

✓ Выявляем типичные временные эффекты в рамках изменений

Новизна (для старых пользователей)

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

Привычка (для старых пользователей)

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

Кумуляция

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

Долгосрочные эффекты

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

✓ После набора достаточной выборки принимаем решение

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

Представим пример:

Гипотеза: “Если мы поменяем цвет кнопки на красный, то конверсия улучшится с 1% до 1.1%”.

Нулевая гипотеза: “Смена цвета не улучшит конверсию (или вообще ухудшит).”

У нас может быть 3 исхода A/B теста:

• Гипотеза подтверждена – меняем цвет;
• Гипотеза опровергнута – это не значит, что красный цвет хуже, это значит, что он дает меньше чем 1.1% конверсии;
• Ничего не понятно (статистически незначимый результат). Результаты не дают ни достоверного подтверждения, ни опровержения гипотезы.

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

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

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

✓ Определяем, полезным ли был для нас тест

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

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

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

✓ Заносим характеристики и результаты теста в историю проведения А/В-тестов

История тестов всегда очень полезна, особенно если:

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

Выводы

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

Источники и полезные ссылки по теме:

• Главные ошибки в AB-тестах и к чему они приводят
• Как одолеть вопросы по АБ тестам с собеседований
• А/В-тесты — не только статистика? Чек-лист для продакт-менеджера (в РФ доступно только под VPN)

• Об авторе
• Свежие записи

Ксения Шипулина

Бакалавр направления экономики (ранее-экономическая кибернетика) Новосибирского государственного университета. Ex-ведущий аналитик направления A/B тестирования в Сравни.

• Чек-лист по правильному A/B-тестированию - 09.06.2023
• Главные ошибки в AB-тестах и к чему они приводят - 27.06.2022