Comments 15
Просто интереса ради
Почему питон, а не R, тоже самое на порядок проще там делается? Плюс очень приличные, но при этом простые в использовании пакеты для визуализации сразу есть. В областях где плотно зависят от статистики - R ща чуть ли не выбор по умолчанию.
Но вообще это вы в одной статье попытались рассказать сразу три главы учебника по какой-нибудь 6 сигма. :-) Есть подозрение что для человека, который не в теме, не очень понятно будет. А изобилие транслитерированных терминов типа “раскатать” (лично я не сразу понял что это не от русского глагола “катать”, а от английского cut). А если учесть достаточно смелое утверждение о применимости т-теста для данных не попадающих под нормальное распределение и пока более чем спорно выглядящий метод фильтрации outliers… Может быть стоит чуть подробнее и тут уж точно надо показывать и на каких выборках, и с какой целью принималось такое решение. Я вполне допускаю что существуют ситуации когда это решение было обоснованным, но как общее правило - очень, очень смелое утверждение.
"Раскатить" от слова "катить". Например: "мы выкатили новые улучшения нашего сайта для всех пользователей". Получается, что мы выпустили некие обновления, которые теперь видны всем пользователям.
Насколько я вижу, именно в таком значении и используется данный оборот в тексте. Применить изменение ко всем нашим пользователям.
Хм… два нюанса. Во-первых статья только выиграет если читателю не придется подменять одно слово другим. Все-таки выкатили как у вас в примере там нигде не используется, только раскатили. А это все-таки два сильно разных слова по значению. Но и во-вторых как минимум один раз там в статье раскатывают тест. Даже приняв ваше объяснение - я не вижу как именно следует трактовать эту фразу в контексте статанализа.
Почему питон, а не R:
1) Питон более популярный язык программирования, поэтому в таком случае код смогут понять большее количество людей
2) Я не вижу никакого преимущества R перед питоном. По крайней мере в тех задачах, которые мне попадались. Можете привести пример стат.критерия или визуализации, которых сейчас не были бы реализованы на питоне, но реализованы на R?
3) Питон в несколько раз быстрее R. https://towardsdatascience.com/is-python-faster-than-r-db06c5be5ce8
Про «раскатили тест» вам все верно сказали до меня. Хочу заметить, что используем этот термин не только мы, но и многие другие компании, достаточно загуглить эту фразу в поисковике.
Про смелое утверждение о применимости т-теста для данных не попадающих под нормальное распределение: я описываю в статье, какие условия на самом деле требует t-test для корректной работы. Кроме того, я демонстрирую на примере выборок из экспоненциального распределения, что t-test работает. Поэтому, если у вас есть нарекания к примеру или объяснение, почему он некорректен, то мне будет интересно подискутировать на эту тему)
Про «спорно выглядящий метод фильтрации outliers»: я привожу примеры, в каких случаях этот метод может привести к ошибкам, а когда его можно применять в статье. Причем в общих рекомендациях (предпоследнее предложение в статье) я снова предупреждаю, что этот метод опасен и его стоит валидировать. Так что моя совесть чиста.
Про то, что статья получилась огромной – это правда, но это только половина) Вторая половина будет опубликована при хорошем раскладе на этой неделе. Статью можно было бы подробить на более мелкие части, но мне показалось, что тогда сложнее было бы вспоминать, что было в предыдущих статьях. Вполне возможно, здесь я был не прав.
Надеюсь я смог ответить на ваши вопросы и замечания, готов отвечать и далее)
Я ж не в порядке оспаривания.
Статья спорная, но взгляд очень интересный и почерпнуть из неё можно много полезного. Но, просто по опыту, 8 из 10 читателей "под кат" там где вы оговариваетесь про ЦПТ скорее всего даже не заглянут, а вот идею категорично выраженную в конце уже понесут гордо на флаге "я на хабре прочитал, там же все мега-профи сидят". :-) Совесть у вас в любом случае чиста, я тоже считаю что читать не умеет - сам себе злая буратина, но они ж потом так же будут страдать на каждом углу как их бедных обманули.
Про питон логика понятна. Я собственно чисто из интереса спросил. С моей колокольни читать код про статанализ - надо 99% знания статистики и только 1% знания языка. Да и скорости выполнения не то что бы были очень важны, чай не в реальном времени считаем. Зато на R все это пишется в 3 раза быстрее и в 3 раза короче. Ну и время развернуть - начать - 5 минут. Хотя операции типа нарезки сетов в одну строку могут напугать, что есть - то есть :-)
Насчет раскатывания - ну я ж тоже сразу предположил сленг, и поискал. При всем моем уважении - одно использование на первые три страницы выдачи. Опять-таки, дело хозяйское, но если избежать узкоспециального сленга - то статья станет только лучше. :-)
А по теме...
я описываю в статье, какие условия на самом деле требует t-test для корректной работы
Вы про кат с оговоркой про ЦПТ? Тогда, если честно, не совсем понятно в чем тут новость. Всю жизнь же проверяли данные например Шапиро-Вилксом и если данные достаточно близки к НР - то и t-тест или anova вполне себе применимы.
я привожу примеры, в каких случаях этот метод может привести к ошибкам, а когда его можно применять в статье.
И, как мне показалось, пример, особенно где про крупных клиентов - он скорее сигнал к тому что может быть критерии эксперимента или таргет-группу надо было по другому проектировать. По крайней мере прислали б мне студенты такой эксперимент в качестве работы по 6 сигма - именно перепланировать эксперимент я бы и отправил. :-) Ну если только у вас совсем нет возможности бить по конкретным группам в рамках тестирования гипотезы.
Про то, что статья получилась огромной
С точностью до наоборот. Маленькая она сильно :-) Ее можно сделать в 3 раза больше и она только выиграет.
А делилась, как мне кажется, легко. Рассуждения о презентации результатов тестирования - вполне себе статья сама по себе и отличная статья, кстати. Близкая к сердцу куда более широкой аудитории :-) Нюансы применения t-теста для не "сферических НР в вакууме", а в реальности (да хотя бы просто когда какая-то с...волочь взяла и округлила исходные данные до целых, при общем диапазоне в пару десятков единиц :-)) - еще статья. Борьба с выбросами - еще статья.
А вторую пишите обязательно, в потоке УГ из серии "как мы классно внедрили модную но никому не нужную фигню" - прям глоток свежего воздуха. :-)
Про раскатку: я в гугле искал) раскатить тест
По поводу проверки на нормальность: нам нужна нормальность среднего по выборке, а среднее у выборки всего одно) А как по одному значению определить, является ли это значение из нормального распределения, я не знаю) Точнее представляю, как это можно сделать, но не совсем через Шапиро-Уилка.
Далее, даже если бы Шапиро-Уилка не отверг гипотезу о ненормальности выборки средних (если бы была выборка средних), то это не значит, что t-test здесь отработает корректно (можно привести пример). Поэтому имеет смысл проверять работоспособность самого критерия, а не нормальность, потому что интересует нас именно корректность критерия.
Теперь, про убирание крупных клиентов – да, можно изначально спроектировать эксперимент так, чтобы топ юзеры в нем не участвовали. Но зачем, если провести можно на всех юзерах? И в случае, когда на всех юзерах мы получили серый результат (а лучше – увидели, что MDE сильно больше ожидаемого, посчитанного на исторических данных), тогда можно перейти к критерию, который не учитывает топ юзеров на пред периоде.
Про применение t-test на реальных данных: я как раз указываю, как проверить корректность использования этого (да и вообще любого) критерия на реальных данных, чтобы убедиться, что вы можете использовать этот критерий для анализа AB-тестов в своей компании. Правда, конечно, от человеческих ошибок типа округления это не спасет, тут вообще мало что спасет на первый взгляд)
А я ведь просто хотел подать объявление о продаже на Авито...
Спасибо за интересную статью!
Мне кажется, в случае серого эксперимента интереснее мониторить MDE. Чтобы бизнес понимал, что это не означает что вообще нет эффекта, а то что на таком количестве данных эффект может быть любой меньше MDE.
Я не очень понимаю, зачем здесь мониторить MDE? Когда я строю доверительный интервал в определенный момент времени, я понимаю, что в alpha проценте случаев эффект будет не лежать в его границах, но как здесь мониторинг MDE позволит что-то сказать точнее? Мониторинг MDE имеет смысл для изначального определения срока теста, но об этом я расскажу во второй части статьи (выйдет на следующей неделе)
MDE состоит из дисперсии, конкретного alpha и количества наблюдений в выборке. Из всего этого с течением времени меняется только количество наблюдений. Теоретически имея огромное множество наблюдений мы могли бы детектировать очень маленькое MDE, но из-за ограничения по времени мы ограничиваем MDE. Условно вычисляя размер выборки для 10% MDE , мы понимаем что нам нужно минимум N наблюдений. Но если бы решили собирать 100*N то возможно нашлибы прокрас но для меньшего MDE. Таким образом менеджер должен понимать, что серый эксп это не вообще отсутствие эффекта , а то что он может быть меньше MDE
Проблема состоит в том, что со временем людей становится больше, но и дисперсия становится больше, в следующей статье будет пример. Поэтому нельзя утверждать, что со временем MDE станет лучше. У нас на практике MDE в какой-то момент просто перестает меняться или меняется очень слабо.
Все остальное правда, эффект будет меньше MDE, но этот вывод никак не зависит от мониторинга MDE
а почему альтернативная гипотеза односторонняя? мы заранее не знаем в какую сторону отклонится эффект в эксперименте
Мы не знаем какой результат будет в эксперимента, но мы знаем чего мы хотим: улучшения метрики (а значит односторонний результат). Если мы получим любой другой результат (к примеру, сильное падение метрики или отсутсвие эффекта), то катить фичу мы не будем. Поэтому нас как раз интересует односторонняя гипотеза.
Как улучшить ваши A/B-тесты: лайфхаки аналитиков Авито. Часть 1