Как бесплатно посчитать MDE
Представьте, что вас забыли пригласить на встречу по дизайну A/B-теста. Длительность никто не посчитал, но через две недели после начала эксперимента продакт спрашивает, достаточно ли трафика набрано. Чтобы ответить на этот вопрос, вам нужно посчитать MDE с учетом текущих размера выборки и дисперсии и затем сравнить его с порогом практической значимости. Выгружать данные, чтобы посчитать дисперсию, довольно муторно, по крайней мере для неконверсионных метрик. Но, к счастью, у вас есть A/B-платформа, которая показывает вам 2% +- 1.5%.
Возьмем 1.5, умножим на 1.43, получим MDE.
ПОЧЕМУ?
MDE – это эффект, который при многократном повторении эксперимента мы зафиксируем с вероятностью, равной выбранной мощности. При использовании H0: mu_t = mu_c такой эффект будет лежать на расстоянии z_(1-alpha/2) + z_(1-beta) стандартных ошибок от 0. Это буквально видно из формулы MDE (см. скрин). Графически тоже видно (см. второй скрин):
◆ Расстояние от 0 до критического значения (CV) – z_(1-a/2) * SE
◆ Расстояние от CV до MDE – z_(1-b) * SE
При стандартных параметрах alpha = 0.05 и beta = 0.2 первый отрезок будет равен 1.96 * SE. Второй – 0.84 * SE. В сумме – 2.8 * SE. В то же время, половина ширины доверительного интервала, который посчитала A/B-платформа, 1.5%, – это те же самые 1.96 * SE. А значит, нам нужно поделить 1.5 на 1.96 и умножить на 2.8. Ну или просто сразу умножить на 1.43, как я писал выше.
Обратите внимание, что я привел формулу, где SE считается для обычной разности средних, но в примере использовал процентный лифт. Для моего лайфхака не важно в каком виде у вас представлен эффект и ДИ, если SE посчитана верно.
И еще. Фактические дисперсия и размер выборки могут отличаться от ваших оценок, полученных на стадии дизайна эксперимента. Поэтому проделать описанное упражнение будет полезно не только в кейсе с забывчивым продактом.
Представьте, что вас забыли пригласить на встречу по дизайну A/B-теста. Длительность никто не посчитал, но через две недели после начала эксперимента продакт спрашивает, достаточно ли трафика набрано. Чтобы ответить на этот вопрос, вам нужно посчитать MDE с учетом текущих размера выборки и дисперсии и затем сравнить его с порогом практической значимости. Выгружать данные, чтобы посчитать дисперсию, довольно муторно, по крайней мере для неконверсионных метрик. Но, к счастью, у вас есть A/B-платформа, которая показывает вам 2% +- 1.5%.
ПОЧЕМУ?
MDE – это эффект, который при многократном повторении эксперимента мы зафиксируем с вероятностью, равной выбранной мощности. При использовании H0: mu_t = mu_c такой эффект будет лежать на расстоянии z_(1-alpha/2) + z_(1-beta) стандартных ошибок от 0. Это буквально видно из формулы MDE (см. скрин). Графически тоже видно (см. второй скрин):
◆ Расстояние от 0 до критического значения (CV) – z_(1-a/2) * SE
◆ Расстояние от CV до MDE – z_(1-b) * SE
При стандартных параметрах alpha = 0.05 и beta = 0.2 первый отрезок будет равен 1.96 * SE. Второй – 0.84 * SE. В сумме – 2.8 * SE. В то же время, половина ширины доверительного интервала, который посчитала A/B-платформа, 1.5%, – это те же самые 1.96 * SE. А значит, нам нужно поделить 1.5 на 1.96 и умножить на 2.8. Ну или просто сразу умножить на 1.43, как я писал выше.
Обратите внимание, что я привел формулу, где SE считается для обычной разности средних, но в примере использовал процентный лифт. Для моего лайфхака не важно в каком виде у вас представлен эффект и ДИ, если SE посчитана верно.
И еще. Фактические дисперсия и размер выборки могут отличаться от ваших оценок, полученных на стадии дизайна эксперимента. Поэтому проделать описанное упражнение будет полезно не только в кейсе с забывчивым продактом.
👾15
Кейс с собеседования на аналитика в Циан
Недавно друг собесился в Циан. Рассказывал, что дали такую задачу:
Написал на эту тему статью
Недавно друг собесился в Циан. Рассказывал, что дали такую задачу:
В Питере 68% респондентов ответили, что знают Циан, а в Москве – 65%. Следует ли из этого, что в Питере лучше знают Циан чем в Москве?
Написал на эту тему статью
Telegraph
Кейс с собеседования на аналитика в Циан
Недавно друг собесился в Циан. Рассказывал, что дали такую задачу:
👾16
Как случайно не обнулить мощность в A/B-тесте
Я когда провожу собесы, периодически спрашиваю у аналитиков, что такое MDE. В подавляющем большинстве случаев получаю следующий ответ:
Ну, допустим. Давайте рассмотрим такой сеттинг:
◆ Целевое значение MDE = 3%
◆ Длительность теста при целевом MDE = 2 недели
◆ Истинный эффект от фичи (мы его не знаем) = 2%
А теперь 4 простых суждения:
1) 2 < 3
2) Всё, что меньше 3, мы обнаружить не можем
3) Мы не сможем обнаружить истинный эффект, если продержим тест 2 недели
4) Мощность теста равна 0
Кайфово задизайнили
На самом деле мощность такого теста, конечно же, нулю не равна. Всё дело в интерпретации MDE. Верное определение будет таким:
В формуле размера выборки есть 3 параметра, которые также присутствуют в формуле z-теста:
◆ z_(1 - α/2)
◆ Var
◆ n
Изменение этих параметров физически влияет на ширину ДИ и размер z-статистики. Они являются характеристиками вашего стат. теста. Они же задают кривую зависимости мощности от размера эффекта (см. скрин в комментах). Так как эта кривая определяется только перечисленными параметрами, её тоже можно рассматривать как характеристику стат. теста.
Изменяя длительность эксперимента, мы сдвигаем кривую таким образом, чтобы нашему целевому MDE на оси x соответствовала мощность 80% на оси y. В реальности мы, как правило, не думаем обо всей кривой, а лишь об этой точке на ней – (целевое MDE, 80%). Из-за этого, а также из-за неудачного нейминга MDE, появляется желание сделать вывод, что эффекты, меньшие чем MDE, мы обнаружить не сможем. Но если построить график такой кривой, становится очевидно, что это не так.
Мы можем обнаружить эффект любого размера.
Это вопрос вероятности. Если истинный эффект будет очень большим, мощность будет близка к 100%. Если истинный эффект будет очень маленьким, мощность будет близка к 5%. Кстати, на моем графике кривые мощности асимптотически приближаются к 2.5%, а не к 5%. Почему так – расскажу в другом посте.
И напоследок хочу обратить внимание еще на одно утверждение, которое часто слышу:
Это не так. Размер истинного эффекта следует оценивать исходя из границ ДИ. MDE тут не при чём. Мы можем словить ошибку 2 рода (= не обнаружить эффект) как при эффекте, меньшем чем MDE, так и большем. Это опять же вопрос вероятности.
Я когда провожу собесы, периодически спрашиваю у аналитиков, что такое MDE. В подавляющем большинстве случаев получаю следующий ответ:
MDE – это минимальный эффект, который мы можем обнаружить в эксперименте
Ну, допустим. Давайте рассмотрим такой сеттинг:
◆ Целевое значение MDE = 3%
◆ Длительность теста при целевом MDE = 2 недели
◆ Истинный эффект от фичи (мы его не знаем) = 2%
А теперь 4 простых суждения:
1) 2 < 3
2) Всё, что меньше 3, мы обнаружить не можем
3) Мы не сможем обнаружить истинный эффект, если продержим тест 2 недели
4) Мощность теста равна 0
На самом деле мощность такого теста, конечно же, нулю не равна. Всё дело в интерпретации MDE. Верное определение будет таким:
MDE – это эффект, который мы можем обнаружить с заданной вероятностью при использовании статистического теста с выбранным уровнем значимости
В формуле размера выборки есть 3 параметра, которые также присутствуют в формуле z-теста:
◆ z_(1 - α/2)
◆ Var
◆ n
Изменение этих параметров физически влияет на ширину ДИ и размер z-статистики. Они являются характеристиками вашего стат. теста. Они же задают кривую зависимости мощности от размера эффекта (см. скрин в комментах). Так как эта кривая определяется только перечисленными параметрами, её тоже можно рассматривать как характеристику стат. теста.
Изменяя длительность эксперимента, мы сдвигаем кривую таким образом, чтобы нашему целевому MDE на оси x соответствовала мощность 80% на оси y. В реальности мы, как правило, не думаем обо всей кривой, а лишь об этой точке на ней – (целевое MDE, 80%). Из-за этого, а также из-за неудачного нейминга MDE, появляется желание сделать вывод, что эффекты, меньшие чем MDE, мы обнаружить не сможем. Но если построить график такой кривой, становится очевидно, что это не так.
Мы можем обнаружить эффект любого размера.
Это вопрос вероятности. Если истинный эффект будет очень большим, мощность будет близка к 100%. Если истинный эффект будет очень маленьким, мощность будет близка к 5%. Кстати, на моем графике кривые мощности асимптотически приближаются к 2.5%, а не к 5%. Почему так – расскажу в другом посте.
И напоследок хочу обратить внимание еще на одно утверждение, которое часто слышу:
Если мы получили серый результат, из этого следует, что если эффект и есть, то он точно меньше MDE
Это не так. Размер истинного эффекта следует оценивать исходя из границ ДИ. MDE тут не при чём. Мы можем словить ошибку 2 рода (= не обнаружить эффект) как при эффекте, меньшем чем MDE, так и большем. Это опять же вопрос вероятности.
👾20
Когда статистические тесты не вывозят
Мы привыкли, что растить мощность – это благо. Ведь высокая мощность теста позволяет нам фиксировать даже небольшие эффекты с достаточной вероятностью. Есть проблема. Представьте, что в попытках увеличить чувствительность теста у вас получилось набрать невероятно (~бесконечно) большую выборку без сопуствтующего роста дисперсии. При невероятно большой выборке ширина доверительного интервала будет близка к 0.
В таком сеттинге мы будем получать статистически значимые результаты почти всегда. Однако статистически значимый ≠ большой. Статистически значимый – это такой, который мы смогли разглядеть (отличить от 0) при том уровне шума, который есть в данных.
Мы можем получить разность средних, равную 10^-5, и увидеть, что она стат. значима. Мы можем посмотреть на бесконечно маленький доверительный интервал вокруг неё и понять, что истинный эффект лежит где-то очень близко к наблюдаемой разности средних. Это всё ожидаемое поведение. При невероятно большой выборке разброс наблюдаемых эффектов вокруг истинного будет крошечным. Выборки будут хорошо апроксимировать ГС, а разность средних по выборкам будет хорошо аппроксимировать истинный эффект.
Но что нам делать c таким экспериментом? Результат стат. значимый, но, исходя из здравого смысла, мы понимаем, что он ничтожен. В случае A/B-тестирования на помощь приходит порог практической значимости. Нам достаточно посмотреть на расположение ДИ относительно этого порога и принять решение о раскатке фичи. Я когда-то писал об этом статью. Если кратко, то мы катим фичу, когда ДИ лежит правее порога. В случае с бесконечно маленьким ДИ процесс сильно упрощается, т.к. мы почти не можем оказаться в спорной ситуации, когда 0 не попадает в ДИ, а порог практической значимости попадает. Добавлю еще, что есть чуть более отрефлексированные подходы к внедрению в процесс принятия решения проверки на практическую значимость. Когда-нибудь об этом тоже напишу.
Ну вроде всё круто – проблему решили, и, более того, при учете порога практической значимости высокая мощность теста опять же сильно упрощает жизнь. Это так. Но, к сожалению, есть тесты, в которых такой порог ввести не получится.
Возьмите, например, тесты на нормальность распределения (критерии Колмогорова-Смирнова, Андерсона-Дарлинга и т.д.). В этих тестах мы не используем разность средних, а смотрим на менее интуитивные величины. Сказать, что является большим отклонением с точки зрения здравого смысла/бизнеса для sup(F_n(x) - F(x)) довольно сложно. И нам не нужно воображать ситуацию с невероятно большой выборкой, чтобы получить тест, который на каждое колебание отвергает H_0. Это случается при просто больших выборках. Классические комментарии под постами про эти критерии в линкедине это "Если размер выборки очень большой, то полезнее смотреть на QQ плот". По сути, это попытка найти хоть какую-то замену порогу практической значимости, чтобы внедрить здравый смысл в слепую статистическую процедуру.
Еще одна ситуация, когда мощность теста вызывает похожую проблему, – это проверка на SRM. При большом количестве пользователей в эксперименте хи-квадрат критерий становится слишком чувствительным. Из-за этого при любом, хоть сколько-нибудь малом, отклонении реального соотношения между группами от заданного мы начинаем ловить алерты. Что есть сильное отклонение с точки зрения здравого смысла – я хз. Обычно эту проблему в A/B-платформах решают путем уменьшения уровня значимости. Например, Growthbook вместо 0.05 использует 0.001 для определения стат. значимых отклонений при проверке на SRM.
Я когда думаю об этом всём, становлюсь статистическим диссидентом. Кажется, что любой критерий, для которого мы не можем построить удобно интерпретируемый и интуитивно понятный доверительный интервал, – просто бесполезный кусок говна
Мы привыкли, что растить мощность – это благо. Ведь высокая мощность теста позволяет нам фиксировать даже небольшие эффекты с достаточной вероятностью. Есть проблема. Представьте, что в попытках увеличить чувствительность теста у вас получилось набрать невероятно (~бесконечно) большую выборку без сопуствтующего роста дисперсии. При невероятно большой выборке ширина доверительного интервала будет близка к 0.
В таком сеттинге мы будем получать статистически значимые результаты почти всегда. Однако статистически значимый ≠ большой. Статистически значимый – это такой, который мы смогли разглядеть (отличить от 0) при том уровне шума, который есть в данных.
Мы можем получить разность средних, равную 10^-5, и увидеть, что она стат. значима. Мы можем посмотреть на бесконечно маленький доверительный интервал вокруг неё и понять, что истинный эффект лежит где-то очень близко к наблюдаемой разности средних. Это всё ожидаемое поведение. При невероятно большой выборке разброс наблюдаемых эффектов вокруг истинного будет крошечным. Выборки будут хорошо апроксимировать ГС, а разность средних по выборкам будет хорошо аппроксимировать истинный эффект.
Но что нам делать c таким экспериментом? Результат стат. значимый, но, исходя из здравого смысла, мы понимаем, что он ничтожен. В случае A/B-тестирования на помощь приходит порог практической значимости. Нам достаточно посмотреть на расположение ДИ относительно этого порога и принять решение о раскатке фичи. Я когда-то писал об этом статью. Если кратко, то мы катим фичу, когда ДИ лежит правее порога. В случае с бесконечно маленьким ДИ процесс сильно упрощается, т.к. мы почти не можем оказаться в спорной ситуации, когда 0 не попадает в ДИ, а порог практической значимости попадает. Добавлю еще, что есть чуть более отрефлексированные подходы к внедрению в процесс принятия решения проверки на практическую значимость. Когда-нибудь об этом тоже напишу.
Ну вроде всё круто – проблему решили, и, более того, при учете порога практической значимости высокая мощность теста опять же сильно упрощает жизнь. Это так. Но, к сожалению, есть тесты, в которых такой порог ввести не получится.
Возьмите, например, тесты на нормальность распределения (критерии Колмогорова-Смирнова, Андерсона-Дарлинга и т.д.). В этих тестах мы не используем разность средних, а смотрим на менее интуитивные величины. Сказать, что является большим отклонением с точки зрения здравого смысла/бизнеса для sup(F_n(x) - F(x)) довольно сложно. И нам не нужно воображать ситуацию с невероятно большой выборкой, чтобы получить тест, который на каждое колебание отвергает H_0. Это случается при просто больших выборках. Классические комментарии под постами про эти критерии в линкедине это "Если размер выборки очень большой, то полезнее смотреть на QQ плот". По сути, это попытка найти хоть какую-то замену порогу практической значимости, чтобы внедрить здравый смысл в слепую статистическую процедуру.
Еще одна ситуация, когда мощность теста вызывает похожую проблему, – это проверка на SRM. При большом количестве пользователей в эксперименте хи-квадрат критерий становится слишком чувствительным. Из-за этого при любом, хоть сколько-нибудь малом, отклонении реального соотношения между группами от заданного мы начинаем ловить алерты. Что есть сильное отклонение с точки зрения здравого смысла – я хз. Обычно эту проблему в A/B-платформах решают путем уменьшения уровня значимости. Например, Growthbook вместо 0.05 использует 0.001 для определения стат. значимых отклонений при проверке на SRM.
Я когда думаю об этом всём, становлюсь статистическим диссидентом. Кажется, что любой критерий, для которого мы не можем построить удобно интерпретируемый и интуитивно понятный доверительный интервал, – просто бесполезный кусок говна
👾16
Как устроены вендорские A/B-платформы
У меня на канале уже больше 300 подписчиков, но он почему-то всё равно не появляется в списке похожих каналов при подписке на другие каналы по аналитике. А вот канал Алины фоточки, у которого 188 подписчиков, появляется.
Можете, пожалуйста, поподписываться на другие аналитические каналы, чтобы было больше пересечений. Ну или хотя бы на Алины фоточки подпишитесь я хз..
И да, написал статью про устройство A/B-платформ на примере GrowthBook
У меня на канале уже больше 300 подписчиков, но он почему-то всё равно не появляется в списке похожих каналов при подписке на другие каналы по аналитике. А вот канал Алины фоточки, у которого 188 подписчиков, появляется.
Можете, пожалуйста, поподписываться на другие аналитические каналы, чтобы было больше пересечений. Ну или хотя бы на Алины фоточки подпишитесь я хз..
И да, написал статью про устройство A/B-платформ на примере GrowthBook
Telegraph
Как устроен GrowthBook
В последние месяцы на рынке вендорских A/B-платформ произошло несколько крупных событий – Statsig поднял 100 млн инвестиций, Datadog поглотил Eppo, а Авито – Sigma от EXPF. В свете этого предлагаю разобраться в том, как устроены эти самые вендорские платформы…
👾19
Про гибкость A/B-платформ
Я в статье про GrowthBook рассказал, что для заведения метрики нужно прописать кусок SQL-запроса, фактовую таблицу, и навесить на него конфиги метрики: столбец со значениями, агрегирующую функцию и фильтры. И после этого GB как конструктор соберет итоговый скрипт для расчета – поджойнит фактовую таблицу на таблицу с участниками эксперимента и сагрегирует данные.
Первый раз с такой идеей я столкнулся, когда пришел работать над A/B-платформой в Профи. Помню, был сильно впечатлен – любой аналитик может за минуту добавить в платформу (почти) какую-угодно метрику.
GB в этом плане идет дальше и дает гибкость буквально во всём. При заведении эксперимента можно собрать кастомный флоу из правил в фиче флаге. При расчете длительности можно оценить трафик тремя разными способами. При анализе результатов можно навесить сегменты, кастомные фильтры, разрезы, выбрать байесовский или частотный движок, добавить последовательное тестирование.
Но часто гибкость A/B-платформы может сыграть против вас. Одна из ключевых задач платформы – унифицировать подход к дизайну и анализу экспериментов. Если у компании нет платформы, то, скорее всего, в разных командах результаты тестов будут считать по-разному. Даже если есть общая тетрадка в репозитории. И это убивает саму идею тестирования.
Если платформа слишком гибкая и эта гибкость доступна всем, то ситуация будет не сильно лучше. Взять те же метрики: когда любой аналитик или продакт может завести метрику, раздел с ними очень быстро превращается в помойку. Хорошо, если метрики из этой помойки используются только как secondary или только для пост-анализа. Плохо, если – как целевые или охранные.
Например, в продукте есть атрибуция. На странице товара – две полки рекомендаций. Меняем алгоритм в верхней и смотрим на ARPU с этой полки. Решаем учесть каннибализацию нижней полки, поэтому добавляем в охранные ARPU с нижней полки. Видим, что верхняя полка стала перформить лучше. И, более того, нижняя тоже стала перформить лучше – никакой каннибализации!
А потом смотрим на то, как считается метрика ARPU с полки, которая когда-то кем-то без какого-либо ревью была добавлена в платформу:
То есть это ratio-метрика. В такие моменты нужно сразу насторожиться и подумать: а с какой стати я вообще использую ratio-метрику?
Помните великую статью от vk про подходы к анализу CTR? Они переходят от кликов на пользователя к CTR вот с таким ассампшеном:
Знаменатель ratio-метрики не должен быть подвержен влиянию тритмента. С верхней полкой это действительно так. А что с нижней? Верхняя стала перформить так хорошо, что до нижней стало доходить существенно меньше пользователей – только самые жесткие шопоголики. Они в среднем тратят больше, чем другие группы пользователей. Вот мы и видим прирост в нашей (неподходящей) ratio-ARPU с нижней полки. Только это не означает, что нижняя полка после внедрения фичи приносит больше денег.
И это уже не ratio, а обычная поюзерная метрика. Она то нам и нужна, так как учитывает и конверсию в полку, и выручку с долиставших до нее.
Я это все к чему. Если в компании никто не следит за методологией A/B-тестирования (в широком смысле), то гибкость платформы становится её недостатком. Хорошее решение проблемы, на мой взгляд, – собрать группу людей, у которых есть время на подумать над методологией. И гибкость должна быть доступна только им – по крайней мере в вопросах, касающихся дизайна экспериментов и принятия решения по ним. Пусть они раздают галочки для метрик, чтобы те можно было использовать как целевые, проверяют нестандартную настройку фиче флагов, возможность использования сегментов и т.д.
А остальным хуй
Я в статье про GrowthBook рассказал, что для заведения метрики нужно прописать кусок SQL-запроса, фактовую таблицу, и навесить на него конфиги метрики: столбец со значениями, агрегирующую функцию и фильтры. И после этого GB как конструктор соберет итоговый скрипт для расчета – поджойнит фактовую таблицу на таблицу с участниками эксперимента и сагрегирует данные.
Первый раз с такой идеей я столкнулся, когда пришел работать над A/B-платформой в Профи. Помню, был сильно впечатлен – любой аналитик может за минуту добавить в платформу (почти) какую-угодно метрику.
GB в этом плане идет дальше и дает гибкость буквально во всём. При заведении эксперимента можно собрать кастомный флоу из правил в фиче флаге. При расчете длительности можно оценить трафик тремя разными способами. При анализе результатов можно навесить сегменты, кастомные фильтры, разрезы, выбрать байесовский или частотный движок, добавить последовательное тестирование.
Но часто гибкость A/B-платформы может сыграть против вас. Одна из ключевых задач платформы – унифицировать подход к дизайну и анализу экспериментов. Если у компании нет платформы, то, скорее всего, в разных командах результаты тестов будут считать по-разному. Даже если есть общая тетрадка в репозитории. И это убивает саму идею тестирования.
Если платформа слишком гибкая и эта гибкость доступна всем, то ситуация будет не сильно лучше. Взять те же метрики: когда любой аналитик или продакт может завести метрику, раздел с ними очень быстро превращается в помойку. Хорошо, если метрики из этой помойки используются только как secondary или только для пост-анализа. Плохо, если – как целевые или охранные.
Например, в продукте есть атрибуция. На странице товара – две полки рекомендаций. Меняем алгоритм в верхней и смотрим на ARPU с этой полки. Решаем учесть каннибализацию нижней полки, поэтому добавляем в охранные ARPU с нижней полки. Видим, что верхняя полка стала перформить лучше. И, более того, нижняя тоже стала перформить лучше – никакой каннибализации!
А потом смотрим на то, как считается метрика ARPU с полки, которая когда-то кем-то без какого-либо ревью была добавлена в платформу:
ARPU с полки = Выручка с полки / количество пользователей, увидевших полку
То есть это ratio-метрика. В такие моменты нужно сразу насторожиться и подумать: а с какой стати я вообще использую ratio-метрику?
Помните великую статью от vk про подходы к анализу CTR? Они переходят от кликов на пользователя к CTR вот с таким ассампшеном:
The directionality of the global CTR is the same as the directionality of the sum of clicks if we don’t change views in our experiment.
Знаменатель ratio-метрики не должен быть подвержен влиянию тритмента. С верхней полкой это действительно так. А что с нижней? Верхняя стала перформить так хорошо, что до нижней стало доходить существенно меньше пользователей – только самые жесткие шопоголики. Они в среднем тратят больше, чем другие группы пользователей. Вот мы и видим прирост в нашей (неподходящей) ratio-ARPU с нижней полки. Только это не означает, что нижняя полка после внедрения фичи приносит больше денег.
Правильный ARPU с полки = Выручка с полки / количество пользователей в группе эксперимента = CR в полку * ratio-ARPU с полки
И это уже не ratio, а обычная поюзерная метрика. Она то нам и нужна, так как учитывает и конверсию в полку, и выручку с долиставших до нее.
Я это все к чему. Если в компании никто не следит за методологией A/B-тестирования (в широком смысле), то гибкость платформы становится её недостатком. Хорошее решение проблемы, на мой взгляд, – собрать группу людей, у которых есть время на подумать над методологией. И гибкость должна быть доступна только им – по крайней мере в вопросах, касающихся дизайна экспериментов и принятия решения по ним. Пусть они раздают галочки для метрик, чтобы те можно было использовать как целевые, проверяют нестандартную настройку фиче флагов, возможность использования сегментов и т.д.
👾13
Build vs Buy
In-house A/B platform дримтим:
◆ DA / DS для работы над методологией
◆ Бэкэндер для разработки и поддержки сплитовалки
◆ Фронтэндер для разработки и поддержки админки
◆ Дизайнер для дизайна админки
◆ DE для настройки пайплайнов расчетов, если DA / DS не вывозят
На самом деле это роскошный минимум без продакта, проджекта и еще пары аналитиков. Но даже с таким сетапом:
vs
Понятно, что если делать свою платформу, то дизайнер и разработчики в какой-то момент могут быть нужны не на фултайм, и 230k превратятся в 130-150.
Но, энивэй, если выбираете вендора, то за короткий промежуток времени получаете вылизанный продукт со всеми необходимыми функциями и адекватно реализованной методологией, а не собранный из говна и палок сервис, над которым нужно годик-другой поработать, чтобы он мог хоть как-то сравниться с предложениями с рынка.
Если вы бигтех и у вас уже есть удачно спроектированная с самого начала платформа, то, в целом, норм её развивать. Но, если только встал вопрос о выстраивании процесса A/B-тестирования в компании, то выбор между Build и Buy – конечно же👋
In-house A/B platform дримтим:
◆ DA / DS для работы над методологией
◆ Бэкэндер для разработки и поддержки сплитовалки
◆ Фронтэндер для разработки и поддержки админки
◆ Дизайнер для дизайна админки
◆ DE для настройки пайплайнов расчетов, если DA / DS не вывозят
На самом деле это роскошный минимум без продакта, проджекта и еще пары аналитиков. Но даже с таким сетапом:
5 * 300k * 12 = 18 000 000 рублей или 230 000 $ в год
vs
100-300k в год за готовое решение (правда это цены за 2022 – сейчас наверное немного дороже будет)
Понятно, что если делать свою платформу, то дизайнер и разработчики в какой-то момент могут быть нужны не на фултайм, и 230k превратятся в 130-150.
Но, энивэй, если выбираете вендора, то за короткий промежуток времени получаете вылизанный продукт со всеми необходимыми функциями и адекватно реализованной методологией, а не собранный из говна и палок сервис, над которым нужно годик-другой поработать, чтобы он мог хоть как-то сравниться с предложениями с рынка.
Если вы бигтех и у вас уже есть удачно спроектированная с самого начала платформа, то, в целом, норм её развивать. Но, если только встал вопрос о выстраивании процесса A/B-тестирования в компании, то выбор между Build и Buy – конечно же
Please open Telegram to view this post
VIEW IN TELEGRAM
👾9
Написал серию статей про C*PED
Вот первая, в которой рассказываю о том, как не перестараться при трансформации метрики.
Потом еще выложу вторую и третью
Вот первая, в которой рассказываю о том, как не перестараться при трансформации метрики.
Потом еще выложу вторую и третью
Telegraph
CUPED One
Двенадцать лет назад Алекс Денг, Я Сю, Рон Кохави и Тоби Уолкер сделали дроп, который помог всей индустрии A/B-тестирования немного ускориться. Что такое CUPED знает, наверное, почти любой человек, трогавший эксперименты. Чего, скорее всего, не знает почти…
👾21
CUPED + Дельта-метод
Вторая часть. Внутри:
- правильная формула для θ
- алгоритм применения CUPED к ratio-метрикам
- мой дизреспект Яндексу
Вторая часть. Внутри:
- правильная формула для θ
- алгоритм применения CUPED к ratio-метрикам
- мой дизреспект Яндексу
Telegraph
CUPED 2
Продолжаем про CUPED. В первой части разобрались, как не перестараться с трансформацией метрики. В этой – выведем верную формулу для θ, а также разберемся, как подружить CUPED с дельта-методом. Оптимальная тета Скорее всего, вы сталкивались вот с таким вариантом…
👾18
AB_Testicles_CUPED.pdf
9.3 MB
Шпаргалка по CUPED
Собрал все формулы из статей в одну PDF, чтобы вы пользовались и делились с друзьями, прославляя канал
Собрал все формулы из статей в одну PDF, чтобы вы пользовались и делились с друзьями, прославляя канал
👾37
🎃🎃Это место похоже на Халлоуин🎃🎃
Канал нарядился для празднования 🧛Дня всех святых👻. Вот вам по случаю страшилка на ночь.
Представьте, что вы рассчитываете необходимый размер выборки для A/B-теста. Допустим для простоты, все фичи оказывают один и тот же по величине эффект на метрику. По старой оккультной традиции вы используете эффект из прошедших успешных экспериментов в качестве MDE. Так как истинный эффект вам недоступен, вы подставляете вместо него наблюдаемый. А ещё так уж вышло, что вы не читали мой пост про ошибку типа M, как и не читали статью от AirBnB про 💀Проклятие победителя💀. И, как следствие, не знаете, что в среднем наблюдаемые стат. значимые эффекты завышают истинный эффект.
В итоге вас засасывает в вечный круговорот:
🕷Вы используете в среднем завышенный эффект в качестве MDE
🧟♂️Рассчитанный размер выборки оказывается меньше, чем нужно
🔪Реальная мощность теста становится меньше желаемых 80%
🥀Полученный наблюдаемый эффект в новом эксперименте, окажись он стат. значимым, в среднем будет завышать истинный эффект еще сильнее, чем раньше
⚰️Вы возвращаетесь к шагу с пауком и используете только что полученный эффект для нового расчета MDE
👹Ваша мощность постепенно снижается и из 80 превращается в 5! Бу!
На самом деле на практике всё чуть менее страшно. Я проверил на симуляциях такой сетап:
- Выборки из экспоненциального распределения с параметром scale = 1000
- Истинный эффект всегда +10 и всегда аддитивный
- Проводим серию из 300 экспериментов
- В первом эксперименте при расчете размера выборок подставляем +10 в качестве MDE, чтобы исходная мощность была равна в точности 80%
- В последующих экспериментах рассчитываем размер выборки одним из 4 способов:
♦️last_statsig - берем в качестве MDE последний наблюдаемый стат. значимый эффект (самый первый эффект +10 тоже считаем стат. значимым)
♠️avg_last5_statsig - берем в качестве MDE среднее по последним 5 наблюдаемым стат. значимым эффектам (пока стат. значимых эффектов меньше 5, берем сколько есть)
♦️avg_statsig - берем в качестве MDE среднее по всем наблюдаемым стат. значимым эффектам
♠️avg - берем в качестве MDE среднее всем эффектам (в том числе не стат. значимым)
- На каждом шаге фиксируем значение, используемое в качестве целевого MDE, полученный размер выборки и реальную мощность (для истинного эффекта, равного +10)
- Проводим 200 таких серий из 300 экспериментов, усредняем значения для каждого из 300 шагов
- Как водится в индустрии для всего этого используем двусторонний критерий, но считаем эффект стат. значимым, только если он в добавок ко всему положительный (красные тесты никто не катит). Размер выборки и реальную мощность считаем как для одностороннего теста, потому что по-другому сложно.
Результаты на графиках. Видно, что все подходы, которые считают MDE по стат. значимым наблюдаемым эффектам, достаточно быстро начинают завышать истинный эффект, что ведет к снижению размера выборки и мощности. Интересно, что мощность при этом не падает к 5%, а стабилизируется на уровне 50-60%. Если же использовать среднее значение по всем наблюдаемым эффектам, то мощность так и будет колебаться в районе 80%. Нравится.
Канал нарядился для празднования 🧛Дня всех святых👻. Вот вам по случаю страшилка на ночь.
Представьте, что вы рассчитываете необходимый размер выборки для A/B-теста. Допустим для простоты, все фичи оказывают один и тот же по величине эффект на метрику. По старой оккультной традиции вы используете эффект из прошедших успешных экспериментов в качестве MDE. Так как истинный эффект вам недоступен, вы подставляете вместо него наблюдаемый. А ещё так уж вышло, что вы не читали мой пост про ошибку типа M, как и не читали статью от AirBnB про 💀Проклятие победителя💀. И, как следствие, не знаете, что в среднем наблюдаемые стат. значимые эффекты завышают истинный эффект.
В итоге вас засасывает в вечный круговорот:
🕷Вы используете в среднем завышенный эффект в качестве MDE
🧟♂️Рассчитанный размер выборки оказывается меньше, чем нужно
🔪Реальная мощность теста становится меньше желаемых 80%
🥀Полученный наблюдаемый эффект в новом эксперименте, окажись он стат. значимым, в среднем будет завышать истинный эффект еще сильнее, чем раньше
⚰️Вы возвращаетесь к шагу с пауком и используете только что полученный эффект для нового расчета MDE
👹Ваша мощность постепенно снижается и из 80 превращается в 5! Бу!
На самом деле на практике всё чуть менее страшно. Я проверил на симуляциях такой сетап:
- Выборки из экспоненциального распределения с параметром scale = 1000
- Истинный эффект всегда +10 и всегда аддитивный
- Проводим серию из 300 экспериментов
- В первом эксперименте при расчете размера выборок подставляем +10 в качестве MDE, чтобы исходная мощность была равна в точности 80%
- В последующих экспериментах рассчитываем размер выборки одним из 4 способов:
♦️last_statsig - берем в качестве MDE последний наблюдаемый стат. значимый эффект (самый первый эффект +10 тоже считаем стат. значимым)
♠️avg_last5_statsig - берем в качестве MDE среднее по последним 5 наблюдаемым стат. значимым эффектам (пока стат. значимых эффектов меньше 5, берем сколько есть)
♦️avg_statsig - берем в качестве MDE среднее по всем наблюдаемым стат. значимым эффектам
♠️avg - берем в качестве MDE среднее всем эффектам (в том числе не стат. значимым)
- На каждом шаге фиксируем значение, используемое в качестве целевого MDE, полученный размер выборки и реальную мощность (для истинного эффекта, равного +10)
- Проводим 200 таких серий из 300 экспериментов, усредняем значения для каждого из 300 шагов
- Как водится в индустрии для всего этого используем двусторонний критерий, но считаем эффект стат. значимым, только если он в добавок ко всему положительный (красные тесты никто не катит). Размер выборки и реальную мощность считаем как для одностороннего теста, потому что по-другому сложно.
Результаты на графиках. Видно, что все подходы, которые считают MDE по стат. значимым наблюдаемым эффектам, достаточно быстро начинают завышать истинный эффект, что ведет к снижению размера выборки и мощности. Интересно, что мощность при этом не падает к 5%, а стабилизируется на уровне 50-60%. Если же использовать среднее значение по всем наблюдаемым эффектам, то мощность так и будет колебаться в районе 80%. Нравится.
AB_Testicles_CUPED_Halloween.pdf
33.5 MB
CUPED Cheatsheet Halloween Edition
На журфаке МГУ запретили отмечать Хэллоуин. Как хорошо, что все еще остаются такие островки свободы, как канал A/B Testicles, где Хэллоуин можно отмечать еще как
Сделал страшную версию шпаргалки для любителей пощекотать нервы во время реализации методологии A/B-тестирования
На журфаке МГУ запретили отмечать Хэллоуин. Как хорошо, что все еще остаются такие островки свободы, как канал A/B Testicles, где Хэллоуин можно отмечать еще как
Сделал страшную версию шпаргалки для любителей пощекотать нервы во время реализации методологии A/B-тестирования
Проклятие победителя на Матемаркетинге
Конфа уже близко, и одним из выступлений на ней будет доклад Сергея Матросова с канала Не АБы какие тесты про альтернативу холдауту, предложенную Airbnb в статье 2018 года. В первой её части приводится доказательство упомянутонного мной в хэллоуинском посте проклятия победителя. Его суть заключается в том, что математическое ожидание разности стат. значимых наблюдаемых эффектов и истинного эффекта – неотрицательная величина. То есть в среднем стат. значимые эффекты завышают истинный эффект.
Формальный вывод доказательства посмотрите в самой статье, а я предлагаю разобраться, почему так происходит, с помощью графиков. Рассмотрим 2 случая:
1) Реальная мощность теста > 50%. Тогда распределение разностей средних, X_i, можно разбить на 4 части (как на картинке). Зеленая, синяя и красная области соответствуют стат. значимым результатам, белая – не стат. значимым.
Давайте посчитаем E[X_i – a], но не для всех X_i, а только для стат. значимых (очевидно, что для всех X_i эта величина равна 0). Сделаем это, проинтегрировав (X_i – a)*p_i для всех 4 областей, но слагаемое, соответствующее белой области, домножим на 0. То есть возьмем E[ I(non-white) * (X_i – a) ], где I(non-white) – индикаторная функция.
Несложно увидеть, что для каждого значения X_i из зеленой области найдется такое значение из синей, что p_i_blue*(X_i_blue – a) = –p_i_green * (X_i_green – a). То есть интегралы по этим двум областям просто отменят друг друга. И останется только интеграл по красной области. А так как все X_i из красной области больше a, то и итоговый результат будет > 0.
2) Реальная мощность теста <= 50%. Тут еще проще – зеленая область вовсе пропадет и останутся только X_i, большие чем a. Очевидно, что E[X_i – a] для таких X_i также будет > 0.
Какой из подходов правильнее, чем они еще отличаются кроме нормирования вероятностей, что делать с обнаруженным байасом и причем тут вообще альтернатива холдауту? Вот статья + выступление Сережи на ММ'25 20 ноября в 17:45.
Конфа уже близко, и одним из выступлений на ней будет доклад Сергея Матросова с канала Не АБы какие тесты про альтернативу холдауту, предложенную Airbnb в статье 2018 года. В первой её части приводится доказательство упомянутонного мной в хэллоуинском посте проклятия победителя. Его суть заключается в том, что математическое ожидание разности стат. значимых наблюдаемых эффектов и истинного эффекта – неотрицательная величина. То есть в среднем стат. значимые эффекты завышают истинный эффект.
Формальный вывод доказательства посмотрите в самой статье, а я предлагаю разобраться, почему так происходит, с помощью графиков. Рассмотрим 2 случая:
1) Реальная мощность теста > 50%. Тогда распределение разностей средних, X_i, можно разбить на 4 части (как на картинке). Зеленая, синяя и красная области соответствуют стат. значимым результатам, белая – не стат. значимым.
Давайте посчитаем E[X_i – a], но не для всех X_i, а только для стат. значимых (очевидно, что для всех X_i эта величина равна 0). Сделаем это, проинтегрировав (X_i – a)*p_i для всех 4 областей, но слагаемое, соответствующее белой области, домножим на 0. То есть возьмем E[ I(non-white) * (X_i – a) ], где I(non-white) – индикаторная функция.
Несложно увидеть, что для каждого значения X_i из зеленой области найдется такое значение из синей, что p_i_blue*(X_i_blue – a) = –p_i_green * (X_i_green – a). То есть интегралы по этим двум областям просто отменят друг друга. И останется только интеграл по красной области. А так как все X_i из красной области больше a, то и итоговый результат будет > 0.
2) Реальная мощность теста <= 50%. Тут еще проще – зеленая область вовсе пропадет и останутся только X_i, большие чем a. Очевидно, что E[X_i – a] для таких X_i также будет > 0.
Добавлю еще, что условие на стат. значимость X_i можно реализовать двумя способами:
◆ как сделали мы – с помощью индикаторной функции. Наши p_i расчитаны на основе исходного распределения из 4 областей
◆ по-другому. Можно сразу считать интеграл по усеченному распределению (без белой области) с отнормированными вероятностями. Тогда результат будет отличаться в 1/ (1-beta) раз. Но знак все равно не поменяет.
Какой из подходов правильнее, чем они еще отличаются кроме нормирования вероятностей, что делать с обнаруженным байасом и причем тут вообще альтернатива холдауту? Вот статья + выступление Сережи на ММ'25 20 ноября в 17:45.
👾12