Comments 20
Плюс, хочу обратить внимание на то, что такая схема может быть путой тратой мощности (power), ведь размер групп уже на старте предполагается не одинаковый.
Что я только что сейчас прочитал?
Вы прочитали мое личное мнение, выраженное и аргументированное в виде статьи.
Ответы на все вопросы, что вы написали в ней есть.
При наличии корректно проведенной рандомизации двух групп (A и B) будет достаточно.
Недостаточно. Кроме некорректной рандомизации есть еще масса факторов, искажающих тест. Этому посвящен целый абзац.
Если, например, есть сомнение в самой системе которая занимается балансировкой пользователей по группам, то можно провести один раз A/A.
Отдельно АА занимает время и ресурсы. С его проведения до последующего проведения АБ ситуация может измениться. Тоже написано.
такая схема может быть путой тратой мощности (power),
Да, для ААБ тратятся ресурсы, это тоже написано в выводах. Почему это имеет смысл написано вначале.
ведь размер групп уже на старте предполагается не одинаковый.
Хотите одинаковый, сделайте ААББ. Хотя, как раз в этом особенного смысла нет.
При наличии корректно проведенной рандомизации двух групп (A и B) будет достаточно.Недостаточно. Кроме некорректной рандомизации есть еще масса факторов, искажающих тест. Этому посвящен целый абзац.
Перечень факторов в статье действительно есть. Но статья не отвечает на вопрос, как ААБ помогает с этим бороться. Не могли бы вы раскрыть эту тему подробней?
Ну, то есть мне интуитивно понятно про факторы 1 и 2. А все остальные уже вызывают вопросы.
Спасибо.
Видим, что А и А не сходятся даже при достаточной выборке, это значит есть факторы искажения. Смотрим другой период, если А и А сошлись, значит факторы были в первый период, думаем что это могло быть.
А нивелируются так: Если просто со временем/объемом продолженного теста А и А сошлись, значит влияние факторов стало статистически незначительным и и тест уже более-менее достоверный.
Можно еще сравнивать насколько расходятся А и А в процентах (после достижения значимой выборки), колебания их разницы, чтобы понимать силу искажающих факторов. Условно, если А и А разнятся на 10%, а Б у нас дает лучше результат на 20%, то нельзя считать, что изменение дало положительный результат.
Всего этого простой АБ-тест не даст.
А нивелируются так: Если просто со временем/объемом продолженного теста А и А сошлись, значит влияние факторов стало статистически незначительным
А как, допустим, фактор "эффект новизны" приведет к расхождению А и А? Они же идентично "новые" (или "старые" — смотря что мы берем за А).
С остальными факторами у меня такое же непонимание. Они же одинаково влияют на А и А — расхождения из-за них не будет. Расхождение будет только из-за проблем с рандомизацией или недостаточным объемом трафика (первые 2 фактора).
Они же одинаково влияют на А и А — расхождения из-за них не будет.
Весь фокус в том, что будет. Представим, что в ИЕ сайт работает некорректно, нельзя оформить заказ. А мы сравниваем и считаем конверсию. Юзер на ИЕ из группы А1 дошел до оформления и отвалился. Чтобы компенсировать эту ситуацию надо, чтобы другой юзер на ИЕ уже из А2 тоже не оформил заказ. Пока это не произошло возникает перекос, которого без этой проблемы с ИЕ не было бы.
Чем больше таких факторов, тем больше время/объем, которые необходимы для корректного теста.
Если А1 и А2 сравнялись по показателям, то без достаточного числа выборки это не значит ничего. Это может быть временное случайное явление совпадения значений внутри очень больших доверительных интервалов. И наоборот, они могут отличаться на какое-то значение, но разница меньше доверительного интервала и следует считать их равными.
Если введением второй А вы пытаетесь решить проблему искажающих факторов то вы просто неправильно проводите тесты. В А и Б должны отличаться только проверяемся вещь, а все остальные факторы быть одинаковыми. Иначе непонятно какой из факторов дал отличие в метрике. Ну и непонятно каким образом введение второй А нейтрализует хотяб один из приведённых искажающих факторов.
Идея вредная
Получить еще один инструмент, который поможет не сделать преждевременные выводы — вредно?
Для принятия решения об остановки теста достаточно расчёта необходимой выборки, например с помощью этого калькулятора.
Недостаточно. Калькулятор показал статистически значимую выборку. Практика показала, что А и А значительно расходятся. Смотрим, разбираемся где искажения.
Если А1 и А2 сравнялись по показателям, то без достаточного числа выборки это не значит ничего.Да, если А1 и А2 сравнялись это не значит, что результат достоверный. Но если НЕ сравнялись — чрезвычайно высока вероятность, что он НЕдостоверный.
Фокус в том, что без достаточной выборки они могут сравняться только случайно. То есть, речь не об уменьшении выборки относительно калькулятора, скорее об увеличении.
Ну и непонятно каким образом введение второй А нейтрализует хотяб один из приведённых искажающих факторов.
Именно увеличением периода или объема для теста. Ну и дополнительным индикатором, который поможет выявить факторы влияния. В жизни их трудно избежать, идеальных условий для теста на реальном проекте не создать.
В комментариях просто повторяю то, что уже написано в статье. Продолжу:
По поводу АА-теста.
Именно он — лишний расход времени и ресурсов. Вы трижды делаете А, вместо двух. Кроме того, что гораздо важнее, условия при АА тесте и при АБ могут быть разные (они делаются в разное время), чего нет при ААБ.
Про расходовать в каждом тесте:
В выводе писал, что можно ААБ каждый раз не делать, только пока не отладится тест.
Одно радует. Вы хотя бы не анонимный комментатор, что по моему наблюдению здесь редкость.
Никакого «может быть» в моем выводе нет. ААБ лучше, чем просто АБ. И лучше, чем АА + АБ, да.
Хорошо, хорошо, я же не спорю. Только остановитесь, пожалуйста, это какой-то сюр.
Возможно, некорректный вопрос задам, но можно ли такой тип тестов применить к тестированию безопасности?
Находка для шпиона: ААБ-тестирование как оптимальный вариант сплит-теста