A/B-тестирование интерфейсов: от гипотезы до решения

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

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

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

Правильно поставленный тест включает:

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

Что такое A/B-тестирование

В простейшем эксперименте сравниваются два варианта:

• A — текущий интерфейс, или контроль;
• B — новая версия, или экспериментальный вариант.

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

Пример:

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

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

Чем A/B-тест отличается от сравнения «до и после»

Сравнение показателей до изменения и после него не является полноценным A/B-тестом.

На результат между двумя периодами могут повлиять:

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

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

Чем A/B-тест отличается от юзабилити-тестирования

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

Когда A/B-тестирование действительно полезно

Эксперимент оправдан, если:

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

Подходящие объекты тестирования

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

Когда A/B-тест не нужен

Очевидная техническая ошибка

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

Нарушение доступности

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

Низкий трафик

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

Полный редизайн

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

Отсутствие стабильной контрольной версии

Если продукт ежедневно меняется, контроль перестаёт быть контрольным.

Критически опасное изменение

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

Неизмеримая гипотеза

Формулировка «сделать интерфейс современнее» не содержит проверяемого результата.

Альтернативы при недостаточном трафике

• юзабилити-тестирование;
• интервью;
• экспертный UX-аудит;
• анализ записей сессий;
• опрос после выполнения действия;
• тест прототипа;
• анализ поисковых запросов;
• проверка воронки;
• постепенный rollout;
• сравнение когорт с учётом ограничений метода.

Этап 1. Найдите проблему

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

Источники проблем

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

Пример проблемы

На страницу оформления переходят 10 000 пользователей, но только 2 000 начинают заполнять форму и 600 завершают заказ. Записи сессий показывают, что часть посетителей покидает страницу после появления обязательной регистрации.

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

Этап 2. Изучите исходный показатель

Перед расчётом эксперимента необходимо знать базовый уровень основной метрики.

Например:

• конверсия контрольной формы — 4%;
• средний доход на пользователя — 350 ₽;
• доля завершения регистрации — 28%;
• доля пользователей, нашедших товар — 62%.

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

Этап 3. Сформулируйте гипотезу

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

Если мы изменим X для аудитории Y,
метрика Z изменится не менее чем на M,
потому что R.

Пример:

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

Состав гипотезы

• Изменение: гостевое оформление.
• Аудитория: новые неавторизованные пользователи.
• Метрика: завершённая оплата.
• Ожидаемый эффект: относительный рост не менее 8%.
• Обоснование: обязательная регистрация создаёт дополнительный барьер.

Слабые гипотезы

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

Сильные гипотезы

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

Этап 4. Приоритизируйте гипотезу

Количество идей обычно превышает доступный трафик и ресурсы. Гипотезы можно оценивать по нескольким параметрам:

• ожидаемое влияние;
• уверенность в обосновании;
• охват;
• стоимость разработки;
• сложность анализа;
• риск;
• время внедрения;
• стратегическая важность.

Этап 5. Выберите основную метрику

Основная метрика должна непосредственно отражать цель эксперимента. Её выбирают до запуска.

Примеры основных метрик

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

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

Основная, вторичные и диагностические метрики

Защитные метрики

Guardrail metrics защищают продукт от локального улучшения за счёт ухудшения другого результата.

Примеры:

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

Возможные защитные метрики

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

Не выбирайте слишком много основных метрик

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

Практичная структура:

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

Этап 6. Определите единицу рандомизации

Распределять варианты можно по:

• пользователю;
• учётной записи;
• компании;
• устройству;
• браузеру;
• сессии;
• географическому объекту;
• магазину;
• команде.

Единица зависит от продукта и возможного влияния участников друг на друга.

Пользователь

Подходит для большинства персональных интерфейсов, если доступен устойчивый идентификатор.

Учётная запись или компания

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

Сессия

Подходит редко. Пользователь может видеть разные варианты при повторных визитах, что создаёт смешение опыта.

Устройство или браузер

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

Firebase A/B Testing для веб-приложений, например, использует идентификатор установки браузера. При другом браузере, приватном режиме или очистке IndexedDB один человек может быть воспринят как новый участник. Это показывает, почему способ идентификации необходимо учитывать при интерпретации результатов.

Закрепление варианта

После назначения варианта участник должен продолжать видеть его в течение всего теста.

Для закрепления применяются:

• серверный идентификатор пользователя;
• feature flag;
• cookie;
• локальное хранилище;
• идентификатор установки;
• данные аккаунта.

Механизм должен учитывать:

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

Этап 7. Определите распределение трафика

Для двух вариантов часто используется распределение 50/50, поскольку оно позволяет быстрее получить сопоставимые выборки.

Другое распределение может быть оправдано, если:

• новая версия несёт повышенный риск;
• эксперимент начинается с небольшого rollout;
• есть несколько вариантов;
• контроль необходимо сохранить для долгосрочного сравнения;
• пропускная способность новой системы ограничена.

Пример постепенного запуска:

1. 1% трафика для технической проверки.
2. 5% после подтверждения стабильности.
3. 20% для проверки метрик.
4. 50% для основного эксперимента.

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

Этап 8. Определите минимальный обнаруживаемый эффект

Minimum Detectable Effect, или MDE, — минимальное изменение метрики, которое эксперимент должен уметь обнаружить при выбранных параметрах.

Например:

• базовая конверсия — 5%;
• минимально полезный относительный рост — 10%;
• ожидаемая тестовая конверсия — 5,5%.

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

• рост с 5% до 5,5% — это 0,5 процентного пункта;
• относительный рост составляет 10%.

Как выбрать MDE

Он должен учитывать:

• экономическую ценность эффекта;
• стоимость разработки;
• риск изменения;
• объём трафика;
• время ожидания;
• вариативность метрики;
• стратегическое значение.

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

Этап 9. Выберите уровень значимости и мощность

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

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

Часто используют:

• alpha = 0,05;
• мощность = 0,8 или 0,9.

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

Этап 10. Рассчитайте выборку

Универсального требования «500 конверсий на вариант» или «1000 посетителей в неделю» не существует.

Размер выборки зависит от:

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

Чем меньше ожидаемый эффект, тем больше наблюдений потребуется.

Пример

Исходные данные:

• базовая конверсия — 4%;
• минимальный относительный эффект — 10%;
• ожидаемая конверсия варианта B — 4,4%;
• alpha — 0,05;
• мощность — 0,8;
• две равные группы.

Для такого теста может потребоваться значительно больше пользователей, чем для обнаружения роста с 4% до 6%. Точное значение рассчитывают статистическим калькулятором или библиотекой, соответствующей выбранному методу анализа.

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

Выборка считается до запуска

Нельзя сначала запустить тест, ежедневно смотреть результат, а затем остановить его в момент появления желаемого p-value. Такая практика повышает риск ложноположительного вывода.

До запуска зафиксируйте:

• метод анализа;
• базовую метрику;
• MDE;
• alpha;
• мощность;
• необходимую выборку;
• минимальную длительность;
• максимальную длительность;
• правила аварийной остановки.

Этап 11. Определите длительность

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

При планировании учитывайте:

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

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

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

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

Задержанные конверсии

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

Необходимо определить:

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

Этап 12. Подготовьте контрольную и тестовую версии

Контрольная версия должна соответствовать текущему продукту. Вариант B реализует гипотезу и не содержит случайных дополнительных изменений.

Тест одного изменения

Правило полезно, когда команда хочет понять влияние конкретного фактора:

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

Тест комплексной концепции

Иногда имеет смысл сравнить два целостных варианта, если проверяется не отдельный элемент, а подход:

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

Такой тест показывает эффект концепции в целом, но не определяет вклад каждого её элемента.

Многовариантные тесты

В A/B/n-тесте сравниваются контроль и несколько тестовых вариантов.

Преимущества:

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

Ограничения:

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

Мультивариантное тестирование

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

Если тестируется:

• два заголовка;
• два изображения;
• две кнопки;

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

Этап 13. Настройте эксперимент технически

Варианты могут предоставляться:

• на сервере;
• через feature flags;
• на уровне приложения;
• клиентским JavaScript;
• через CMS;
• через специализированную платформу.

Серверная реализация

Сервер определяет вариант до формирования HTML.

Преимущества:

• нет визуальной подмены после загрузки;
• можно тестировать архитектурные изменения;
• меньше зависимость от клиентского JavaScript;
• проще контролировать производительность.

Ограничения:

• нужна разработка;
• сложнее запуск для нетехнической команды;
• необходима интеграция с аналитикой.

Клиентская реализация

JavaScript изменяет страницу после загрузки.

Преимущества:

• быстрый запуск простых изменений;
• визуальный редактор;
• меньше изменений backend.

Ограничения:

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

Feature flags

Флаг позволяет включать вариант для определённой группы без отдельной кодовой ветки продукта.

Флаг должен иметь:

• владельца;
• дату создания;
• описание;
• условия включения;
• события аналитики;
• план удаления после эксперимента.

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

Актуальные инструменты

Google Optimize и Optimize 360 недоступны с 30 сентября 2023 года, поэтому рекомендации использовать их для новых экспериментов устарели.

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

• собственную систему feature flags;
• Optimizely;
• VWO;
• AB Tasty;
• GrowthBook;
• Statsig;
• Firebase A/B Testing;
• экспериментальные инструменты рекламных платформ;
• внутреннюю платформу аналитики.

Firebase A/B Testing работает совместно с Remote Config для изменений приложения и с Firebase Cloud Messaging для экспериментов с сообщениями.

Отчёт Яндекс Метрики «Директ, эксперименты» предназначен для оценки экспериментов Яндекс Директа, включая сравнение настроек кампаний, типов кампаний, объявлений и посадочных страниц. Это не универсальный визуальный редактор интерфейсных A/B-тестов.

Как выбрать платформу

Проверьте:

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

Этап 14. Настройте события

До запуска проверьте каждое событие, участвующее в анализе.

Событие должно иметь

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

Пример структуры

event: checkout_completed
experiment_id: guest_checkout_2026_01
variant: B
user_id: 184529
order_id: 98321
revenue: 14500
timestamp: 2026-08-01T12:30:00Z

Проверка событий

1. Назначить тестового пользователя варианту A.
2. Пройти сценарий.
3. Проверить отправку событий.
4. Повторить для B.
5. Проверить отсутствие дублей.
6. Сверить событие с backend или CRM.
7. Проверить задержку появления данных.

Не доверяйте только клиентскому событию

Для оплаты, договора, возврата или квалифицированного лида желательно использовать серверное подтверждение.

Клиентский код может:

• не выполниться;
• быть заблокирован;
• отправить событие дважды;
• зафиксировать нажатие без успешной операции;
• потерять соединение;
• сработать до ответа сервера.

Этап 15. Проведите A/A-тест

В A/A-тесте две группы видят одинаковую версию интерфейса.

Он помогает проверить:

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

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

Этап 16. Проверьте Sample Ratio Mismatch

Sample Ratio Mismatch, или SRM, означает, что фактическое распределение участников значительно отличается от запланированного.

Например, при настройке 50/50 система получила:

• A — 60 000 пользователей;
• B — 40 000 пользователей.

Возможные причины:

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

При выраженном SRM нельзя сразу анализировать конверсию. Сначала необходимо найти причину нарушения распределения.

Этап 17. Запустите технический контроль

Перед полноценным распределением трафика проверьте тест на небольшой аудитории.

Проверка включает

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

Данные технического периода можно исключить из основного анализа, если параметры эксперимента ещё изменялись.

Этап 18. Зафиксируйте план эксперимента

До запуска создайте документ, содержащий:

• название;
• владельца;
• проблему;
• гипотезу;
• описание A и B;
• аудиторию;
• единицу рандомизации;
• распределение трафика;
• основную метрику;
• вторичные метрики;
• защитные метрики;
• базовое значение;
• MDE;
• alpha;
• мощность;
• расчёт выборки;
• минимальную длительность;
• правило остановки;
• исключения;
• сегменты;
• риски;
• план внедрения;
• план отката.

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

Этап 19. Запустите эксперимент

После запуска не следует менять:

• варианты;
• основную метрику;
• алгоритм распределения;
• долю трафика без документированной причины;
• целевую аудиторию;
• правило завершения;
• аналитические события.

Если критическое изменение необходимо, эксперимент лучше остановить, задокументировать проблему и запустить заново.

Что контролировать во время теста

Ежедневная техническая проверка

• объём трафика;
• распределение вариантов;
• ошибки;
• работа событий;
• скорость;
• аварийные показатели;
• жалобы;
• доступность продукта.

Что не следует делать ежедневно

• объявлять победителя;
• останавливать тест при первом p-value меньше 0,05;
• искать успешный сегмент среди десятков вариантов;
• менять гипотезу;
• перераспределять трафик в пользу лидера;
• удалять неудобные данные.

Правила аварийной остановки

Эксперимент можно остановить раньше, если:

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

Порог аварийной остановки желательно определить до запуска.

Этап 20. Завершите набор данных

Тест завершается после выполнения заранее определённых условий:

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

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

Этап 21. Рассчитайте показатели

Конверсия

CR =
Конверсии / Участники × 100%

Абсолютная разница

Абсолютная разница =
CR(B) − CR(A)

Относительное изменение

Относительное изменение =
(CR(B) − CR(A)) / CR(A) × 100%

Пример

• A: 1 000 конверсий из 20 000 пользователей — 5%;
• B: 1 100 конверсий из 20 000 пользователей — 5,5%.

Абсолютное изменение =
5,5% − 5% = 0,5 процентного пункта

Относительное изменение =
0,5 / 5 × 100% = 10%

Что такое p-value

p-value — вероятность получить наблюдаемую или более выраженную статистику теста при условии, что нулевая гипотеза верна. Это не вероятность того, что вариант B лучше, и не вероятность истинности гипотезы.

NIST определяет p-value как вероятность получить тестовую статистику не менее экстремальную, чем наблюдаемая, при условии истинности нулевой гипотезы. Уровень, при котором результат считается основанием для отклонения нулевой гипотезы, следует определить до теста.

p-value меньше 0,05 не означает

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

Доверительный интервал

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

Пример:

Относительный эффект: +6%
95%-й доверительный интервал: от −1% до +13%

Такой результат не позволяет уверенно исключить небольшое ухудшение.

Другой пример:

Относительный эффект: +6%
95%-й доверительный интервал: от +3% до +9%

Диапазон полностью положительный и показывает более устойчивое улучшение.

Статистическая и практическая значимость

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

При принятии решения учитывайте:

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

Рост конверсии на 0,02 процентного пункта может быть статистически различимым, но экономически бессмысленным.

Множественные сравнения

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

Необходимо учитывать:

• число вариантов;
• число основных метрик;
• число проверяемых сегментов;
• повторные просмотры результата;
• серии экспериментов.

Возможные подходы:

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

Сегментный анализ

Вариант может по-разному влиять на:

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

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

Исследовательский сегмент

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

Парадокс Симпсона

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

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

Поэтому важно:

• проверять распределение аудитории;
• сравнивать заранее определённые сегменты;
• учитывать единицу рандомизации;
• не делать вывод только по одной агрегированной строке.

Эффект новизны

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

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

Для функций с регулярным использованием полезно анализировать:

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

Эффект переноса

Если пользователь сначала видел B, а затем попал в A, приобретённый опыт может повлиять на поведение в контроле.

Особенно это важно для:

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

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

Пересечение экспериментов

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

Например:

• один тест меняет карточку товара;
• другой — кнопку покупки;
• третий — цену доставки.

Совместное влияние может отличаться от результата каждого теста по отдельности.

Подходы к управлению

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

Этап 22. Проверьте защитные метрики

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

Пример:

• конверсия формы выросла на 12%;
• доля квалифицированных лидов снизилась на 20%;
• нагрузка отдела продаж увеличилась;
• стоимость клиента выросла.

В этом случае локальная метрика улучшилась, а бизнес-результат ухудшился.

Этап 23. Рассчитайте экономический эффект

Пример:

• 100 000 пользователей в месяц;
• контрольная конверсия — 4%;
• вариант B — 4,3%;
• дополнительные заказы — 300;
• маржинальная прибыль заказа — 1 500 ₽.

Дополнительная маржинальная прибыль =
300 × 1 500 = 450 000 ₽ в месяц

Из результата необходимо вычесть:

• стоимость разработки;
• поддержку;
• дополнительную обработку;
• возвраты;
• комиссии;
• стоимость инфраструктуры;
• возможные потери других метрик.

Этап 24. Примите решение

Вариант B победил

Основная метрика улучшилась, интервал эффекта приемлем, защитные показатели не ухудшились, внедрение экономически оправдано.

Различия не обнаружены

Возможные причины:

• реального эффекта нет;
• эффект меньше MDE;
• выборки недостаточно;
• изменение слишком слабое;
• метрика не соответствует механизму;
• аудитория неоднородна;
• данные слишком вариативны.

Вариант B проиграл

Это полезный результат. Он предотвращает внедрение изменения, которое ухудшило бы продукт.

Результат неоднозначен

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

Возможные решения:

• не внедрять;
• переработать вариант;
• повторить тест;
• ограничить внедрение сегментом;
• провести качественное исследование;
• собрать дополнительные данные.

Нулевой результат — тоже результат

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

Это позволяет:

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

Этап 25. Внедрите победивший вариант

После завершения эксперимента:

1. Проверьте стабильность результата.
2. Подготовьте production-реализацию.
3. Удалите временный экспериментальный код.
4. Проведите регрессионное тестирование.
5. Постепенно увеличьте rollout.
6. Контролируйте основные и защитные метрики.
7. Удалите feature flag после стабилизации.
8. Обновите документацию и дизайн-систему.

Экспериментальная версия часто создаётся быстрее обычного production-компонента. Её нельзя оставлять в продукте как постоянную реализацию без проверки качества кода, доступности и производительности.

Проверка после внедрения

Результат A/B-теста может не полностью сохраниться после rollout на 100% пользователей.

Причины:

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

После внедрения продолжайте отслеживать:

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

Этап 26. Документируйте эксперимент

Карточка завершённого теста должна содержать:

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

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

Полный пример A/B-теста

Проблема

Большая часть пользователей покидает оформление на шаге регистрации.

Наблюдения

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

Гипотеза

Гостевое оформление повысит долю оплат среди новых пользователей минимум на 8% относительно контроля, поскольку удалит обязательный шаг до покупки.

Контроль A

Регистрация обязательна перед вводом данных доставки.

Вариант B

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

Аудитория

Новые неавторизованные пользователи интернет-магазина.

Единица рандомизации

Идентификатор пользователя или стабильный идентификатор браузера до авторизации.

Основная метрика

Оплаченные заказы на участника.

Вторичные метрики

• начало оформления;
• завершение адреса;
• успешная оплата;
• создание аккаунта после заказа.

Защитные метрики

• возвраты;
• ошибки доставки;
• обращения поддержки;
• повторные покупки;
• ошибки оплаты;
• скорость страницы.

План анализа

• двусторонняя проверка;
• alpha 0,05;
• мощность 0,8;
• MDE 8% относительного роста;
• выборка рассчитана до запуска;
• минимум два полных недельных цикла;
• дополнительное окно для созревания оплат;
• сегменты мобильных и десктопных устройств определены заранее.

Возможные решения

• внедрить B для всех новых пользователей;
• внедрить только на мобильных устройствах;
• переработать гостевой сценарий;
• сохранить A при отсутствии полезного эффекта;
• провести отдельный тест создания аккаунта после покупки.

Частые ошибки A/B-тестирования

Тест начинается без проблемы

Команда проверяет случайные элементы вместо устранения подтверждённых потерь.

Гипотеза не содержит причины

Невозможно понять, чему научил эксперимент.

Основная метрика выбирается после запуска

Команда находит показатель, который случайно улучшился.

Используется универсальная выборка

Число участников не соответствует базовой метрике и MDE.

Тест останавливается при первом положительном результате

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

Игнорируется SRM

Сравниваются группы, распределённые с ошибкой.

Пользователь видит разные варианты

Опыт смешивается, а данные теряют независимость.

Тестируются слишком похожие варианты

Эффект настолько мал, что для его обнаружения нужен огромный трафик.

Одновременно меняется всё

Результат нельзя связать с конкретным решением.

Слишком много метрик

Вероятность случайного положительного результата возрастает.

Сегменты ищутся после завершения

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

Клик принимается за бизнес-результат

CTR растёт, но продажи не меняются.

Не учитываются защитные показатели

Локальное улучшение ухудшает качество продукта.

Игнорируется задержка конверсии

Часть покупок не успевает попасть в результат.

Сравниваются сессии вместо пользователей

Один человек учитывается несколько раз и может попасть в разные группы.

Не проверяется производительность

Новый интерфейс улучшает CTA, но замедляет страницу.

Визуальный редактор ломает страницу

Тестовый скрипт создаёт вспышку, сдвиг макета или ошибку JavaScript.

Победитель остаётся экспериментальным кодом

Временное решение превращается в постоянный технический долг.

Не сохраняются результаты

Через несколько месяцев команда повторяет тот же тест.

Чек-лист до запуска

• Определена проблема.
• Собраны количественные и качественные данные.
• Гипотеза содержит изменение, аудиторию, метрику и причину.
• Определён контроль.
• Вариант B реализует гипотезу.
• Выбрана единица рандомизации.
• Настроено закрепление варианта.
• Определена аудитория.
• Выбрана одна основная метрика.
• Определены вторичные метрики.
• Определены защитные метрики.
• Известно базовое значение.
• Определён MDE.
• Выбраны alpha и мощность.
• Рассчитана выборка.
• Определена минимальная длительность.
• Учтена задержка конверсии.
• Зафиксировано правило остановки.
• Определены аварийные пороги.
• Настроены события.
• События проверены.
• Данные можно связать с вариантом.
• Проверена дедупликация.
• Проверена доступность.
• Проверена производительность.
• Подготовлен план отката.
• Эксперимент задокументирован.

Чек-лист во время теста

• Контролируется объём трафика.
• Проверяется распределение вариантов.
• Проверяется SRM.
• Контролируются ошибки.
• Контролируются защитные метрики.
• Не меняется основная метрика.
• Не меняются варианты.
• Не меняется аудитория.
• Не выполняется преждевременная остановка.
• Не исключаются неудобные данные.
• Фиксируются внешние события.
• Проверяется работа аналитики.
• Сохраняется журнал изменений.

Чек-лист анализа

• Достигнута рассчитанная выборка.
• Пройден минимальный временной цикл.
• Созрели задержанные конверсии.
• Не обнаружен необъяснённый SRM.
• Рассчитаны показатели A и B.
• Показана абсолютная разница.
• Показано относительное изменение.
• Рассчитан доверительный интервал.
• Корректно интерпретирован p-value.
• Учтены множественные сравнения.
• Проверены заранее определённые сегменты.
• Проверены защитные метрики.
• Оценена практическая значимость.
• Рассчитан экономический эффект.
• Описаны ограничения.
• Принято документированное решение.

Чек-лист после теста

• Подготовлена production-версия.
• Проведено регрессионное тестирование.
• Проведён постепенный rollout.
• Контролируется результат после внедрения.
• Удалён временный экспериментальный код.
• Удалён устаревший feature flag.
• Обновлена дизайн-система.
• Обновлена документация.
• Сохранена карточка эксперимента.
• Сформированы новые гипотезы.
• Результат доступен другим командам.

Вывод

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

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

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

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

p-value меньше 0,05 не означает, что вариант B с вероятностью 95% лучше контроля. Для решения необходимо учитывать доверительный интервал, размер эффекта, качество данных, множественные сравнения, защитные показатели и экономическую ценность.

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

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

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