Comments 9
Возможно, я недостаточно разбираюсь в данном вопросе, но весь этот мат аппарат нужен для того чтоб понять какого цвета сделать кнопку "красную" или "синюю" ?
Хах, нет конечно) Хотя, чаще всего, именно для этого используют AB-тесты)
На самом деле AB-тестирование нужно практически всегда для принятия любого продуктовго решения, например:
Давать ли пользователям скидки или нет?
Новые услуги продвижения работают лучше старых или нет?
Нужно ли вводить больше фильтров на сайте?
Работает ли рекламная компания?
Работают ли красивые цены на услуги на сайте или нет?
Ну и конечно, как Вы верно отметили, для проверки нового дизайна тоже используют AB
Отличная статья, пара вопросов.
Почему на поюзерных тестах uplift всегда хуже чем CUNOPAC и CUMPED? Ведь кажется в uplift можно использовать те же модели только еще с привлечением дополнительной информации о trreatment
Не было мысли сделать полность репродуцируемое исследование, выложив обфусцированные данные и код на gitlab? Статья очень практичная (присутствуют тезисы типа "это просто работает", а также есть фрагменты кода) , но была бы еще более практичной, если бы можно было тут же закрепить все прогоном кода в ноутбуке.
Спасибо за фидбек!
Интересный вопрос)
Про CUNOPAC: сходу мне сложно предположить, почему мощности разнятся( Предполагаю, что дело в разных подходах алгоритма: uplift модель, если бы мы использовали предсказания не на всем датасете, а лишь на части (тестовые предсказания на тестовых пользователях, контрольные предсказания на контрольных пользователях) -- ничем не отличался бы от обычного ttest. CUNOPAC же смотрит на остатки e_t, e_c при условии, что мы предсказывали бы все без знания, кто в тесте и в контроле. Раз CUPED более мощный чем TTEST, то логично, что алгоритм основанный на CUPED может быть мощнее uplift модели (который дает результаты как t-test, если бы не увеличение датасета в 2 раза);
Про CUMPED - те же рассуждения. Плюс здесь нет шума от ML-модели, которая могла начать плохо предсказывать.
Ух, есть такая идея) Но боюсь что по времени успею лишь весной(
Привет. Спасибо за статью.
Ещё больше интересных и нетривиальных моментов про CUPED расписано в прошлой статье.
Надеюсь, я не нарушу правила, задав вопрос к вашей предыдущей статье :) Под ней я уже не могу оставить комментарий.
Также, часто в некоторых статьях предлагают следующую метрику для CUPED:
...
Так вот, запомните: никогда не используйте такую CUPED–метрику!
А можете привести пример такой статьи?
Я сначала подумал про статью Booking.com. Но там другая формула:
В вашем примере неправильного расчета из ковариаты вычитается среднее по варианту теста (контролю или тритменту соотвественно).
В варианте Booking.com из коварианты вычитается среднее по контролю и тритменту вместе. Т.е. константа.
Спасибо за вопрос! А то никаких комментариев по той статье не было, уже грустить начал)
Да, изначально была эта статья, плюс была статья про CUPED на русском медиуме. При применении критерия у Букинга ошибки нет, но есть несколько но:
1) Они вводят в заблуждение читателя, приводя пример с вычитанием среднего. Зачем вообще это делать? Какой от этого профит?
2) Приводя это в пример, и говоря, что так выглядит cuped-метрика, я думаю многие могли начать сокращать так вариацию для построения доверительного интервала для мат. ожа одной метрики, без сравнения с тестом. И это реально бы работало, только это неверно.
3) Ну и главное: не все хорошо шарят за код в sql и в спарке и могли прочесть лишь строчки с формулами, где написано вычитать среднее, и уже в этом случае прийти именно к тому неправильному CUPED-критерию, описанному в статье.
Спасибо за ответ)
Они вводят в заблуждение читателя, приводя пример с вычитанием среднего.
Очень спорное устверждение) Вроде явно говорят об этом. Рассказывают, как применяют CUPED сами.
Зачем вообще это делать? Какой от этого профит?
Зачем Букинг так делает, лучше спросить у них) Но я могу дать свою интерпретацию. При такой трансформации сохраняется среднее метрики (по всем вариантам вместе). А т.к. CUPED дает более точную оценку разницы средних двух вариантов, то с такой трансформированной метрикой дальше можно работать как с обычной метрикой. Это просто удобнее (не надо тащить дальше по коду метрику без CUPED-трансформации).
Удобство -- штука субъективная. Вам может быть неудобно. Но это точно не повод говорить, что так делать нельзя)
2) Приводя это в пример, и говоря, что так выглядит cuped-метрика, я думаю многие могли начать сокращать так вариацию для построения доверительного интервала для мат. ожа одной метрики, без сравнения с тестом. И это реально бы работало, только это неверно.
3) Ну и главное: не все хорошо шарят за код в sql и в спарке и могли прочесть лишь строчки с формулами, где написано вычитать среднее, и уже в этом случае прийти именно к тому неправильному CUPED-критерию, описанному в статье.
Я читаю это так: те, кто будут применять CUPED с такой трансформацией, с большей вероятностью допустят ошибку. Моё мнение такое:
Те, кто знают статистику, не должны допустить такую ошибку.
Те, кто не знают статистику, и без этого могут ошибиться. Например, рассчитать коэффициент при ковариате для каждого варианта отдельно :)
Спасибо за вопрос! А то никаких комментариев по той статье не было, уже грустить начал)
Думаю, тема для узкого круга людей. Но будьте уверены, аналитики вас читают. И скорее всего добавили ваши статьи к себе в закладки) По тексту выше может показаться, что я придираюсь, но на самом деле считаю, что круто, что вы пишете так детально о том, как считаете АБ-тесты. Очень полезные материалы.
Кстати, пользуясь случаем, хочу сказать спасибо за то, что написали про критерий Манна-Уитни в первой статье. Коллеги из Delivery Club, например, написали, что используют этот критерий для среднего чека... И не одобрили мой комментарий к статье))) Я когда-то сделал скрипт с примерами, чтобы показать, что его нельзя использовать для проверки гипотез равенства средних или медиан.
И раз уж мы обсуждаем ваши предыдущие статьи, хочу поинтересоваться, какой метод для расчета доверительного интервала вы используете, когда применяете бутстрап? Percentile, studentized, BCa? Многие в статьях про АБ упомнают бутстрап. Но я почти не видел, чтобы кто-то предупреждал о его подводных камнях. Например, о важности большого кол-ва бустрап выборок (>=10000). И о том, что простой percentile bootstrap не очень точный. Вот статья о том, что может пойти не так с бутстрапом: https://yanirseroussi.com/2019/10/06/bootstrapping-the-right-way/
Не хотите думать — используйте бутстрап!
На мой взгляд, эта фраза вводит в заблуждение больше, чем статья Букинга про CUPED))
Про бутстрап:
1) мы используем центральный бутстрап (который видимо BCa). Но я не обнаруживал на выборках размера более 10к разницы в 3 методах построения доверительного интервала бутстрапом, так что можно юзать любой (если предварительно проверишь его на своих данных). По поводу скинутого примера - см пункт 3
2) Все подводные камни легко обнаружить, если проверить свой критерий. Этому была посвящана большая часть первой статьи и это самое важное, что надо помнить! По поводу большого количества бутстрап выборок - мы используем 10к, у нас все работает на реальных и искусственных данных.
3) По поводу статьи: все бы хорошо, но пример некорректный) Просто в качестве простого чекера: всегда стоит запустить на сгенерированных данных t-test. Если он не работает -- есть повод задуматься о корректности примера.
Автор генерирует в своих примерах выборки с зависимыми элементами , когда использует multinomial респределение для генерации размера выборок (https://github.com/yanirs/yanirs.github.io/blob/master/talks/bootstrapping-the-right-way/notebook.ipynb). Достаточно прочесть вики https://en.wikipedia.org/wiki/Multinomial_distribution , там показано, что есть зависимость между элементами (раз ненулевая ковариация)
3.5) Если исправить пример автора, то все бутстрапы работают на выборках размера 1000 (на других размерах не проверял)
4) "Не хотите думать — используйте бутстрап!" <- да, я действительно так считаю) Но, конечно же, при условии, что этот бутстрап будет проверен на реальных/искусственных данных.
Про CUPED: я пересмотрел статью еще раз, и не увидел, чтобы они явно подчеркивали, что вычитаемое среднее одно и то же (кроме одного упоминания, что вычитание среднего не влияет на разницы метрик). Может плохо читаю, но я считаю, что это очень важно было подчеркнуть, а не показывать на примерах в коде.
Те, кто не знают статистику, и без этого могут ошибиться. Например, рассчитать коэффициент при ковариате для каждого варианта отдельно :)
Не, это порочная практика) Все мы можем ошибаться, и это нормально (как пример - статья выше про бутстрап). Плюс даже те, кто шарят статы, могут не понять, почему нельзя вычитать 2 разных средних в тесте и в контроле? Или почему нельзя для мат.ожа такой метрики построить дов интервал? И здесь возникает ровно та же проблема, что и в статье про бутстрап - зависимость элементов выборки, что является совсем нетривиальной проблемой, которую сложно заметить. Здесь поможет не знание статистики, а лишь опыт.
Плюс всегда стоит стараться уменьшить до минимума количество недопомониманий от статьи. И вот здесь, как мне кажется, booking не прав) Вот второй пример - https://medium.com/statistics-experiments/cuped-или-увеличение-чувствительности-метрики-de7183fc964c и здесь наверняка точно также имелось в виду, что среднее одно и то же на предпериоде. Но в обоих статьях не объяснено, почему нельзя вычитать разные средние на тесте и контроле. Или зачем вообще они вычитают это среднее .
А ну и про Манна-Уитни: я еще у вк видел статью, где они также рекламирвали этот критерий) В январе (надеюсь...) я опубликую более подробную статью про этот критерий, где прям по полочкам разложу, в чем проблема этого критерия, почему его вообще используют и к чему на практике он приводит)
Про бутстрап, спасибо за ответ. Если честно, не заглядывал в скрипт, поверил на слово) Изучу подробнее.
Про ввод в заблужение статьей про CUPED, это субъективщина. Я статью на букинге сразу правильно понял. Логично, что трансформация метрики просиходит до деления на тритмент и контроль. Кажется, я только в статьях Авито видел отдельные формулы для тритмента и контроля)
А вот в вашей статье пришлось код читать, чтобы понять, что вы имеете в виду) Написали формулу только для контроля, без тритмента. Вот так точно можно ввести в заблуждение))
ML-критерии для A/B-тестов