Разбор А/В: будьте внимательны при выборе наблюдений
У нас первый кейс с А/В на разбор! Кейс тут удачный: аналитики сами нашли проблему и исправили 👮♀️
Дисклеймер: В разборах мы немного меняем формулировки (для анонимности и понятности) и добавляем комментарии от себя, чтобы граждане аналитики получили максимум пользы
Отрасль: E-commerce
Кто прислал на разбор: Аналитик
Сам кейс:
"""
Когда пришел в компанию, операционные тесты считали в разрезе заказа (order_id), иногда по store_id - day
Я начал проверять: естесственно в таких разрезах А/А никак не сходится! Единственное наблюдение, в котором сходится — это логистическая зона (~географический район города)
- внутри нее общие курьеры и магазины - нет сетевых эффектов
- пользователь при заказе может попасть в любой магазин внутри лог-зоны в зависимости от их загруженности / текущих метрик
- лог-зон у нас ~500 штук
Три урока которые я вынес:
1. Выбор независимого наблюдения для теста
Проверили, что нельзя считать тесты по наблюдениям заказ / магазин / магазин - день / зона - день. Только целиком лог-зона за весь период теста. Проводите А/А перед проведением А/В теста
2. Наблюдений мало - сокращай дисперсию
Мы пришли к лог-зонам, которых всего 500 штук. Параллельно хочется крутить хотя бы 4 теста, поэтому дальше уменьшаем дисперсию:
- Раз в 2 недели делаем новый сплит этих зон на 5 групп, стратифицируя по основным метрикам + предыдущему сплиту
- А дальше классика: для линейных метрик cuped, для ratio: pvalue считаем по cuped + линеаризация, а размер эффекта diff-in-diff
3. Автоматизируй А/В
Обернули это в простую библиотеку, которой бы могли пользоваться все аналитики: в ней есть метод run() и метод выплевывания единообразной эксельки. Стандартный вид отчета о результатах помог всем менеджерам лучше понимать, как прошел эксперимент
"""
А/В полиция полностью одобряет! В целом, А/В тесты на небольших выборках - целое искусство. Нужно очень аккуратно подходить к выбору наблюдения (независимые), сплитованию на группы (группы одинаковые) и расчету эффекта (учет выбросов и снижение дисперсии). Из рекомендаций: можно в качестве развития CUPED применять линейную регрессию с бОльшим числом факторов
metric_t = a1 * metric_{t-21} + a2 * store_format_encoding + ...
Кстати, есть гипотеза, что многие стали ошиочно подводить итоге А/В по наблюдению магазин-день и даже пользователь-день после неверной интерпретации действительно хорошей статьи от X5
Там вводят понятие Пятерочка-день для расчета MDE. И для MDE действительно важно учитывать, проводим мы эксперимент 7 дней или 14: для одного магазина за 14 дней наберется больше данных и дисперсия снизится. Ноооо, при применении T-теста (или любого другого) наблюдение - это один магазин Пятерочка. Потому что метрика в одном магазине сегодня и завтра естественно коррелирует, а это строго запрещено!
Граждане аналитики, вы можете прислать свое заявление кейс на бесплатный разбор в гугл-форму
#разбор@abpolice
У нас первый кейс с А/В на разбор! Кейс тут удачный: аналитики сами нашли проблему и исправили 👮♀️
Дисклеймер: В разборах мы немного меняем формулировки (для анонимности и понятности) и добавляем комментарии от себя, чтобы граждане аналитики получили максимум пользы
Отрасль: E-commerce
Кто прислал на разбор: Аналитик
Сам кейс:
"""
Когда пришел в компанию, операционные тесты считали в разрезе заказа (order_id), иногда по store_id - day
Я начал проверять: естесственно в таких разрезах А/А никак не сходится! Единственное наблюдение, в котором сходится — это логистическая зона (~географический район города)
- внутри нее общие курьеры и магазины - нет сетевых эффектов
- пользователь при заказе может попасть в любой магазин внутри лог-зоны в зависимости от их загруженности / текущих метрик
- лог-зон у нас ~500 штук
Три урока которые я вынес:
1. Выбор независимого наблюдения для теста
Проверили, что нельзя считать тесты по наблюдениям заказ / магазин / магазин - день / зона - день. Только целиком лог-зона за весь период теста. Проводите А/А перед проведением А/В теста
2. Наблюдений мало - сокращай дисперсию
Мы пришли к лог-зонам, которых всего 500 штук. Параллельно хочется крутить хотя бы 4 теста, поэтому дальше уменьшаем дисперсию:
- Раз в 2 недели делаем новый сплит этих зон на 5 групп, стратифицируя по основным метрикам + предыдущему сплиту
- А дальше классика: для линейных метрик cuped, для ratio: pvalue считаем по cuped + линеаризация, а размер эффекта diff-in-diff
3. Автоматизируй А/В
Обернули это в простую библиотеку, которой бы могли пользоваться все аналитики: в ней есть метод run() и метод выплевывания единообразной эксельки. Стандартный вид отчета о результатах помог всем менеджерам лучше понимать, как прошел эксперимент
"""
А/В полиция полностью одобряет! В целом, А/В тесты на небольших выборках - целое искусство. Нужно очень аккуратно подходить к выбору наблюдения (независимые), сплитованию на группы (группы одинаковые) и расчету эффекта (учет выбросов и снижение дисперсии). Из рекомендаций: можно в качестве развития CUPED применять линейную регрессию с бОльшим числом факторов
metric_t = a1 * metric_{t-21} + a2 * store_format_encoding + ...
Кстати, есть гипотеза, что многие стали ошиочно подводить итоге А/В по наблюдению магазин-день и даже пользователь-день после неверной интерпретации действительно хорошей статьи от X5
Там вводят понятие Пятерочка-день для расчета MDE. И для MDE действительно важно учитывать, проводим мы эксперимент 7 дней или 14: для одного магазина за 14 дней наберется больше данных и дисперсия снизится. Ноооо, при применении T-теста (или любого другого) наблюдение - это один магазин Пятерочка. Потому что метрика в одном магазине сегодня и завтра естественно коррелирует, а это строго запрещено!
Граждане аналитики, вы можете прислать свое заявление кейс на бесплатный разбор в гугл-форму
#разбор@abpolice