Шесть причин, почему ваши A/B-тесты не работают
Всем привет!
В прошлой статье, посвящённой 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.
Рассмотрим расширенные версии этих формул, которые вывела наша команда:
\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))}» src=«https://habrastorage.org/getpro/habr/upload_files/cd0/9e1/238/cd09e1238496fb1aec67fa7d1b4ee8e2.svg» />
где
Расшифруем параметры:
α и β — параметры, отвечающие за уровни ошибок 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-критерий, наоборот, можно и нужно применять для ненормально распределённых данных.
Так что же проверяет критерий Манна-Уитни? Нулевая гипотеза критерия Манна-Уитни — распределения двух выборок равны, альтернативная гипотеза — распределения двух выборок равны с точностью до определенного сдвига:
Как видим, U-критерий проверяет равенство распределений, а не медиан, средних или ещё чего-либо. Однако давайте проверим это эмпирически: проведём симуляцию из 10000 A/A-тестов, сэмплируя две выборки в 1000 наблюдений из нормального распределения со следующими параметрами
