#ltv #AB #statistics

Использование суррогатных метрик в онлайн экспериментах.

https://telegra.ph/Online-Experimentation-with-Surrogate-Metrics-Guidelines-and-a-Case-Study-07-24

#ltv #libraries

Интересные библиотеки.

С библиотеками в плане расчета LTV не особо густо, но советую посмотреть пару библиотек.

Первая библиотека - lifetimes. Библиотека с реализацией алгоритмов и семейства Pareto/NBD моделей. Последние коммиты достаточно давно, но ее все же часто упоминают в разных материалах по предсказанию LTV. 

Вторая библиотека уже как-то встречалась в моих постах. Это - retentioneering. Не совсем про LTV, но там точно есть возможности построить из логов матрицу переходов и проделать над ней некоторые операции. Что сильно напоминает подходы с использованием Марковских цепей.

#libraries

Наткнулся на порт shiny for python. Знаю, что многие любители R его хвалят (сам не использовал, т.к. в R почти не залезал).

На первый взгляд, выглядит неплохо. Впрочем, сильного превосходства над streamlit не вижу, но я и не ковырялся глубоко.

Вот страничка с примерами для shiny for python.

P.S. Серия про LTV закончилась, а новую я пока не стартовал (по некоторым понятным причинам). Так что пока будут разные мелкие заметки выходить.

АБ-тесты. Интеграция в процесс пилотирования. Что делать.
Цикл постов про АБ-тестирование. Пост 4.

Теперь, когда мы разобрали бизнес-процессы и ключевые риски инвестиционного цикла и отдельно пилотирования, можно поговорить о том, как предусмотреть митигацию этих рисков при интеграции АБ-тестов в деятельность компании.

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

Создание такого бизнес-процесса (далее - БП):

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

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

Необходимые атрибуты процесса взаимодействия бизнеса с командой АБ-тестирования: единое окно для подачи всех заявок на АБ, механизм приоритезации, чек-листы для подачи заявки на дизайн пилота и на оценку эффекта после пилота, SLA ответа на корректно поданную заявку.

Ключевой атрибут - это чек-листы. Рассмотрим их подробнее.

A. Чек-лист для подачи заявки на дизайн пилота в команду АБ, включающий как технику, так и бизнес-постановку.

Бизнес-часть:

- сведения о заказчике пилота (бизнес-подразделение, контакты);
- содержание пилота (что внедряем, почему это принесет эффект);
- категория приоритетности расчета. Пока у вас нет библиотеки или платформы АБ-тестирования и дизайны экспериментов требуют вовлечения DS-ов, необходимо выстроить процесс приоритезации заявок: какие проекты оцениваются в 1/2/3 очередь, какие - не оцениваются вообще. Основа критериев: бюджет проведения пилота (считается ли проект крупным с точки зрения инвестиционного цикла компании) и материальность ожидаемого эффекта для PnL компании (ждем ли реально большой пользы от проекта).

Техническая часть. Стоит обозначить все пункты, необходимые для математического дизайна пилота по вашей методе:

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

Б. Чек-лист для подачи заявки в команду АБ на оценку пилота. Здесь возможны 2 варианта:

- Дизайн пилота делала команда АБ по единой методике. Чек-лист не требуется, вся информация есть у команды. Нужно только уведомление о завершении пилота и просьба рассчитать эффект.

- Пилот проводился без участия команды АБ. Для заявки на оценку пилота нужен максимально детальный чек-лист дизайна. Так команда АБ сможет понять, может ли сделать математически корректную оценку эффекта.

#business #ab_testing

​​#competition

Немного похвастаюсь.

Поучаствовал в соревновании Цифровой Прорыв 2022. Задачкой была "Разработка концепции ранжирования районов города по уровню самодостаточности на основе больших данных". То есть, не классическое ML соревнование, а скорее соревнование презентаций, без явного лидерборда (хотя финальные оценки были для каждого). В принципе, подумал, что презентации я делаю лучше среднего DS'а, а анализирую лучше среднего консультанта, так что есть преимущество. Ну и плюсом было, что задачка интересная, а я когда-то занимался городским планированием в сфере наземного транспорта.

В итоге занял 1-е место.

Процесс примерно так проходил:
1. Выделил первые ключевые слова для поиска (self-sufficient city);
2. Наткнулся на концепцию 15(20)-минутного города, пошел уже по целевым словам этой идеи;
3. Отсюда получилась основная концепция - строим изохроны и рассчитываем количество жителей с доступностью к благу;
4. Реализовал первую версию в коде;
5. Стало понятно, что одной цифры мало, так что в итоге предложил еще и в матрицу BCG все уложить, взяв за оси среднюю доступность и разброс доступности;
6. Дошлифовал примеры, вытащил нужные данные, описал пути развития.

Итоговое решение здесь.

P.S. Несколько интересных ссылок по теме 20-минутного города и оценки городских пространств (раз, два, три, четыре)

#statistics

Сегодня поговорим об особенностях теста Манна-Уитни.

https://telegra.ph/O-Manne-Uitni-zamolvite-slovo-10-11

​​#statistics

А вы знали про связь теста Манна-Уитни и AUC?

Смутные сомнения такой связи меня посетили после того, как я узнал про то, что критерий Манна-Уитни проверяет стохастическое равенство (stochastic equality). То есть, следующую гипотезу H_0: P(X > Y) = P(X < Y).

Тут сразу возникла идея, что очень уж похоже на вероятность того, что значения из одного списка окажутся выше значений из другого. Потому полез смотреть о связи между понятиями. И, как оказалось, она достаточно прямая 🤯.

Формула связи между AUC и U статистикой такая:

AUC = U / (n_0 * n_1)

где U - U статистика, n_0 и n_1 - количество наблюдений в группах.

Собственно, это показывается в следующей статье.

Кстати, смысл тут весьма логичный - мы хотим проверить, как хорошо у нас отличаются два множества. То есть, оценить, одинаковы ли наши распределения (если одинаковы, то это соответствует тому, чтобы случайно назначать нашим элементам выборок их scores, следовательно, и вероятности будут равны 0.5 и для P(X > Y) и для P(X < Y)).

Еще я нашел красивую визуальную интерпретацию вывода (можно найти по ссылке). Эта визуализация в приложении к посту.

На ней все становится понятнее.

Сверху мы визуализируем ранги по двум выборкам (можем назначить одну за "позитивный" класс и вторую за "негативный").

Снизу переводим эти ранги в вид кривой на двух осях, где каждый шаг вверх - это позитивный класс на графике вверх, а шаг вправо - негативный. Это достаточно сильно напоминает то, как мы строим ROC-AUC кривую.

В итоге, получаем, что площадь зеленой фигуры в черном пунктирном прямоугольнике будет равна U-статистике. Масштабируя эту площадь на оси (то есть, поделив на (n_0 * n_1)), получаем нашу искомую площадь под фигурой, что и есть AUC (Area Under Curve).

Бонусом, нашел красивый пост-ноутбук "The ROC-AUC and the Mann-Whitney U-test" (там еще и доп. материалы есть, например, про доверительные интервалы для AUC).

​​#books

Какие времена - такие и книги ¯\_(ツ)_/¯

Сегодня напишу про книгу "Терапия беспокойства" доктора Дэвида Бернса. Автор практикующий терапевт в области КПТ (когнитивно-поведенческая терапия).

А КПТ, между прочим, показала доказанную эффективность во множестве исследований (результаты мета-анализа множества исследований). Так что метод рабочий.

В книге много примеров, описываются истории применения разных упражнений и способов справиться с тревогой. И весьма подробные описания этих упражнений (даже есть раздел про то, как правильно себе подобрать подходящий набор).

Только сразу скажу, что эффективнее реально выполнять упражнения, а не просто читать книгу. Тут работает правило "как потопаешь - так и полопаешь".

P.S. В мета-анализе увидел про g Хеджеса, как показатель величины эффекта. Кому интересно - можно почитать здесь.

#libraries

Fitter - простая библиотечка для поиска подходящего типа распределения. Берет данные, после чего фиттит все распределения из scipy, и выдает лучшие в плане суммы квадратов ошибок.

Дешево и сердито, но может пригодиться, если хотите прикинуть тип распределения ваших данных.

АБ-тесты. Интеграция в процесс пилотирования. Что делать. База пилотов
Цикл постов про АБ-тестирование. Пост 5

Как мы разобрались раньше, при внедрении АБ-тестирования в процесс пилотирования полезно создать базу пилотов. Хорошая база позволяет не только снизить риск некорректного финального решения о дальнейшем развитии проекта (можем отслеживать пересечения пилотов: чтобы в пилотной группе тестировался только один проект, а в контрольной - ни одного), но и сильно систематизировать знания компании о пилотах. А последнее потом очень помогает подбить эффект от работы команды АБ-тестирования за год 😉, а также найти проблемы в работе с пилотами (как технические, так и бизнесовые).

Каковы компоненты идеальной базы пилотов?

На самом деле, мы наполовину уже ответили на этот вопрос в предыдущем посте цикла, описав поля для чек-листа заявки на дизайн пилота. Все эти сведения будут полезны для базы пилотов. Полезно также присвоить им метку design (сведения, известные на момент дизайна пилота).

К этим данным стоит добавить:

- Параметры пилота, полученные после осуществления дизайна: расчетные даты границ пилота и препилота, полученные ошибки 1-го и 2-го рода, минимально детектируемый эффект, на который рассчитан дизайн, ID объектов пилотной и контрольной группы.

- Результаты оценки эффекта пилота, рассчитанные после его окончания: итоговый эффект пилота (или его отсутствие😐), итоговые параметры пилота (даты пилота/препилота, ошибки, ID объектов). Для этих данных полезно проставить метку estimation (этап оценки эффекта пилота).

Так мы видим идеальную базу. Будем рады комментариям и дополнениям!

Предыдущие посты цикла тут.
Продолжение следует!

#tech #ab_testing

#statistics

Нашел клевую штуку - интерактивную книгу "Дружелюбная эконометрика". Полистал, выглядит весьма интересно.

В качестве выдержки приведу "чек-лист эконометриста" из источника:
1. Нет ли в модели пропущенных существенных переменных?
2. Верна ли выбранная функциональная форма?
3. Нет ли в модели эндогенности в результате двусторонней причинно-следственной связи?
4. Не искажены ли выводы из-за сильных ошибок измерения регрессора?
5. Не забыли ли вы использовать состоятельные в данных условиях стандартные ошибки?
6. Если переменная интереса оказалась незначимой, не вызвана ли эта незначимость сильной мультиколлинеарностью?
7. Верно ли определены границы генеральной совокупности, на которую вы обобщаете выводы своей модели?

#statistics #AB

Сделал пересказ "Caveats and Limitations of A/B Testing at Growth Tech Companies".

Сразу скажу, что я согласен с автором лишь частично (мне кажется, что очень уж он напирает на то, что какие-то вещи решаются только мнением эксперта в области). Но сами идеи и аргументы весьма интересны.

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

P.S. Пересказ вышел весьма длинным (ближе к переводу), так что прикреплю ссылку на telegraph

https://telegra.ph/Caveats-and-Limitations-of-AB-Testing-at-Growth-Tech-Companies-11-17

АБ-тесты. Интеграция в процесс пилотирования. Что делать. Математическая методика дизайна и оценки результатов пилотов.
Цикл постов про АБ-тестирование. Пост 6

Ну вот, кажется, самая занудная часть постов про процессы закончена и можно перейти к методике. Последняя, как вы видите, занимает уже не так много места в общем процессе успешного запуска АБ в крупной компании 🙂 Но, тем не менее, остается основой для его появления.

Почти в любой методике АБ-тестирования для офлайна можно выделить следующие этапы:

- Этап 1. Дизайн пилота. Подбор пилотной и контрольной групп объектов (число и id), оптимальной длительности пилота, минимально-детектируемого эффекта с учетом вводных от бизнеса (чек-лист тут). Часть этих параметров обязательно будет ограничена - но только за счет свободы по остальным: либо эффект хочется поймать минимальный, но готовы взять в пилот много объектов, либо готовы взять в пилот мало объектов и провести его надо быстро, но эффект от проекта ждем бомбический.

Что важно учитывать в этом этапе:

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

- (б) ошибки 1-го и 2-го рода на препилотном периоде, равном планируемому периоду пилота. Ошибка 1-го рода - вероятность поймать эффект, когда его нет. Ошибка 2-го рода - вероятность не поймать эффект, когда он есть. И то, и другое не есть хорошо. Период препилота - возможность протестировать корректность алгоритма оценки эффекта заранее - в ситуации, когда мы знаем, что различий между группами нет. Важно определить границы допустимых ошибок 1-2го рода в вашей компании. Для офлайн экспериментов на нашей практике бенчмарком являются границы в ~15%.

- Этап 2. Расчет эффекта от проведенного пилота. На базе сравнения распределения значений целевой метрики (на которую воздействовали) в пилотной и контрольной группах. Важно, чтобы оценка эффекта здесь и на этапе дизайна (когда считаем ошибки) совпадала. Тогда расчеты будут согласованы.

Выстроить корректную оценку для офлайн-экспериментов сложнее, чем для онлайна, по ряду причин. Основные из них: мало объектов можем позволить себе в пилот (причем это “мало” может варьироваться от 100-150 объектов для одного пилота (если это, например, банкоматы), до 2-10 объектов (если это, например, сеть продуктового ритейла с небольшим числом магазинов🤓), объекты очень сильно отличаются друг от друга, на них сильно воздействуют внешние факторы (это влияет и на рост волатильности целевых метрик).

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

- Этап 3. Интерпретация эффекта. На предыдущем этапе мы получили какие-то цифры. В худшем случае - одну цифру (точечную оценку). Теперь нужно сделать вывод об успехе или неуспехе пилота. На основе точечной оценки делать такой вывод, разумеется, нельзя. Важно рассчитать доверительный интервал и сделать вывод о робастности полученного вами результата (статистической значимости полученного эффекта). Будет ли оценка эффекта в таком же пилоте, проведенном сразу после только что завершенного, близкой к полученной сейчас? Будет ли она такой для всех объектов в целом, если мы сделаем ролл-аут проекта, который пилотировали?

Решение о значимости результатов пилота и возможности его экстраполяции должно осуществляться на основе доверительного интервала эффекта пилота.

Причем не стоит недооценивать важность погружения в статметоды для корректной оценки доверительного интервала. Известны случаи, когда внешний консультант утверждал о положительном эффекте от своего проекта, манипулируя именно расчетом доверительного интервала.

Будьте бдительны и хороших вам АБ-тестов!

#tech #ab_testing

Продолжая говорить на тему прошлого материала, давайте обсудим плюсы и минусы data-driven подхода.

Основные преимущества подхода, основанного на данных, заключаются в том, что он помогает компаниям избежать предвзятости, принимать более точные решения и экономить время и ресурсы.

Основные недостатки заключаются в том, что сбор и анализ данных может быть дорогостоящим и отнимать много времени, а также в том, что не все данные являются точными и надежными.

Если более подробно говорить о преимуществах, то такой подход позволяет:
1) Избежать предвзятости: принимая решения на основе данных, предприятия могут избежать личных предубеждений, которые могут привести к неточному принятию решений;
2) Принимать более точные решения: данные могут дать понимание, которое предприятия не смогли бы получить только с помощью интуиции или опыта;
3) Экономить время и ресурсы: принятие решений на основе данных может сэкономить время и деньги, поскольку снижает необходимость проб и ошибок.

Соответственно, недостатки data-driven подхода заключаются в том, что он может быть:
1) Дорогостоящим и трудоемким для сбора и анализа данных: сбор достоверных данных может быть дорогостоящим и трудоемким. Анализ этих данных также может потребовать значительных ресурсов.
2) Не все данные будут точными или надежными: данные хороши лишь настолько, насколько они точны и надежны. Некачественные данные могут привести к неправильным выводам.
3) Чрезмерная зависимость от технологий: подход, основанный на данных, в значительной степени зависит от технологий, что означает, что в случае технических проблем процесс принятия решений может быть нарушен.

В целом, важность конкретных плюсов и минусов data-driven подхода, зависит от каждого конкретного бизнес-кейса. Тут, как со всем новым - лучше постепенно внедрять методы работы с данными и принятия решений на их основе. Это позволит "акклиматизироваться" и самим прочувствовать все плюсы и минусы.

Не удержался и тоже сгенерировал нечто забавное в новой нейронке для чатов от OpenAI.

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

What a wonderful time we live in 🧙‍♂️