Я разработчик программного обеспечения, работающий над системами A / B-тестирования. Я не обладаю достаточным опытом в области статистики, но последние несколько месяцев собираю знания.
Типичный тестовый сценарий предполагает сравнение двух URL-адресов на веб-сайте. Посетитель посещает, LANDING_URL
а затем случайным образом перенаправляется либо на, URL_CONTROL
либо URL_EXPERIMENTAL
. Посетитель представляет собой образец, и условие победы достигается, когда посетитель выполняет некоторые желательные действия на этом сайте. Это составляет конверсию, а коэффициент конверсии - это коэффициент конверсии (обычно выражаемый в процентах). Типичный коэффициент конверсии для данного URL-адреса составляет от 0,01% до 0,08%. Мы запускаем тесты, чтобы определить, как новые URL сравниваются со старыми. Если URL_EXPERIMENTAL
показано, что превосходит URL_CONTROL
, мы заменяем URL_CONTROL
на URL_EXPERIMENTAL
.
Мы разработали систему с использованием простых методов проверки гипотез. Я использовал ответы на другой вопрос CrossValidated здесь, чтобы разработать эту систему.
Тест настроен следующим образом:
- Оценка коэффициента конверсии
CRE_CONTROL
изURL_CONTROL
рассчитываются с использованием исторических данных. - Требуемый коэффициент конверсии целевой
CRE_EXPERIMENTAL
изURL_EXPERIMENTAL
этого множества. - Уровень значимости 0,95 обычно используется.
- Обычно используется мощность 0,8.
Вместе все эти значения используются для вычисления желаемого размера выборки. Я использую функцию R, power.prop.test
чтобы получить этот размер выборки.
Тест будет выполняться до тех пор, пока не будут собраны все образцы. На этом этапе доверительные интервалы для CR_CONTROL
и CR_EXPERIMENTAL
вычисляются. Если они не перекрываются, то может быть объявлен победитель с уровнем значимости 0,95 и силой 0,8.
У пользователей наших тестов есть две основные проблемы:
1. Если в какой-то момент во время теста будет собрано достаточное количество образцов, чтобы показать явного победителя, нельзя ли остановить тест?
2. Если в конце теста не будет объявлено ни одного победителя, можем ли мы провести тест дольше, чтобы посмотреть, сможем ли мы собрать достаточно образцов, чтобы найти победителя?
Следует отметить, что существует множество коммерческих инструментов, позволяющих их пользователям делать именно то, что хотят наши собственные пользователи. Я читал, что с вышесказанным есть много ошибок, но я также натолкнулся на идею правила остановки и хотел бы изучить возможность использования такого правила в наших собственных системах.
Вот два подхода, которые мы хотели бы рассмотреть:
1. Используя power.prop.test
, сравните текущие измеренные коэффициенты конверсии с текущим количеством выборок и посмотрите, было ли собрано достаточно выборок, чтобы объявить победителя.
Пример: был настроен тест, чтобы увидеть, существует ли в нашей системе следующее поведение:
CRE_CONTROL
: 0.1CRE_EXPERIMENTAL
: 0,1 * 1,3- С этими параметрами размер выборки
N
составляет 1774.
Однако, по мере того, как тест продвигается и достигает 325 образцов, CRM_CONTROL
(измеренная скорость преобразования для контроля) составляет 0,08 и CRM_EXPERIMENTAL
0,15. power.prop.test
рассчитывается по этим коэффициентам конверсии и N
составляет 325. Именно количество образцов должно быть объявлено CRM_EXPERIMENTAL
победителем! На данный момент мы надеемся, что тест может быть закончен. Точно так же, если тест достигает 1774 выборок, но победитель не найден, но затем он достигает 2122 выборок, что достаточно, чтобы показать, что CRM_CONTROL
0,1 и CRM_EXPERIMENTAL
0,128 - это результат, в котором можно объявить победителя.
В связанном вопросе пользователи сообщили, что такой тест менее достоверен из-за поощрения ранних остановок с меньшим количеством выборок, а также из-за уязвимости к ошибкам оценки и увеличению числа ошибок типа I и типа II. Есть ли способ заставить это правило остановки работать? Это наш предпочтительный подход, так как он означает меньше времени для программирования. Возможно, это правило остановки может сработать, предлагая какой-либо числовой балл или баллы, которые измеряют достоверность теста, если он будет остановлен досрочно?
2. Используя последовательный анализ или SPRT .
Эти методы тестирования предназначены именно для той ситуации, в которой мы находимся: как наши пользователи могут начать тестирование и завершить его таким образом, чтобы не тратить лишнее время на тестирование? Либо слишком длительное выполнение теста, либо необходимость повторного запуска теста с другими параметрами.
Из двух вышеупомянутых методов я предпочитаю SPRT, потому что мне немного легче понять математику, и, похоже, ее легче программировать. Однако я не понимаю, как использовать функцию правдоподобия в этом контексте. Если бы кто-то мог построить пример того, как вычислить отношение правдоподобия, совокупную сумму отношения правдоподобия, и продолжить на примере, иллюстрирующем ситуацию, когда можно было бы продолжать мониторинг, когда кто-то принял бы нулевую гипотезу и альтернативную гипотезу, это поможет нам определить, является ли SPRT верным путем.