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

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

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

Сформулируйте гипотезу так, чтобы её можно было опровергнуть

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

Рабочая гипотеза звучит конкретнее: например, «если сократить форму оформления заказа с четырёх полей до двух для новых пользователей мобильной версии, доля пользователей, перешедших к оплате, вырастет; решение о внедрении принимаем только если эффект не ухудшает защитные метрики». Здесь уже понятны объект изменения, аудитория и способ проверки. Полезно сразу зафиксировать и минимальный практически значимый эффект: не любой статистически заметный сдвиг стоит релиза, если он слишком мал для продукта.

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

Выберите одну основную метрику и несколько защитных

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

Частая ошибка — назначить сразу три-четыре «главные» метрики и потом выбрать ту, где результат оказался красивее. Чтобы не подменять критерий решения задним числом, основная метрика должна быть одна. Остальные показатели лучше оформить как защитные метрики: они не определяют победу варианта, но помогают не пропустить побочный вред. Например, рост конверсии в первый шаг может сопровождаться падением оплаты, всплеском ошибок формы или снижением среднего чека.

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

Определите единицу рандомизации и заранее зафиксируйте план запуска

Единица рандомизации — это объект, который попадает в вариант A или B: пользователь, сессия, аккаунт, заказ, магазин, регион. Выбор здесь не техническая мелочь, а часть логики эксперимента. Если один и тот же человек может в разных сессиях увидеть то A, то B, вы получите «перемешанный» опыт и затрудните интерпретацию результата. Для тестов интерфейса чаще подходит рандомизация по пользователю или аккаунту, чтобы человек видел один и тот же вариант на всём пути.

Перед запуском полезно письменно зафиксировать: кого включаете в тест, кого исключаете, в каком соотношении делите трафик, какие события логируете и как будете обрабатывать дубли, отмены и технические сбои. Это выглядит бюрократично, но именно здесь часто прячутся будущие споры. Если команда не договорилась заранее, после запуска начинаются уточнения вроде «давайте ещё уберём пользователей с планшетов» или «эту неделю не считаем». Такие решения могут незаметно изменить результат сильнее, чем сам тестируемый вариант.

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

Длительность и правило остановки задают до старта, а не по настроению

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

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

Учебный пример

Учебный пример. Интернет-магазин книг тестирует сокращённую форму заказа в мобильной версии. Текущая доля пользователей, которые после корзины переходят к оплате, равна 12 из 100. Команда решает, что внедрять изменение имеет смысл только при эффекте не меньше +1,2 процентного пункта, то есть росте до 13,2 из 100. Единица рандомизации — пользователь, основная метрика — переход к оплате, защитные метрики — успешная оплата и ошибки формы.

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

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

После запуска основные ошибки начинаются не в коде, а в интерпретации. Первая ошибка — смотреть только на относительный рост. Фраза «конверсия выросла на 10%» звучит сильнее, чем «с 12% до 13,2%», но для продукта важно понимать и относительное, и абсолютное изменение. Вторая ошибка — игнорировать защитные метрики: вариант может лучше заводить пользователей в воронку, но хуже доводить до оплаты.

Третья ошибка — менять вопрос по ходу теста. Если вы запускали проверку для новых пользователей мобильной версии, не стоит после результата для всей аудитории внезапно объявлять победу в узком сегменте, который заранее не был основным. Сегментный анализ полезен как диагностика, но если решение строится только на постфактум найденном сегменте, возрастает риск случайной находки.

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

Если хотите отработать эту схему на учебных задачах, посмотрите программу «Основы статистики и A/B-тестирования». На официальной странице курса указаны темы про статистические гипотезы, A/B-тесты, требуемый объём групп, MDE и мощность, а в программе есть симулятор подготовки теста. Для выбора обучения полезно проверить три вещи: есть ли в программе расчёт плана эксперимента, будет ли самостоятельная практика с собственным решением и как именно вы проверите, что интерпретируете результат корректно.