5 стульев Ratio метрик
Осторожно, технопост!
После 'https://t.me/abpolice/16https://t.me/abpolice/16' rel='nofollow'>разбора про ratio метрики (= метрики-дроби) несколько человек спросили, какой же из 5 способов работы с ними лучше выбрать?
От А/В тестирования мы хотим глобально 3 вещи:
- Статитстическая корректность (Имеем реальных ошибок 1 и 2 рода не больше alpha и 1-мощность)
- Можно крутить много тестов параллельно по 1-2 недели, а не по 100 лет
- Легко и быстро считается аналитика АВ. Желательно еще и информационные метрики по срезам (платформы, типы пользователей, ...)
Как ни крути, все эти 3 условия соблюдаются только в таком сетапе
Если у компании >100К пользователей
Обычно это крупные продуктовые компании (Авито, Яндекс, Netflix, ...)
Тут выгоднее применять бакетный Т-тест. Кстати, это можно считать облегченной версией бутстрапа
Проблем с длительностью теста тут особо нет, потому что пользователей много = ускорять через условный cuped не обязательно
А вот проблемы со временем подсчета по каждому пользователю - еще как есть, если таких пользователей миллоны. Поэтому выгоднее обьединить пользователей в 10К бакетов (групп). Считать среднее внутри каждой группы, строить их распределение. И потом проводить обычный Т-тест над таким распределением. Это помогает:
- Экономить ресурсы на подсчет АВ
- Считать практически любые метрики внутри бакета
Если у компании
Осторожно, технопост!
После 'https://t.me/abpolice/16https://t.me/abpolice/16' rel='nofollow'>разбора про ratio метрики (= метрики-дроби) несколько человек спросили, какой же из 5 способов работы с ними лучше выбрать?
От А/В тестирования мы хотим глобально 3 вещи:
- Статитстическая корректность (Имеем реальных ошибок 1 и 2 рода не больше alpha и 1-мощность)
- Можно крутить много тестов параллельно по 1-2 недели, а не по 100 лет
- Легко и быстро считается аналитика АВ. Желательно еще и информационные метрики по срезам (платформы, типы пользователей, ...)
Как ни крути, все эти 3 условия соблюдаются только в таком сетапе
Если у компании >100К пользователей
Обычно это крупные продуктовые компании (Авито, Яндекс, Netflix, ...)
Тут выгоднее применять бакетный Т-тест. Кстати, это можно считать облегченной версией бутстрапа
Проблем с длительностью теста тут особо нет, потому что пользователей много = ускорять через условный cuped не обязательно
А вот проблемы со временем подсчета по каждому пользователю - еще как есть, если таких пользователей миллоны. Поэтому выгоднее обьединить пользователей в 10К бакетов (групп). Считать среднее внутри каждой группы, строить их распределение. И потом проводить обычный Т-тест над таким распределением. Это помогает:
- Экономить ресурсы на подсчет АВ
- Считать практически любые метрики внутри бакета
Если у компании