Шесть причин, почему ваши A/B-тесты не работают / forpes.ru

Главная
Шесть причин, почему ваши A/B-тесты не работают

Шесть причин, почему ваши A/B-тесты не работают +16

24.01.2023 12:16

Eth_Moses 1 3000 Источник

Всем привет!

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

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

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

Код к статье можете посмотреть тут.

Причина №1. Децентрализованный процесс принятия решений с помощью A/B-тестирования

Если в вашей компании нет контроля над процессом A/B-тестирования, то у вас нет A/B-тестирования.

Исповедь продакт-менеджера

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

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

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

Чтобы среднестатистически принимать верные с точки зрения бизнеса решения, необходимо постоянно контролировать уровни ошибок I и II рода на установленных заранее значениях:

Ошибка I рода — на самом деле эффекта нет, но мы считаем, что он есть.
Ошибка II рода — на самом деле эффект есть, но мы считаем, что его нет.

Как раз контроль этих ошибок и делает A/B-тестирование незаменимым инструментом в проверке гипотез.

Можно это выразить так: мы делаем ошибки, но мы знаем их вероятность, и нас она устраивает.

Обеспечить контроль ошибок I и II рода довольно просто — не нужно делать ошибок в методологии.

Вопрос в том, а как это обеспечить? Можно, конечно, пустить процесс принятия решений в свободное плавание, позволив каждой из команд самостоятельно проводить A/B-тесты по своему усмотрению, однако есть ряд причин, почему это может привести к росту количества ошибок:

Разный уровень знаний об A/B-тестировании среди аналитиков. Самая распространённая причина — не у всех есть достаточные знания о том, как проводить и правильно оценивать эксперименты.
Эксперименты разных команд могут пересекаться и влиять на результаты друг друга. Обычно, когда мы проводим множество экспериментов, один пользователь может участвовать сразу в нескольких A/B-тестах. Если тестируемые фичи сильно влияют друг на друга, то, скорее всего, мы получим искажённый результат и не сможем изолировать эффект для каждой из фич.
Каннибализация метрик. Внедряемые изменения одной команды могут сильно повлиять на метрики другой команды. Если не вести контроль за метриками, то можно часто принять положительный эффект в целевых метриках за успех, за которым скрывается деградация метрик смежных команд.
Недобросовестное искажение результатов в интересах команды.

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

Для этого нужно:

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

Плюсы:

обеспечение необходимого контроля за ошибками I и II рода;
значительное облегчение и ускорение проведения аналитики по экспериментам;
снижение трудозатрат;
облегчение взаимодействия между командами;
максимально прозрачная реализация процесса A/B-тестирования.

Причина № 2. Отсутствие дизайна A/B-тестов

Рассчитывать дизайн эксперимента — удел неуверенных в себе аналитиков (сарказм).

Команда A/B-тестирования Ozon

Дизайн A/B-теста — это один из важных этапов проведения эксперимента.

Дизайн — это, по сути, некоторое прогнозирование потенциальной эффективности эксперимента.

Мы определяем, насколько чувствительны наши метрики к изменениям. Хватит ли нам данных для обеспечения адекватной чувствительности. Сможем ли мы провести эксперимент за разумный период времени.

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

Как правильно задизайнить тест?

С дизайном связаны два понятия: MDE — минимальный детектируемый эффект, и Sample size — размер выборки, необходимый для статистически значимого обнаружения заданного эффекта.

Стандартные формулы расчета MDE и Sample size вы можете найти в интернете почти в каждой статье на эту тему, однако существенный недостаток классической формулы состоит в том, что она не учитывает случаи, когда у нас несколько групп в эксперименте, и они разного размера. Ведь не всегда есть возможность проводить тесты в пропорции 50/50.

Рассмотрим расширенные версии этих формул, которые вывела наша команда:

$MDE > \frac{\sqrt{ratio{\;}correction}\times\left[ \Phi^{-1} \left( 1-\frac{\alpha}{2} \right) + \Phi^{-1} \left( 1-\beta \right) \right]\times{STD}}{\sqrt{sample{\;}size\times(1-pilot{\;}group{\;}share\times(comparisons-1))}}$ $Sample{\;}size > \frac{ratio{\;}correction\times\left[ \Phi^{-1} \left( 1-\frac{\alpha}{2} \right) + \Phi^{-1} \left( 1-\beta \right) \right]^2\times{STD}^2}{effect^2\times(1-pilot{\;}group{\;}share\times(comparisons-1))}$

где

$ratio{\;}correction = r +2+\frac{1}{r}$ $comparisons = n_{groups} - 1$

Расшифруем параметры:

α и β — параметры, отвечающие за уровни ошибок I и II рода. Чем меньше эти параметры, тем больше MDE и Sample size;
Ф^-1 — квантильная функция;
STD — стандартное отклонение метрики. Чем меньше дисперсия, тем меньше MDE и Sample size;

ngroups — количество групп в тесте. Чем больше групп, тем больше MDE и Sample size;
r — соотношение самой маленькой группы к самой большой группе в эксперименте. Чем меньше это значение, тем больше MDE и Sampe size;
effect — эффект в абсолютных значениях, который мы хотим обнаружить. Чем меньше эффект, тем больше Sampe size;
Pilot group share — доля пилотной (таргетной) группы от Sample size.

Последний пункт явно указывает, что данные формулы являются валидными для случаев, когда все пилотные группы равны (установка разного размера пилотных групп сомнительна, так как в таком случае мы увеличиваем мощность одного тестируемого варианта за счет другого). Sample size в данных формулах подразумевает общее количество наблюдений в тесте с учетом всех групп. Также в эту формулу можно добавить коррекцию α с помощью метода Бонферрони, если вы используете классические поправки на множественное тестирование.

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

Пример таблицы с MDE в % за разные периоды времени

Метрика/ Период	7 дней	14 дней	21 день	28 дней
Метрика 1	2	1,8	1,3	0,5
Метрика 2	3	2,7	1,7	0,9
Метрика 3	4	3	1,9	1,2

Причина № 3. Использование U-критерия для проверки гипотезы о разности средних и медиан

Хочешь поссориться с аналитиком? Поговори с ним про политику, про религию или про критерий Манна-Уитни.

Команда A/B-тестирования Ozon

С критерием Манна-Уитни, наверное, связано самое распространённое заблуждение в A/B-тестировании.

По какой-то причине множество аналитиков, среди которых есть достаточно опытные специалисты, считают, что с помощью критерия Манна-Уитни можно проверять гипотезу о равенстве средних, заменив тем самым t-критерий Стьюдента, исходя из того, что U-критерий якобы проверяет равенство медиан. Более того, есть довольно распространенное мнение, что U-критерий намного чувствительнее t-критерия Стьюдента, так как на данных с сильно скошенным распределением критерий Манна-Уитни имеет большую мощность.

Еще существует мнение, что U-критерий менее чувствителен к выбросам.

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

Так что же проверяет критерий Манна-Уитни? Нулевая гипотеза критерия Манна-Уитни — распределения двух выборок равны, альтернативная гипотеза — распределения двух выборок равны с точностью до определенного сдвига:

$H_{0}: = F_{x}(t)=F_{y}(t)$ $H_{1}: = F_{x}(t)=F_{y}(t+\Delta), \Delta\neq0$

Как видим, U-критерий проверяет равенство распределений, а не медиан, средних или ещё чего-либо. Однако давайте проверим это эмпирически: проведём симуляцию из 10000 A/A-тестов, сэмплируя две выборки в 1000 наблюдений из нормального распределения со следующими параметрами ????(0,10) и ????(0,100),соответственно, и проверяя гипотезы с помощью t-критерия Стьюдента и U-критерия Манна-Уитни. Ожидаемый результат — равномерное распределение p-value от 0 до 1 ????(0,1). Так как медиана в нормальном распределении совпадает со средним, то мы должны получить одинаковые результаты для обоих критериев.

Гистограммы распределения p-value двух критериев значительно отличаются. У t-критерия распределение равномерное, у критерия Манна-Уитни оно скошено влево к 0, где H0 отвергается. Ошибка I рода для U-критерия больше 5 %.

Следовательно, наше предположение, что тест Манна-Уитни проверяет равенство медиан, не подтверждается на практике. Про проверку равенства средних вывод очевиден.

Проверим еще один миф, но теперь про t-критерий Стьюдента. Требует ли данный критерий нормального распределения данных? Теряет ли он мощность при скошенных данных?

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

В качестве примера скошенного распределения возьмём логнормальное распределение со средним 1.82 и стандартным отклонением 2.37 ????????????????????????????????????(1.82,2.37).

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

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

Результат аналогичен предыдущему. Среднее распределено нормально.

Далее проведём A/A/B-тесты и замерим уровни ошибок I и II рода. Для этого предварительно рассчитаем MDE для параметров нашего распределения. Воспользуемся формулой из главы № 2. Получаем MDE = 16.246 %.

Для сравнения уровней ошибок сначала проведем симуляции на данных с нормальным распределением и аналогичными параметрами: ????(1.82, 2.36).

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

Результаты A/A/B-симуляций для нормального распределения ????(1.82, 2.36)

Этап	t-критерий Стьюдента		U-критерий Манна-Уитни
Этап	Ошибка I рода	Ошибка II рода	Ошибка I рода	Ошибка II рода
1	0.051	0.200	0.051	0.217
2	0.051	0.199	0.049	0.218
3	0.047	0.193	0.050	0.209

Результаты A/A/B-симуляций для логнормального распределения ????????????????????????????????????(1.82, 2.36)

Этап	t-критерий Стьюдента		U-критерий Манна-Уитни
Этап	Ошибка I рода	Ошибка II рода	Ошибка I рода	Ошибка II рода
1	0.051	0.208	0.051	0
2	0.049	0.206	0.051	0
3	0.048	0.201	0.051	0

Таким образом, можно сделать вывод, что U-критерий Манна-Уитни действительно имеет более высокую мощность на скошенных данных, однако t-критерий сохранил заданную в дизайне мощность. Следовательно, резюмируем, что t-критерий не имеет требований к распределению данных и не теряет мощность на скошенных выборках.

Какой же итоговый вывод можно сделать по поводу U-критерия? Его можно использовать по назначению, то есть для проверки гипотезы о равенстве распределений. Для проверки гипотезы о равенстве средних или медиан его использовать нельзя, так как это приведет к увеличению ошибки I рода, вместо него используйте t-критерий Стьюдента или бутстрап

Причина № 4. Неправильный подход к анализу ratio-метрик

Да кто такой этот ваш дельта-метод?!

Начинающий A/B-тестер

Что такое ratio-метрика или метрика-отношение? Давайте рассмотрим таблицу с историей заказов некоторых пользователей, где есть данные по сумме заказа (GMV) и по количеству товаров в заказе (Qty).

User ID	GMV, руб.	Qty, шт.
34252353545	1356	1
34252353545	2400	2
43354435465	400	4
55656574677	3000	2

Посчитаем средний GMV на пользователя:

$ARPU =\frac{(1356+2400+400+3000)}{3}=2385,3{\;}руб.$

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

Теперь посчитаем метрику средний чек или AOV:

$AOV =\frac{(1356+2400+400+3000)}{2+1+1}=1789{\;}руб.$

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

Пользовательская метрика:

$M_{A} =\frac{1}{|A|}\sum_{u\in{A}}^{X}(u)$

Ratio-метрика:

$\mathfrak{R}_{A} =\frac{\sum_{u\in{A}}^{X}(u)}{\sum_{u\in{A}}^{Y}(u)}$

Так в чём проблема? Разве мы не можем применить в A/B-тесте к такой метрике t-критерий?

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

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

взять за единицу наблюдения каждый отдельный заказ и засунуть такую выборку в t-тест — наивный подход;
перейти к пользовательской метрике, посчитав для каждого пользователя ratio-метрику (user average);
использовать бутстрап.

Давайте опробуем каждый из этих способов на A/A-тестах и посмотрим на распределение p-value.

По полученным гистограммам можно сделать вывод, что наивный способ, когда мы считаем за единицу наблюдения отдельный заказ, даёт высокий уровень ошибки I рода (почти 20 %), при этом остальные два способа удерживают ошибку на заданном уровне.

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

Продолжим искать способы для оценки ratio-метрик. Мы определили два метода, которые способны контролировать ошибку I рода на заданном уровне, однако следует добавить в нашу коллекцию еще два метода, с помощью которых можно оценивать A/B-тесты для ratio-метрик:

Дельта-метод. Метод, позволяющий вычислить дисперсию ratio-метрики через информацию Фишера следующим образом:

$Var\left(\frac{X}{Y}\right) =\frac{Var(X)}{\mu_{Y}^2}+\frac{\mu_{X}^2}{\mu_{Y}^4}Var(Y) - \frac{2\mu_{X}}{\mu_{Y}^3}COV(X,Y)$

Линеаризация. Переход к пользовательской метрике через другое признаковое пространство, по сути являющийся перевешиванием пользователей по вкладу в ratio-метрику. Осуществляется по формуле:

$L(u)=X(u)-k\times{Y(u)}$

где k — это значение ratio-метрики в контрольной группе теста.

Дельта-метод незаменим для дизайна A/B-тестов с ratio-метриками и для построения доверительных интервалов разности ratio-метрик, так как он, в отличие от всех остальных способов, позволяет рассчитать дисперсию метрики-отношения. Линеаризация, в свою очередь, незаменима при оценке A/B-тестов, так как её легко реализовать и она создаёт пользовательскую метрику, к которой можно применить все методы снижения дисперсии (CUPED, CUPAC, стратификация и пост-стратификация).

Начнём игру на выбывание среди наших методов. Проведём A/A-симуляцию, но теперь проверим направленность разности средних и p-value у трех способов: бутстрапа, усреднения по пользователям (user average) и линеаризации. Если методы проверяют одну и ту же гипотезу, то их дельты и p-value должны быть практически идеально сонаправлены, образуя диагональную линию.

Графики показывают, что подход с усреднением не сонаправлен по разности средних и p-value с бутстрапом и линеаризацией. Бутстрап и линеаризация, в свою очередь, имеют идеальную сонаправленность между собой. Следовательно, усреднение проверяет равенство совершенно другой метрики. Используя данный метод, вы можете попасть в ситуацию, когда усреднённая по пользователям метрика имеет положительный стат. значимый эффект, а реальная ratio-метрика, наоборот, имеет отрицательный эффект. Таким образом, применение усреднения по пользователям ведёт к росту ошибок I и II рода.

Проиллюстрируем данный кейс на примере: есть группа A и группа B с метриками GMV и orders:

Группа A				Группа B
User ID	GMV, руб.	Orders, шт.	AOV, user average	User ID	GMV, руб.	Orders, шт.	AOV, user average
34252353545	1356	1	1356	4543643636	2000	5	400
43354435465	400	4	100	4653657577	3456	7	493,7
55656574677	3000	2	1500	3414356565	7645	5	1529

Посчитаем разность группы B и группы A по метрике AOV через усреднение по пользователям и стандартным способом:

$\Delta{AOV}_{user{\;}average}^{B-A} =\left(\frac{400+493,7+1529}{3}\right)-\left(\frac{1356+100+1500}{3}\right)=-177,8{\;}руб.$ $\Delta{AOV}_{classic}^{B-A} =\left(\frac{2000+3456+7645}{5+7+5}\right)-\left(\frac{1356+400+3000}{1+4+2}\right)=91,2{\;}руб.$

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

Однако это не единственная проблема, хотя её одной уже должно хватить, чтобы больше не использовать усреднение для анализа ratio-метрик. Так как мы усредняем клиентов с разным вкладом в ratio-метрику, мы одновременно размазываем и потенциальный эффект, который, скорее всего, распределён неравномерно. Клиенты с большим весом дают больший импакт от изменений. Такой эффект называют гетерогенным. Попробуйте теперь самостоятельно провести A/A/B-симуляции с гетерогенным эффектом и замерить ошибки I и II рода для метода с усреднением пользователей и для линеаризации. Для расчета MDE воспользуйтесь дельта-методом.

Причина № 5. Ранняя остановка тестов без использования последовательного тестирования или критериев регламента

Ну что там, есть эффект?

Любой любопытствующий коллега

Проведение A/B-тестов — это дорогостоящее занятие.

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

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

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

Видим, что ошибка I рода при таком подходе выросла в 10 раз. Причина проблемы подглядывания заключается в том, что по факту мы проверяем не одну гипотезу, а несколько поочередно. Вероятность ошибки I рода в таком случае резко возрастает. Мы рассмотрим проблему множественного тестирования подробнее в следующей части.

Что же делать, как решить проблему подглядывания? Есть несколько вариантов:

Останавливать A/B-тест заранее можно при наличии сильного отрицательного эффекта, причём на нескольких метриках сразу. Например: после старта эксперимента у вас упали метрики высшей иерархии (ключевые метрики компании) на 10 %, скорее всего, это не случайность, следует немедленно остановить эксперимент. Данное правило лучше прописать в регламенте A/B-тестирования и внедрить алерты на подобные события в A/B-платформу;
Воспользоваться методами последовательного тестирования, которые позволяют контролировать ошибку I рода.

На данный момент существует множество методов последовательного тестирования: от самых примитивных, связанных с корректировкой уровня значимости в зависимости от количества подглядываний, до наиболее продвинутых методов, таких как критерий Вальда или sequential probability ratio test (SPRT) и его современный подвид mixture sequential probability ratio test (mSPRT).

SPRT основан на вычислении отношений правдоподобий для нулевой (????0) и альтернативной (????1) гипотез:

$\Lambda_{n} =\frac{L(X_{1},...,X_{n};\theta_{1})}{L(X_{1},...,X_{n};\theta_{0})} = \frac{\prod_{i=1}^nf(X_{i};\theta_{1})}{\prod_{i=1}^nf(X_{i};\theta_{0})}$

Ключевой недостаток данного метода — нужно заранее знать, чему равно ????1, что в реальных условиях не представляется возможным (????0 при проверке гипотезы о равенстве средних мы приравниваем к нулю).

Метод mSPRT, в свою очередь, не требует конкретного значения ????1, а использует его некоторое приближение, априорное распределение данного параметра:

$\Lambda_{n}^{H,\theta_{0}} =\int_{\Theta}\prod_{m=1}^{n}\frac{f_{\theta}(X_{m})}{f_{\theta_{0}}(X_{m})}h(\theta)d\theta$

Авторы замечательной статьи Peeking at A/B Tests предложили следующую реализацию mSPRT:

$\Lambda_{n}^{H,\theta_{0}} =\sqrt{\frac{Var_{n}}{Var_{n}+n\tau^2}}exp\left\{\frac{n^2\tau^2(\mu^B_{n} - \mu^A_{n} - \theta_{0})^2}{2Var_{n}(Var_{n}+n\tau^2)}\right\}$

где ????0=0,Var — сумма дисперсий группы A и B, ???? — значение метрики, а параметр ????, который как раз и отвечает за альтернативную гипотезу вычисляется следующим образом:

${\tau = \sigma^2 \frac{\Phi(-\beta)}{\beta^{-1}\phi(\beta)-\Phi(-\beta)}}, {\beta = \frac{2\log(\alpha^{-1})}{\sqrt{N\sigma^2}}}$

где ???? — уровень ошибки I рода, ???? – размер одной выборки в тесте, Ф — кумулятивная функция распределения, ???? — функция плотности вероятности, ???? — стандартное отклонение метрики на исторических данных.

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

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

Если не знаешь что делать, делай бутстрап

Команда A/B-тестирования Ozon

Множественное тестирование — самая неочевидная проблема в A/B-тестировании. Казалось бы, мы знаем, что ошибка I рода у нас равна ????, так как мы учли все методологические нюансы, описанные выше. Однако это не так. Когда мы проводим A/B-тесты, то практически всегда смотрим на множество метрик, ведь нам важно узнать, как могло повлиять наше изменение на различные KPI, и не придаем значения тому, что в данной ситуации классическая постановка H0 нам не подходит. В эксперименте мы проверяем не одну гипотезу, а несколько, и нам необходимо понять, случайно ли прокрасились наши метрики или нет.

При множественном тестировании мы хотим узнать, есть ли среди тестируемых нами гипотез те, что приводят к изменению метрик. Нулевая гипотеза: наше изменение не приводит к значимым отличиям в метриках. Альтернативная гипотеза состоит в том, что изменение действительно дает нам улучшение в метриках. Следовательно, нужно оценивать не классическую ошибку I рода, а FWER (family-wise error rate) — групповую ошибку I рода. Выразить зависимость FWER можно через следующую формулу:

$FWER = 1 - (1-\alpha)^n$

где ???? — заданный уровень ошибки I рода, ???? — количество проверяемых гипотез. По сути, это вычисление вероятности для независимых событий. При одновременной проверке двух гипотез ????????????????>???? , так как 1−(1−0.05)2=0.0975, что уже больше ????. Проверим это на практике. Проведём A/A/B-тесты с 20 зависимыми метриками и увидим, что FWER, когда мы не используем поправки, равен 60 % (см. код).

Далее можно было бы рассказать про классические поправки на множественное тестирование, однако есть одна проблема — они работают только для независимых гипотез. В случае, когда мы сравниваем группу A и B по множеству метрик, гипотезы являются зависимыми, потому что мы считаем метрики на одних и тех же данных. Причины, по которым не работают классические методы:

Парадокс применения классических поправок на множественное тестирование. Представим, что у нас прошёл A/B-тест и все наши метрики (100 штук) прокрасились на 10 %. Мы предварительно сделаем вывод, что это явно не случайность.

Метрика	Эффект	p-value
Метрика 1	10%	0.002
Метрика 2	10%	0.01
...	...	...
Метрика 100	10%	0.009

Применим одну из классических поправок на множественное тестирование, например, Бонферрони:

$\frac{a}{n}=\frac{0,05}{100}=0,0005$

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

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

Проведем A/A-тесты и замерим максимальные эффекты. Видим довольно жуткую картину.

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

Однако не всё потеряно. А что, если мы построим критерий, который позволит нам определить, случайно прокрасились метрики или нет. Когда нужно что-то оценить эмпирически, на помощь приходит бутстрап. Давайте построим с помощью него распределение некоторой статистики, критические области которой позволяли бы нам отвергать нулевую гипотезу и контролировать FWER.

Алгоритм действий:

определим набор из m метрик, проведём A/A-тест на исторических данных и получим m p-value: {p1, p2, ..., pm};

посчитаем какую-либо заранее определённую статистику Τ от полученного вектора с p-value и получим число T(p1, p2, ..., pm) = M1;

повторим это n раз;

построим распределение полученной статистики и найдём критическую область (или области).

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

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

Давайте применим данный метод к нашим данным, рассчитаем среднее p-value при верной H0 10000 раз. Получим значение критической области, равное 0.37.

Соответственно, если наше среднее p-value входит в данную область, т.е. оно меньше 0.37, то мы отклоняем H0, иначе принимаем H0. Перейдём к A/A/B-тестам и замерим FWER и ошибку II рода. Результат соответствует ожиданиям: FWER = 5.5 %, ошибка II рода равна 0 для 2000 итераций.

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

при добавлении новых метрик в A/B-платформу следует обновить распределение;

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

Если вы сможете внедрить данный метод в ваш A/B-процесс, то FWER вам больше не страшен, а эффективность системы принятия решений многократно возрастёт.

Следует также отметить, что существует ряд мнений о том, что проблему множественного тестирования можно решить с помощью уменьшения уровня значимости или с помощью обратных тестов. Первый способ сразу отпадает, так как из формулы FWER мы уже поняли, что при любом уровне ????, если ????>2, то ????????????????>????. Обратные тесты затруднительно использовать по банальной причине — они удлиняют A/B-тест в 2 раза, плюс не факт, что данный способ спасёт от ложных эффектов, вполне вероятна ситуация, когда часть метрик прокрасится повторно.

Заключение

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

А еще, 25 января в 18:00, у нас пройдет открытый Ozon Tech Community A/B-testing Meetup. Для участия в событии регистрируйтесь по ссылке и ждите подтверждения в письме. В этом письме вам придёт ссылка на трансляцию. Трансляция будет на нашем YouTube-канале и в сообществе в VK.

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

Комментарии (1)

CAXAline
25.01.2023 14:45
#25153554
Проведите, пожалуйста, А/В-тестирование всплывающего при каждом (!) заходе на сайт озона окна выбора как я буду покупать, как физик или юрлицо. Раздражает оно или бесит.