Ну а если вам понравилась тема про рейтинги, то подробности подхода Booking вы можете почитать здесь. Поставьте палец вверх, и в следующих постах я расскажу ещё много крутых вещей про рейтинги:)
https://nplus1.ru/news/2021/05/26/citing-nonreplicable-publications
Недавно наткнулся на статью о том, что "Статьи с невозпроизводимыми результатами цитруются чаще"
Интересно, что все больше научных трудов невоспроизводимы ~ им особо нельзя доверять. Из этого рисерча кажется что это проблема достигла действительно больших масштабов
Ещё более забавно то, что кто-то перевёл заголовок статьи на русский как "невоспроизводимость научных статей только увеличивает их цитируемость"
Переводчики этого рисерча сами допускают одну из логических ошибок. Вы наверняка её знаете: "Correlation does not imply causality". Авторы нашли некую корреляцию между воспроизводимостью результатов и цитируемостью. И написали в статье именно о корреляции. Намеренно снижая воспроизаодимость результатов, вы конечно же не повысите цитируемость статьи:)
Но переводчики рисерча недосмотрели / решили сделать более кликбейтный заголовок. Грустно.
Недавно наткнулся на статью о том, что "Статьи с невозпроизводимыми результатами цитруются чаще"
Интересно, что все больше научных трудов невоспроизводимы ~ им особо нельзя доверять. Из этого рисерча кажется что это проблема достигла действительно больших масштабов
Ещё более забавно то, что кто-то перевёл заголовок статьи на русский как "невоспроизводимость научных статей только увеличивает их цитируемость"
Переводчики этого рисерча сами допускают одну из логических ошибок. Вы наверняка её знаете: "Correlation does not imply causality". Авторы нашли некую корреляцию между воспроизводимостью результатов и цитируемостью. И написали в статье именно о корреляции. Намеренно снижая воспроизаодимость результатов, вы конечно же не повысите цитируемость статьи:)
Но переводчики рисерча недосмотрели / решили сделать более кликбейтный заголовок. Грустно.
N + 1 — главное издание о науке, технике и технологиях
Невоспроизводимость научных статей только увеличила их цитируемость
Этому не мешает даже публикация результатов проверки воспроизводимости
Но к чему я все это:
Когда вы как аналитик/DS показываете результаты своего рисерча (сравнения средних / коэффициенты линейной регрессии /..) бизнес-заказчику, то внимательно следите за разницей Correlation VS causality
Бизнес-заказчик вполне может воспринять корреляцию (из коэффициентов линейной регрессии) как причинно-следственную связь, когда это не так
Например, многие сервисы в случае плохого качества услуг (жалоба от клиента) дают ему скидку на следующий заказ. И ваша лог-регрессия легко может найти связь "плохое качество услуг" - - > рост вероятности совершить следующий заказ. Хотя на самом деле на вероятность следующего заказа влияет скидка!
Будьте осторожны 📈📉❗️
Когда вы как аналитик/DS показываете результаты своего рисерча (сравнения средних / коэффициенты линейной регрессии /..) бизнес-заказчику, то внимательно следите за разницей Correlation VS causality
Бизнес-заказчик вполне может воспринять корреляцию (из коэффициентов линейной регрессии) как причинно-следственную связь, когда это не так
Например, многие сервисы в случае плохого качества услуг (жалоба от клиента) дают ему скидку на следующий заказ. И ваша лог-регрессия легко может найти связь "плохое качество услуг" - - > рост вероятности совершить следующий заказ. Хотя на самом деле на вероятность следующего заказа влияет скидка!
Будьте осторожны 📈📉❗️
Около полугода назад я стал тимлидом команд персонализации и А/В в Delivery Club. И примерно с тех пор почти не было новых постов в канале 🙂
За это время произошло много интересного: мы запустили несколько крупных проектов, наняли крутых ребят (это заслуживает отдельного поста), я вновь был студентом, а ещё научился совершенно неожиданным для себя вещам
Кажется, настало время возобновить посты и поделиться этим интереснейшим опытом с вами!)
За это время произошло много интересного: мы запустили несколько крупных проектов, наняли крутых ребят (это заслуживает отдельного поста), я вновь был студентом, а ещё научился совершенно неожиданным для себя вещам
Кажется, настало время возобновить посты и поделиться этим интереснейшим опытом с вами!)
И для начала небольшое резюме того, что я понял за эти полгода:
1. Вдруг осознал, что на своем опыте смог проследить, зачем действительно нужны все best practice в техническом плане ⚙️
За 2 года в деливери мы прошли крутое путешествие от PostgreSQL --> python + jenkins --> metabase до всех современных buzzwords: зоопарк apache, poetry, docker, автотесты, микросервисная архитектура, Golang и много всего еще! Прямо на моих глазах поменялась бОльшая часть технического стека. И самое главное - я четко понимаю, почему и зачем мы его меняли
Если вкратце, то best practice в долгосрочной перспективе сильно упрощают жизнь и позволяют в целом масштабировать data science в компании. 1 DS может и в ноутбуке крутить ML, а вот 10 DS уже должны обзавестить всеми best practices
2. Agile работает
Спринты, планирование, задачи в jira, документация в конфлюенс и все-все и правда делает вашу жизнь проще и эффективнее в среднесрочной перспективе. Но сначала будет немного больно
3. Планировать нужно
Еще раз убедился, что лучше потратить 2 недели на брейншторм и планирование DS проекта, чем потом 2 месяца менять все на ходу
4. 💪Сильный продакт в DS проекте - ваш главный друг и залог успеха проекта
Одна и та же ML-модель (в моем случае recsys) может выглядеть и влиять на пользователя совершенно по-разному. Это очень сильно зависит от того, как ее результаты будут представлены пользователям
5. Вокруг очень много крутых ребят, у которых есть чему поучиться
Даже если вы Ян Лекун в ML, то всегда можно научиться хорошим практикам кода у разработчиков, продуктовому видению у менеджеров, пониманию метрик у аналитиков
1. Вдруг осознал, что на своем опыте смог проследить, зачем действительно нужны все best practice в техническом плане ⚙️
За 2 года в деливери мы прошли крутое путешествие от PostgreSQL --> python + jenkins --> metabase до всех современных buzzwords: зоопарк apache, poetry, docker, автотесты, микросервисная архитектура, Golang и много всего еще! Прямо на моих глазах поменялась бОльшая часть технического стека. И самое главное - я четко понимаю, почему и зачем мы его меняли
Если вкратце, то best practice в долгосрочной перспективе сильно упрощают жизнь и позволяют в целом масштабировать data science в компании. 1 DS может и в ноутбуке крутить ML, а вот 10 DS уже должны обзавестить всеми best practices
2. Agile работает
Спринты, планирование, задачи в jira, документация в конфлюенс и все-все и правда делает вашу жизнь проще и эффективнее в среднесрочной перспективе. Но сначала будет немного больно
3. Планировать нужно
Еще раз убедился, что лучше потратить 2 недели на брейншторм и планирование DS проекта, чем потом 2 месяца менять все на ходу
4. 💪Сильный продакт в DS проекте - ваш главный друг и залог успеха проекта
Одна и та же ML-модель (в моем случае recsys) может выглядеть и влиять на пользователя совершенно по-разному. Это очень сильно зависит от того, как ее результаты будут представлены пользователям
5. Вокруг очень много крутых ребят, у которых есть чему поучиться
Даже если вы Ян Лекун в ML, то всегда можно научиться хорошим практикам кода у разработчиков, продуктовому видению у менеджеров, пониманию метрик у аналитиков
Сегодня речь пойдёт про А/В платформы. И почему это не только про стат тесты
Думаю, многие видели статью "Hidden technical debt in ML systems" с её знаменитой картинкой
Вкратце статья о том, что мало построить ML-модели и показать SOTA качество. Нужно ещё и построить инфраструктуру вокруг модели, иначе все рискует обернуться полным провалом. Ведь изменение в логгировании данных, высокая нагрузка в проде и множество других вещей может сделать самую прекрасную модель совершенно бесполезной
Вышла статья в далёком 2015 году. На мой взгляд из 2021 года, там явно не хватает блока "А/В testing". Этот блок тянет на ещё одну статью, которую я бы назвал "Hidden technical debt in A/B testing systems"
Думаю, многие видели статью "Hidden technical debt in ML systems" с её знаменитой картинкой
Вкратце статья о том, что мало построить ML-модели и показать SOTA качество. Нужно ещё и построить инфраструктуру вокруг модели, иначе все рискует обернуться полным провалом. Ведь изменение в логгировании данных, высокая нагрузка в проде и множество других вещей может сделать самую прекрасную модель совершенно бесполезной
Вышла статья в далёком 2015 году. На мой взгляд из 2021 года, там явно не хватает блока "А/В testing". Этот блок тянет на ещё одну статью, которую я бы назвал "Hidden technical debt in A/B testing systems"
Часть 1. Разделение пользователей на группы
Почему-то все думают, что это самый простой этап: "Делим случайно и все дела"! Но на самом деле, это одно из самых сложных и спорных мест во всех А/В платформах
Опустим очень сложные кейсы, когда пользователи (наблюдения) зависят друг от друга. Как например, в логистике или соц сетях. Или кейс с оффлайн А/В тестированием, когда наблюдений мало и они очень разные: например, тесты над оффлайн магазинами
Пусть у вас есть самое классическое мобильное приложение: скажем, онлайн-магазин одежды. Даже в таком случае начнутся проблемы при разделении "Просто случайным образом"
Пусть вы проводите одновременно 2 теста на изменение в дизайне на главной странице. Очевидно, они влияют друг на друга - хорошо бы сделать так, чтобы эти тесты проводились на разных пользователях. Такой подход довольно популярен и называется двойным солированием. Упрощенно, вы сначала делите пользователей случайно с random_seed=Х (солью) условно на 100 групп. Группы 1-50 попадают в первый тест, а группы 51-100 - во второй. А потом внутри каждого теста делите пользователей второй раз с random_seed=Y (солью) на тест и контроль. При этом не стоит забывать, что у каждого теста должна быть своя вторая соль
Неплохо, мы смогли развести 2 влияющих друг на друга теста! Но тут нас подстерегает вторая проблема: если разводить все тесты, то у нас будет очень мало экспериментального пространства. Если 1 тест занимает в среднем 10 из 100 групп, то одновременно мы можем запускать всего 10 тестов - грустно😥
Тут нам может помочь подход со слоями от Гугла. Идея весьма проста: давайте разделим наше приложение на "слои". Внутри одного слоя эксперименты считаем зависимыми и разводим их = пользователи не пересекаются. А вот между слоями считаем эксперименты независимыми - пользователь может попасть сразу в N экспериментов в разных слоях. Слой - обычно логически отдельный кусок приложения (главная страница, поиск, экран оплаты заказа и т.д). Вуаля, мы только что смогли проводить не 10 параллельных экспериментов, а 10 * N, где N - число слоев
Я описал лишь пару сложностей и варианты их решения. Когда мы строили свою А/В платформу v1.0 в Delivery Club, таких неочевидных моментов было гораздо больше! Со времени написания статьи произошло множество улучшений в платформе. Но на мой взгляд, до сих пор одной из крупнейших побед остается именно корректное разделение пользователей на группы. Помните, что это, пожалуй, ключевой шаг, и начинайте делать А/В тесты в своей компании именно с него 😉
#ab
Почему-то все думают, что это самый простой этап: "Делим случайно и все дела"! Но на самом деле, это одно из самых сложных и спорных мест во всех А/В платформах
Опустим очень сложные кейсы, когда пользователи (наблюдения) зависят друг от друга. Как например, в логистике или соц сетях. Или кейс с оффлайн А/В тестированием, когда наблюдений мало и они очень разные: например, тесты над оффлайн магазинами
Пусть у вас есть самое классическое мобильное приложение: скажем, онлайн-магазин одежды. Даже в таком случае начнутся проблемы при разделении "Просто случайным образом"
Пусть вы проводите одновременно 2 теста на изменение в дизайне на главной странице. Очевидно, они влияют друг на друга - хорошо бы сделать так, чтобы эти тесты проводились на разных пользователях. Такой подход довольно популярен и называется двойным солированием. Упрощенно, вы сначала делите пользователей случайно с random_seed=Х (солью) условно на 100 групп. Группы 1-50 попадают в первый тест, а группы 51-100 - во второй. А потом внутри каждого теста делите пользователей второй раз с random_seed=Y (солью) на тест и контроль. При этом не стоит забывать, что у каждого теста должна быть своя вторая соль
Неплохо, мы смогли развести 2 влияющих друг на друга теста! Но тут нас подстерегает вторая проблема: если разводить все тесты, то у нас будет очень мало экспериментального пространства. Если 1 тест занимает в среднем 10 из 100 групп, то одновременно мы можем запускать всего 10 тестов - грустно😥
Тут нам может помочь подход со слоями от Гугла. Идея весьма проста: давайте разделим наше приложение на "слои". Внутри одного слоя эксперименты считаем зависимыми и разводим их = пользователи не пересекаются. А вот между слоями считаем эксперименты независимыми - пользователь может попасть сразу в N экспериментов в разных слоях. Слой - обычно логически отдельный кусок приложения (главная страница, поиск, экран оплаты заказа и т.д). Вуаля, мы только что смогли проводить не 10 параллельных экспериментов, а 10 * N, где N - число слоев
Я описал лишь пару сложностей и варианты их решения. Когда мы строили свою А/В платформу v1.0 в Delivery Club, таких неочевидных моментов было гораздо больше! Со времени написания статьи произошло множество улучшений в платформе. Но на мой взгляд, до сих пор одной из крупнейших побед остается именно корректное разделение пользователей на группы. Помните, что это, пожалуй, ключевой шаг, и начинайте делать А/В тесты в своей компании именно с него 😉
#ab
DoorDash
Experiment Rigor for Switchback Experiment Analysis - DoorDash
At DoorDash, we believe in learning from our marketplace of Consumers, Dashers, and Merchants and thus rely heavily on experimentation to make the data-driven product and business decisions.
👍2
Часть 2. Выбор метрик в А/В
В идеальном мире для дизайна А/В нужно взять 3 вида метрик:
- Приемочные (обычно 1-3) = те, по прокрасу которых мы принимаем решение об успехе эксперимента
- Контрольные = те, по которым мы понимаем, что ничего не сломалось. Ожидаемое поведение - нет стат значимых изменений
- Барьерные = если покрасились в красный, то тест неудачный не смотри ни на что. Обычно это какие-то крупные метрики всего бизнеса вроде ARPU
Во-первых, достаточно сложно обьяснить такое разделение менеджерам: стандартная проблема - хочется в "примемочные" запихнуть штук 20 метрик. А потом увидеть, что покрасилась конверсия из "одной кнопки в другую" и решить, что тест успешен
Во-вторых, очень сложно выбрать 1-3 приемочных метрики даже если вы аналитик, который все прекрасно понимает. Бизнес - довольно многогранная штука, его состояние тяжело аггрегировать всего 1-3 размерностями. Но это делать нужно! Иначе вы рискуете в приемочные метрики отправить кучу скоррелированных метрик + не забывайте про поправки на множественность. С ними есть мой любимый парадокс: если в тесте 1 метрика, то она стат значима, а если 10, то с поправками на множественность та же метрика уже НЕ стат значима
В-третьих, даже если вы договорились на 1-3 приемочные метрики, то внезапно может оказаться, что тест нужно крутить 3 месяца. Обычно тут как между Сциллой и Харибдой: либо метрика явно влияет на бизнес (как конверсия из захода в приложение в заказ), либо она достаточно чувствительная = держим тест 2 недели, а не 3 месяца. И как выбрать хорошую прокси метрику к вашей целевой - это целая наука
Так что цените ваших аналитиков, которые помогают выбрать правильные метрики, и прислушивайтесь к ним!)
#ab
В идеальном мире для дизайна А/В нужно взять 3 вида метрик:
- Приемочные (обычно 1-3) = те, по прокрасу которых мы принимаем решение об успехе эксперимента
- Контрольные = те, по которым мы понимаем, что ничего не сломалось. Ожидаемое поведение - нет стат значимых изменений
- Барьерные = если покрасились в красный, то тест неудачный не смотри ни на что. Обычно это какие-то крупные метрики всего бизнеса вроде ARPU
Во-первых, достаточно сложно обьяснить такое разделение менеджерам: стандартная проблема - хочется в "примемочные" запихнуть штук 20 метрик. А потом увидеть, что покрасилась конверсия из "одной кнопки в другую" и решить, что тест успешен
Во-вторых, очень сложно выбрать 1-3 приемочных метрики даже если вы аналитик, который все прекрасно понимает. Бизнес - довольно многогранная штука, его состояние тяжело аггрегировать всего 1-3 размерностями. Но это делать нужно! Иначе вы рискуете в приемочные метрики отправить кучу скоррелированных метрик + не забывайте про поправки на множественность. С ними есть мой любимый парадокс: если в тесте 1 метрика, то она стат значима, а если 10, то с поправками на множественность та же метрика уже НЕ стат значима
В-третьих, даже если вы договорились на 1-3 приемочные метрики, то внезапно может оказаться, что тест нужно крутить 3 месяца. Обычно тут как между Сциллой и Харибдой: либо метрика явно влияет на бизнес (как конверсия из захода в приложение в заказ), либо она достаточно чувствительная = держим тест 2 недели, а не 3 месяца. И как выбрать хорошую прокси метрику к вашей целевой - это целая наука
Так что цените ваших аналитиков, которые помогают выбрать правильные метрики, и прислушивайтесь к ним!)
#ab
Зачем нужен продакт менеджер в ML-проектах?
Много кто спрашивал в комментариях к прошлым постам об этом. Поэтому решил сделать отдельный пост на эту тему
Вообще, ML product manager - довольно редкий человек на рынке, особенно в России. И я очень рад, что мне с такими продактами удалось поработать. Сразу оговорюсь, что я в основном встречал продакт менеджеров, которые выполняют сразу 2 роли: продакта и проджекта (то есть формируют видение продукта и помогают вести проект) - дальше речь пойдет именно о таких людях. Итак, что же делает ML product manager?
1. Формирует бизнес-требования к ML-модели
В общем-то это тот человек, который должен разобраться, на какую бизнес-метрику мы хотим повлиять ML-проектом, и какие есть ограничения
Пример
Классика: вы оптимизировали в рекомендациях кол-во кликов (оно даже и в А/В выросло!), но что-то бизнес не очень рад: ведь заказы упали
2. Собирает всех вовлеченных в проект
Если вы думаете, что "все вовлеченные" - это data scientist, data engineer и еще пара data-***, то вы глубоко ошибаетесь)
Внезапно, практически на любой ML-проект нужны:
- Классические бэк/фронт разработчики
- UX-рисерчеры, чтобы хотя бы на макетах финального продукта (спойлер: это НЕ ml-модель) понять, нужно ли пользователям именно это
- Дизайнеры, чтобы нарисовать эти макеты и финальный продукт
- Аналитики, которые помогут найти "слабые места" в продукте, где будет больше всего выхлопа от ML
- Список может продолжиться еще дальше
Примеры
Согласитесь, будет неприятно узнать на этапе выкатки в прод, что бэкенд разработчики были не в курсе всего происходящего, и что бэкенд не способен сейчас поддерживать ваше ML-решение?
Или что ваше мега-решение по рекомендациям фильмов с precision@5 = 90% (что вы и оптимизировали) вдруг окажется не слишком хорошим, потому что дизайнеры нарисовали карточку рекомендаций с всего 2 фильмами вместо ожидаемых вами 5?
3. Помогает формировать гипотезы ДО начала разработки
Как же много ML-моделей не доходит до прода, потому что оказываются ненужными конечному пользователю. Поэтому важно собрать всех вместе и понять, на какие метрики мы должны влияеть (продакт), в какие точки продукта стоит приложить усилия (тут помогут аналитики), каким должен быть дизайн и еще бы проверить это все хотя бы на UX-макетах
Пример
Непопсовая классика: вы вырастили конверсию из показа блока "Похожие товары" в заказ на 20%! Ну круто же! Но этими рекомендациями пользуются <1% пользователей, потому что они расположены на далеееком и никому неизвестном экране приложения
4. Помогает формировать бэклог "широкой" команды проекта
Не нуждается в представлении, поэтому сразу:
Пример
Сформировать бэклог всех вовлеченных супер важно, иначе вы можете выкатить свой мега крутой ML-микросервис, но бэк сможет с ним интегрироваться через 2 месяца, а фронты отрисовать - через 3
5. И еще бесконечно много вещей!
Цените ваших продактов - они решают миллион маленьких сложностей, о которы вы даже не догадываетесь. Неплохой список таких сложностей/рисков можно почитать вот тут
Много кто спрашивал в комментариях к прошлым постам об этом. Поэтому решил сделать отдельный пост на эту тему
Вообще, ML product manager - довольно редкий человек на рынке, особенно в России. И я очень рад, что мне с такими продактами удалось поработать. Сразу оговорюсь, что я в основном встречал продакт менеджеров, которые выполняют сразу 2 роли: продакта и проджекта (то есть формируют видение продукта и помогают вести проект) - дальше речь пойдет именно о таких людях. Итак, что же делает ML product manager?
1. Формирует бизнес-требования к ML-модели
В общем-то это тот человек, который должен разобраться, на какую бизнес-метрику мы хотим повлиять ML-проектом, и какие есть ограничения
Пример
Классика: вы оптимизировали в рекомендациях кол-во кликов (оно даже и в А/В выросло!), но что-то бизнес не очень рад: ведь заказы упали
2. Собирает всех вовлеченных в проект
Если вы думаете, что "все вовлеченные" - это data scientist, data engineer и еще пара data-***, то вы глубоко ошибаетесь)
Внезапно, практически на любой ML-проект нужны:
- Классические бэк/фронт разработчики
- UX-рисерчеры, чтобы хотя бы на макетах финального продукта (спойлер: это НЕ ml-модель) понять, нужно ли пользователям именно это
- Дизайнеры, чтобы нарисовать эти макеты и финальный продукт
- Аналитики, которые помогут найти "слабые места" в продукте, где будет больше всего выхлопа от ML
- Список может продолжиться еще дальше
Примеры
Согласитесь, будет неприятно узнать на этапе выкатки в прод, что бэкенд разработчики были не в курсе всего происходящего, и что бэкенд не способен сейчас поддерживать ваше ML-решение?
Или что ваше мега-решение по рекомендациям фильмов с precision@5 = 90% (что вы и оптимизировали) вдруг окажется не слишком хорошим, потому что дизайнеры нарисовали карточку рекомендаций с всего 2 фильмами вместо ожидаемых вами 5?
3. Помогает формировать гипотезы ДО начала разработки
Как же много ML-моделей не доходит до прода, потому что оказываются ненужными конечному пользователю. Поэтому важно собрать всех вместе и понять, на какие метрики мы должны влияеть (продакт), в какие точки продукта стоит приложить усилия (тут помогут аналитики), каким должен быть дизайн и еще бы проверить это все хотя бы на UX-макетах
Пример
Непопсовая классика: вы вырастили конверсию из показа блока "Похожие товары" в заказ на 20%! Ну круто же! Но этими рекомендациями пользуются <1% пользователей, потому что они расположены на далеееком и никому неизвестном экране приложения
4. Помогает формировать бэклог "широкой" команды проекта
Не нуждается в представлении, поэтому сразу:
Пример
Сформировать бэклог всех вовлеченных супер важно, иначе вы можете выкатить свой мега крутой ML-микросервис, но бэк сможет с ним интегрироваться через 2 месяца, а фронты отрисовать - через 3
5. И еще бесконечно много вещей!
Цените ваших продактов - они решают миллион маленьких сложностей, о которы вы даже не догадываетесь. Неплохой список таких сложностей/рисков можно почитать вот тут
skillsetter.io
Риски проекта: анализ, оценка и стратегии управления
Разбираем виды рисков и выбираем стратегии управления.
ML for Value / Ваня Максимов pinned «Зачем нужен продакт менеджер в ML-проектах? Много кто спрашивал в комментариях к прошлым постам об этом. Поэтому решил сделать отдельный пост на эту тему Вообще, ML product manager - довольно редкий человек на рынке, особенно в России. И я очень рад, что…»
ML for Value / Ваня Максимов pinned «Привет! Меня зовут Иван Максимов, @Ivan_maksimov. Достаточно долгое время я работал в data science консалтинге: делал оптимизацию промо-акций, аплифт, определение оптимальной локации и многое другое. А сейчас уже около года развиваю ML в Delivery Club Наверняка…»
Badass data scientist
Этот пост начинался как список того, без чего точно не стоит приступать к любой ds-задаче. Но в итоге превратился в список для badass data scientist - но иногда лучше действительно им побыть:)
1. Не делай задачу, пока нет ее четкого описания
Навеяно просмотром десятков курсов, кагглом и ютуб-разбором бизнес задач. Почему-то все в них говорят что-то вроде: "К нам пришел бизнес-заказчик и попросил решить такую задачу: кому отправлять e-mail со скидкой 20%, чтобы минимизировать отток пользователей? Мы готовы тратить на удержание пользователя не более Х руб, стоимость смс - Y руб, общий бюджет - Z рублей. Будет круто, если сократим отток с 12% до 7%"
В реальности это же совсем не так! Обычно бизнес хочет "повысить эффективность скидок". Хорошо, если еще накидывает варианты реализации: предотвращать отток, реактивировать спящих клиентов, повышать чек существующих и т д. Но, как правило, из первого описания задачи вообще не понятно, что от вас хотят, и что такое "успех" в решении задачи
Поэтому до того, как начинать что-то делать, обязательно потратьте время на обсуждение задачи с бизнес-заказчиком. Если нужно 10 встреч - проведите 10 встреч, чтобы досконально выяснить цель и критерии успеха
2. Не делай задачу, пока нет четкого критерия "успеха"
Это должна быть одна (максимум две) метрики + их ожидаемый прирост + сроки
Иначе можно легко и стат значимо (!) повысить конверсию "из кнопки Х в кнопку Y" на 0.001% за полгода. Но вряд ли это можно назвать успехом
3. Не делай задачу, если сомневаешься в ее бизнес-эффекте
ML - довольно дорогостоящая для внедрения штука: сервера, время дата саентистов и других вовлеченных в проект. Если вы сомневаетесь, что действительно сможете улучшить бизнес - не делайте это
4. Не делай задачу от бизнеса, пока нет одного ответственного за нее от бизнеса
Иначе рискуешь делать непонятно что, непонятно к каким срокам. И не факт, что это потом решат внедрять в бизнес-процесс
Но не стоит уходить и в другую крайность, которая описана в этой статье
Вроде бы все это очевидные вещи, но об них все мы очень часто спотыкаемся 😏
Этот пост начинался как список того, без чего точно не стоит приступать к любой ds-задаче. Но в итоге превратился в список для badass data scientist - но иногда лучше действительно им побыть:)
1. Не делай задачу, пока нет ее четкого описания
Навеяно просмотром десятков курсов, кагглом и ютуб-разбором бизнес задач. Почему-то все в них говорят что-то вроде: "К нам пришел бизнес-заказчик и попросил решить такую задачу: кому отправлять e-mail со скидкой 20%, чтобы минимизировать отток пользователей? Мы готовы тратить на удержание пользователя не более Х руб, стоимость смс - Y руб, общий бюджет - Z рублей. Будет круто, если сократим отток с 12% до 7%"
В реальности это же совсем не так! Обычно бизнес хочет "повысить эффективность скидок". Хорошо, если еще накидывает варианты реализации: предотвращать отток, реактивировать спящих клиентов, повышать чек существующих и т д. Но, как правило, из первого описания задачи вообще не понятно, что от вас хотят, и что такое "успех" в решении задачи
Поэтому до того, как начинать что-то делать, обязательно потратьте время на обсуждение задачи с бизнес-заказчиком. Если нужно 10 встреч - проведите 10 встреч, чтобы досконально выяснить цель и критерии успеха
2. Не делай задачу, пока нет четкого критерия "успеха"
Это должна быть одна (максимум две) метрики + их ожидаемый прирост + сроки
Иначе можно легко и стат значимо (!) повысить конверсию "из кнопки Х в кнопку Y" на 0.001% за полгода. Но вряд ли это можно назвать успехом
3. Не делай задачу, если сомневаешься в ее бизнес-эффекте
ML - довольно дорогостоящая для внедрения штука: сервера, время дата саентистов и других вовлеченных в проект. Если вы сомневаетесь, что действительно сможете улучшить бизнес - не делайте это
4. Не делай задачу от бизнеса, пока нет одного ответственного за нее от бизнеса
Иначе рискуешь делать непонятно что, непонятно к каким срокам. И не факт, что это потом решат внедрять в бизнес-процесс
Но не стоит уходить и в другую крайность, которая описана в этой статье
Вроде бы все это очевидные вещи, но об них все мы очень часто спотыкаемся 😏
Medium
How to be a bad data scientist!
A few stereotype of peoples not ready to be data scientists and some ideas on how to improve.
О ценности культуры А/В тестирования и не только
Думаю многие слышали, что в компании хорошо бы внедрять MLOPS, единый feature store, code review и многие другие "правила хорошей работы с данными и моделями"
При этом про "правила хорошего А/В" говорят не так активно. Сегодня я покажу, сколько может стоить "маленькая ошибка" при проведении А/В теста
Представьте, что Junior аналитик решил задизайнить А/В тест. Он знает про классический А/В эксперимент из учебника с Т-статистикой (что уже неплохо на самом деле!)
Но продакты просят его сделать А/В/С тест и сравнить там всего 2 метрики - конверсию и средний чек. При этом хотят быть "очень уверенными" в результатах
(Да-да, это то же самое, когда хотят 100% точность классификации)
Junior решил полностью последовать их просьбе ("мы ведь совсем капельку поменяем параметры А/В теста!") и выбрал:
alpha=1% (для уверенности)
power=90% (для уверенности-2)
кол-во групп = 3
кол-во метрик = 2
Напомню, что базовый кейс из учебника - это:
alpha=5%
power=80%
кол-во групп = 2
кол-во метрик = 1
#ab
Думаю многие слышали, что в компании хорошо бы внедрять MLOPS, единый feature store, code review и многие другие "правила хорошей работы с данными и моделями"
При этом про "правила хорошего А/В" говорят не так активно. Сегодня я покажу, сколько может стоить "маленькая ошибка" при проведении А/В теста
Представьте, что Junior аналитик решил задизайнить А/В тест. Он знает про классический А/В эксперимент из учебника с Т-статистикой (что уже неплохо на самом деле!)
Но продакты просят его сделать А/В/С тест и сравнить там всего 2 метрики - конверсию и средний чек. При этом хотят быть "очень уверенными" в результатах
(Да-да, это то же самое, когда хотят 100% точность классификации)
Junior решил полностью последовать их просьбе ("мы ведь совсем капельку поменяем параметры А/В теста!") и выбрал:
alpha=1% (для уверенности)
power=90% (для уверенности-2)
кол-во групп = 3
кол-во метрик = 2
Напомню, что базовый кейс из учебника - это:
alpha=5%
power=80%
кол-во групп = 2
кол-во метрик = 1
#ab
Как думаете, во сколько раз больше наблюдений ему потребуется по сравнению с базовым кейсом из учебника?
Anonymous Poll
2%
1.5
2%
2
6%
4
13%
10
13%
15
33%
30
31%
50
Долго ли, коротко ли, но наконец я возобновил выступления на конференциях!) Ближайшая будет уже во вторник в 20:00
Там я буду рассказывать про ускорение А/В тестов - приходите, буду очень рад увидеть вас среди зрителей :)
Там я буду рассказывать про ускорение А/В тестов - приходите, буду очень рад увидеть вас среди зрителей :)
Forwarded from ML in Marketing - events & meetups
Всем привет!
В этот вторник (26-го октября) проведем совместный online митап (@leands и @mlinmarketing)
🔥 Поговорим про А/Б тестирование
🔸20:00 - 21:00
🎤 спикер: Иван Максимов,
- Data Science Team Lead at Delivery Club
- автор телеграм канала @ml4value
📋 тема: 13 способов ускорить А/В тест, или "Не CUPED-ом единым"
📋 описание: Многие аналитики для ускорения А/В тестов в первую очередь используют достаточно сложные статистические приемы (например, CUPED). Однако существует огромное множество более простых и эффективных способов ускорить А/В тесты. Мы обсудим 13 таких способов: от улучшения процесса дизайна теста до применения стат критерия и финального принятия решения о выкатке/нет фичи. А также оценим потенциальный trade-off эффект-затраты от внедрения каждого из способов.
— — —
🗓 26 октября, начало в 20:00 мск, Вторник
🌐 ОНЛАЙН
Регистрация на мероприятие тут
Добавляйте в календарь, ссылка придет на почту перед началом митапа
В этот вторник (26-го октября) проведем совместный online митап (@leands и @mlinmarketing)
🔥 Поговорим про А/Б тестирование
🔸20:00 - 21:00
🎤 спикер: Иван Максимов,
- Data Science Team Lead at Delivery Club
- автор телеграм канала @ml4value
📋 тема: 13 способов ускорить А/В тест, или "Не CUPED-ом единым"
📋 описание: Многие аналитики для ускорения А/В тестов в первую очередь используют достаточно сложные статистические приемы (например, CUPED). Однако существует огромное множество более простых и эффективных способов ускорить А/В тесты. Мы обсудим 13 таких способов: от улучшения процесса дизайна теста до применения стат критерия и финального принятия решения о выкатке/нет фичи. А также оценим потенциальный trade-off эффект-затраты от внедрения каждого из способов.
— — —
🗓 26 октября, начало в 20:00 мск, Вторник
🌐 ОНЛАЙН
Регистрация на мероприятие тут
Добавляйте в календарь, ссылка придет на почту перед началом митапа
👍1