То есть мы проводим ААБ тесты, по АБ части делаем выводы, а АА часть накапливаем и по нескольким десяткам последних для этой метрики проверяем, что он срабатывает (окрашивается) в рамках заданной вероятности false positive.
Спасибо за статью! Она помогла понять, что нужно собирать сырые данные данные теста и проверять вероятность ошибки false positive для метрики.
Могут ли быть нежелательные эффекты при ААБ–тесте: по А1 и А2 проверим вероятность ошибки false positive, а по А1 и Б делать выводы, если вероятность нас устаивает?
Имеет ли практический смысл проверять вероятность ошибки false negative?
Наверняка есть готовые решения, но можно сделать и своими силами. Вам нужно написать код, который будет присваивать новому пользователю случайным образом тег вида «тест 1: вариация Х». У вас получится группы пользователей одинакового размера. Этот тег устанавливается как свойство пользователя в системе аналитики, которую вы используете. Дальше в самой системе делается отчёт с графиками ключевых метрик для пользователей из вариации А и Б.
Напишите. Про то как технически делается запуск не стал писать в посте для хаба «Управление». Всё же это уже относится к разработке. Не очень понял как связано юнит–тестирование и АБ–тестирование. Про остановку теста написал, но, видимо, вы опять же имеете ввиду какая это сделать технически.
Извините, я всю дорогу пытаюсь вам намекнуть, что статью никто не понял, потому что она плохо, путано и неинтересно написана. А не потому что все такие невнимательные. Но, видимо, без прямых как железная дорога слов это никак не сделать. Поэтому суть обсудить не получается, а всё скатывается к «я же вот тут писал».
Этот вывод действительно пропустил. Често сказать, статью читать было тяжело, поэтому пробежался по диагонали. Возможно, поэтому вам приходится в ответах цитировать свою статью. Сама статья, взять даже название, про то что, ААБ лучше АБ, а выводе скромно написано, что может быть и не всегда.
По–моему, достаточно один раз запустить АА–тест чтобы проверить правильно ли вы делаете тесты. Но расходовать треть выборки на такую проверку в каждом тесте — это чрезмерная неуверенность в своей системе. Если вы ей настолько не доверяете — разберитесь как она работает и исправьте её.
Идея вредная и показывает непонимание АБ–тестирования. Для принятия решения об остановки теста достаточно расчёта необходимой выборки, например с помощью этого калькулятора.
Если А1 и А2 сравнялись по показателям, то без достаточного числа выборки это не значит ничего. Это может быть временное случайное явление совпадения значений внутри очень больших доверительных интервалов. И наоборот, они могут отличаться на какое-то значение, но разница меньше доверительного интервала и следует считать их равными.
Если введением второй А вы пытаетесь решить проблему искажающих факторов то вы просто неправильно проводите тесты. В А и Б должны отличаться только проверяемся вещь, а все остальные факторы быть одинаковыми. Иначе непонятно какой из факторов дал отличие в метрике. Ну и непонятно каким образом введение второй А нейтрализует хотяб один из приведённых искажающих факторов.
Действительно, а как можно прямым способом обнаружить источник исключения? То есть без построения предположений о том откуда оно могло взяться, а именно точно знать откуда. Особенно, если мы его не сами выбрасываем и точку останова нельзя поставить.
Что-то в дебаггере Visual Studio 2010 Express я этого не находил.
Могут ли быть нежелательные эффекты при ААБ–тесте: по А1 и А2 проверим вероятность ошибки false positive, а по А1 и Б делать выводы, если вероятность нас устаивает?
Имеет ли практический смысл проверять вероятность ошибки false negative?
Если А1 и А2 сравнялись по показателям, то без достаточного числа выборки это не значит ничего. Это может быть временное случайное явление совпадения значений внутри очень больших доверительных интервалов. И наоборот, они могут отличаться на какое-то значение, но разница меньше доверительного интервала и следует считать их равными.
Если введением второй А вы пытаетесь решить проблему искажающих факторов то вы просто неправильно проводите тесты. В А и Б должны отличаться только проверяемся вещь, а все остальные факторы быть одинаковыми. Иначе непонятно какой из факторов дал отличие в метрике. Ну и непонятно каким образом введение второй А нейтрализует хотяб один из приведённых искажающих факторов.
Что-то в дебаггере Visual Studio 2010 Express я этого не находил.