Почему большинство A/B-тестов вас обманывают

4 статистических ошибки, которые обходятся вашей команде в реальные деньги (и 15-минутное решение для каждой)

Делиться

Три часа дня, четверг. Менеджер по продукту в SaaS-компании, находящейся на этапе привлечения инвестиций серии B, в четвертый раз за день открывает панель A/B-тестирования, рядом с ноутбуком стоит наполовину выпитый холодный кофе. На экране отображается: Вариант B, увеличение конверсии на +8,3%, статистическая значимость 96%.

Она делает скриншот результата. Публикует его в канале Slack #product-wins с эмодзи вечеринки. Руководитель отдела разработки отвечает лайком и начинает планировать спринт внедрения.

Вот чего ей не показала панель мониторинга: если бы она подождала еще три дня (первоначально запланированная продолжительность теста), значимость снизилась бы до 74%. Прирост в +8,3% сократился бы до +1,2%. Ниже уровня шума. Нереально.

Если вы когда-либо прерывали тестирование на ранней стадии, потому что оно «достигло статистической значимости», вы, вероятно, допускали подобную ошибку при выпуске продукта. Вы не одиноки. В Google и Bing, согласно исследованию Ронни Кохави, опубликованному в Harvard Business Review, только 10-20% контролируемых экспериментов дают положительные результаты. В Microsoft в целом треть экспериментов оказываются эффективными, треть — нейтральными, а треть — активно вредят показателям, которые они должны были улучшить. Большинство идей не работают. Эксперименты, которые «доказывают» свою эффективность, часто говорят вам то, что вы хотите услышать.

Четыре статистических ошибки, перечисленные ниже, составляют большинство ненадежных результатов A/B-тестирования. Исправление каждой из них занимает менее 15 минут. К концу этой статьи у вас будет контрольный список из пяти пунктов для подготовки к тестированию и схема принятия решений для выбора между частотным, байесовским и последовательным тестированием, которые вы сможете применить к своему следующему эксперименту в понедельник утром.

Проблема подглядывания: 26% ваших победителей — не настоящие.

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

Частотные тесты значимости предназначены для однократного анализа на заранее определенной выборке. Когда вы проверяете результаты после 100 посетителей, затем 200, затем 500, затем 1000, вы проводите не один тест, а четыре. Каждый последующий анализ дает шуму еще один шанс замаскироваться под сигнал.

Эван Миллер количественно оценил это в своем широко цитируемом анализе «Как не следует проводить A/B-тестирование». Если проверять результаты после каждой партии новых данных и останавливаться в тот момент, когда вы видите p < 0,05, то фактическая частота ложноположительных результатов составляет не 5%.

Это 26,1%.

Каждый четвертый «победитель» — это чистый шум.

Механизм прост. Проверка значимости контролирует частоту ложноположительных результатов на уровне 5% для одной точки анализа. Многократные проверки создают множество возможностей для случайных колебаний, которые могут пересечь порог значимости. Как говорит Миллер: «Если вы десять раз заглянете в текущий эксперимент, то то, что вы считаете 1% значимости, на самом деле окажется всего лишь 5%».

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

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

Вакуум мощности: малые выборки, завышенные эффекты

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

Статистическая мощность — это вероятность того, что ваш тест обнаружит реальный эффект, если он существует. Стандартная целевая мощность составляет 80%, что означает 20%-ную вероятность того, что вы пропустите реальный эффект, даже если он есть. Для достижения 80% мощности необходим определенный размер выборки, и это число зависит от трех факторов: вашего базового коэффициента конверсии, наименьшего эффекта, который вы хотите обнаружить, и вашего порога значимости.

Большинство команд пропускают расчет мощности. Они проводят тест «до тех пор, пока он не станет значимым» или «в течение двух недель», в зависимости от того, что наступит раньше. Это порождает явление, называемое проклятием победителя.

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

Команда могла бы отпраздновать рост конверсии на +8%, внедрить изменения, а затем наблюдать, как фактическое значение стабилизируется на уровне +2% в следующем квартале. Тест не был совсем ошибочным (эффект действительно был), но команда основывала свои прогнозы выручки на завышенных данных. Это следствие недостаточного размера выборки.

Решение: перед каждым тестом проводите анализ мощности. Установите минимальный обнаруживаемый эффект (MDE) на уровне наименьшего изменения, которое оправдало бы инженерные и производственные затраты на выпуск продукта. Рассчитайте необходимый размер выборки при мощности 80%. Затем проводите тест до достижения этого значения. Никаких преждевременных выходов.

Ловушка множественных сравнений

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

Вот в чем проблема. При уровне значимости 5% для каждого показателя вероятность хотя бы одного ложноположительного результата среди всех пяти составляет не 5%, а 22,6%.

Математический расчет: 1 − (1 − 0,05)⁵ = 0,226.

Если увеличить это значение до 20 показателей (что часто встречается в аналитических командах), вероятность составит 64,2%. Вероятность обнаружения шума, который выглядит реальным, выше, чем вероятность его полного избегания.

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

Существуют две коррекции, и основные платформы уже их поддерживают. Коррекция Бенджамини-Хохберга контролирует ожидаемую долю ложных срабатываний среди значимых результатов (менее консервативная, сохраняет большую мощность). Коррекция Холма-Бонферрони контролирует вероятность даже одного ложноположительного результата (более консервативная, подходит, когда одна неверная оценка имеет серьезные последствия). Optimizely использует многоуровневую версию коррекции Бенджамини-Хохберга. GrowthBook предлагает обе.

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

Когда «значительное» не означает значительное

Четвертый грех — самый незаметный и, возможно, самый дорогостоящий. Тест может быть одновременно статистически значимым и практически бесполезным.

Статистическая значимость отвечает ровно на один вопрос: «Вероятно ли, этот результат случайный?» Она ничего не говорит о том, достаточно ли велика разница, чтобы иметь значение. Тест с 2 миллионами посетителей может с высокой степенью уверенности обнаружить увеличение конверсии на 0,02 процентных пункта. Это увеличение реально. Кроме того, на внедрение такого результата не стоит тратить ни одного спринта разработки.

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

Перед началом любого тестирования установите пороговое значение практической значимости: минимальный размер эффекта, оправдывающий внедрение. Он должен отражать инженерные затраты на внедрение изменений, упущенную выгоду от времени выполнения теста и влияние на конечный доход. Если увеличение на 0,5 процентных пункта приводит к годовому доходу в 200 000 долларов, а внедрение изменений занимает один спринт, это и есть ваш порог. Все, что ниже него, считается «верным, но бесполезным» результатом.

Решение: рассчитайте свой MDE до начала тестирования, не только для анализа мощности (хотя это то же самое число), но и в качестве критерия принятия решения. Даже если тест достигнет статистической значимости, если измеренный эффект окажется ниже MDE, выпуск продукта невозможен. Запишите это число. Получите согласие заинтересованных сторон до запуска.

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

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

Это самое распространённое заблуждение в современных экспериментах.

Байесовское A/B-тестирование решает одну реальную проблему: коммуникацию. Сказать вице-президенту: «Существует 94%-ная вероятность того, что вариант B лучше», — понятнее, чем «Мы отвергаем нулевую гипотезу при α = 0,05». Первое утверждение интуитивно понятно заинтересованным сторонам бизнеса. Для понимания второго требуется лекция по статистике.

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

В октябре 2025 года Алекс Молас опубликовал подробное имитационное исследование, показавшее, что байесовские A/B-тесты с фиксированными апостериорными порогами страдают от той же проблемы увеличения числа ложноположительных результатов, когда вы проверяете результаты и останавливаетесь на успехе. Использование 95% «вероятности превзойти контрольную группу» в качестве правила остановки, проверяемого после каждых 100 наблюдений, привело к частоте ложноположительных результатов в 80%. Не 5%. Не 26%. Восемьдесят процентов.

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

Всё это не означает, что байесовские методы бесполезны. Для решений, не имеющих большого значения (выбор заголовка для блога, темы электронного письма), где контроль ошибок первого типа не критичен, интуитивно понятная вероятностная модель действительно лучше. Для важных решений, касающихся продукта, где необходимы надёжные гарантии ошибок, «просто перейдите на байесовский подход» — не решение. Это всего лишь переделка той же самой задачи.

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

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

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

Контрольный список из 5 пунктов для предварительного тестирования

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

1. Расчет размера выборки. Установите значение MDE (наименьший эффект, оправданный для использования в исследованиях). Рассчитайте необходимый размер выборки при мощности 80% и уровне значимости 5%, используя бесплатный калькулятор Эвана Миллера или встроенный инструмент вашей платформы. Пример: базовая конверсия 3,2%, MDE 0,5 процентных пункта → ~25 000 на вариант.
2. Время выполнения фиксировано и задокументировано. Разделите необходимый размер выборки на ежедневный допустимый трафик. Округлите в большую сторону. Добавьте буфер для учета колебаний в будние/выходные дни (минимум 7 полных дней, даже если размер выборки будет достигнут раньше). Запишите конечную дату. Пример: 8300 допустимых посетителей в день, всего необходимо 50000 → минимум 6 дней, округлено до 14 дней для учета недельных циклов.
3. Объявлен один основной показатель. Запишите его до начала тестирования. Второстепенные показатели носят исключительно исследовательский характер. Если необходимо формально оценить несколько показателей, примените поправки Бенджамини-Хохберга или Холма-Бонферрони. Пример: «Основной: коэффициент конверсии при оформлении заказа. Второстепенный (исследовательский): средняя стоимость заказа, процент отказов от покупки».
4. Установлен порог практической значимости. Определите минимальный эффект, оправдывающий внедрение. Согласуйте это с инженерами и заинтересованными сторонами в области продукта до запуска. Если тест достигает статистической значимости, но оказывается ниже этого порога, выпуск продукта не производится. Пример: «Минимальное увеличение конверсии на +0,5 процентных пункта (прибыль около 200 000 долларов в год, оправдывает двухнедельный спринт)».
5. Выбран метод анализа. Выберите один из них: частотный, байесовский или последовательный. Обоснуйте свой выбор. Используйте приведенную ниже матрицу решений. Пример: «Последовательное тестирование. Два запланированных анализа на 7-й и 14-й день. Распределение альфа-доходности с помощью границ О'Брайена-Флеминга».

Пример решения задачи: Тестирование процесса оформления заказа

Команда, работающая в сфере электронной коммерции среднего размера (500 000 посетителей в месяц), хочет протестировать новую одностраничную форму оформления заказа, сравнив её с текущей многоэтапной процедурой. Вот как они проводят тестирование по контрольному списку:

1. Показатель MDE: 0,5 процентных пункта (с базового уровня 3,2% до 3,7%). При 500 000 посетителей в месяц и средней стоимости заказа в 65 долларов, увеличение на 0,5 процентных пункта приносит примерно 195 000 долларов дополнительного годового дохода. Разработка новой формы заказа обходится примерно в 2 недели (примерно 15 000 долларов на загрузку). Рентабельность инвестиций превосходит все ожидания.

2. Размер выборки: При мощности 80% и уровне значимости 5% требуется примерно 25 000 образцов на каждый вариант. Всего 50 000.

3. Время работы: 250 000 посетителей в месяц доходят до оформления заказа. Это примерно 8300 в день. 50 000 всего ÷ 8300 в день = 6 дней. Округлено до 14 дней, чтобы учесть влияние будних и выходных дней.

4. Основной показатель: коэффициент конверсии при оформлении заказа. Средняя стоимость заказа и процент отказов от покупки отслеживаются в исследовательских целях (коррекция не требуется, поскольку они не влияют на решение о доставке/отказе от доставки).

5. Метод: Последовательное тестирование. Высокий трафик, заинтересованные стороны хотят получать еженедельные отчеты о ходе работы. Два заранее запланированных анализа: на 7-й и 14-й день. Распределение альфа-доходности с помощью границ О'Брайена-Флеминга.

Результат: На 7-й день наблюдаемый прирост составляет +0,3 процентных пункта. Последовательная граница не пересечена. Продолжаем. На 14-й день прирост составляет +0,6 процентных пункта. Граница пересечена. Запускаем.

Без соблюдения протокола: руководитель проекта проверяет ежедневно, на третий день видит рост на +1,1 процентных пункта с 93% «значимостью» и объявляет результат успешным. Она запускает продукт, основываясь на цифре, которая почти вдвое превышает истину. Прогнозы выручки завышены на 83%. Фактический рост составляет +0,6 пункта в следующем квартале. Руководство теряет доверие к программе экспериментов.

Что на самом деле дают тщательные испытания?

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

В результате выручка от каждого поиска выросла на 12%, что составляет более 100 миллионов долларов в год только в США. Это стало самым ценным изменением, когда-либо внедренным Bing.

Эта история, описанная Ронни Кохави в Harvard Business Review, содержит два урока. Во-первых, интуиция в отношении того, что действительно важно, в большинстве случаев ошибочна. В Google и Bing от 80% до 90% экспериментов не показывают положительного эффекта. Как выразился Кохави: «Любая цифра, которая выглядит интересной или необычной, обычно неверна». Тщательное тестирование необходимо именно потому, что ваши инстинкты недостаточно хороши.

Во-вторых, тщательное тестирование приносит свои плоды. Программа экспериментов Bing выявляла десятки изменений, повышающих доход, ежемесячно, что в совокупности увеличивало доход от каждого поиска на 10–25% ежегодно. Это накопление стало одним из главных факторов роста доли Bing на рынке поисковых систем США с 8% в 2009 году до 23%.

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

Тот менеджер по продукту, с которой мы общались в 3 часа дня в четверг? Она собирается провести еще одно тестирование на следующей неделе. И вы тоже.

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

Но теперь вы знаете, чего не показывает панель управления. 26,1%. Проклятие победителя. 64% ложных срабатываний. Байесовский мираж.

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

Какой из них выберете?

Ссылки

1. Эван Миллер, «Как НЕ следует проводить A/B-тестирование»
2. Алекс Молас, «Байесовский A/B-тестирование не застрахован от подглядывания» (октябрь 2025 г.)
3. Дэвид Робинсон, «Устойчиво ли байесовское A/B-тестирование к подглядыванию? Не совсем», Variance Explained.
4. Рон Кохави, Стефан Томке, «Удивительная сила онлайн-экспериментов», Harvard Business Review (сентябрь 2017 г.)
5. Optimizely, «Контроль частоты ложных срабатываний», документация по поддержке.
6. GrowthBook, «Множественные исправления в процессе тестирования», Документация
7. Analytics-Toolkit, «Недостаточно эффективные A/B-тесты: путаница, мифы и реальность» (2020)
8. Statsig, «Размер эффекта: практическая и статистическая значимость»
9. Statsig, «Последовательное тестирование: как взглянуть на результаты A/B-тестирования, не испортив достоверность».

Каушик Раджан Посмотреть все материалы от Каушика Раджана

Источник: towardsdatascience.com