Оптимизация промо-акций
Часть 2
Выбор ML-метрик и Loss
Часть 1: договорённости ДО начала проекта. https://news.1rj.ru/str/ml4value/8
Грабли #1: Неочевидные ML метрики 🎯
С таргетом определились. Потихоньку начинаем выстраивать цепочку:
Бизнес метрика --> Таргет --> ML-метрика --> Loss
Давайте обсудим, как выбрать ML-метрики, по которым мы будем оценивать модель. В этом деле важны 2 детали:
1. Насколько страшны большие ошибки прогноза (увеличение ошибки с 0 до 100 и с 100 до 200 съедает одинаковое кол-во прибыли?)
2. Одинакова ли стоимость ошибки в сторону недопрогноза и перепрогноза (ошибка в -100 и +100 заказов - это одинаково плохо для бизнеса?)
Первый пункт влияет на линейность функции ошибки (условно, RMSE или MAE). Если увеличение ошибки с 0 до 100 заказов не приводит к потере денег, а со 100 до 200 - приводит к огромной потере ---> скорее всего, вам нужно смотреть в сторону RMSE. В случае с прогнозом спроса, я бы сказал, что нужно выбирать более линейную функцию ошибки (MAE или схожую)
#pricing #timeseries
Часть 2
Выбор ML-метрик и Loss
Часть 1: договорённости ДО начала проекта. https://news.1rj.ru/str/ml4value/8
Грабли #1: Неочевидные ML метрики 🎯
С таргетом определились. Потихоньку начинаем выстраивать цепочку:
Бизнес метрика --> Таргет --> ML-метрика --> Loss
Давайте обсудим, как выбрать ML-метрики, по которым мы будем оценивать модель. В этом деле важны 2 детали:
1. Насколько страшны большие ошибки прогноза (увеличение ошибки с 0 до 100 и с 100 до 200 съедает одинаковое кол-во прибыли?)
2. Одинакова ли стоимость ошибки в сторону недопрогноза и перепрогноза (ошибка в -100 и +100 заказов - это одинаково плохо для бизнеса?)
Первый пункт влияет на линейность функции ошибки (условно, RMSE или MAE). Если увеличение ошибки с 0 до 100 заказов не приводит к потере денег, а со 100 до 200 - приводит к огромной потере ---> скорее всего, вам нужно смотреть в сторону RMSE. В случае с прогнозом спроса, я бы сказал, что нужно выбирать более линейную функцию ошибки (MAE или схожую)
#pricing #timeseries
👌2
Второй пункт про симметричность ошибки. Недопрогноз --> потеря прибыли из-за того, что товара но полке меньше, чем хотят купить. Перепрогноз - товаров слишком много. И они, например, могут портиться.
Тут начинается интересное:) В большинстве кейсов для ритейла лучше, если товара на полке > чем хотят купить. Пустые полки - самый большой страх. НО в категориях скоропортящихся товаров ситуация ровно обратная, т.к. ритейлер несет существенные потери из-за утилизации испорченных продуктов. +когда клиент видит гнилой банан/помидорку на полке - это не очень хорошо. Поэтому наша ML метрика будет зависеть от категории товара! 🍫/🍌
Важно: менеджеры понимат только симметричные метрики в интервале от 0 до 100%. Поэтому мы можем измерить 2 метрики:
MAPE = sum(|y - y_true|) / sum(y_true)
Bias = sum(y - y_true) / sum(y_true)
И будем говорить, что для большинства категорий мы хотим минимизировать MAPE при bias от +1% до +5%, а для скоропортящихся товаров - минимизировать MAPE при bias от -1% до -5%
(!) Не забываем, что нужно измерять MAPE и MAE для изменения прибыли, а не продаж. Иногда такую метрику называют WAPE - Weighted average percent error
Вывод:
Используйте метрики, нормированные от 0 до 100%, чтобы их было легко объяснить. Учитывайте стоимость ошибки в большую и меньшую стороны
Тут начинается интересное:) В большинстве кейсов для ритейла лучше, если товара на полке > чем хотят купить. Пустые полки - самый большой страх. НО в категориях скоропортящихся товаров ситуация ровно обратная, т.к. ритейлер несет существенные потери из-за утилизации испорченных продуктов. +когда клиент видит гнилой банан/помидорку на полке - это не очень хорошо. Поэтому наша ML метрика будет зависеть от категории товара! 🍫/🍌
Важно: менеджеры понимат только симметричные метрики в интервале от 0 до 100%. Поэтому мы можем измерить 2 метрики:
MAPE = sum(|y - y_true|) / sum(y_true)
Bias = sum(y - y_true) / sum(y_true)
И будем говорить, что для большинства категорий мы хотим минимизировать MAPE при bias от +1% до +5%, а для скоропортящихся товаров - минимизировать MAPE при bias от -1% до -5%
(!) Не забываем, что нужно измерять MAPE и MAE для изменения прибыли, а не продаж. Иногда такую метрику называют WAPE - Weighted average percent error
Вывод:
Используйте метрики, нормированные от 0 до 100%, чтобы их было легко объяснить. Учитывайте стоимость ошибки в большую и меньшую стороны
👍1
#оффтоп
"What one programmer can do in one month, two programmers can do in two months. – Frederick P. Brooks"
Радует, что в сообществе начинают появляться блогпосты о том, что DS должны быть более end-to-end, чтобы приносить value
Unpopular opinion: Data scientist should be more end-to-end
https://eugeneyan.com/writing/end-to-end-data-science/
TL;DR
Фокус на решении изначальной бизнес-проблемы, а не узких задачах про данные/модель/микросервис/.. позволяет:
1. Более глобально понимать бизнес - - > делать более эффективные решения
2. Делать те задачи, которые полезны бизнесу, а не те, которые кажутся полезными с точки зрения ML
3. Снизить число ненужных коммуникаций (DE - DS - ML engineer - ML Ops - РМ) и ускорить решение задачи
4. Повышает шанс довести задачу до конца, т.к. есть конкретный ответственный за неё человек, а не плеяда data-* специалистов
Имхо, абсолютно согласен. Я бы разделял только data-related обязанности и инфраструктурные.
Условно, делать базу данных и инфраструктуру микросервисов для инференса должны архитекторы / software инженеры. А вот все, что связанно непосредственно с обработкой данных и ML - работа data scientist-а
"What one programmer can do in one month, two programmers can do in two months. – Frederick P. Brooks"
Радует, что в сообществе начинают появляться блогпосты о том, что DS должны быть более end-to-end, чтобы приносить value
Unpopular opinion: Data scientist should be more end-to-end
https://eugeneyan.com/writing/end-to-end-data-science/
TL;DR
Фокус на решении изначальной бизнес-проблемы, а не узких задачах про данные/модель/микросервис/.. позволяет:
1. Более глобально понимать бизнес - - > делать более эффективные решения
2. Делать те задачи, которые полезны бизнесу, а не те, которые кажутся полезными с точки зрения ML
3. Снизить число ненужных коммуникаций (DE - DS - ML engineer - ML Ops - РМ) и ускорить решение задачи
4. Повышает шанс довести задачу до конца, т.к. есть конкретный ответственный за неё человек, а не плеяда data-* специалистов
Имхо, абсолютно согласен. Я бы разделял только data-related обязанности и инфраструктурные.
Условно, делать базу данных и инфраструктуру микросервисов для инференса должны архитекторы / software инженеры. А вот все, что связанно непосредственно с обработкой данных и ML - работа data scientist-а
eugeneyan.com
Unpopular Opinion: Data Scientists Should be More End-to-End
Why (and why not) be more end-to-end, how to, and Stitch Fix and Netflix's experience
👌1
Грабли #2: В реальности MSE - почти всегда не лучший выбор ❌
Что ж, мы определились, что ML-метрики не симметричны. В этом случае достаточно логично было лы использовать квантильный лосс
https://medium.com/analytics-vidhya/prediction-intervals-in-forecasting-quantile-loss-function-18f72501586f
Для скоропортящихся товаров прогнозируем, например, 45% квантиль, а для остальных - 55%. Кажется, что тут все очевидно, но есть одна проблема:
ML-модели достаточно хорошо прогнозируют каждый товар в отдельности, но в совокупности - нет
То есть, используя quantile loss c 55% квантилем, по всем товарам в совокупности вы далеко не всегда получите bias +5%.
Причина кроется в распределении продаж - как правило, это пуассоновское распределение с очень тяжелым хвостом. Поэтому помимо quantile loss я бы посоветовал также протестировать poisson loss и его более обобщенную версию - tweedie loss. Например, отдел прогноза спроса в Х5 Retail Group использует именно tweedie
Вывод
Loss крайне важен. Не пугайтесь тестировать нестандартные функции потерь
#metrics
Что ж, мы определились, что ML-метрики не симметричны. В этом случае достаточно логично было лы использовать квантильный лосс
https://medium.com/analytics-vidhya/prediction-intervals-in-forecasting-quantile-loss-function-18f72501586f
Для скоропортящихся товаров прогнозируем, например, 45% квантиль, а для остальных - 55%. Кажется, что тут все очевидно, но есть одна проблема:
ML-модели достаточно хорошо прогнозируют каждый товар в отдельности, но в совокупности - нет
То есть, используя quantile loss c 55% квантилем, по всем товарам в совокупности вы далеко не всегда получите bias +5%.
Причина кроется в распределении продаж - как правило, это пуассоновское распределение с очень тяжелым хвостом. Поэтому помимо quantile loss я бы посоветовал также протестировать poisson loss и его более обобщенную версию - tweedie loss. Например, отдел прогноза спроса в Х5 Retail Group использует именно tweedie
Вывод
Loss крайне важен. Не пугайтесь тестировать нестандартные функции потерь
#metrics
Medium
Prediction Intervals in Forecasting: Quantile Loss Function
In most real world prediction problems, the uncertainty in our predictions provides significant value
❤2
Оптимизация промо акций
Часть 3
ML - это не только модели
Хороший подход при построении модели таков:
Строим MVP (базовую модель) - - > тестируем её в бою - - > собираем фидбек/метрики - - > улучшаем
Повторяем цикл несколько раз
Представим, что мы построили MVP с помощью LightGBM и запустили наш ML проект в бой. И отправимся в увлекательное путешествие по граблям ✈️
#pricing #timeseries
Часть 3
ML - это не только модели
Хороший подход при построении модели таков:
Строим MVP (базовую модель) - - > тестируем её в бою - - > собираем фидбек/метрики - - > улучшаем
Повторяем цикл несколько раз
Представим, что мы построили MVP с помощью LightGBM и запустили наш ML проект в бой. И отправимся в увлекательное путешествие по граблям ✈️
#pricing #timeseries
Грабли #1: Иногда модель прогнозирует падение спроса при росте скидки 📉
- "Стоп.. Как такое возможно?" - спросите вы
- "Элементарно" - ответит любое решающее дерево
Вроде бы простейшую логику "при росте скидки растёт спрос" деревьям очень сложно выучить. Деревья в целом очень плохо учат около-линейные зависимости
К счастью, в LightGBM есть параметр monotone_constraints, который позволяет задать ограничение на монотонность по каждой фиче
Пофиксили.
- "Стоп.. Как такое возможно?" - спросите вы
- "Элементарно" - ответит любое решающее дерево
Вроде бы простейшую логику "при росте скидки растёт спрос" деревьям очень сложно выучить. Деревья в целом очень плохо учат около-линейные зависимости
К счастью, в LightGBM есть параметр monotone_constraints, который позволяет задать ограничение на монотонность по каждой фиче
Пофиксили.
Грабли #2: Почему-то модель прогнозирует меньше, чем есть на самом деле.. или проблемы в данных
Несмотря на то, что для большинства категорий мы прогнозируем 55% квантиль, итоговый прогноз в среднем < факта! То есть у нас отрицательный bias. Чтобы разобраться, что случилось, начинаем копаться в данных и видим, что под конец многих акций продажи падаюют в 0, хотя в начале акции они довольно хорошо росли
В ритейле и не только бывают out-of-stock: товар физически заканчивается на полке. Клиенты хотели бы купить больше товаров, но их нет. А нам нужно прогнозировать как раз то, сколько купили бы клиенты, если товаров было бы досатоточно. То есть в среднем таргет в модели < реального прироста продаж
Вариантов решения 2:
1. Если у нас есть данные по out-of-stock (обычно инвентаризация), то мы можем убрать из обучающей выборки те даты, когда товар заканчивался. А лучше еще и пару дней до этого момента
2. Если таких данных нет, то попытаться определить out-of-stock по данным. Для начала можно попробовать простейшие правила вроде:
- Продажи на промо < 1/2 средненедельных продаж без промо
- Продажи на второй неделе промо < 1/4 продаж на первой неделе
Есть шанс, что что-то из этих вариантов сработает
Несмотря на то, что для большинства категорий мы прогнозируем 55% квантиль, итоговый прогноз в среднем < факта! То есть у нас отрицательный bias. Чтобы разобраться, что случилось, начинаем копаться в данных и видим, что под конец многих акций продажи падаюют в 0, хотя в начале акции они довольно хорошо росли
В ритейле и не только бывают out-of-stock: товар физически заканчивается на полке. Клиенты хотели бы купить больше товаров, но их нет. А нам нужно прогнозировать как раз то, сколько купили бы клиенты, если товаров было бы досатоточно. То есть в среднем таргет в модели < реального прироста продаж
Вариантов решения 2:
1. Если у нас есть данные по out-of-stock (обычно инвентаризация), то мы можем убрать из обучающей выборки те даты, когда товар заканчивался. А лучше еще и пару дней до этого момента
2. Если таких данных нет, то попытаться определить out-of-stock по данным. Для начала можно попробовать простейшие правила вроде:
- Продажи на промо < 1/2 средненедельных продаж без промо
- Продажи на второй неделе промо < 1/4 продаж на первой неделе
Есть шанс, что что-то из этих вариантов сработает
Грабли #3: Прогноз продаж все еще меньше факта.. Или человеческий фактор 👩🔧
Но мы же вроде решили проблему out-of-stock. Модель работает хорошо: на валидации с метриками все в порядке. Где же может быть загвоздка?
Типичный флоу ML-продукта:
Данные -->
Модель + прогноз --> Рекомендации (какое промо проводить) -->
Реализация рекомендаций
Чтобы ваш ML-проект реально принес value для бизнеса, нужно убедиться, что в реальной жизни ваши рекомендации / прогнозы / что угодно реально используются. Мне очень нравится фраза одного моего друга-разработчика:
"Поменял цвет кнопки - зайди на сайт и проверь, что он изменился"
Так и в ML-проектах. Если вы что-то сделали - возьмите и физически проверьте, что это работает. Зайдите в магазин и проверьте, идет ли акция, которую порекомендовала завести ML-модель
Зашли в магазин - акции нет. Идем к менеджеру, который заводит промо:
"Ваша модель рекомендует слишком низкие скидки. Мой личный KPI - выручка, а не прибыль. Если я буду пользоваться вашей моделью, то стану меньше зарабатывать"
Упс. Вот это уже серьезная проблема. Не то что ваши лоссы и ml-метрики. Чтобы модель заработала, вероятно, нужно будет поменять KPI менеджеру - через директора(?) - иначе все, что вы делали - зря
Вывод
Проверяйте, как в реальности работает ваша модель / рекомендации. Обычно все проблемы в implementation details. Менеджер с другим KPI - лишь одна из возможных проблем
Но мы же вроде решили проблему out-of-stock. Модель работает хорошо: на валидации с метриками все в порядке. Где же может быть загвоздка?
Типичный флоу ML-продукта:
Данные -->
Модель + прогноз --> Рекомендации (какое промо проводить) -->
Реализация рекомендаций
Чтобы ваш ML-проект реально принес value для бизнеса, нужно убедиться, что в реальной жизни ваши рекомендации / прогнозы / что угодно реально используются. Мне очень нравится фраза одного моего друга-разработчика:
"Поменял цвет кнопки - зайди на сайт и проверь, что он изменился"
Так и в ML-проектах. Если вы что-то сделали - возьмите и физически проверьте, что это работает. Зайдите в магазин и проверьте, идет ли акция, которую порекомендовала завести ML-модель
Зашли в магазин - акции нет. Идем к менеджеру, который заводит промо:
"Ваша модель рекомендует слишком низкие скидки. Мой личный KPI - выручка, а не прибыль. Если я буду пользоваться вашей моделью, то стану меньше зарабатывать"
Упс. Вот это уже серьезная проблема. Не то что ваши лоссы и ml-метрики. Чтобы модель заработала, вероятно, нужно будет поменять KPI менеджеру - через директора(?) - иначе все, что вы делали - зря
Вывод
Проверяйте, как в реальности работает ваша модель / рекомендации. Обычно все проблемы в implementation details. Менеджер с другим KPI - лишь одна из возможных проблем
❤2
Грабли #4: локально оптимальное решение.. или каннибализация
Для новых участников канала напомню, что мы разбираем грабли в задаче оптимизации промо-акций на товары в продуктовом ритейле
Часть 1: Договорённости ДО начала проекта: https://news.1rj.ru/str/ml4value/8
Часть 2: Выбор ML-метрик и Loss: https://news.1rj.ru/str/ml4value/18
Часть 3: ML-это не только модели (сечас вы читаете пост №4 в этой части): https://news.1rj.ru/str/ml4value/24
Все мы знаем про проблему локальных минимумов у функций потерь. Есть куча способов и туториалов по тому, как эти проблему решать. Сегодня я расскажу про локально оптимальные ML-решения
Мы прогнозируем прирост прибыли для конкретного товара в зависимости от параметров акции. И выбираем argmax (profit) по параметрам акции. На самом деле, наше решение оптимально лишь для 1 конкретного товара
Но есть проблема: Каннибализация - рост продаж этого товара снижает продажи всех остальных товаров в категории
Простой пример: сделайте скидку 20% на кока-колу - продажи всех остальных газировок резко упадут. Может быть, 20% - оптимально для прибыли кока-колы в вакууме. Но мы же хотим повысить совокупные продажи магазина (или хотя бы продажи всех газировок). Поэтому, оптимизируя прибыль колы, мы находим лишь локально оптимальное решение
Подробно про решение проблемы каннибализации я рассказывал на конференции Х5:
https://www.youtube.com/watch?v=2djYDhQG_BM
TL;DR
Продажи категории товаров (газ. напитки) - функция от промо продаж в этой категории. Поэтому можно делать так:
Шаг 1. Прогнозируем продажи всех товаров на промо
Шаг 2. Суммируем их --> прогноз промо продаж в категории
Шаг 3. Обучаем простую модель, где таргет = все продажи в категории, а одна из фичей - промо продажи в категории. Зависимость, очевидно, нелинейная (см. рисунок ниже)
Шаг 4. Вуаля, мы получили, что прирост промо продаж с 1000 до 1200 (+200) увеличивает продажи категории лишь на +150. Каннибализация = 150 - 200 = -50. И ее нужно учитвывать при выборе параметров промо каждого товара
Вывод:
Помните, что ML-решения зачастую оптимальны лишь локально. И пытайтесь их приблизить к глобальному оптимуму
Для новых участников канала напомню, что мы разбираем грабли в задаче оптимизации промо-акций на товары в продуктовом ритейле
Часть 1: Договорённости ДО начала проекта: https://news.1rj.ru/str/ml4value/8
Часть 2: Выбор ML-метрик и Loss: https://news.1rj.ru/str/ml4value/18
Часть 3: ML-это не только модели (сечас вы читаете пост №4 в этой части): https://news.1rj.ru/str/ml4value/24
Все мы знаем про проблему локальных минимумов у функций потерь. Есть куча способов и туториалов по тому, как эти проблему решать. Сегодня я расскажу про локально оптимальные ML-решения
Мы прогнозируем прирост прибыли для конкретного товара в зависимости от параметров акции. И выбираем argmax (profit) по параметрам акции. На самом деле, наше решение оптимально лишь для 1 конкретного товара
Но есть проблема: Каннибализация - рост продаж этого товара снижает продажи всех остальных товаров в категории
Простой пример: сделайте скидку 20% на кока-колу - продажи всех остальных газировок резко упадут. Может быть, 20% - оптимально для прибыли кока-колы в вакууме. Но мы же хотим повысить совокупные продажи магазина (или хотя бы продажи всех газировок). Поэтому, оптимизируя прибыль колы, мы находим лишь локально оптимальное решение
Подробно про решение проблемы каннибализации я рассказывал на конференции Х5:
https://www.youtube.com/watch?v=2djYDhQG_BM
TL;DR
Продажи категории товаров (газ. напитки) - функция от промо продаж в этой категории. Поэтому можно делать так:
Шаг 1. Прогнозируем продажи всех товаров на промо
Шаг 2. Суммируем их --> прогноз промо продаж в категории
Шаг 3. Обучаем простую модель, где таргет = все продажи в категории, а одна из фичей - промо продажи в категории. Зависимость, очевидно, нелинейная (см. рисунок ниже)
Шаг 4. Вуаля, мы получили, что прирост промо продаж с 1000 до 1200 (+200) увеличивает продажи категории лишь на +150. Каннибализация = 150 - 200 = -50. И ее нужно учитвывать при выборе параметров промо каждого товара
Вывод:
Помните, что ML-решения зачастую оптимальны лишь локально. И пытайтесь их приблизить к глобальному оптимуму
Telegram
ML for Value / Ваня Максимов
Оптимизация промо-акций.
Часть 1
Зачем понимать ДО начала проекта, что хочет бизнес 💼
Представьте, что вы работаете DS-ом в крупном ритейлере (условно, Дикси/Пятерочка). К вам приходит менеджер и предлагает оптимизировать промо-акции с помощью ML, выбирая…
Часть 1
Зачем понимать ДО начала проекта, что хочет бизнес 💼
Представьте, что вы работаете DS-ом в крупном ритейлере (условно, Дикси/Пятерочка). К вам приходит менеджер и предлагает оптимизировать промо-акции с помощью ML, выбирая…
👌2
Оптимизация промо акций
Часть 4
Как померить бизнес-эффект? 💰💰
- Очевидно, А/В тестом!
- Да, но не все так просто. Опять мои любимые implementation details:)
Грабли #1: Выбор корректного теста
Классические А/В из учебников применяются не так часто, т.к. столкновение теории с реальностью разбивает первую вдребезги
Что же не так с А/В из учебника? Вспомним, что там пишут:
Шаг 1. Разбиваем юзеров на А и В группы.. Но стоп. Мы же делаем акции на товары в магазине, как же мы побьем юзеров? Правильно - никак. Нужно сплитить магазины
Шаг 2. Провести А/А тест. Обычно в лекциях это упоминается вскользь. Предполагают, что А/А тест всегда успешен. Но в кейсе со сплитом по магазинам зачастую это не так 🙅♀ Хьюстон, у нас проблемы
Причин может быть 2:
>> Магазинов мало (даже у Х5 и Магнита их ~20к по всей России) + А/В на полстраны вам запустить никто не даст. В итоге, дай бог, дадут 1-2к магазинов для теста
>> Магазины очень сильно отличаются (разные города, районы города, уровень зп,...)
Что же делать?
1. Можно стратифицированно сэмплировать магазины для А и В групп. Не рекомендую, т к очень сложно подобрать хорошие фичи, по которым вы будете стратифицировать (город? з/п? Население? Все сразу?)
2. Switch back тесты. Рекомендую.
Хорошая статья от DoorDash на эту тему:
https://www.google.com/amp/s/doordash.engineering/2019/02/20/experiment-rigor-for-switchback-experiment-analysis/amp/
TL;DR;
Раз в неделю (в идеале день, но у нас оффлайн ритейл) вы делаете сплитование заново. Если тест идёт 3 недели, то один и тот же магазин может на одной неделе быть в А группе, а на другой - в В. Это позволяет нивелировать различия между средними в А и В группах, и даже снизить дисперсию метрик (ускорить тест)
Вывод
Внимательно следите за тем, какую технику А/В вы используете
#pricing #timeseries
Часть 4
Как померить бизнес-эффект? 💰💰
- Очевидно, А/В тестом!
- Да, но не все так просто. Опять мои любимые implementation details:)
Грабли #1: Выбор корректного теста
Классические А/В из учебников применяются не так часто, т.к. столкновение теории с реальностью разбивает первую вдребезги
Что же не так с А/В из учебника? Вспомним, что там пишут:
Шаг 1. Разбиваем юзеров на А и В группы.. Но стоп. Мы же делаем акции на товары в магазине, как же мы побьем юзеров? Правильно - никак. Нужно сплитить магазины
Шаг 2. Провести А/А тест. Обычно в лекциях это упоминается вскользь. Предполагают, что А/А тест всегда успешен. Но в кейсе со сплитом по магазинам зачастую это не так 🙅♀ Хьюстон, у нас проблемы
Причин может быть 2:
>> Магазинов мало (даже у Х5 и Магнита их ~20к по всей России) + А/В на полстраны вам запустить никто не даст. В итоге, дай бог, дадут 1-2к магазинов для теста
>> Магазины очень сильно отличаются (разные города, районы города, уровень зп,...)
Что же делать?
1. Можно стратифицированно сэмплировать магазины для А и В групп. Не рекомендую, т к очень сложно подобрать хорошие фичи, по которым вы будете стратифицировать (город? з/п? Население? Все сразу?)
2. Switch back тесты. Рекомендую.
Хорошая статья от DoorDash на эту тему:
https://www.google.com/amp/s/doordash.engineering/2019/02/20/experiment-rigor-for-switchback-experiment-analysis/amp/
TL;DR;
Раз в неделю (в идеале день, но у нас оффлайн ритейл) вы делаете сплитование заново. Если тест идёт 3 недели, то один и тот же магазин может на одной неделе быть в А группе, а на другой - в В. Это позволяет нивелировать различия между средними в А и В группах, и даже снизить дисперсию метрик (ускорить тест)
Вывод
Внимательно следите за тем, какую технику А/В вы используете
#pricing #timeseries
👌1
Грабли #2: А/В тест длиною в жизнь
Допустим, мы выбрали относительно хороший дизайн А/В:
-- Метрика - прибыль на 1 магазин за 1 день
-- Switch back тест
-- Нам разрешили взять максимум 2к магазинов в тестовую группу
Всё, запускаем? Вообще, нужно бы посчитать, сколько недель нам нужно держать А/В. Считаем и получаем.. 2 года 😱
И тут мы приходим к необходимости ускорить А/В тест. Ускорить А/В = снизить дисперсию вашей метрики. Я оставлю ссылки на варианты решения этой проблемы и напишу TL; DR
Допустим, мы выбрали относительно хороший дизайн А/В:
-- Метрика - прибыль на 1 магазин за 1 день
-- Switch back тест
-- Нам разрешили взять максимум 2к магазинов в тестовую группу
Всё, запускаем? Вообще, нужно бы посчитать, сколько недель нам нужно держать А/В. Считаем и получаем.. 2 года 😱
И тут мы приходим к необходимости ускорить А/В тест. Ускорить А/В = снизить дисперсию вашей метрики. Я оставлю ссылки на варианты решения этой проблемы и напишу TL; DR
Ускорение А/В
Способ 1. Стратификация и CUPED
https://youtu.be/pZpUM08mv-E
Стратификация = Сначала посчитать средние в каждой группе (город/страна/сегмент юзеров по доходу/..), а потом взвещенно по кол-во наблюдений в группе усреднить
Тогда итоговое среднее останется таким же как и в классическом подходе, а дисперсия упадёт - - > тест нужно будет держать меньше
CUPED
В видео объяснение довольно сложное, но по сути вы просто строите линейную регрессию вашей целевой метрики на фичи
Важно (!): значение фичей должно быть известно ДО начала эксперимента
Пример фичей:
-- Целевая метрика магазина N недель назад
-- Город, в котором находится магазин
--...
Потом, вы из целевой метрики вычитание её прогноз. И считаете А/В на уже получившейся величине. Это сильно ускоряет тест, но снижает его интерпретируемость
P.S. Для любителей строгой мат.статистики - выше я описал лишь концепцию. Если вдаваться в детали, то текст выше в чем-то не совсем корректен. Но суть идеи передаёт отлично:)
Способ 1. Стратификация и CUPED
https://youtu.be/pZpUM08mv-E
Стратификация = Сначала посчитать средние в каждой группе (город/страна/сегмент юзеров по доходу/..), а потом взвещенно по кол-во наблюдений в группе усреднить
Тогда итоговое среднее останется таким же как и в классическом подходе, а дисперсия упадёт - - > тест нужно будет держать меньше
CUPED
В видео объяснение довольно сложное, но по сути вы просто строите линейную регрессию вашей целевой метрики на фичи
Важно (!): значение фичей должно быть известно ДО начала эксперимента
Пример фичей:
-- Целевая метрика магазина N недель назад
-- Город, в котором находится магазин
--...
Потом, вы из целевой метрики вычитание её прогноз. И считаете А/В на уже получившейся величине. Это сильно ускоряет тест, но снижает его интерпретируемость
P.S. Для любителей строгой мат.статистики - выше я описал лишь концепцию. Если вдаваться в детали, то текст выше в чем-то не совсем корректен. Но суть идеи передаёт отлично:)
YouTube
002. Увеличение чувствительности в A/B с помощью Cuped — Валерий Бабушкин
Доклад с совместного митапа Expfest x Яндекс.Практикум. Про эксперименты
❤1
Ускорение А/В
Способ 2. Выбрать другую метрику 😅
Да-да, вы не ослышались. Можно и иногда даже нужно выбирать другие метрики в А/В, чтобы ждать результатов не 2 года, а 2-3 недели
Прибыль = кол-во заказов * средняя прибыль с одного заказа
Невероятно, но факт (ну, почти всегда факт 😜): дисперсия этих множителей сильно меньше дисперсии прибыли
А значит, А/В успешен, если
хотя бы одна из метрик растёт, а другая - не падает
P.S. Но не забывайте про поправки (например, Бонферонни) для множественного тестирования гипотез
Способ 2. Выбрать другую метрику 😅
Да-да, вы не ослышались. Можно и иногда даже нужно выбирать другие метрики в А/В, чтобы ждать результатов не 2 года, а 2-3 недели
Прибыль = кол-во заказов * средняя прибыль с одного заказа
Невероятно, но факт (ну, почти всегда факт 😜): дисперсия этих множителей сильно меньше дисперсии прибыли
А значит, А/В успешен, если
хотя бы одна из метрик растёт, а другая - не падает
P.S. Но не забывайте про поправки (например, Бонферонни) для множественного тестирования гипотез