В работе над цифровым продуктом рано или поздно наступает момент, когда мнения в команде разделяются. Дизайнер говорит, что кнопка должна быть зелёной, потому что зелёный успокаивает. Продакт-менеджер настаивает на красной — она привлекает внимание. Разработчик предлагает синюю, потому что она лучше сочетается с корпоративным стилем. И у каждого есть аргументы. Но аргументы — это не данные.
В таких случаях на помощь приходит A/B-тест. Это эксперимент, в котором двум случайным группам пользователей показывают разные версии одного и того же элемента. Одна группа видит контрольный вариант, другая — изменённый. А дальше остаётся только сравнить, какая версия привела к лучшим результатам по заданной метрике.
Но важно запустить тест правильно. Ошибки в дизайне эксперимента, неверный выбор метрики или неправильная интерпретация p-value могут свести на нет все усилия. Или, что хуже, привести к ложному выводу, который повлияет на развитие продукта. В статье разберём, как формулировать гипотезы, выбирать метрики, рассчитывать размер выборки и не поддаваться искушению остановить тест при первом «значимом» результате.
ВАМ ПРИШЛО ПРИГЛАШЕНИЕ 💌
Приходите к нам в соцсети поделиться своим мнением и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
Зачем нужен A/B-тест и когда он не нужен
A/B-тест — это ответ на вопрос «какой вариант лучше?». Он не выявляет причины выбора, не объясняет поведение пользователей и не предсказывает будущее. Тест только сравнивает две версии одного и того же элемента в контролируемых условиях.
Но прежде чем запускать эксперимент, стоит понять: а нужен ли он вообще. Сценарии, где A/B-тест — пустая трата времени, денег и нервов:
- Трафик меньше тысячи целевых событий в неделю. Если у вас на страницу заходит 500 человек в месяц, а целевое действие — покупка, которую совершает один из ста, то статистически значимый результат вы не получите. Никакой. Даже если новый дизайн удвоит конверсию, вы просто не сможете это доказать. Альтернатива — качественные методы: юзабилити-тестирование, опросы, анализ сессий. С ними вы хотя бы увидите паттерны поведения.
- Необратимое решение. Если вы собираетесь переделать архитектуру приложения или сменить платёжного провайдера, A/B-тест не поможет. Вы не можете откатить половину пользователей на старую архитектуру, а половину оставить на новой — это технически невозможно. Или вы меняете систему целиком, или не меняете ничего.
- Изменение, которое невозможно проверить изолированно. Некоторые изменения влияют на всё сразу: новый брендинг, смена ценовой политики, ребрендинг мобильного приложения. В таких случаях сравнивать нечего — есть только новое состояние. Всё, что вы можете сделать, — это сравнить показатели до и после, но это уже не A/B-тест, а анализ временных рядов.
- Очевидное решение. Иногда ответ лежит на поверхности: если кнопка не видна, её нужно сделать видимой; если форма слишком длинная, её нужно сократить. Тратить неделю на тестирование очевидных вещей — значит просто терять время. Внедряйте и двигайтесь дальше.
- Сезонный бизнес. Если ваш продукт привязан к конкретному времени года, а тест нужно провести в межсезонье, результаты ничего не скажут о поведении пользователей в пиковый период. Гораздо полезнее проанализировать данные прошлых лет.
Как сформулировать гипотезу
Гипотеза — это не идея. Идея: «давайте сделаем кнопку красной». Гипотеза — это утверждение, которое можно проверить и которое объясняет, почему изменение должно сработать.
Структура хорошей гипотезы такая:
Если [мы сделаем изменение X], то [метрика Y] изменится на [величину Z], потому что [механизм].
Без последней части — «потому что» — это не гипотеза, а догадка. Механизм — это ваше предположение о том, как пользователь отреагирует на изменение. Если механизм не работает, гипотеза не подтвердится, даже если метрика случайно изменится.
Пример плохой и хорошей гипотезы
Плохая: «Сделаем кнопку крупнее — конверсия вырастет».
Почему плохо. Непонятно, насколько вырастет, непонятно, почему должна вырасти. Если конверсия действительно вырастет на 0,1%, вы засчитаете это как успех? А если упадёт, но незначительно? Формулировка не даёт чёткого критерия принятия решения.
Хорошая: «Если мы увеличим кнопку „Купить“ с 32 до 48 пикселей, то конверсия в целевое действие вырастет как минимум на 5% в течение двух недель, потому что более крупный элемент привлекает больше внимания и снижает когнитивную нагрузку — пользователю не нужно искать кнопку на странице».
Теперь у нас есть конкретное изменение, конкретная метрика, конкретный ожидаемый эффект и механизм. Если конверсия выросла на 5% — гипотеза подтвердилась. Если выросла на 2% — не подтвердилась. Если упала — тем более.
Критерий «как минимум на 5%» — это минимальный детектируемый эффект, о котором мы поговорим в разделе про размер выборки.
Какую метрику выбрать
Метрики делятся на два типа: те, ради которых вы затеваете эксперимент, и те, которые не должны пострадать.
Primary metric — это главный показатель. Он один. Если у вас их два, вы не знаете, что измеряете. В интернет-магазине это может быть конверсия в корзину. В сервисе подписки — количество пользователей, дошедших до оплаты. В рекламной кампании — стоимость лида.
Одна метрика — одно решение. Если тест показывает рост по одной метрике и падение по другой, что вы делаете? Непонятно. Поэтому primary metric должен быть единственным критерием победы.
Guardrail-метрики — это те показатели, которые не должны упасть, пока растёт основная метрика. Например, вы увеличили конверсию в корзину, но средний чек упал на 20%. Или улучшили кликабельность баннера, но отток пользователей вырос. Guardrail-метрики страхуют от побочных эффектов.
Частая ошибка — тестировать сразу по пяти-шести метрикам и объявлять победу, если хотя бы одна «выстрелила». Это прямой путь к ложноположительным результатам. Если вы проверяете 20 метрик, вероятность случайно получить значимый результат хотя бы по одной из них превышает 60%.
Метрика влияет на длительность теста
Выбор метрики напрямую влияет на то, сколько времени займёт тест. Чем реже событие, тем дольше придётся ждать:
- Если вы тестируете кликабельность баннера, событие происходит часто — сотни и тысячи раз в день. Тест может закончиться за пару дней.
- Если вы тестируете количество оформленных заказов, событие происходит реже — может быть, десятки раз в день. Тест займёт недели.
- Если вы тестируете удержание пользователей через месяц после регистрации, событие происходит раз в месяц. Тест займёт минимум два-три месяца.
Логика простая: чем реже событие, тем больше времени нужно, чтобы накопить достаточное количество наблюдений. Никакая статистическая уловка не ускорит сбор данных, если событие происходит раз в неделю.
Размер выборки и длительность теста
Размер выборки — это количество пользователей, которых нужно привлечь в тест, чтобы получить надёжный результат. Эту величину нельзя выбрать произвольно.
От чего зависит размер выборки:
- Базовая конверсия — то, как часто событие происходит сейчас. Если 10% пользователей доходят до оплаты, это один вариант. Если 1% — совсем другой. Чем ниже базовая конверсия, тем больше нужна выборка.
- Минимальный детектируемый эффект (MDE) — наименьшее изменение, которое вы хотите обнаружить. Если вы хотите увидеть рост с 10% до 11% — это MDE в 10% относительных. Если хотите увидеть рост до 15% — это MDE в 50%. Чем меньше эффект, тем больше выборка.
- Уровень значимости (альфа) — вероятность ошибочно объявить эффект там, где его нет. Стандарт — 5% (то есть альфа = 0,05).
- Мощность теста — вероятность обнаружить реальный эффект, если он есть. Стандарт — 80%.
Типичная ошибка — досрочная остановка теста. Выглядит это так: запустили тест, через два дня посмотрели — в группе B конверсия выше на 15%, p-value меньше 0,05. Ура, победа, останавливаем и раскатываем.
Проблема в том, что если проверять результат каждый день в течение месяца, вероятность хотя бы раз увидеть p-value меньше 0,05 вырастает с 5% до 30%. Это называется peeking — подглядывание. Вы не увидели реальный эффект, вы увидели случайность, которая в какой-то момент показалась значимой.
Единственный правильный способ — рассчитать нужный размер выборки до теста, набрать его и только потом анализировать результат. Никаких промежуточных побед.
Полезный блок со скидкой
Формулу расчёта выборки можно найти за минуту. Понять, почему мощность 80%, а не 95%, и что вы теряете, снижая MDE вдвое, — уже сложнее. Без этого калькулятор выборки остаётся чёрным ящиком, которому вы верите на слово.
Разобраться помогают программы «Аналитик данных» и «Математика для анализа данных».
Промокод: KOD (можно просто нажать) даст скидку при покупке любого курса.
Бесплатная вводная часть тоже есть — карту привязывать не нужно.
Статистическая значимость: что она на самом деле показывает
Статистическая значимость не утверждает, что эффект точно есть. Она лишь показывает, что можно с достаточной уверенностью считать наблюдаемую разницу неслучайной.
p-value — это вероятность получить такие же или более экстремальные результаты, если на самом деле никакого эффекта нет. Если p-value = 0,03, это значит: если эффекта нет, то в 3% случаев мы увидим разницу не меньше той, что наблюдаем сейчас.
«Результат значим на уровне 95%» означает, что p-value меньше 0,05. Это не гарантия, что эффект реальный — это просто порог, который мы договорились считать достаточным для принятия решения.
Что не так с традиционным подходом. Классический p-value работает только при фиксированном размере выборки. Если вы решили набрать 10 000 пользователей и не смотрите на данные до конца эксперимента — всё в порядке. Но если вы проверяете данные каждый день — p-value перестаёт работать.
Именно поэтому крупные компании переходят на последовательное тестирование (sequential testing). Вместо того чтобы ждать фиксированную выборку, вы проверяете данные непрерывно, но используете скорректированные пороги значимости. mSPRT (Mixture Sequential Probability Ratio Test) позволяет останавливать тест в любой момент без потери надёжности.
Метод используют компании Uber и Netflix. Вместо того чтобы ждать месяц, вы можете остановиться через неделю, если эффект достаточно сильный. Или продолжить, если данных пока недостаточно. При этом вероятность ложноположительного результата остаётся под контролем.
Ложноположительные результаты и как их избежать
p-hacking — это когда вы подгоняете данные под значимый результат. Ситуации, при которых такое может произойти:
- тест запущен без предрасчёта выборки;
- результаты проверяются каждый день, тест останавливается при первом «значимом» результате;
- тестируются десятков метрик в надежде, что хоть одна «выстрелит»;
- пользователи добавляются в тест после того, как результат оказался незначимым;
- исключены «выбросы» постфактум.
Исследование 2026 года показало: тестировщики, которые занимаются p-hacking, увеличивают долю ложноположительных результатов с 33% до 42%. Это значит, что больше 40% объявленных побед на самом деле могут быть случайностью.
Анализ 2101 коммерческого A/B-теста, проведённый в 2018 году исследователями Уортона и Optimizely, показал: около 57% экспериментаторов останавливают тест, как только уверенность дотягивает до 90%. У них доля ложноположительных результатов (False Discovery Rate) вырастает с 33% до 42% — то есть больше 40% объявленных побед могут оказаться случайностью.
Как избежать. Зафиксируйте всё до теста: гипотезу, primary metric, размер выборки, уровень значимости, правила остановки. Не меняйте правила по ходу игры. Если тест дал неожиданный результат — не додумывайте метрики задним числом.
Инструменты для A/B-тестирования
Инструменты делятся на две большие группы: для маркетинга и лендингов и для инженерных команд с продуктовыми экспериментами.
Для маркетинга и лендингов. Это визуальные редакторы, где можно поменять текст, цвет кнопки или картинку без программиста. Настройка — через интерфейс, код не требуется:
- VWO — один из самых популярных сервисов. Комбинирует A/B-тестирование с тепловыми картами, записями сессий и опросами. Поддерживает и байесовскую, и частотную статистику. Стоимость — от $199 в месяц.
- AB Tasty — позиционируется как инструмент для команд без разработчиков. Визуальный редактор и готовые виджеты. Цены — по запросу.
- Convert — платформа с акцентом на приватность. Частотная статистика, от $199 в месяц.
- Optimizely — для крупных предприятий с выделенными командами оптимизации. Статистический движок — байесовский, позволяет мониторить тесты непрерывно. Цены — от $36 000 в год. Это серьёзный инструмент для серьёзных бюджетов.
Для инженерных команд. Здесь всё строится вокруг фича-флагов, серверных экспериментов и интеграции с кодом. Визуального редактора в таких инструментах либо нет, либо он играет второстепенную роль — основная работа ведётся через SDK, API и конфигурационные файлы:
- Statsig — связывает фича-флаги, A/B-тесты и продуктовые метрики в одной платформе. Использует частотную статистику с CUPED — методом, который сокращает дисперсию и позволяет получить результат на 20–40% быстрее. Есть бесплатный тариф до 1 млн ежемесячных активных пользователей.
- Eppo — для команд, которые уже работают с data warehouse. Цены — по запросу.
- LaunchDarkly — сервис начинался как платформа для фича-флагов, потом добавил эксперименты. Байесовская статистика. От $12 за пользователя в месяц.
- Яндекс.Эксперименты — доступны через интерфейс Директ Про и Рекламную сеть Яндекса. Позволяют тестировать настройки кампаний, креативы, посадочные страницы. Есть калькулятор достоверности для оценки результатов.
Примечание: Google Optimize больше нет. Сервис закрыли 30 сентября 2023 года. Google рекомендует использовать сторонние инструменты для A/B-тестирования, а Google Analytics — только для анализа результатов.
Как выбрать инструмент под задачу
Три критерия:
- Кто настраивает тесты. Если это маркетолог без доступа к коду — нужен визуальный редактор. VWO, AB Tasty, Convert. Если это инженерная команда — подойдут Statsig, Eppo, LaunchDarkly с их SDK и API.
- Бюджет. До $200 в месяц — Statsig (бесплатный тариф), VWO, Convert. От $200 до $1000 — VWO, Convert. От $1000 — AB Tasty, Eppo. От $5000 — Optimizely.
- Нужны ли фича-флаги. Если вы не только тестируете лендинги, но и управляете релизами, раскатываете фичи по группам и можете откатить их в любой момент — вам нужна платформа с фича-флагами. Statsig, LaunchDarkly, Eppo.
Полезный блок со скидкой
Если вы хотите принимать решения на основе данных, есть возможность освоить инструменты на профессиональном уровне. В Яндекс Практикуме этому учат на курсах по продуктовой аналитике, Data Science и управлению продуктом. Разберётесь, как формулировать гипотезы, считать выборку и не верить ложным корреляциям. Держите промокод на любой платный курс: KOD — просто введите его при оплате. Он даст скидку и сделает обучение чуть доступнее. А если пока не готовы платить, у Практикума есть бесплатные вводные курсы по всем направлениям — регистрируйтесь без привязки карты и начинайте в любое время.
Частые ошибки при проведении A/B-тестов
- Остановка теста раньше срока. Самая распространённая ошибка. Вы увидели значимый результат на третий день, остановили тест и раскатили изменение. А через неделю эффект исчез. Потому что это была случайность. Тест должен идти до расчётного размера выборки, не раньше.
- Тестирование без учёта сезонности. Запустили тест в выходные, получили один результат. Запустили в будни — другой. Сезонность, день недели, праздники — всё это влияет на поведение пользователей. Минимальная длительность теста — две полные недели, чтобы захватить все дни недели.
- Смешение метрик. Выбрали primary metric, но в отчёте смотрите на десять других и принимаете решение на основе той, которая показала наилучший результат. Это p-hacking в чистом виде. Решение принимается по одной метрике, которая была выбрана до теста.
- Отсутствие guardrail-показателей. Основная метрика выросла — отлично. Но если при этом упала выручка или вырос отток, победа превращается в поражение. Guardrail-метрики страхуют от таких сценариев.
- Слишком маленькая выборка. Если вы не рассчитали размер выборки заранее, тест, скорее всего, недостоверен. Вы либо не увидите реальный эффект (ошибка второго рода), либо увидите случайность (ошибка первого рода). Без расчёта выборки вы гадаете.
- Тестирование слишком многих вариантов. A/B/C/D/E — каждый дополнительный вариант требует больше пользователей. Если у вас ограниченный трафик, лучше протестировать два варианта, но качественно.
- Игнорирование практической значимости. Статистическая значимость — это не практическая значимость. Рост конверсии на 0,5% может быть статистически значимым на выборке в миллион пользователей, но бизнесу от этого ни холодно ни жарко. Всегда оценивайте, имеет ли эффект значение для продукта.
A/B-тестирование — инструмент, который требует дисциплины. Сформулировать гипотезу, выбрать одну метрику, рассчитать размер выборки, дождаться окончания теста, принять решение. Никаких сокращений, никаких подглядываний, никаких лишних метрик.
Четыре хорошо спроектированных теста в месяц принесут больше пользы, чем двенадцать, в которых никто не уверен. Потому что результаты плохих тестов не внедряют — или внедряют и потом откатывают. А хорошие тесты дают уверенность, что решение принято на основе данных, а не предположений.
Полезный блок со скидкой
Все 7 ошибок из списка выше объединяет одно: решение принимает человек, которому не хочется ждать. И это можно исправить только привычной проверять себя. Дальше у неё три разных продолжения.
Считать и проверять — «Специалист по Data Science». Принимать решения по продукту — «Продакт-менеджер». Строить данные, на которых всё это считается, — «Инженер данных».
Промокод: KOD (можно просто нажать) даст скидку при покупке любого курса в Яндекс Практикум.
Советуем дополнительно почитать
Кто такой Data Scientist и чем он занимается — как устроена работа с данными за пределами A/B-тестов: модели, прогнозы и три опоры профессии — код, математика и бизнес-контекст.
Что такое регрессионный анализ — как оценивают влияние нескольких факторов сразу, когда изолировать одно изменение невозможно.
Теория вероятности в машинном обучении: с формулами и примерами кода — математика, из которой растут и p-value, и байесовский подход, с расчётами на Python.
Честный рассказ аналитика данных о своей профессии — сколько времени уходит на чистку данных, как выглядят задачи изнутри и что раздражает в работе.
Роман Халкечев: обязанности руководителя отдела аналитики — как в большой компании устроен контроль качества экспериментов и кто отвечает за то, чтобы результаты не подгоняли.
