Оптимизация стратегии продвижения с помощью Starbucks

0 Введение

Пользователи мобильного приложения Starbucks rewards получают предложение раз в несколько дней. Предложение может быть любым: от чисто информационного содержания до реальной скидки или промо-акции «купи один - получи один бесплатно». Однако предложения рассылаются не всем пользователям, и даже те, кто их получает, могут не получить одинаковые предложения.

Одна из целей Starbucks, которая рассылает эти предложения, - увеличить отклик пользователей мобильного приложения. С одной стороны, ответ может относиться к частоте транзакций, а с другой - к потраченным деньгам. Однако, если и как пользователи ответят, зависит от типов отправляемых предложений, а также от конкретных (социально) демографических характеристик пользователя. Фактически, несоответствие между этими двумя критериями может существенно повлиять на финансовые показатели Starbucks.

1 Цель проекта

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

Основной показатель, необходимый для сравнения различных решений рассматриваемой проблемы, - это транзакция прибыль на пользователя, полученная Starbucks. Это определяется следующим образом:

Где:

• PPU = (транзакция) прибыль на пользователя
• O = Набор предложений
• D = Демографические данные пользователя
• A = Общая потраченная сумма
• R = общая полученная награда
• T = общее количество транзакций
• U = Пользователь
• N = количество пользователей

2 набора данных

Используемые наборы данных содержат только смоделированные данные из Starbucks, которые имитируют поведение клиентов в мобильном приложении Starbucks rewards, включая события транзакций и ответ на предложение. Он был предоставлен Starbucks в рамках Программы Nanodegreee Data Scientist от Udacity. Обратите внимание, что это очень упрощенная версия реальных событий отслеживания в приложении, поскольку оно рассматривает только один продукт, тогда как Starbucks продает их десятки.

Данные разделены на три файла:

- portfolio.json
- profile.json
- transcript.json

Данные портфеля содержат данные о портфеле предложений Starbucks, включая метаданные, такие как тип предложения, продолжительность и подлежащие выплате вознаграждения. В данных профиля хранятся демографические данные пользователей приложения, например пол, возраст и доход. Он также содержит данные о датах регистрации учетной записи приложения. И наконец, что не менее важно, данные стенограммы предоставляют данные о транзакциях, т. Е. О покупках (включая временные метки), а также о событиях, связанных с предложениями, например о том, когда предложения принимаются, просматриваются. или завершено.

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

3 Исследовательский анализ

3.1 Портфолио

Портфель предложений Starbucks содержит десять различных предложений в трех различных категориях: предложения «купи один - получи один бесплатно» (BOGO) (4x), информационные предложения (2x) и скидки (4x). BOGO и информационные предложения не гарантируют положительный эффект на финансовый результат, так как имеют минимальную норму прибыли 0%. Это связано с тем, что вознаграждения за выполнение предложений BOGO равны сумме, уплаченной за выполнение предложения в первую очередь, и что информационные предложения не возвращают никаких вознаграждений. Напротив, скидки - это единственные предложения с положительной минимальной маржой прибыли для завершенных предложений (не менее 71%), поскольку их сложность (сумма, которую необходимо накопить до получения вознаграждения) составляет в среднем довольно высокие, а вознаграждения относительно низкие.

3.2 Профиль

В данных профиля хранятся данные 17 000 пользователей. Средний пользователь приложения Starbucks довольно старый, его средний возраст составляет 55 лет, что примерно в 1,44 раза больше возраста среднего американца. Он также зарабатывает более чем вдвое больше, чем средний американец (64 000 долларов против 31 099 долларов) и начал использовать приложение примерно полтора года назад. 13% пользователей мобильных приложений вообще не предоставляют никакой дополнительной демографической информации.

3.3 Расшифровка стенограммы

Каждая запись описывает 1 из 306 137 событий из 17 000 зарегистрированных пользователей приложения Starbucks за период 29 дней. Пользователи могут получать, просматривать и заполнять предложения или совершать транзакции. Каждый раз, когда пользователь выполняет 1 из 10 предложений, доступных в портфеле Starbucks, он получает вознаграждение. Однако получение вознаграждения означает сначала совершение транзакций, пока не будет накоплена сумма, указанная в предложении.

Отправка предложений из портфеля происходила в 6 различных дней. Несмотря на то, что 99% всех пользователей приложения получали предложение хотя бы один раз, мы наблюдаем только общий коэффициент конверсии 57%. Пользователи приложения Starbucks совершают транзакции каждые 3–4 дня, в течение которых они тратят в среднем 13,68 доллара. Каждые ~ 3 из этих транзакций завершают предложение, в результате чего получают среднее вознаграждение в размере 4,75 доллара. Поскольку распределение суммы транзакций между пользователями в значительной степени искажены, Starbucks все еще может достичь общей маржи прибыли своих предложений в размере 91%.

На рисунке 5 показано, как события приложения распределяются во времени. Большинство предложений просмотров приходится на день отправки. Фактический пик транзакций с небольшой задержкой в течение нескольких дней после отправки предложения. Более короткие промежутки времени между отправками предложений после 14-го дня, по-видимому, вызывают большее общее количество транзакций. Увеличение объемов транзакций также увеличивает доходы, как показано на Рисунке 6 ниже. Тем не менее, прибыль от транзакции на пользователя остается стабильной, поскольку увеличение количества предложений также приводит к большему количеству выполненных предложений, а значит, более частым выплатам вознаграждений.

Несмотря на то, что общий коэффициент конверсии предложений составляет 57% (который для простоты рассчитывается на основе событий получения и завершения), весьма вероятно, что предложения и типы предложений работают по-разному. На рисунке 7 показано их прямое сравнение. Обратите внимание, что информационные предложения не были включены, поскольку в них нет событий завершения.

Скидки представляют собой тип предложений, которые выполняются чаще по сравнению с предложениями купи один - получи один бесплатно (60% против Коэффициент конверсии 51%). Коэффициент конверсии стандартное отклонение (12,27% против 6,39%), а также визуальный осмотр выше показывают, что это действительно зависит от эффективности отдельных предложений. Таким образом, BOGO явно выигрывает с точки зрения согласованности.

4 Предварительная обработка

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

4.1 Данные портфеля

Поскольку предложения из Starbucks предлагают портфель предложений, как правило, довольно длинные в данном наборе данных, я добавляю короткую версию «offer_id», чтобы улучшить удобочитаемость.

4.2 Данные профиля

Я также добавляю еще один столбец во фрейм данных профиля, который использует дату регистрации учетной записи приложения для выражения возраста пользователя приложения. К сожалению, невозможно определить точный возраст участника на момент просмотра или завершения предложения, поскольку временные метки в данных стенограммы указаны только в часах, тогда как данные профиля содержат даты. Отсутствующие значения в столбце «возраст» были заменены значением «118». Я отменяю эту замену, поскольку возраст следует порядковой шкале, и замена пропущенных значений большим числом не кажется значимой или даже не сохраняет ее естественный порядок.

4.3 Расшифровка стенограммы

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

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

Чтобы узнать, действительно ли транзакция относится к периоду предложения, т. Е. Если на транзакцию действительно влияет предложение, нам нужно найти эти транзакции с отметкой времени между «просмотренным предложением» и «предложением завершено». " событие. В ситуациях, когда человек никогда не завершает предложение, он все равно может совершать транзакции из-за просмотра предложения. Я использую дату истечения срока действия предложения как верхний предел для этого. Дата истечения срока действия может быть рассчитана путем добавления срока действия предложения в часах к отметке времени, когда предложение было получено. Здесь важно отметить, что транзакция связана с предложением только в том случае, если пользователь действительно просматривал предложение ранее.

Наконец, мы получаем фрейм данных, где каждая запись представляет транзакцию, включая выплаченную сумму и полученное вознаграждение (в случае, если транзакция завершила предложение). Мы также знаем, повлияло ли на транзакцию предложение , и если да, то какой тип предложения (-ий) использовался. И наконец, что не менее важно, такие столбцы, как «сложность» и «reward_expected», показывают, насколько сложно было выполнить предложение для пользователя и что он собирается получить в ответ .

5 Методология

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

Есть два альтернативных подхода, которые я хотел бы сравнить, чтобы решить проблему максимизации прибыли для Starbucks:

1. Логика рассылки предложений Starbucks основана на комбинации предложений с наибольшим PPU на демографическую группу
2. Логика рассылки предложений Starbucks основана на комбинации предложений с наибольшим PPU , прогнозируемым регрессионной моделью

Обе модели сравниваются не только друг с другом, но и с эталонным тестом, установленным PPU, который в настоящее время установлен Starbucks.

Модель 6 демографических групп¶

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

6.1 Реализация

Для оценки PPU на основе демографических групп я выполнил следующие шаги:

• Создайте три новые переменные для столбцов профиля «возраст», «доход» и «member_age», создав по 4 ячейки для каждой из их квантилей («пол» уже представлен как функция группирования с четырьмя уникальными значениями в кодировке как строка: 'M', 'F', 'O', 'None')
• Рассчитайте прибыль на транзакцию по уникальной комбинации типов предложений и группированных демографических характеристик.
• Выберите комбинацию предложений для каждой группы, где либо количество случаев, поддерживающих комбинацию, является наибольшим (риск игнорирования прибыли), ЛИБО прибыль на транзакцию наибольшее ( риск выбора комбинации предложений с незначительным принятием) ИЛИ прибыль на транзакцию самая высокая среди лучших комбинаций в зависимости от количества случаев
• Назначьте комбинацию предложений и соответствующую прибыль от транзакции для пользователей.
• Оценка PPU

Задача состоит в том, чтобы получить комбинацию типов предложений для каждой комбинации демографических характеристик, которая не только показывает значительную поддержку в данных, но также максимизирует Прибыль Starbucks. При выборе комбинации типов предложений, которую клиенты Starbucks чаще всего просматривали перед совершением транзакции, мы не отправляли никаких предложений большинству пользователей мобильных приложений. Это просто связано с тем, что большое количество транзакций на самом деле происходит без участия. С другой стороны, выбирая комбинацию с максимальной прибылью на транзакцию, мы, скорее всего, получим очень небольшую поддержку в данных, поскольку такие случаи могут быть на удивление редкими. Чтобы преодолеть эти трудности, я решил попробовать другой / гибридный подход:

• Ранжируйте комбинации типов предложений по демографической группе по сначала частоте
• Выберите комбинацию с наибольшей прибылью на транзакцию среди первых наиболее частых комбинаций.
• При N = 2, 3, 4, 5,…, n + 1

6.2 Результаты

Отправка предложений на основе каждого из вариантов приводит к улучшению PPU на 20–44% по сравнению с нашим эталоном (см. Рисунок 9). Увеличение количества комбинаций типов предложений для каждой демографической группы в результате первого ранжирования на основе частоты еще больше улучшает оценочный PPU. Однако увеличение PPU происходит за счет потери поддержки в данных, например получение PPU (Top5) = 17,28 $ PPU основано только на записях 10 603 (62%) пользователей.

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

7 Модель регрессии

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

Несмотря на то, что в этом проекте второстепенные, нам необходимо определить некоторые основные метрики для оценки производительности регрессионной модели:

• Скорректированный R2
• Средняя абсолютная ошибка (MAE)

Оба показателя необходимы для оценки соответствия и предсказательной силы регрессионной модели. Хотя R2 уже говорит нам, какая часть дисперсии PPU может быть объяснена с помощью регрессионной модели, это скорректированная версия помогает нам контролировать отсутствие добавления функций с небольшим пояснительным влиянием. Несмотря на соответствие модели, MAE используется, чтобы убедиться, что наша модель предсказывает PPU правильно. Только тогда мы сможем с уверенностью использовать модель для оптимизации стратегии рассылки предложений Starbuck.

7.1 Разработка дополнительных функций

Перед обучением модели я добавляю пару дополнительных функций к набору данных. Сначала я добавляю зависимые / целевые переменные «прибыль», вычитая вознаграждение из суммы транзакции. Затем я включаю столбец, представляющий долю вознаграждения, которую пользователь получает в обмен на достижение минимальной суммы транзакции предложения, или просто озвучивая, ожидаемое вознаграждение, разделенное на сложность для все предложения, просмотренные пользователем до его транзакции. Во-вторых, поскольку на поведение людей всегда влияет их предыдущий опыт, весьма вероятно, что реакция пользователя приложения на предложения очень зависит от его собственной истории Starbucks, состоящей из:

• Предложения просмотрены
• Суммы транзакций потрачены
• Полученные награды

Поэтому я также добавляю эти данные во фрейм данных транзакций. Я также хочу получить с точки зрения отдельной транзакции на пользователя агрегированное представление комбинации на пользователя и тип предложения, показывающее средний денежный ответ пользователей на определенный набор предложений в зависимости от его средней транзакции и истории взаимодействия с предложениями. И последнее, но не менее важное: я добавляю все предварительно обработанные демографические данные из данных профиля и фиктивно закодировал столбец «пол».

Как только все необходимые переменные объединены в один фрейм данных, есть еще три вещи, которые необходимо проверить, прежде чем, наконец, начать обучение первой регрессионной модели:

• M Issing values ​​
• S постоянное распределение
• C или связанные функции

Из исследовательского анализа мы знаем, что в данных профиля отсутствуют значения для «возраста» и «дохода». По всей видимости, они присутствуют и сейчас, но позже будут обработаны посредством медианного вменения в конвейере регрессии.

На рисунке 10 показан парный график всех функций, которые я использую для выявления выбросов и искаженных распределений. Для более подробного просмотра я могу только посоветовать вам увеличить масштаб или лучше обратиться к проекту J upyter notebook, на который я указал внизу этого сообщения.

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

• «Прибыль» (зависимая переменная)
• «Amount_prev» (ранее потраченные суммы транзакции)
• «Reward_reveived_prev» (ранее полученные награды)

Поскольку такие искаженные распределения могут влиять на производительность регрессионной модели, я применяю к ним логарифмическое преобразование. Это распространенный подход при работе с сильно искаженными данными. Поэтому имейте в виду, что затем модель обучается на целевой переменной, преобразованной в журнал, «profit_log».

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

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

• Удаление коррелированных признаков (и введение пересечений признаков между коррелированными объектами)
• Использование регуляризованных методов, таких как регрессия лассо / гребня / эластичной сетки
• Использование древовидных методов, таких как случайный лес или повышение градиента

Пожалуйста, смотрите ниже окончательный набор функций:

# Dependent variable
target = 'profit_log'
# Independent variables
features = ['n_bogo', 'n_discount', 'n_informational', 'difficulty',
'reward_expected', 'reward_per_difficulty', 'amount_prev_log', 'reward_received_prev_log', 'n_bogo_prev', 'n_discount_prev', 'n_informational_prev', 'age', 'income', 'member_age', 'gender_F', 'gender_M', 'gender_None', 'gender_O']

7.2 Обучение

Чтобы приступить к обучению первой регрессионной модели, мне нужно настроить пару последних вещей:

• Разделите данные транзакции на разделы для обучения и проверки.
• Создайте конвейер регрессии, который включает преобразование функций, такое как вменение отсутствующих значений, масштабирование функций и модель регрессии (см. Пример ниже).

# Build a sklearn regression pipeline
print('\nBuilding pipeline ...')
    
# Separate numerical from categorical features (e.g. "age")
num_features = X.columns.tolist()
    
# Transformation of numeric columns
num_transformer = Pipeline([
    ('imputer', SimpleImputer(strategy='median')),
    ('scaler', MinMaxScaler())
])
# Pre-processing pipeline
preprocessor = ColumnTransformer([
    ('num', num_transformer, num_features)
])
# Create regression pipeline
regr_pipeline = Pipeline([('preprocessor', preprocessor),
    ('regressor', regressor)
])
    
print('... pipeline ready.')

• Настройте конвейер для проверки модели, чтобы отслеживать эффективность обучения и проверки, измеряемую с помощью скорректированного R2 и средней абсолютной ошибки (MAE)
• Настройте конвейер для проверки модели на основе обратного преобразования журнала целевой переменной; это помогает оценить MAE в исходной шкале (поскольку зависимая переменная была преобразована в журнал)

Для первой итерации обучения я выбираю три различных регрессионных модели, одну линейную модель, а также две древовидные модели со стандартными параметрами:

• ElasticNet
• GradientBoostingRegressor
• XGBRegressor

# Define regressor(s)
# ElasticNet
net_regr = ElasticNetCV(l1_ratio=0.99, eps=0.001, n_alphas=1000, normalize=False, max_iter=1000, cv=10, n_jobs=-1, random_state=None, tol=0.0001)
# GradientBoosting
grb_regr = GradientBoostingRegressor(n_estimators=500, learning_rate=0.01, max_depth=4, random_state=None, loss='ls', criterion='friedman_mse')
# XGBoost
xgb_regr = xgb.XGBRegressor(objective ='reg:linear',
n_estimators=500, learning_rate=0.01, max_depth=4, reg_alpha=0.9, reg_lambda=0.1, early_stopping_rounds=15, silent=1, nthread=-1, n_jobs=-1, eval_metric='mae')

7.3 Валидация

После завершения первого цикла обучения всех трех моделей пора сравнить их эффективность на скорректированном R2 и MAE :

# ElasticNet Model Performance:
Training metrics:  |  Validation metrics:
R2       : 0.5495  |  R2       : 0.5665
R2 (adj.): 0.5492  |  R2 (adj.): 0.5656
MAE      : 0.1935  |  MAE      : 0.1923
RMSE     : 0.2953  |  RMSE     : 0.2916
# GradientBoosting Model Performance:
Training metrics:  |  Validation metrics:
R2       : 0.6584  |  R2       : 0.6489
R2 (adj.): 0.6582  |  R2 (adj.): 0.6482
MAE      : 0.1586  |  MAE      : 0.1610
RMSE     : 0.2571  |  RMSE     : 0.2625
# XGBoost Model Performance:
Training metrics:  |  Validation metrics:
R2       : 0.6552  |  R2       : 0.6480
R2 (adj.): 0.6550  |  R2 (adj.): 0.6473
MAE      : 0.1574  |  MAE      : 0.1597
RMSE     : 0.2583  |  RMSE     : 0.2628

Модель регрессии ElasticNet работает примерно на 12% хуже для скорректированного R2 и на 16% хуже для MAE / MAE (журнал) , чем обе древовидные модели. Несмотря на это, GradientBoosting- и XGBoost-Regressors действительно работают одинаково с точки зрения соответствия модели тестовым данным (скорректированный R2 = ~ 0,65). Однако XGBoost показывает немного лучшую производительность на тестовых данных (MAE = 4,60 против 4,62).

Мне нужно задать себе вопрос: Почему все модели показывают посредственную производительность?

Чтобы улучшить модели, я хочу сначала изучить возможные причины текущей производительности, проанализировав отношения между ошибками прогнозирования и независимыми функциями. Анализ выполняется на основе процентилей абсолютной ошибки между истинным и прогнозируемым значениями после обращения обоих логарифмических преобразований (рисунок 12). Обратите внимание, что этот подход отличается от просмотра простых графиков ошибок, которые я также использую в Блокноте Jupyter проекта.

Каждый процентиль на оси X представляет 1% тестовых данных, в то время как процентиль «1» включает прогнозы с наименьшими абсолютными ошибками прогнозирования и процентиль «. 100 »включает прогнозы с наибольшими абсолютными ошибками прогнозов. Глядя на графики выше, можно увидеть четкие различия между процентилями для большинства столбцов. Однако я хотел бы указать только на, вероятно, самый важный вывод.

График с «true_profit» на оси Y показывает, что самая большая ошибка, допускаемая моделью, возникает для пользователей с очень большими суммами транзакций, то есть прибылью от транзакции. Поскольку такие большие значения редко встречаются в наборе данных, сложно узнать их представление. Удаление выбросов перед обучением может привести к повышению эффективности обучения, но затем легко не удастся предсказать такие случаи на невидимых данных.

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

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

7.4 Настройка

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

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

# Parameter space
parameters =  {
    'regressor__n_estimators': [1000, 1500, 2000, 2500, 3000],
    'regressor__learning_rate': [0.01 * x for x in range(1,11)],
    'regressor__max_depth': [2, 3, 4, 5, 6],
    'regressor__min_child_weight': [1, 10, 50, 100]
}

После обучения 20 различных моделей мы можем добиться следующих результатов:

# XGBoost Grid Search Regression Model
Training metrics:  |  Validation metrics:
R2       : 0.7065  |  R2       : 0.6614
R2 (adj.): 0.7064  |  R2 (adj.): 0.6607
MAE      : 0.1444  |  MAE      : 0.1541
RMSE     : 0.2383  |  RMSE     : 0.2577
 
Validation metrics (reversed log-transformation):
MAE      : 4.5263  |  RMSE     : 22.5526

Эффективность обучения повышается на 8% при подборе модели (скорректированный R2 = 0,71) и на 6% при прогнозировании прибыли от транзакции (MAE (log) = 0,14). В то же время производительность теста улучшается на 2% при подборе модели (скорректированный R2 = 0,66) и на 4% при прогнозировании прибыли от транзакции в логарифмической шкале, что соответствует фактически только 2% по исходной шкале (MAE (log) = 0,15; MAE = 4,53). Однако разница между производительностью обучения и тестирования может указывать на то, что наша модель переоснащается.

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

Затем я хочу проверить параметры модели, особенно чтобы выяснить, где модель фактически начинает переобучаться. На рисунке 14 показана взаимосвязь между количеством итераций на модель и обучением / тестом R2.

Судя по всему, R2 для тестирования и обучения начинает расходиться после 2500 итераций обучения. Хотя модель продолжает изучать представления обучающих данных, она больше не улучшает свою производительность на тестовых данных.

Сводка всех параметров наиболее эффективной модели приведена ниже. Они подтверждают оптимальное количество деревьев при визуальном осмотре.

# Parameters of best model
{'regressor__n_estimators': 2500,
 'regressor__min_child_weight': 50,
 'regressor__max_depth': 5,
 'regressor__learning_rate': 0.01}

И последнее, но не менее важное, я еще раз взгляну на график важности функции ниже.

Комбинированное влияние типов предложений на прибыль от отдельных транзакций показывает только относительную важность 2% для предложений, увиденных непосредственно перед совершением транзакции, и 11% для предложений, замеченных в прошлом. Самая важная функция - это «amount_prev_log» (28%), за которым следуют «доход» и «member_age». (оба ~ 13%). Результаты подтверждают, что вновь созданные функции, такие как ранее оплаченные суммы транзакций, а также количество дней с момента регистрации учетной записи приложения, могут иметь значительное влияние на прогнозируемую эффективность моделей.

7.5 Прогноз типа предложения

После того, как обученная регрессионная модель создана, можно начинать оптимизацию стратегии предложения Starbucks для отдельных пользователей. Цель состояла в том, чтобы найти комбинацию типов предложений, включая трудности и ожидаемые вознаграждения, которые максимизируют прибыль от транзакций пользователя приложения. Выбор типов предложений вместо предложений, а также включение трудностей и ожидаемых вознаграждений позволяет Starbucks имитировать реакцию пользователя приложения на более общем уровне. Это также может помочь в разработке совершенно новых предложений с учетом пользовательских трудностей и предлагаемых вознаграждений.

Следующие шаги описывают процесс:

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

Результаты моделирования / оптимизации показаны ниже:

# Results
PPU Benchmark        : 11.67$, Users with Response to Offer: 15449
PPU Demographics Top2: 14.33$, Users with Response to Offer: 2305
PPU Demographics Top3: 14.55$, Users with Response to Offer: 3686
PPU Demographics Top4: 15.64$, Users with Response to Offer: 8172
PPU Demographics Top5: 17.28$, Users with Response to Offer: 8946
PPU Regression       : 12.45$, Users with Response to Offer: 13335

Модель регрессии способна находить комбинации типов предложений для каждого пользователя, которые увеличивают прибыль от транзакций для каждого пользователя на 7% с PPU (Regr) = 12,45 $. В этом случае поиск подходящих предложений также означает обращение к меньшему количеству пользователей (на 14% меньше). Тем не менее регрессионная модель XGBoost не может превзойти PPU оценки аналитических моделей (хуже на 13%).

8 Результатов

В следующем разделе кратко суммируются предыдущие результаты.

8.1 Аналитическая модель

• Отправка предложений на основе каждого из вариантов приводит к улучшению PPU на 20–44% по сравнению с нашим ориентиром в 11,67 $.
• Увеличение количества комбинаций типов предложений для каждой демографической группы в результате первого ранжирования на основе частоты еще больше улучшает ожидаемый PPU
• Увеличение PPU происходит за счет потери поддержки в данных, например получение PPU (Top5) = 17,28 $ основано на записях только 10 603 (62%) пользователей
• Способ создания демографических групп может вызвать неопределенность, особенно когда приводит к очень маленьким группам или даже к отдельным пользователям.

8.2 Модель регрессии

8.2.1 Характеристики модели

• Модель достигает скорректированного R2 0,71 и MAE (журнал) 0,14 во время обучения.
• Производительность модели во время тестирования немного хуже: скорректированный R2 равен 0,66 и MAE (log) = 0,15, т. Е. MAE = 4,53 соответственно
• Разница между эффективностью обучения и тестирования может указывать на то, что наша модель переоснащается.
• По-видимому, значения R2 для теста и обучения начинают расходиться после 2500 итераций обучения; пока модель продолжает изучать представления обучающих данных, она больше не улучшает свою производительность на тестовых данных.
• Параметры модели, которые обеспечивают баланс между соответствием, предсказательной силой и переобучением:

# Parameters of best model
{'regressor__n_estimators': 2500,
 'regressor__min_child_weight': 50,
 'regressor__max_depth': 5,
 'regressor__learning_rate': 0.01}