Разбор А/В: будьте внимательны при выборе наблюдений

У нас первый кейс с А/В на разбор! Кейс тут удачный: аналитики сами нашли проблему и исправили 👮‍♀️
Дисклеймер: В разборах мы немного меняем формулировки (для анонимности и понятности) и добавляем комментарии от себя, чтобы граждане аналитики получили максимум пользы

Отрасль: 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

Отрасль: Маркетинговое агенство
Кто прислал на разбор: Продуктовый маркетолог
Сам кейс:
Мы проводим АБ тест 2ух рекламных компаний (РК) в Яндекс Директ по привлечению новых пользователей: они кликают на рекламу и попадают на лендинг. В день ~1000 новых уникальных пользователей
Гипотеза: если поменяем лендинг, добавив динамическую кнопку, то CR в регистрацию вырастет на x%

Вопросы:
1. Нужны ли нам дополнительные прокси или guardrail метрики? На сайте все кнопки ведут на одну и ту же форму регистрации, других действий для пользователя нет. Соответственно и метрик, которые можем уронить, нет?

-- В целом, CR в регистрацию - уже хорошо! Можно еще добавить более глубокие CR. Например, в покупку после регистрации, чтобы точно максимизировать прибыль от рекламной компании, а не только новичков. Ведь компании важны деньги, а не просто количество пользователей. Если бы РК отличались стоимостью, то стоило бы учесть еще и CPA (cost per action) или CPM (cost per mille) в зависимости от мехники РК 💸


2. Стоит ли менять дефолтные alpha=5% и power=80%? Нужно ли проводить А/А тест?

-- Эти парметры для большинства случаев - ОК. Но для стартапов их можно ослабить (alpha=10%) для быстрых итераций. А для мега-корпораций ужесточить (alpha = 0.1%, например), чтобы еще больше не усложнять продукт и не катить в прод потенциально опасные фичи. А/А тест лучше хотя бы единожды провести, чтобы проверить правильность сплитования пользователей и расчета метрик + стат тестов

3. Если мы провели зеленый эскперимент на РК, которая таргетируются на один сегмент аудитории, то мы же не можем экстраполировать на другие сегменты (другие гео, тип устройства, возраст итд)?

-- В целом, А/В на неслучайных выборках (на отдельных сегментах, например) никак не экстраполируются. Скидка 10% на метро для студентов вряд ли так же хорошо сработает на it-шниках. В маркетинге полезно проводить большие тесты на случайной выборке из всех пользователей, и пост-анализом А/В находить сегменты, где РК работает лучше. И уже последующие РК делать "умнее"

4. По формуле необходимо 8948 пользователей в каждой группе. Посчитал, что мы наберем их за 18 дней. Для лучшего отслеживания недельной сезонности стоит ли округлить до 21 дня? Эксперимент нужно остановить через 21 день или когда наберем 8948 пользователей?

-- Период А/В всегда должен быть кратен 1 неделе (1w, 2w, 3w, ...), чтобы убрать эффеткы от разного поведению людей в будни и выходные. Когда А/В тест задизайнен и запущен, то мы не меняем в нем ничего. Вот вообще ничего! Период (21 день), целевые метрики и прочее - соблюдаем максимально жестко. Иначе появится эффект подглядывания, А/В полиция придет к вам

5. Коллеги из другого отдела считают результаты А/В через https://yandex.ru/adv/statvalue . Насколько верно пользоваться этим калькулятором? не лучше ли считать через z-test/хи-квадрат в python?

-- Этим калькулятором не пользовался, и нигде не нашел, что у него под капотом. Но вангую, что Z-test. Основная ошибка при применении стат критериев - это даже не выбор критерия, а проблемы с данными на входе) Например, в вашем кейсе нужно подавать на вход не количество кликов/регистраций, а количество уникальных пользователей с кликом/регистрацией. Если человек 3 раза кликнул на рекламу и зарегистрировался, то это для целей маркетинга так же хорошо, как и регистрация с первого раза


Вопросы отличные, А/В полиция одобряет 👮
#разбор@abpolice

Сегодняшний разбор очень технический. Постарались ответить коротко - для глубоких деталей нужно писать отделньую статью

Отрасль: AI 🤖
Кто прислал на разбор: DS / Аналитик
Сам кейс:
Как считать дисперсию и MDE ratio-метрики, когда мы уже перешли к линеаризованной. Как корректно интерпретировать?

Пояснение от A/B полиции: Ratio-метрика = метрика-дробь. Почти все метрики такие
- конверсия = число действий / число кликов
- средний чек = сумма чеков / число чеков (да, это тоже ratio-метрика!)

В целом, есть 2 стула 5 способов работать с такими метриками: Дельта-метод, Бустрап, Бакетный T-test, T-test над прокси метрикой пользователя и Линеаризация. Про детали и выбор между ними - отдельная история. Наш гражданин-аналитик использует линеаризацию:
metric_linearized = числитель - a * знаменатель

Дисперсию ratio-метрики можно считать через формулу из дельта-метода (см картинку к посту). Ну и MDE просто формулой mde из t-test, подставив в нее дисперсию. Считать прирост для бизнеса лучше в исходной ratio-метрике (а-ля CR выросла +2%), а его стат значимость - через линеаризацию. В целом, линеаризация - просто способ корректно считать p-value. Для всего остального она не нужна

Но если вы применяете линеаризацию + cuped, например, то тут уже интереснее! Честнее всего будет делать моделирование: добавляете +X% к среднему в 1000 фейковых А/В тестах, считаете для какого X красится в alpha% случаев. На практике можно аккуратно применять снижение дисперсии линеаризованной метрики благодаря cuped на y% к дисперсии ratio-метрики, посчитанную дельта-методом
Var(ratio + cuped) = Var(ratio) * (1-y%)

Это быстро, но не очень честно. Нужно быть крайне аккуратным и лучше бы все же провести моделирование на 1000+ фейковых экпериментах
Ваша @abpolice

Ловушка маленьких данных
Капитан АВ-полиции был в прошлом году во Вьетнаме, а сейчас ловит вьетнамские же флэшбеки про пятерочка-дни, которые все пытаются внедрить, когда данных для АВ мало

Отрасль: Монетизация мобильных приложений
Кто прислал: Аналитик
Сам кейс:
У нас основные тесты - разные варианты предложения подписки:
- Во время онбординга или позже
- Трайл на 7 или на 3 дня
- Стоимость самой подписки

Основная проблема - как добиться нормальной мощности?
Стагдартно тестим на 15% аудитории, бизнес хочет смотреть на ARPU и CR установка-подписка
Но для замера +- адекватных изменений этих метрик нужно запредельное количество наблюдений, которого у нас нет

Сейчас подоход странный: аграгируются данные на уровне пользователь-день (arpu) и применяют стат критерий. То есть от пользователя как датапоинта переходим к дате, что по-моему вообще странно

Сам вопрос: Как стоит поменять подход к АБ, чтобы завершать тест раньше?
Или смириться с тем, что такую разницу не увидеть и увеличивать mde?

Разбор:
Ну что ж, во-первых, применять стат тесты над наблюдением юзер-день нельзя, тк наблюдения зависимы. Юзер сегодня и завтра очевидно ведет себя крайне похоже. Нужно агрегировать данные до юзера. Эх, и правда многие вдохновились неверно понятой статьей про пятерочка-дни:)

Про ускорение А/В тестов у меня есть целое видео на ютубе: 13 способов ускорить А/В тест. В твоем кейсе нужно искать хорошую прокси-метрику оформления подписки. В видео- и социальных сервисах это может быть таймспент. В геймдеве дохождение до определенного уровня в игре и процент проигранных игр. Тут нужно будет постараться)

Искать такую прокси в идеале на истории результатов А/В тестов: находить такую прокси, которая красится в ту же сторону, что и конверсия/arpu, но более чувствительна. Если истории А/В нет, то можно пойти скользкой дорожкой регрессии на исторических данных
target = a1 * proxy + a2 * control_metric + ...

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

Ваша АВ-полиция 👮
#разбор@abpolice

Отдельная камера АВ-рецидивистов - ч.1

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

Джонни: раскатывал фичу до окончания А/В теста
Эксперименты - дотошная вещь. Надо держать по 2-3 недели на приличный % пользователей. Определить 1-2 целевых метрик, пару контрольных, да еще и барьерные метрики есть. Но зачем это все если можно запустить А/В, подержать 3-4 дня. Затем увидеть прокрас какой-то "важной" метрики в зеленый и просто выкатить фичу?

У Джонни под это даже были аргументы:
- Мы продуктовая компания и быстро проверяем гипотезы
- Не раскатанная в прод зеленая фича генерит недозарадботанных денег на миллионы в день
- Если что-то ухудшается значимо, то мы это и на общих графиках день-ко-дню для всей компании увидим
- Нужно быть гибкими, а не душнить вашей теорией А/В
- Внутри компании все пополльзовались фичей - она всем нравится
- И вообще сроки горят, СЕО просил выкатить фичу еще на прошлой неделе!

Но у товарища прокурора были более веские аргументы:
- Проблема подглядывания
Каждый день смотрим на метрики = не 1 эксперимент, а N экспов по числу дней подглядывания. Как известно, увидеть эффект где его нет можно в alpha (обычно 5%) случаев. Если эксп идет 21 день, то... мы почти наверняка найдем день, когда метрика красится в зеленый, хотя эффекта нет

- Проблемы будней-выходных
В будни и выходные приходит разная аудитория по сотаву и по количеству (в выхи обычно больше). Если тест красит метрики в будни, то это нельзя распространить на выходные. А в авыходные компания зарабатывает как правило очень много. Есть кейсы, когда в будни АВ зеленый, а в выходные - красный

- Сбитый график запусков
Если тест можно закончить хоть во вторник, хоть в пятницу, то угадайте что? Правильно, через неделю половина выкаток фичи на 100% пользователей будет по пятницам

- Ломаем другие экмперименты
Не у всех отлажена система непересекающихся АВ. Если мы включаем/выглючаем тесты хаотчино, то очень легко упустить пересечение взаимовлияющих экспов. А если оно есть, то результаты всех таких экспов (а не экспов одного менеджера, аналитика, который хаотично жмет вкл/выкл) превращаются в рандом

Как думаете, кто еще сидит в камере АВ-рецидивистов? 🔐
#рецидивисты@abpolice

5 стульев Ratio метрик
Осторожно, технопост!

После разбора про ratio метрики (= метрики-дроби) несколько человек спросили, какой же из 5 способов работы с ними лучше выбрать?
От А/В тестирования мы хотим глобально 3 вещи:
- Статитстическая корректность (Имеем реальных ошибок 1 и 2 рода не больше alpha и 1-мощность)
- Можно крутить много тестов параллельно по 1-2 недели, а не по 100 лет
- Легко и быстро считается аналитика АВ. Желательно еще и информационные метрики по срезам (платформы, типы пользователей, ...)
Как ни крути, все эти 3 условия соблюдаются только в таком сетапе

Если у компании >100К пользователей
Обычно это крупные продуктовые компании (Авито, Яндекс, Netflix, ...)
Тут выгоднее применять бакетный Т-тест. Кстати, это можно считать облегченной версией бутстрапа

Проблем с длительностью теста тут особо нет, потому что пользователей много = ускорять через условный cuped не обязательно
А вот проблемы со временем подсчета по каждому пользователю - еще как есть, если таких пользователей миллоны. Поэтому выгоднее обьединить пользователей в 10К бакетов (групп). Считать среднее внутри каждой группы, строить их распределение. И потом проводить обычный Т-тест над таким распределением. Это помогает:
- Экономить ресурсы на подсчет АВ
- Считать практически любые метрики внутри бакета

Если у компании <100K пользователей
Обычно это небольшие компании или оффлайн бизнесы. Часто тут наблюдение - это даже не пользователь, а курьер, магазин, географическая зона или B2B клиент

Тут главная проблема - как проводить много А/В тестов за приемлемое время. Поэтому очень важно ускорение тестов через CUPED, CUPAC или линейную регрессию. Единственный способ ускорять тесты и все еще иметь статистическую корректность - это комбинация: Линеаризация + CUPED / Линейная регрессия

При этом дельта-метод все еще полезен для расчета дисперсии исходной ratio-метрики, но скорее как вспомогательный инструмент, а не основной
Дополнительный бонус этого подхода - вы получаете промежуточный датасет статистик на уровне пользователь-день (потом он саггрегигруется до пользователя!). Его можно переиспользовать для обычных дэшбордов, ML-моделей и много где еще.

Можно ли попробовать другие варианты? Можно, успешные подходы есть. Но шансов накосячить в этих вариантов кратно больше. А/В полиция рекомендует вам выбрать более простой и быстрый путь - следовать советом выше 👮

Нас уже больше 500 человек: пора получше узнать, кто же подписался на канал)
Это поможет лучше составлять идеи для постов и баланс бизнес/технический постов

А оно все еще работает?

Знаете ту ситуацию, когда был запуск громкой маркетинговой скидки: она в начале несла кучу денег, а сейчас кажется, что скорее несет кучу фрода? Или когда ты полгода-год назад сделал классную фичу и очень ею гордишься. Но начали приходить тревожные звоночки, что сейчас она уже не комильфо?

Вот и А/В полиция тоже знает) Это классические проблемы "эффект новизны" и "долгосрочных эффектов"
Чтобы их замерять давно придумали 3 механики

1. Обратные (ухудщающие) эксперименты
Берем фичи в продакшене и отключаем ее в А/В. Через полгода-год даже очень крута фича может перестать жечь. Я видел даже пару кейсов, когда крутая фича в прошлом через какое-то время начинала ронять метрики 📈

Осторожно: применение в вашей компании может нанести непоправимую боль вам пользу компании

2. Долгосрочные эксперименты
Запускаем обычный эксперимент на 1-2 недели на условно 20% пользовтелей. По окончанию экспа видим, что он зеленый - раскатываем на всех. Но для проверки долгосрочных метрик (retention, вымывание эфффекта из АВ) оставляем 3-4% все еще без фичи и ждем уже 1-2-3 месяца

Небольшой лайфхак: можно в эти 3-4% взять тех юзеров, которые уже были в контроле обычного эксперимента: сэкономите себе 1-2 недели
Особенно актуально в тестах, где есть долгосрочные негативные эффекты: повышение цен, принудительный баннер/соглашение и тд

3. Вечный контроль
Предельный случай долгосрочного эксперимента. Особо популярен в маркетинговых тестах: оставляем 3-5% пользователей, которым вообще не шлем никакие пуши и скидки. Замеряем долгосрочно эффект всех маркетинговых механик на них - часто прилично отрезвляет

В продукте вижу такое редко, хотя зря: тоже полезно знать, дают ли что-то эти великолепные 50 фич через полгода или нет

А у вас в компании есть вечный контроль?)

Т-тест VS Манн-Уитни

Холивар эпохи во многих компаниях и сообществах) Лично я стою на стороне добра t-test. Для начала..

Чем плох тест Манна-Уитни?
Многие думают, что это критерий про равенство средних, но на самом деле это ранговый критерий про изменение распределения
H0: f_a = f_b
H1: f_a != f_b

В качестве частного (!) упрощения можно считать, что это критерий про сдвиг распределения
f_a = f(x)
f_b = f(x + dx)
H0: dx = 0
H1: dx != 0

И отсюда вытекает куча проблем

1. Теряется связь AB с финансами компании
Обычно мы подразумеваем что-то вроде
E(выручка) = E(траффик в приложении) * E(СR app start-заказ) * E(средний чек)

Ну и если мы АВ-тестом растим E(средний чек), а остальные множители серые, то мы автоматом влияем на выручку. Но зеленый прокрас по Манна-Уитни ничего не говорит про рост того самого E(средний чек) => ничего не говорит о росте E(выручка). А зачем тогда нужен АВ-тест, если мы не можем сказать в итоге, стали ли больше зарабатывать благодаря фиче?

2. Не работает с дублями значений метрики
Ну точнее формально во многих либах работает, но неправильно:) Критерий ранговый, а проставить ранг серии из одинаковых значений (например 10К нулей) корректно нельзя. Поэтому с метриками вроде конверсии и ARPU (много нулей), стоимость доставки и средняя позиция кликнутого товара (в принципене много частотных значений) и многими другими критерий просто не применим

3. Слишком устойчив к выбросам
Нередко 1% самых активых пользователей могут давать даже 20% выручки компании. Новой фичей мы могли вырастить у этих пользователей средний чек пусть на 2%. Это на минуточку +2% * 0,2 = 0.4% выручки компании. Для гигантов индустрии это могут быть дополнительные сотни миллионов рублей. При этом ранги значений метрики из-за этого могли вообще не поменяться: по тесту Манна-Уитни изменение серое

4. Не дружит с методами ускорения АВ
По сути, почти все методы ускорения АВ-тестов - это частный случай линейной регрессии. А она, как известно, не работает с рангами
Есть конечно ordinal regression, которую можно попытаться применить, но никаких статистических гарантий корректности уже не будет + есть очень много подводных камней

5. Непросто считать необходимое число наблюдений для теста и MDE
Да, формулы тут нет. Придется моделировать: задача решаемая, но сильно сложнее, чем подставить пару чисел в готовую формулу

Всех этих минусов в самом обычном Т-тесте нет! У него есть и свои доп плюсы, но о них в следующий раз
Если интересно более длинный лонгрид, то у Авито есть достойная статья про минусы Манна-Уитни
Так что не усложняте, и пользуйтесь Т-тестом - это просто, корректно, ну и математически красиво 🧐

P.S. Для особо внимательных: Какая классическая ошибка в интерепретации теста Манна-Уитни изображена на картинке к посту? Взял ее на первой же странице гугла по запросу "Mann-Whitney"

Разбор №8. А/В тесты в логистике дарксторов

Эх, мои любимые тесты со времен работы в доставке еды 🙂

Отрасль: Доставка продуктов из дарксторов
Кто прислал на разбор: Аналитик
Сам кейс:
Проводим А/В тесты на метрики Click-to-Eat или процент опозданий на уровне дарксторов. Но их мало и они сильно отличаются друг от друга. Сложно разбивать на тест и контроль: АА тесты могут сходиться на одном периоде и расходиться на другом

Сейчас разбиваем на группы исходя из сходства распределений разбитых на бины во время предпериода. А статистическаю значимость оцениваем через бутстрап-критерий или серию t-тестов. Есть ли более надежные методы проведения А/В в таких случаях?

Ответ
Круто, что в целом задумались про честное разбиение на группы в таком кейсе! И правда, когда у вас 100, 300 или даже 1000 наблюдений (сильно разных дарксторов), то просто случайно побить на контроль и тест часто не работает. И я знаю 2 пути решения этой проблемы

Первый путь - который выбрали вы. Можно еще сверху добавить фильтрацию дарксторов-выбросов: 1-2 экстра-крупные, 2-3 не работали за период теста какое-то время и тд. Тоже сильно помогает!) Ну и еще CUPED, CUPAC, линейные регрессии тоже выручают: они не только снижают дисперсию, но могут помочь контролировать вншние факторы: то, что в тесте условно больше огромных дарксторов

🏃‍♂️Второй путь - switch-back тесты. Судя по вашим целевым метрикам, у вас тесты в логистике курьеров. Можно раз в 2 часа случайно переразбивать дарксторы на тест и контроль. Тогда у вас будут сырые данные в виде
Даркстор | Тестовая группа | Аггрегированное значение метрики

Огромный плюс в том, что все дарксторы попадают и в тест, и в контроль - благодаря этому выборки становятся более сбалансированными
Огромный минус - организационный. Придется подстроить многие процессы компании и технологии под такой вид сплитования. Но если получится, то оно того стоит! Когда-то в Delivery Club мы прошли этот сложный путь и написали статью на хабр. Надеюсь, она как раз поможет в вашем кейсе
Есть еще классная чуть более техническая статья от основоположников таких тестов в продакшене - doordash, тоже моя рекомендация почитать

А еще напомним, что вы можете прислать свой кейс на бесплатный разбор, просто заполнив гугл-форму 😇

А/В тесты и ревью

Наступает пора лентих ревью - все подводят итоги полугодия. И как правило, команда bottom-up суммирует приросты метрики во всех своих успешных А/В - таким образом получает суммарных эффект своих внедрений. Спешу вас расстроить: этот эффект сильно завышен. На это есть 3 причины:
- Вероятность ошибок alpha "суммируются" в серии экспериментов: часть экспов из серии не несет эффекта
- Периодически эксперимента "перезатируют" друг друга
- Эффекты новизны со временем вымываются

Честно оценить эффект от серии экспериментов можно через глобальный контроль: оставляем 5% юзеров, на которых не катим вообще никакие изменения полгода. Сравниваем метрики со всеми изменениями vs без них (глобальный контроль). Но у этого подхода есть пара минусов:
- Полгода на 5% пользователей мы не получаем прироста метрик = прямая потеря денег
- Подход комбинаторно взрывается, когда нужно оценить суммарный эффект экспериментов всей компании, нескольких департаментов и отдельных команд. На каждый такой срез глобальных (и не очень) контролей не напасешься

Поэтому придумали более дешевые способы оценивать эффективность серии экспериментов: сегодня речь про один из них:)
Ребята из AirBnB вывели формулу для корректировки суммарного эффекта (оставлю ее в комментариях), а разобрали этот вывод довольно хорошо в этой статье.

Формула корректирует вклад от "пограничных" экспов, где p-value близка к 5% (условно 4.7%). А таких на практике немало: где-то менеджер подглядывал в эксп до окончания и остановил в удобный момент. В других случаях выбрали удобную прокрашенную метрику/срез. В общем, если посчитать скорректированный эффект от серии экспов, то он может оказаться и в 2-3 раза меньше, чем просто сумма эффектов отдельных А/В

Если вы руководитель высокого уровня или относитесь к команде АВ, то призываю внимательно посмотреть на этот метод - и честно оценивать итоги полугодия 🏆

Вашему вниманию — а/б тестирование в реальной жизни

Как покрасить главную метрику?

В каждом бизнесе есть самая главная метрика - EBITDA, GMV, кол-во кастомеров, кол-во подписчиков, timespent и тп
Проблема в том, что в обычных небольших экспериментах прокрасить ее почти невозможно. В итоге получается, что команды как будто год работали, но не могут показать свое влияние на основную метрику. Давайте это исправлять

1. В АВ красить основную метрику в срезе Х -> Пересчитать в интегральное влияние
Команда может развивать новую программу лояльности, в которой пока участвуют 5% клиентов. Можно улучшать программу и основную метрику в срезе этих 5% пользователей. Потом такой прирост отнормировать (+X * 0.05) до интеграла - вот вам и влияние на условный GMV

2. Разложить основную метрику на компоненты
GMV = Трафик * CR заход в приложение-заказ * Средний чек

Можно в АВ красить более чувствительную компоненту (допустим, CR). Если при этом остальные стат значимо не падают, а GMV в сером плюсе - можно аккуратно пересчитать рост CR в рост GMV

3. Найти прокси-метрику и ее размен на основную метрику
Это путь самурая. Но часто единственно возможный. Условный timespent сложно разложить на компоненты или на срезы
Тут важно найти причинно-следуственную связь, а не корреляцию + все же посчитать размен прокси-основная метрика

Всем прокрасов основных метрик вашей компании 😊