Схемы проведения АБ тестов

Один из холиварных вопросов в среде АБ тестов - это стоит ли проводить одновременно несколько экспериментов на одних и тех же пользователях. Те кто против запуска нескольких экспериментов говорят, что попадание пользователя сразу в несколько экспов может исказить результат.

Сторонники запуска нескольких АБ тестов одновременно на одних и тех же пользователей топят за то, что это позволяет сильно увеличить число экспериментов, т.к. в предыдущем подходе необходимо ждать когда закончится ранее запущенный эксперимент.

По моему мнению правда где-то по середине. В большинстве случаев мы можем запускать несколько АБ тестов одновременно на одних и тех же пользователях. Главное, чтобы соблюдался принцип ортогональность и эффекты одного АБ теста оказывали одинаковое влияние на эффекты другого АБ теста.

Это может смещать абсолютные значения метрик, но если смещение одинаково для обоих вариантов АБ теста, то дельта сохранится, а ведь именно дельта важна нам для подведения итогов АБ теста. Т.к. p-value это вероятность обнаружить такие или еще более экстремальные различия(дельту) в метриках при верности H0.

Но также бывают случаи когда мы не можем запускать АБ тесты одновременно, т.к. пересечение их тестовых вариантов может ломать продукт или пользовательский опыт. В таком случае лучше отказаться от перекрытия и запускать их отдельно на разных пользователях.

Перейдем к схемам проведения АБ тестов. Есть 3 наиболее распространенных схемы, их вы можете увидеть на картинках

Последовательное проведение экспериментов
Здесь мы запускаем 1 эксперимент в нашем продукте и ждем когда он завершится, а после запускаем другой. В такой схеме никакие изменения других экспериментов никак не будут аффектить на запущенный эксперимент, т.к. других экспериментов нет.

Довольно сомнительное преимущество если учесть, что разные части продукта могут быть довольно независимы друг от друга и мы могли бы в них также проводить эксперименты, на тех же самых пользователях. Основной минус и он очень существенный - малое число АБ тестов в такой схеме. Это очень тормозит развитие продукта.

Изолированное проведение экспериментов
Здесь мы запускаем несколько АБ тестов одновременно, но делаем так чтобы пользователи могли попадать только в один эксперимент, а в другой нет. По сути мы получаем изолированные эксперименты как и в случае описанном ранее. Во многих случаях эта схема не особо отличается пропускной способностью от последовательной, т.к. в последовательной вы бы сначала провели эксп 1 за 1 неделю, а потом эксп 2 за 2 неделю.

В изолированных экспах, т.к. вы например делите трафик на 2 экспа, то эксп 1 будет длится 2 недели и эксп 2 - 2 недели, но одновременно и там и там вы получаете что за 2 недели провели 2 эксперимента. Конечно в изолированных экспериментах возможны некоторые конфигурации, когда такой подход даст увеличение пропускной способности, но здесь не буду об этом.


Проведение перекрывающихся экспериментов
В такой схеме один и тот же пользователь в одно время попадает во множество экспериментов в рамках продукта. В большинстве случаев за счет ортогональности и одинакового влияния эффектов между экспами мы будем получать достаточно хорошие оценки в АБ тестах, конечно такая схема не застрахована от проблем, о которых я писал в начале поста.

Как показывает практика такие эффекты не так часты, но такой подход сильно увеличивает число проводимых экспериментов и с точки зрения бизнеса дает больше value, чем попытки избежать всех негативных последствий за счет изоляций. Большинство компаний придерживается именно такой схемы проведения экспов.