SRM: проверка сплитования в А/В-тестировании
Как понять, что сплитование неравномерно?
О проблеме
Допустим вы запустили А/В-тест в разбиении 50/50, собрали данные и начинаете их анализировать. Вы посчитали кол-во пользователей в каждой из групп, и разбиение оказалось не совсем 50/50. Например, оно и не может быть точным в случае если кол-во пользователей — нечетное число. Но что, если кол-во пользователей отличается на сотни или даже тысячи? Стоит ли бить тревогу??
Данная проблема называется несоответствие коэффициента выборки (sample ratio mismatch, SRM), и еще посвящена целая глава 21 в одной из наиболее популярных книг по А/В-тестированию. В частности в Microsoft около 6 % экспериментов показали SRM. Проблема остается актуальной не только для разбиения 50/50, но и для все остальных (что часто используется в экспериментах, если уметь это готовить). Например, при сплите 10/90 контрольной группа будет не ровно в 9 раз большое таргетной. Итак, для начала определим почему так может быть.
Во-первых, может быть проблема с самим рандомизатором, например хэш-функцией. В целом, это не очень страшно, если она не выделяет в одну из групп пользователей с определенным признаками (например пользаков, у которых id небольшие, и скорее всего они являются первым пользователями/early adopters). Также, проблема может возникнуть при рампинге, т.е. наращивание общего процент пользователей, участвующих в тесте. Главное, чтобы основное предположение А/В о равенстве групп до внесения изменения было выполнено. Тут можно только посоветовать использовать хорошую популярную хэш-функцию. Например, Yahoo! использовали быструю FNV, хотя в следующей статье мы разберем почему они от нее отказались), а плохую хэш функцию можно найти в вышеупомянутой книге в уроке 3.2.4.
Во-вторых, что случается гораздо чаще — это баги в коде, раздающем метку в тесте (вызывающем рандомизатор). Сюда можно отнести тесты, реализованные непосредственно на фронте с редиректом. Дело в том, что редиректы снижает скорость отрисовки, и пользователь может просто уйти. Кроме того, не все боты нормально отрабатывают редиректы, что также скажется на SRM в тестах на неавторизованных пользователях. Даже если рандомизация прошла правильно, то могут перетереться куки или теряться логирование для части таргетной группы. Больше примеров можно найти в этой статье.
В-третьих, намеренное удаление пользователей из какой-либо группы. Например тестовых клиентов или обратившихся в поддержку, а также исключенных по другим бизнес-причинам (например, участие в другом тесте). Сюда же можно отнести условия попадания в тест в любую из групп: например, в тесте только не-премиум пользователи, и клиент выпадает из теста когда оформит премиум. В такое случае, если фича в тестовой группе влияет на оформление премиума, получится SRM.
Похожее происходит, когда эксперимент начинают не сначала, а добавляют к уже имеющимся пользователям, а также останавливают и включают эксперимент обратно (т.к. в случае большой разницы между группами ретенш в новый запуск будет отличаться). Обычно так работает в офлайн А/В-платформах, где пользоватей сплитуют еще до теста вручную (кодом, но не платформенным).
В-четвертых, может быть банальное влияние другого эксперимента (например, изменение одного и того же параметра), но это история уже для следующей статьи.
Второй и третий пункт можно нивелировать использованием онлайн server-side архитектуры с параметризированными конфигами, я уже разбирал это в другой статье. Также, важно запоминать в платформе или полность повторять при анализе сплитование пользователей, вместо того чтобы доставать из логирования тех кто пользовался фичей и кто нет. Однако, даже в такой архитектуре может возникнуть SRM, и скорее всего результаты такого теста будут невалидными.
Если говорить о статистике, то LinkedIn сообщает о 10% тестов, страдающих от SRM, у Microsoft порядка 6%. Значит, это довольно частая и серьезная проблема. Кроме первой причины, все остальные приводят к т.н. selection bias, а значит доверять результатам теста нельзя!
Как проверить
Если разбиение не точно 50/50, а скажем 49.5/50.5, то возникает вопрос а действительно ли есть проблема, или это случайность. Также как и при анализе разницы метрик, здесь нам поможет функционал стат-значимости. Поскольку разбиение может быть любым, в том числе с большим число таргетных групп, наиболее подходящий стат-критерий здесь это хи-квадрат (статья).
Данный критерий позволит понять, совпадает ли фактическое распределение трафика по группам с ожидаемым. Поскольку мы не знаем сколько точно должно было быть пользователей в каждой группе, мы можем посчитать через ожидаемые доли.
Код, реализующий данный тест, приведен ниже. Важно передавать именно не доли групп, а абсолютные значения, поскольку размер выборки сильно влияет на значимость.
# Например, ожидаемое распределение 20% контрольная группа
# и 2 таргетные группы по 40%
import numpy as np
import scipy.stats as st
st.chisquare(f_obs=[395, 395, 210], f_exp=[400, 400, 200])После того, как получена значимость о неравенстве, можно сделать one-sample биноминальный тест для каждой группы чтобы понять, в какой есть расхождение. Делать его изначально — означало бы получить много false-positive. Twitter с своей статье указал, что после анализа 179 своих экспериментов кейсы, когда результаты биноминальных тестов были неконсистенты с хи-квадрат, являются скорее всего FP (кол-во групп в тесте было от 4х и только в одной был стат-значимый биноминальный тест, хотя по идее должно быть минимум 2 группы).
Одна из проблем, возникающая с такой проверкой — это т.н. peeking, т.е. возросший уровень ошибок первого рода из-за множества ежедневных сравнений. Microsoft использует p-value < 0.0005. На больших выборках правильный тест маловероятно получит такой низкий порог, а неправильные эксперименты как правило имеют еще более низкий p-value.
Твиттер делит временной промежуток времени на отрезки по 8 часов и считает доли групп в рамках этого отрезка, а затем процент таких отрезков с SRM. При пороге p-value в 5% таких отрезков должно быть 1 из 20. Получается, что они контролирует FDR. Очевидно, что за каждый промежуток нужно брать только новых пользователей, первый раз попавших в тест, т.к. ретенш между группами может отличаться, а значит вырасти доля одной из групп (пример от Yahoo!).
Еще один способ нивелировать данную проблему — использовать другие критерии. Например, метод SSRM: последовательное тестирование через байесовскую статистику и априорное мультиномиальное распределение.
Как найти причину SRM
Во-первых, можно пойти по примеру Microsoft и составить свою таксономию причин расхождения коэффициента выборки по принципу дерева (см. Картинку 1).
Во-вторых, для того чтобы идти по дереву, можно использовать стандартные методы из анализа А/В-тестов, т.н. контекстные метрики. Среди них можно отметить сегментирование (проверка SRM только на ботах, версиях браузера и платформ, пользователи с медленной загрузкой и тд). Важно проверять и направление эффекта (в таргетной группе меньше чем должно быть?).
Также, в “ленивом” анализе А/В теста, т.е. учитывающем только тех пользователей кто мог увидеть новый treatment во всех группах, важно провести триггерный анализ. Это означает, что SRM проверяется на всех пользователей до момента в CJM, когда пользователь встречается в фичей. Если на этом этапе расхождения нет, значит ошибка в функционале расхождения.
Иногда, для нахождения причины приходится использовать ML-модель! Для примера — кейс от Skype в тестировании параметров передачи данных по сети.
Кстати, существует браузерное расширение для Chrome, которое находит SRM в популярных решения для А/В-тестов, таких как Google Optimize.
P.S.: Если тебе понравилась стать, в качестве благодарности можешь купить мне кофе на https://www.donationalerts.com/r/stats_data_ninja или https://buymeacoffee.com/koch.
