Модели Take-Rate: погружение в бизнес-процессы для успешного ценообразования

Привет, меня зовут Даниил, я занимаюсь Data Science в Альфа-Банке! Думаю, каждый из нас при разработке модели сталкивается с различными трудностями. Часто нам удаётся наступить на новые грабли, но намного чаще — на старые. Чтобы вам не пришлось наступать на мои, хочу на примере своего проекта, касающегося ценообразования, рассказать, на что стоит обращать внимание при создании моделей, и почему глубокое погружение в бизнес-процесс так важно.

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

Бизнес-идея при создании модели

Мы все любим покупать и имеем товары, которые хотим приобрести. Готовы ли мы купить их сейчас, если цена снизится на 5, 10 или 15%? Насколько цена влияет на наше решение? Потребитель хочет заплатить меньше, но иногда готов заплатить полную цену за желаемый продукт.

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

Итак, возникает необходимость в более умном и взвешенном подходе.

Как найти баланс?

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

Подход: оптимизировать цену портфельно.

Последствия.

Подход: оптимизировать цену индивидуально.

Последствия.

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

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

Экономика модели

Чтобы создать персонализированные предложения по кредиту наличными, банк следует стратегии «Win-Win», стремясь находить баланс между интересами клиента и собственными доходами. Цель — найти точку пересечения двух ключевых показателей:

1. Спрос клиента: его готовность принять предложение по данной цене.

2. Доходность продукта: величина дохода, который банк получает от сделки.

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

Подходы к моделированию и цели

Перед тем как перейти к построению модели, нужно чётко определить, какую задачу мы решаем. В нашем случае это задача классификации:

• 1 — по комбинации клиент+оффер была совершена сделка.

• 0 — по комбинации клиент+оффер сделки не произошло.

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

• Ставка: чем выше, тем меньше вероятность, что клиент заинтересуется предложением.

• Сумма кредита: чем меньше одобрена сумма, тем выше вероятность отказа.

• Требования документов: чем больше требований, тем меньше клиенту нравится предложение.

Варианты подходов к моделированию с учётом монотонных зависимостей

№1. Линейная регрессия: обучаем линейную регрессию и проверяем, что знак у весов по управляемым параметрам соответствует ожиданиям. Недостаток подхода — в одинаковом влиянии параметров на клиентов со схожими характеристиками, а также в том, что качество регрессии уступает бустингам.

№2. Модель на данных без управляемых признаков и последующая калибровка модели с учётом управляемых параметров. Подход позволяет учесть портфельные зависимости, но у нас задача персонализации, что требует индивидуального подхода.

№3. Бустинг с монотонными ограничениями. Наиболее подходящий вариант, так как позволяет учитывать важность управляемых параметров персонально для каждого клиента, а не на уровне общей тенденции. Такой подход позволяет максимально повысить качество модели, учитывая все признаки в единой модели, что упрощает взаимосвязи между управляемыми параметрами и остальными характеристиками клиента. Ниже ссылка, где продемонстрировано, как именно работают монотонные ограничения в бустинге.

Разработка

Итак, бизнес-задача была поставлена, и мы с энтузиазмом приступили к разработке модели. Казалось бы, всё должно было быть просто: собираем данные, обучаем модель — и вот у нас готовое решение. Однако реальность оказалась сложнее. Уже на начальном этапе стало ясно, что путь к решению будет тернистым.

Первая проблема — «Нелогируемые офферы»

Проблема возникла, как только мы начали собирать данные. Оказалось, что при оформлении кредита клиенту может быть предложено несколько офферов. Если первый вариант не подошёл, менеджер мог предложить второй, третий и так далее. Однако, как узнать, какой из них выбрал клиент, если система фиксировала только конечное решение — сделка или отказ?

Мы потратили много времени на изучение логов, но конкретной информации о промежуточных офферах не нашли. Тем не менее, в случае успешной сделки мы знали её параметры и номер соответствующего оффера. Таким образом, мы выяснили, что более 90% клиентов выбирают оффер из первой десятки при заключении сделки. Поэтому мы решили в случае отказа анализировать выбор клиента, случайным образом выбирая один из офферов из топа. Это не идеальное решение, но оно позволило нам продвинуться дальше.

Вторая проблема — «Константные ставки или отсутствие разнообразия»

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

Чтобы не застрять на этом этапе мы обратились к бизнес-команде и предложили провести тест с расширенным диапазоном ставок для каждого сегмента. Это позволило нам собирать разнообразные данные, добавив в выборку примеры реакции на разную ценовую политику.

Третья проблема — «Ложная значимость длительности кредита»

Спустя несколько месяцев тестирования мы накопили достаточно данных и приступили к повторному обучению модели. Всё шло гладко, пока мы не заметили неожиданную зависимость: признак длительности кредита вырвался на первое место по важности. Это было удивительно и даже слегка настораживало. Бизнес-заказчики, как и мы, были озадачены: с чего бы это длительность кредита стала столь критичным фактором?

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

Поэтому нам пришлось отказаться от использования этого признака в модели.

Четвертая проблема — «Взаимосвязанные параметры оффера»

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

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

Пятая проблема — «Уязвимость к фроду и различия в каналах»

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

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

Проверка модели

Первое, что приходит на ум для тестирования — ретроспективный тест (ретро-тест). Мы замерили качество модели на Out-Of-Time выборке и убедились, что новая модель работает лучше предыдущей. Но этого было недостаточно для понимания, увеличит ли модель доходность банка.

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

Итоги

С успехом пройдя через все этапы разработки и тестирования, мы запустили модель для всех клиентов банка. Теперь она приносит банку значительный доход, соответствующий поставленной задаче по оптимизации прибыли, и оправдала ожидания по ultra mega stonks.

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

---

А чтобы быть в курсе новых статей и реализованных проектов, познакомиться поближе с командой Центра продвинутой аналитики и получать инфо об актуальных вакансиях — присоединяйтесь к нашему TG-каналу Alfa Advanced Analytics.