Как оценить валидность A/B тестов. SRM и другие критерии
Привет! Меня зовут Полина, я руковожу A/B‑платформой в СберМаркете. В этой статье я расскажу о нескольких нюансах экспериментирования, которые возникают на разных этапах: от дизайна и сплитования до подведения итогов. Если их не учитывать, нам приходиться с осторожностью относиться к результатам или вовсе проводить эксперимент заново. К ним относятся Sample Ratio Mismatch, корректное пересечение тестов, взаимодействие нескольких экспериментальных механик и другое. Разберем как эти критерии обнаружить, найти причину и что делать с экспериментом дальше.
Sample Ratio Mismatch
Один из основных критериев валидности — это несоответствие между ожидаемым и наблюдаемым соотношением групп в экспериментах. Важно, что это не разница между количеством пользователей, а нарушение изначально заданных пропорций между группами.
Например, мы ожидали распределение 50:50, а в конечном итоге получаем 45:55. При этом неважно, каким было изначально запланированное распределение по группам. Если вы планировали 10:90, а получилось 5:95 — это также проблема.
Почему это плохо? Чтобы ответить на этот вопрос, отойдем от долей и посмотрим на пользователей. Слева на картинке показано, как выглядит желаемая пропорция, а справа — SRM. Часть пользователей из группы B пропала, а в группе А все на месте. Если бы пропажа пользователей была случайной, пользователей в обеих группах было бы меньше, но пропорция бы сохранялась.
Эти пользователи пропали неслучайно — и, скорее всего, это обусловлено какой-то ошибкой. Попадание в группу теперь связано не только с алгоритмом рандомизации, но и с неизвестными внешним фактором. Это нарушает основную предпосылку АБ тестирования о рандомности сплитования — и теперь у нас нет уверенности, обусловлена ли разница между группами нашей фичей или чем-то еще. Поэтому результатам теста с SRM мы не можем доверять. Разберем основные причины возникновения SRM.
Первая причина возникновения SRM — проблемы со сплитованием. Если дело в неми, эксперимент придется повторно перезапустить. Обычно проблемы возникают не на стороне самого сплиттера, а на стороне клиента. Например, выбирается некорректное условие для раздачи метки. В одном из экспериментов условие для раздачи метрики тестовой группы было во взаимодействием с одним компонентом карточки товара. На одной из платформ был еще один компонент карточки — команда о нем не знала. В итоге пользователи, у которых был другой компонент, в тестовую группу не попадали.
Другая причина связана с фильтрацией пользователей. Чаще всего встречаются проблемы с триггерингом — дополнительной фильтрацией пользователей, на которых был воздействие экспериментальной механики. Этот способ позволяет повысить чувствительность, когда раздача метки группы происходит сильно раньше по флоу пользователя, чем он увидит фичу. Например, мы сплитуем пользователя при заходе на сайт, а фичу показываем пользователю на чекауте. Если событие для триггеринга выбрано некорректно и сама фича может влиять на отправку или логирование этого события — мы «потеряем» часть пользователей. Большинство тестов с SRM в СберМаркете было вызвано именно этим фактором.
Фильтрация может быть и по бизнес-требованиям: например, если мы хотим оставить в тесте только активных пользователей или тех, кто не участвовал в маркетинговой акции. SRM произойдет, если сама экспериментальная механика влияет на эти условия. Например, однажды так случилось у Netflix — фича настолько увеличила активность пользователей, что их отмечали как ботов и удаляли из анализа.
Последняя причина некорректной фильтрации — проблемы на стороне аналитики, неправильные трансформации, объединение таблиц и так далее. Например, какие-то пользователи из-за объединения с устаревшей таблицей удаляются из эксперимента. Если была обнаружена проблема с фильтрацией, ее, скорее всего, получится починить без перезапуска, подобрав другое условие.
Как обнаружить SRM?
SRM встречается довольно часто: в целом компании описывают частоту появления в 5–15% тестов. В СберМаркете его обнаруживали в 8% тестов. Даже если расхождения могут казаться небольшими, их нужно тестировать. Сделать это в конце эксперимента достаточно просто:
Разделите всех пользователей, попавших в тест, в соответствии с изначальным соотношением групп.
Посчитайте реальную долю контроля и теста относительно всех пользователей в тесте.
Сравните ожидаемое распределение по группам из пункта 1 и реальное из пункта 2 через критерий Хи-квадрат.
Однако мы хотим обнаруживать SRM не только в конце эксперимента, но и во время него. Проблема в том, что тестируя каждый день, доля ложных прокрасов может стать гораздо больше принятых 5%. Простое решение — использовать низкий трешхолд p-value < 0.0005, но у этого подхода есть недостаток — при тестировании на ранних этапах тест скорее будет недостаточно мощным и мы не зафиксируем дисбаланс.
Другой вариант — использовать sequential SRM. Этот метод показывает наилучший баланс с точки зрения мощности, скорости обнаружения дисбаланса и сонаправленности с результатами на последний день среди других методов последовательного тестирования.
SRM просто обнаружить и гораздо сложнее найти его причину — на это порой могут уйти недели, даже у опытных аналитиков. В качестве отправной точки можно проанализировать, чем две группы отличаются друг от друга. Посмотрите на SRM в разрезе пользователей. Если он наблюдается, например, только на одной версии приложения или платформе — возможно, при сплитовании не учли какие-то особенности этих параметров.
Также полезно посмотреть на SRM в динамике. Если SRM наблюдался только в какой-то промежуток эксперимента, дисбаланс может возникнуть из-за пересечения двух фичей, которые по отдельности работают корректно, но при тестировании вместе приводят к тому, что у части пользователей не отображается одна из фичей.
Пересечения тестов
С одновременным проведением большого количества тестов возникают две проблемы:
техническая, которая показывает, что группы экспериментов пересекаются некорректно;
и бизнесовая, отображающая «взаимодействие» двух фичей. Поэтапно рассмотрим каждую.
Неравномерное пересечение
Мы предполагаем, что эксперименты 1 и 2 ортогональны, поскольку сплитование для них происходит независимо. То есть, если у обоих экспериментов желаемое разбиение трафика задано как 50:50, то пользователи второго эксперимента имеют одинаковые шансы попасть в любую из групп. Допустим, у нас есть 1000 пользователей, тест 1 разбивает трафик в пропорции 50:50, а тест 2 — в пропорции 70:30. Вот как выглядит таблица сопряженности для этих тестов:
Тест 1 / Tест 2 | Контроль | Тест |
Контроль | 350 | 150 |
Тест | 350 | 150 |
Однако это предположение не всегда соблюдается. Пользователи одного теста могут неравномерно распределяться по группам второго. Вернемся к примеру выше. У нас также есть 1000 пользователей, разбиение 50:50 для теста 1 сохраняется, но в каждой из групп теста 1 Тест 2 сплитуется уже не 70:30.
Тест 1 / Tест 2 | Контроль | Тест |
Контроль | 400 | 100 |
Тест | 300 | 200 |
Это приводит к некорректным результатам: фича одного теста неравномерно влияет на пользователей в другом тесте. Если фича теста 1 приводит к ухудшению метрик, то таких недовольных пользователей в контроле и тесте 2 становится неравное количество.
Проблемы с неравномерностью пересечений связаны, в первую очередь, с алгоритмом сплитования. Они возникают редко, но важны для отслеживания валидности всех тестов. Чтобы это измерять, мы применяем хи-квадрат тест для каждой пары. Смысл тестирования похож на тот, что мы используем для SRM — с одним отличием, что здесь мы тестируем не две группы одного теста, а группы двух тестов.
Неаддитивность эффектов
Взаимодействие (interaction) между фичами — вторая, бизнесовая часть проблемы пересечения тестов. Бывает, что совместный эффект тестов не равен сумме их индивидуальных эффектов — это называют неаддитивностью.
Классический пример: параллельное тестирование синей кнопки и синего фона сайта. Допустим, что обе фичи положительно влияют на метрики, но вместе они дают обратный эффект — мы наблюдаем неаддитивность.
Неаддитивность эффектов — это не обязательно плохо. Две фичи могут усиливать друг друга и приводить к росту метрик. Важно, что решение по взаимодействующим фичам нужно принимать, учитывая их совместный эффект. Если мы предполагаем, что такие эксперименты могут влиять друг на друга, их нужно тестировать совместно. Для этого можно запускать эксперименты в изолированном месте в продукте (слое) или ортогонально пересечь.
Напомним, что для оценки эффекта от фичи на метрики можно воспользоваться линейной регрессией.То есть наше уравнение регрессии будет выглядеть так:
Теперь добавим информацию о взаимодействии двух тестов через переменную взаимодействия:
Коэффициент при b3 и показывает то, насколько эффект одного эксперимента изменился при добавлении к нему другого. Если он статистически значим на уровне 0.0001 — мы считаем, что тесты пересеклись. Мы отслеживаем пересечения пары тестов, начиная с 7-го дня и в конце каждого теста, чтобы не сравнивать еще не наполненные группы.
Пересечение тестов — очень редкая ситуация. В среднем мы детектируем пересечения для 10% пар тестов хотя бы по одной из метрик, но сам эффект от взаимодействия минимален. Это связано с тем, что при налаженном процессе продуктового планирования две разные команды не будут внедрять фичи, которые совсем не уживаются друг с другом. Более того, скорее фичи в разных частях продукта не сильно взаимодействуют друг с другом.
Так как интерпретация пересечений в продуктовой логике не всегда проста, все пересечения можно разделить по степени их важности. Например, подсвечивать пользователю только те пересечения, которые убирают эффект, меняют его знак или меняют итоговый цвет метрики. Дополнительной информацией для экспериментатора могут стать длительность пересечения тестов, количество пользователей в пересекшихся экспериментах. Если пересечение пользователей достаточно небольшое, то можно подставить под вопрос эффект от пересечения.
Другие критерии
Мы также подсвечиваем дополнительные критерии, которые могут и не говорить напрямую о некорректном дизайне эксперимента, но сигнализируют о потенциальных проблемах.
Длительность теста меньше недели. Возможно, тест остановили раньше времени, потому что увидели положительные прокрасы и решили не ждать окончания теста и выкатить фичу. Если отест заранее был запланирован таким коротким, при такой длительности не учитывается внутринедельная сезонность — поведение пользователей на выходных отличается от остальной недели.
Тест запущен на той же соли, что и какой-либо тест в прошлом. Если такое произошло, есть вероятность, что на результаты вашего теста повлияет смещение в группах, обусловленное остаточными эффектами от предыдущего теста.
Исторические А/А тесты. Для всех А/Б тестов мы считаем расхождение метрик на истории. Это важный показатель и для самих экспериментов, и для понимания корректности сплитования на уровне платформы.
Критерии валидности — только один из шагов для контроля качества экспериментов. За скобками осталась проверка корректности самого дизайна эксперимента и соблюдение предпосылок экспериментирования, например, Stable Unit Treatment Value Assumption. О том, что это такое и в каких ситуациях эта предпосылка нарушается я рассказывала здесь.
Для контроля на уровне платформы также не стоит забывать о метриках качества данных и технических метриках платформы. Например, мы следим за аномалиями в агрегированных данных, на которых строятся финальные расчеты. А также смотрим, насколько они соответствуют источникам, контролируем долю не посчитанных результатов экспериментов и, конечно же, время и память, которые требуются для расчетов. Это в том числе помогает понять, вызваны ли проблемы валидности экспериментов проблемами на стороне платформы, и оперативно реагировать.
Если хотите работать в А/Б платформе — наши открытые вакансии здесь.
Спасибо Аделине Якуповой за работу над этой статьей и ценные комментари.
Product&data команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
