Комментарии 35
Очень классно, спасибо что поделились.
- Можно ли с помощью такой системы следить за средней выручкой с посетителя/пользователя?
- Если A/B тест запускается, например, на iOS, то метрики собираются только с этой платформы или со всех?
- Что произойдёт, если пользователь оказался в тестовой группе, но он ещё не обновил приложение где реализована новая функциональность?
Спасибо, что прочитали!
Отвечаю на вопросы:
1. Можно, cистема полностью для этого подходит.
2. Зависит от настроек в самом эксперименте. Но чтобы метрики собирались со всех платформ, необходимо делить пользователей на группы по хешу от id учетной записи, а не устройства.
3. В таком случае мы не собираем метрики со старых приложений. Это поведение также настраивается через конфиг.
Отвечаю на вопросы:
1. Можно, cистема полностью для этого подходит.
2. Зависит от настроек в самом эксперименте. Но чтобы метрики собирались со всех платформ, необходимо делить пользователей на группы по хешу от id учетной записи, а не устройства.
3. В таком случае мы не собираем метрики со старых приложений. Это поведение также настраивается через конфиг.
Огромное спасибо за статью!
Несколько вопросов, если можно:
1) В рамках эксперимента вы оцениваете сразу несколько метрик. Используете ли какие-то поправки для групповой проверки гипотез (бонферони и тп)?
2) В какой ситуации вы принимаете решение об остановке эксперимента? Только когда достигнут размер выборки необходимый для достижения нужной стат мощности?
3) Как вы формулируете нулевую / альтернативную гипотезы если нужно проверить что некоторая метрика не упала?
Несколько вопросов, если можно:
1) В рамках эксперимента вы оцениваете сразу несколько метрик. Используете ли какие-то поправки для групповой проверки гипотез (бонферони и тп)?
2) В какой ситуации вы принимаете решение об остановке эксперимента? Только когда достигнут размер выборки необходимый для достижения нужной стат мощности?
3) Как вы формулируете нулевую / альтернативную гипотезы если нужно проверить что некоторая метрика не упала?
Спасибо за правильные вопросы.
В репорте можно менять порог для вероятности ошибки I рода (по дефолту у нас он довольно низок: 0.005). Это «ручной» аналог различных поправок. Вообще говоря, поправки на множественность гипотез в нашем случае плохо применимы: с учетом разрезов в каждом тесте мы проверяем десятки тысяч гипотез, многие из них коррелируют друг с другом.
Крутим до тех пор, пока MDE не сойдется до приемлемых значений по самым важным метрикам. Бывает, что MDE вообще не сходится до нужных значений за адекватный срок, в таком случае нужно перезапускать эксперимент на большей доле трафика.
Так и формулируем: метрика M не должна упасть больше чем на X%. В течение эксперимента ждем прокраса на X%, либо отсутствие прокраса при MDE <= X%.
1) В рамках эксперимента вы оцениваете сразу несколько метрик. Используете ли какие-то поправки для групповой проверки гипотез (бонферони и тп)?
В репорте можно менять порог для вероятности ошибки I рода (по дефолту у нас он довольно низок: 0.005). Это «ручной» аналог различных поправок. Вообще говоря, поправки на множественность гипотез в нашем случае плохо применимы: с учетом разрезов в каждом тесте мы проверяем десятки тысяч гипотез, многие из них коррелируют друг с другом.
2) В какой ситуации вы принимаете решение об остановке эксперимента? Только когда достигнут размер выборки необходимый для достижения нужной стат мощности?
Крутим до тех пор, пока MDE не сойдется до приемлемых значений по самым важным метрикам. Бывает, что MDE вообще не сходится до нужных значений за адекватный срок, в таком случае нужно перезапускать эксперимент на большей доле трафика.
3) Как вы формулируете нулевую / альтернативную гипотезы если нужно проверить что некоторая метрика не упала?
Так и формулируем: метрика M не должна упасть больше чем на X%. В течение эксперимента ждем прокраса на X%, либо отсутствие прокраса при MDE <= X%.
С одной стороны вы пришите, что что-то контролирует нежелательные пересечения экспериментов, с другой стороны вы ссылаетесь на пересекающиеся эксперименты в Google, причем говорите, что «Чтобы не допускать потенциально опасных пересечений экспериментов, мы используем логику, схожую со «слоями» в Google». В итоге непонятно. Так пересекаются у Вас эксперименты или не пересекаются? Или Вы только опасные пересечения не допускаете, а неопасные пересечения допускаете? Каким же образом?
Во скольких экспериментах одновременно может участвовать Ваш посетитель? Если больше одного, то как много посетителей участвуют в более чем одном эксперименте? Сколько максимум экспериментов одновременно система тестирования выдерживает? Прокомментируйте 17 слайд презентации Google.
Во скольких экспериментах одновременно может участвовать Ваш посетитель? Если больше одного, то как много посетителей участвуют в более чем одном эксперименте? Сколько максимум экспериментов одновременно система тестирования выдерживает? Прокомментируйте 17 слайд презентации Google.
Вы верно сформулировали: опасные пересечения не допускаем, опасные допускаем.
Невозможно одновременно проводить много экспериментов, не допуская пересечений. Поэтому мы делим все экспы на подмножества (слои), в каждом из которых обеспечивается отсутствие пересечений: т. е. ни один пользователь не может попасть одновременно в два эксперимента из одного слоя. Подробное объяснение, как реализована эта логика, осталась за пределами статьи, но презентация Google наглядно объясняет идею.
Статистику по количеству экспериментов разглашать не могу.
Невозможно одновременно проводить много экспериментов, не допуская пересечений. Поэтому мы делим все экспы на подмножества (слои), в каждом из которых обеспечивается отсутствие пересечений: т. е. ни один пользователь не может попасть одновременно в два эксперимента из одного слоя. Подробное объяснение, как реализована эта логика, осталась за пределами статьи, но презентация Google наглядно объясняет идею.
Статистику по количеству экспериментов разглашать не могу.
Дайте пожалуйста определение опасного пересечения.
Опасное пересечение это такое, которое в одном слое или опасное пересечение это нечто, что вредит посетителю?
Так в скольких экспериментах максимум может участвовать один пользователь одновременно? Увеличивается ли количество слоев с течением времени, как на 17 слайде, или же количество слоев более менее постоянная величина, условно — дизайн, реклама, поиск? Может ли быть в слое «дизайн» много подслоев дизайна?
Опасное пересечение это такое, которое в одном слое или опасное пересечение это нечто, что вредит посетителю?
Так в скольких экспериментах максимум может участвовать один пользователь одновременно? Увеличивается ли количество слоев с течением времени, как на 17 слайде, или же количество слоев более менее постоянная величина, условно — дизайн, реклама, поиск? Может ли быть в слое «дизайн» много подслоев дизайна?
> Статистику по количеству экспериментов разглашать не могу.
Я не прошу Вас здесь что-то разглашать из NDA. Интересует теория эффективности предложенного дизайна проведения экспериментов.
Например, существует 1 млн пользователей и 1 млн запросов в день.
Есть желание провести 1 тысячу экспериментов. Предполагается, что никакие эксперименты не опасны друг с другом, не делают сильных ухудшений важных метрик и не делают сильных улучшений. 9 из 10 экспериментов ухудшают важную метрику на 1 процент, а 1 из 10 экспериментов улучшает важную метрику на 1 процент. Заранее неизвестно, кто будет плохой, а кто хороший.
Учитывая входные данные предложите схему потока экспериментов — на какой части аудитории, в каком порядке, сколько слоев будете использовать, сколько экспериментов будет в расчете на одного пользователя в один момент времени, сколько времени потребуется всего на всю тысячу экспериментов.
Подозреваю, такая практическая теория была бы интересна многим читателям вашей публикации.
Я не прошу Вас здесь что-то разглашать из NDA. Интересует теория эффективности предложенного дизайна проведения экспериментов.
Например, существует 1 млн пользователей и 1 млн запросов в день.
Есть желание провести 1 тысячу экспериментов. Предполагается, что никакие эксперименты не опасны друг с другом, не делают сильных ухудшений важных метрик и не делают сильных улучшений. 9 из 10 экспериментов ухудшают важную метрику на 1 процент, а 1 из 10 экспериментов улучшает важную метрику на 1 процент. Заранее неизвестно, кто будет плохой, а кто хороший.
Учитывая входные данные предложите схему потока экспериментов — на какой части аудитории, в каком порядке, сколько слоев будете использовать, сколько экспериментов будет в расчете на одного пользователя в один момент времени, сколько времени потребуется всего на всю тысячу экспериментов.
Подозреваю, такая практическая теория была бы интересна многим читателям вашей публикации.
Правильно ли я понимаю что пользователю не дают выбора и не сообщают о том что над ним проводят эксперимент?
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за то, что показываете кухню! А для людей, кто не сильно в теме можете в двух словах рассказать о примерах таких «зеленых» и «красных» экспериментов?
.
Весь транспорт данных в цикле занимает один день. Эксперименты длятся, как правило, неделю, но заказчик получает инкремент результатов каждый день.
Не возникает ли здесь проблемы многократного тестирования гипотезы?
В теории возникает, на практике — нет. Во-первых, MDE не дает принимать преждевременные решения, если важные метрики не прокрасились. Во-вторых, когда у тебя в распоряжении много метрик и разрезов, легко отличить реальный эффект от false positive.
Если смотреть каждый день в тест в ожидании MDE, возрастает верояность его ложно принять. Даже наличие стат значимого MDE при разовом просмотре теста не гарантирует что не будет ошибки, при многократном просмотре риск растет, разве нет?
Промоделировать это довольно просто или можно посмотреть здесь
varianceexplained.org/r/bayesian-ab-testing
Промоделировать это довольно просто или можно посмотреть здесь
varianceexplained.org/r/bayesian-ab-testing
Теперь возникает вопрос: как провести T-test и MW-test для Ratio-метрик? Для T-test нужно уметь считать дисперсию выборки, а для MW выборка должна быть «поюзерной».
Что мешает считать дисперсию для метрика отношения, говорим что это биномиальное распределение/бернули, оценочная дисперсия p*(1-p)
Теперь переходим к новой экспериментальной единице — бакет. Наблюдения в бакете суммируем (числитель и знаменатель независимо):
Вы оценивали процент ошибок (например на синтетике или уже проведенном А/Б) первого/второго рода, при разных B, от B = N до B = const c разными значениеяси
Теперь возникает вопрос: как провести T-test и MW-test для Ratio-метрик? Для T-test нужно уметь считать дисперсию выборки, а для MW выборка должна быть «поюзерной».
Ответ: нужно разложить Ratio в ряд Тейлора до первого порядка в точке:
Данная формула преобразует две выборки (числитель и знаменатель) в одну, сохраняя среднее и дисперсию (асимптотически), что позволяет применять классические стат. тесты.
Похожую идею коллеги из Яндекса называют методом линеаризации Ratio (выступления раз и два).
Почему не стали использовать линеаризацию, она выглядит вычислительно проще и элегантнее
Что мешает считать дисперсию для метрика отношения, говорим что это биномиальное распределение/бернули, оценочная дисперсия p*(1-p)
Это не то же самое, что ratio-метрика в общем смысле.
Вы оценивали процент ошибок (например на синтетике или уже проведенном А/Б) первого/второго рода, при разных B, от B = N до B = const c разными значениеяси
Оценивали. Чем больше B, тем меньше ошибка. 200 — хороший компромисс между размером ошибки и объемом данных, которые нужно хранить.
Почему не стали использовать линеаризацию, она выглядит вычислительно проще и элегантнее
Наш метод — это абсолютно то же самое немного в другом ракурсе. Но при этом он сохраняет mean для выборки и не зависит от mean в контрольной группе, а выборочная дисперсия равна оценке по дельта-методу.
>Если индикатор красный, то, возможно, в выборке есть выбросы или аномально длинный хвост. В таком случае принимать результат по этой метрике нужно осторожно, либо не принимать вовсе.
>MDE не дает принимать преждевременные решения, если важные метрики не прокрасились.
Вы случайно не делали очень много (1 млн) виртуальных слоев и не смотрели сколько процентов виртуальных слоев окрашиваются по какой-либо важной метрике?
>MDE не дает принимать преждевременные решения, если важные метрики не прокрасились.
Вы случайно не делали очень много (1 млн) виртуальных слоев и не смотрели сколько процентов виртуальных слоев окрашиваются по какой-либо важной метрике?
Расскажите пожалуйста про фронтовую часть. Вы заранее делаете сборки с A/B тестами или в рантайме на клиенте включаете соответствующие вариации?
На клиенте должны быть реализованы различные сценарии, включением и отключением которых занимается бэкенд (в нашем случае это микросервис). Мы умеем запускать и останавливать эксперимент без накатывания новой сборки.
Ну допустим, что мы хотим потестить новостной блок (чисто пример). Бэкенд пропускает пользователей через гейт, на сервере рисуется вариант с этим блоком, отправляется js код с логикой этого новостного блока.
Но тем юзерам, которые не участвуют в эксперименте ведь тоже будет отправляться код с этим новостным блоком. Получается, что если мы запустим 10 А/B тестов, то на клиенте будет куча неиспользуемого кода.
Интересно как у вас эта проблема решена. Или это необходимая боль?)
Но тем юзерам, которые не участвуют в эксперименте ведь тоже будет отправляться код с этим новостным блоком. Получается, что если мы запустим 10 А/B тестов, то на клиенте будет куча неиспользуемого кода.
Интересно как у вас эта проблема решена. Или это необходимая боль?)
Привет.
А делаете ли вы тесты более чем с двумя вариантами? Когда есть контрольный A вариант, но еще и B, C и может больше. Хотя бы 3 пока интересует.
Или попарное сравнение используете может?
Тема интересная как мне кажется.
А делаете ли вы тесты более чем с двумя вариантами? Когда есть контрольный A вариант, но еще и B, C и может больше. Хотя бы 3 пока интересует.
Или попарное сравнение используете может?
Тема интересная как мне кажется.
Привет! У нас часто бывает больше одной тестовой группы с разными вариантами. В таких случаях мы делаем попарное сравнение. Как правило, заводим также две контрольные группы, что иногда помогает валидировать случайные прокрасы.
Интересует математическая сторона вопроса.
В теории говорится о поправке Бонферрони.
Грубо говоря надо делить изначальное p-value на количество вариантов N-1, т.к. вероятность случайности и ошибки 1 рода больше с увеличением вариантов.
Еще возможно вы не верно поняли про какие мультисравнения я говорю. Я не про разные группы тестов, а про разные варианты одного теста.
Грубо говоря когда у нас зеленая кнопка, это наш контрольный вариант A.
И мы хотим протестировать синюю кнопку — B,
красную — C,
желтую — D.
И все это одновременно.
В теории говорится о поправке Бонферрони.
Грубо говоря надо делить изначальное p-value на количество вариантов N-1, т.к. вероятность случайности и ошибки 1 рода больше с увеличением вариантов.
Еще возможно вы не верно поняли про какие мультисравнения я говорю. Я не про разные группы тестов, а про разные варианты одного теста.
Грубо говоря когда у нас зеленая кнопка, это наш контрольный вариант A.
И мы хотим протестировать синюю кнопку — B,
красную — C,
желтую — D.
И все это одновременно.
Спасибо за статью. Вопрос: в какой момент происходит разметка пользователей? Заранее или непосредственно в момент входа пользователя в эксперимент?
Спасибо за вопрос! Происходит по-разному. Но в большинстве случаев в момент входа в эксперимент. Таким образом в эксперименте участвуют в том числе и новые пользователи.
А разметка заранее происходит в тех случаях, если нужно вручную «выравнивать» группы по метрике, чтобы устранить риск изначального смещения.
Даниил, спасибо за ответ. Пытаемся применить опыт которым ты делишься в компании, где я работаю (вероятно, что бы даже можешь догадываться, что за компания).
В продолжение предыдущего, есть ещё один, нетривиальный для меня, вопрос:
представим, что мы разметили «в момент входа», тогда с какого момента считать метрики по «размеченным»?
- С момента «входа в эксперимент»? Но тогда кто-то придёт в первый день старта эксперимента, а кто-то уже в последний — и, кажется, это ни как не учитывается, например, в t-критерии.
- С момента старта эксперимента? Но тогда мы учитываем то поведение пользователя на которое эксперимент не мог оказать ни какого влияния.
Какой вариант выбрали вы и почему?
Буду благодарен за ответ — очень актуально.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как устроено A/B-тестирование в Авито