Базовые требования к качеству модуля сплитования АБ тестов. Часть 2

Вчера говорили про 4 требования к выборкам, которые должна обеспечивать сплитовалка.

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

5. Ортогональность Если у нас есть 2 АБ теста и часть пользователей могут попадать в оба АБ теста, то мы ожидаем, что пользователи экспа 1 попадающие в эксп 2 будут попадать в варианты экспа 2 в равных пропорциях, в т.ч. с учетом баланса вариантов эксп 1 и наоборот.

Т.е. по сути это про однородность выборок, но с акцентом именно на их сбалансированности по пользователям, которые попадают в другие АБ тесты

6. Разведение несовместимых экспериментов Можно выделить 2 типа несовместимых экспериментов: - эксперименты, которые ломают интерфейс или неожиданно ломают пользовательский опыт - эксперименты, в которых эффекты одного эксперимента могут в разной степени влиять на варианты в другом АБ тесте

Один из классических примеров не совместимых экспериментов. Это когда в одном эксперименте тестируют цвет кнопки, а в другом цвет надписи на кнопке. Например в экспе 1 - красный шрифт на кнопке в тесте, а в экспе 2 красная кнопка в тесте. Пользователи, которые попадут в тестовую группу экспа 1 и экспа 2 получат красную кнопку с красным шрифтом. Это ломает логику интерфейса для пользователя и такие изменения не совместимы.

Как правило для решения таких кейсов применяют механизм слоев, где экспериментам в рамках одного слоя раздают разных пользователей, не допуская попадания пользователей одного экспа в другой.

7. Обеспечение принципа SUTVA Stable Unit Treatment Value Assumption. Здесь имеется в виду, что при проведении экспа тестовое воздействие для одной из групп должно влиять только на нее, и не должно оказывать влияние на пользователей из других групп.

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

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

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

Другой пример. Для одной группы пользователей снизили цену поездок на такси, они стали больше заказывать такси, свободных машин стало меньше, а пользователи другой группы не могут заказать такси, т.к. мало свободных. Т.е. через воздействие на одну группу, мы повлияли на другую группу.

Соответственно если в экспериментах есть такие "социальные эффекты", то платформа должна уметь работать с ними для того чтобы АБ тест можно было бы считать валидным. Например платформа должна поддерживать Switchback-тесты.