Меня зовут Игорь Дойников, в Альфе я CDS — Chief Data Scientist в Розничном Бизнесе. Моя команда строит модели машинного обучения для розничного бизнеса Альфа-Банка.
В рознице Альфа-Банка на февраль 2024 года — 13 млн активных клиентов, но я уже не успеваю следить за этим числом, потому что оно очень быстро растёт. И CLTV (Customer LifeTime Value) — это один из инструментов, который позволит увеличивать это количество. В статье я расскажу, что такое CLTV, как от бизнес постановки задачи мы перешли к задаче машинного обучения, какие при этом возникали проблемы и как мы их решали. А главное — что такое Feature Store и как этот инструмент помогает нам решать задачи СLTV.
Немного о себе. Закончил замечательный факультет вычислительной математики и кибернетики в МГУ имени М.В.Ломоносова. Правда это было давно, поэтому не будем о грустном. За плечами большой опыт в Data Science, в основном, в банках: долгое время работал в классическом банковском скоринге, в технологических блоках, сейчас — в рознице. И мне всё время интересно — за 14 лет работы я не устал от банков. Задач, где требуется DS в банках действительно много, и много данных, которые можно использовать.
Что такое CLTV?
Начнем, как принято в математике, с определений.
CLTV — это показатель того, какую прибыль принесёт клиент в результате правильно выстроенного долгосрочного сотрудничества. Это непрерывная величина, которая, в своей сути, показывает, какой доход клиент принесет организации.
Давайте чуть-чуть раскроем это определение. Посмотрим на этот тёплый ламповый график, нарисованный от руки.
На графике много всего, но начнём его разбирать с осей координат. По оси X у нас время, а по оси Y — прибыль компании от клиента. Соответственно, кривая на графике показывает, какую прибыль получает компания от конкретного клиента в определенный момент времени.
График разбит на три важных этапа взаимодействия с клиентом: привлечение, развитие и удержание. Это базовые этапы взаимодействия с клиентом, которые обычно и рассматриваются в теории.
Начнём с привлечения. На этом этапе мы привлекаем клиента и делаем первую продажу. Это важнейший и самый сложный этап, на котором, как вы видите, прибыль некоторое время отрицательная. Но ничего страшного — в самом начале клиент часто убыточный, потому что банк тратит деньги на маркетинг для привлечения.
Этап развития. Постепенно банк продаёт клиенту другие продукты (cross-sell, upsell), прибыль растёт, кривая идет вверх…
Этап удержания. Но наступает время, когда, к сожалению, прибыль начинает падать. Клиент иногда смотрит в сторону наших конкурентов, может взять продукт, например, дебетовую карту у наших конкурентов. В идеале, нам нужно заранее это понять и удержать клиента, направить его на «путь истинный».
А в какой момент времени появляется CLTV? Давайте разбираться.
Допустим мы с вами находимся в момент времени t1 (на графике). Наша задача — спрогнозировать будущую ценность клиента. Здесь важное слово — будущая ценность: ведь надо посчитать, какой будет доход клиента после времени t1, в котором мы сейчас находимся.
На графике кажется всё просто — у нас есть наша кривая дохода в каждый момент времени t > t1. Математически это площадь под кривой, для вычисления которой достаточно знаний школьной математики. Если смотреть на график, то заштрихованная площадь под кривой — это и есть наша будущая доходность от клиента.
В реальности у нас нет этой кривой, мы не можем заглядывать в будущее, хотя так хотелось бы. Дальше в статье, мы поймем как эту проблему решить.
Прежде чем мы перейдем к математической постановке задачи, давайте разберемся…
А зачем нам знать будущую доходность клиента?
Как это нам поможет при принятии решений в организации?
Я люблю идти от частного к общему, поэтому приведу один пример, как принимаются решения в концепции знания CLTV. Я думаю многие сталкивались с рекламой сервисов онлайн-кинотеатров. Обычно нас заманивают бесплатной подпиской на короткий срок — «Подпишитесь на 3 месяца бесплатно!».
Это крайне простой пример, но он показывает, как концепция CLTV помогает организации разрабатывать правильные стратегии по привлечению клиентов. Компания ничего не получает с клиента за эти 3 месяца, но мы, как владельцы компании, думаем о будущей доходности с клиента на более длинном горизонта — на год, на два, на три вперёд.
Идем дальше — ещё один график
Была в начале 2000-х реклама со слоганом «Не все йогурты одинаково полезны!» Но причем тут йогурты, когда у нас CLTV? Дело в том, что для компании не все клиенты одинаково полезны — не от всех клиентов компания получает одинаковую прибыль.
Доходность клиента для организации зависит от множества факторов (на примере Банка):
от того, сколько продуктов Банка есть у клиента (ипотека, вклад, кредитная карта, например);
от того, как часто клиент пользуется дебетовой картой;
от состоятельности клиента;
и многих других.
Клиент для Банка может быть даже убыточным, если у него есть задолженность по кредиту.
Если посмотрим график, то мы увидим распределение по клиентам по прибыли:
есть какая-то большая часть, которая приносит компании среднюю прибыль;
есть правый край с очень активными клиентами, на которых компания много зарабатывает,
и есть левый край, они приносят мало, например, у них всего один продукт.
Это некоторое теоретическое распределение доходность от клиента. Нам важно понять, что доходность по каждому клиенту отличается.
Итак, здесь мы ответили на следующие вопросы.
Знание будущей доходности клиента позволяет нам принимать правильные решения, выстраивать стратегии взаимодействия с клиентом, как на примере с онлайн-кинотеатром. Будущая доходность отличается от клиента к клиенту, поэтому эти решения могут быть персонализированными под каждого клиента.
Мы готовы идти к бизнес-постановке задачи.
Бизнес-постановка
Мы хотим уметь считать будущую доходность для каждого клиента Банка в каждый момент времени и на основе этого принимать решения. Для этого немного формализуем задачу — чтобы посчитать прибыль клиента от продукта, которого у клиента ещё нет, нам надо знать два множителя из простой формулы ниже:
(Вероятность появления продукта у клиента) х (Lifetime Profit & Loss по продукту)
Чтобы рассчитать прибыль нам ещё нужно знать P&L (Profit & Losses) — прогнозную прибыль клиента при взятии продукта.
Умножаем вероятность появление продукта на P&L и получаем потенциальную будущую прибыль по данному продукту.
В этой статье мы сосредоточимся на первом множителе — вероятности появления продукта у клиента.
Переход к задаче DS: как будем решать?
Как только мы начинаем говорить про вероятность какого-то события, то опытный читатель поймёт, что где-то здесь уже близко появление задачи машинного обучения, ибо событие можно предсказывать исходя из данных. Давайте, как в школе, рассмотрим, что нам дано и что нам надо найти.
Итак что нам дано?
Нам дано число клиентов банка — N.
М — число банковских продуктов.
Т — горизонт времени прогноза, потому что мы не можем прогнозировать прибыль клиента на бесконечность.
Что мы хотим посчитать? А мы хотим посчитать собственно вот это — ( Pij ) — найти вероятность для каждого клиента появления у него каждого продукта, где i — клиент из множества N, j – продукт из множества М.
Давайте покажу как это работает на примере кредитной карты.
Дано — N клиентов, у которых пока нет кредитной карты.
T = 36 месяцев. К сожалению, мы не можем взять бесконечный горизонт. В данном случае мы ограничиваемся 36 месяцами прогноза.
Задача — мы хотим посчитать вероятность появления кредитной карты на горизонте 36 месяцев для каждого клиента Банка.
Возникающие проблемы задачи
№1. М — число продуктов
В Банке, в целом продуктов, не так много. Из флагманских это кредитные карты, кредит наличными, дебетовая карта, вклад, премиальный пакет, инвестиции. Получается, что для нас M = 6. Но когда у организации достаточно много продуктов это может стать проблемой. Например, у ритейл компаний число продуктов может исчисляться десятками тысяч наименований.
№2. Т — горизонт прогноза.
Я уже говорил, что на бесконечность мы прогнозировать не сможем — нам надо как-то ограничиться тем, на какой горизонт мы хотим прогнозировать. Это нужно сделать так, чтобы с одной стороны у нас были релевантные данные, с другой — горизонт всё-таки должен быть достаточно большим.
Мы выбрали T = 36 месяцев.
№3. Дедлайны и много моделей.
Помимо того, что мы не сможем прогнозировать на большой срок, прогнозировать вероятность появления продукта на весь горизонт (от 0 до 36 месяцев) тоже не самая лучшая идея. Здесь неочевидно и я поясню почему.
Сейчас приведу экстремальный пример для наглядности. Смоделируем ситуацию — мы прогнозируем, что в течение 36 месяцев клиент возьмёт кредитную карту у банка с вероятностью 100%. Показываем бизнесу — «Огонь, классно, молодцы!».
Проходит 3 месяца — кредитную карту клиент не взял. Проходит 6 месяцев — не взял, год — не взял. И тогда бизнес к нам приходит:
— «Слушай, что-то не так — у тебя вероятность единица, клиент уже должен взять карту. Не работает система?»
— «Стой, стой, стой, да подожди…У нас ещё два года впереди. Он ещё возьмёт, всё будет хорошо»
Но так плохо работает. Бизнес ведь принимал решения, на основе нашего прогноза, что клиент возьмет кредитную карту.
Значит нам нужно как можно раньше понять, что наша модель релевантная, работает корректно и отображает действительность. Что тогда делать? Как вариант — разбить этот горизонт от 0 до 36 месяцев на несколько интервалов. В нашем случае мы разбили на 6 интервалов.
от 0 до 3 месяцев,
от 3-х до 6,
от 6 до 12,
от 12 до 18,
от 18 до 24,
от 24 до 36.
Теперь мы можем на раннем этапе понимать, ретроспективно, где наши модели нормально работают, а где не очень.
С точки зрения машинного обучения здесь тоже есть плюсы. Паттерны клиентов, которые в течение первых трех месяцев возьмут кредитную карту сильно отличаются от клиентов, которые возьмут кредитную карту через 2 года. Мы увидим в данных, что у клиента уже есть горячая потребность в карте. Например, недавно он оставлял заявки в других Банках, заходил на соответствующие сайты, кликал на наши предложения в мобайле, изучал их и так далее. Модели будет не так сложно найти и выучить эти паттерны поведения.
С клиентами, которые ещё далеко в будущем заинтересуются кредитной картой, всё сложнее — паттерны другие. Ведь горячей потребности в кредитке у клиента нет. Мы из данных, в целом, знаем, что клиент склонен к кредитам, возможно у него есть кредитная карта конкурента и он ей пользуется сейчас, но модели придется искать другие паттерны.
Итак, для нашего примера, нам надо построить модели для М = 6 продуктов и для 6 горизонтов. Итого 36 моделей. И бизнес хочет, что мы это сделали быстро, допустим за 2 месяца.
Как построить много моделей в короткий срок?
Рассмотрим обычный процесс создания ML-модели: постановка задачи, потом сбор и получение данных, подготовка так называемых фичей для моделей, моделирование, тестирование и внедрение и так далее. Наибольшее время по опыту занимает именно этап сбора и подготовки данных для модели.
Представим, что у нас вообще нет ничего и мы думаем над тем, что повлияет на то, что человек возьмёт кредитную карту? Мы начинаем собирать данные, придумывать фичи, привлекаем дата-инженеров, дата сайентистов. Всё это достаточно растянуто во времени. Вот этот жёлтый кружочек на иллюстрации — итеративный — может очень-очень долго длиться.
Как нам оптимизировать процесс сбора данных и подготовки фичей? Здесь мы приходим к такому понятию как Feature Store.
Начнем с определения.
Feature Store — это управляемое специализированное хранилище, предназначенное для безопасного хранения, обновления, публикации и совместного использования ML-признаков (фичей).
Что такое Feature Store для нас, как для дата саентистов, на простом языке?
Это набор знаний, обернутый в признаки(фичи), в нашем случае о розничном клиенте Банка, который мы можем быстро заиспользовать для наших моделей.
За нас уже кто-то закодировал фичи, например, по тому, как клиенты пользуются нашей дебетовой картой, как проводят транзакции, и мы сразу можем использовать эту фичу в модели. Причем как на разработке, так и в ПРОМе.
Feature Store розничного клиента в Альфе содержит более 5000 фичей о клиенте. И количество фичей постоянно растет. Давайте верхнеуровнево посмотрим из каких фичей состоит Feature Store. Вот из таких.
Какие у нас есть данные о клиенте банка? Например, транзакции: мы знаем, где они пиво покупают, где авокадо, а где заправляют автомобиль. Это, на самом деле, самые золотые данные, которыми банк обладает.
Также у нас есть данные от Бюро Кредитных Историй (БКИ). Это агрегатор кредитных историй со всех Банков, МФО. Банки могут узнать какие кредиты в других банках есть у клиента.
Что есть еще? У нас есть Росстат, внешние данные операторов, есть информация, как клиент заходит в наше мобильное приложение, как он ходит по нашему сайту , данные как клиент нас оценивает после разговора с менеджером и многое другое.
Как дата сайентист работает с FS?
Очень просто. Есть такие стандартизированные шаблонные скрипы: есть SQL-подобные, есть Python-подобные. Пример такого скрипта ниже.
Мы указываем по каким клиентам хотим посчитать фичи, на какую ретро дату и какие фичи хотим посчитать и из какой фича группы. Наличие такого инструмента, как Feature Store позволяет быстро построить хороший бейзлайн для любой задачи.
Feature Store(FS) — это радикальное ускорение разработки моделей.
Представим, что мы работаем без FS. Тогда, чтобы разработать 36 моделей нам бы понадобилось несколько дата-инженеров и, по моей оценке, 6-12 месяцев для подготовки данных, создания фичей под каждый продукт, вывод этих фичей в ПРОМ и т.д. С FS у нас это сделал один дата сайентист за 2 месяца. А можно еще быстрее с помощью AutoML. Но это за рамками этой статьи.
Примечание. Но об AutoML можно почитать в статье «AutoML на практике — как делать автоматизацию, а не её иллюзию»
Качество полученных моделей
Здесь большая цветастая табличка. По строкам — продукты. По столбцам — горизонты прогноза. Внутри ячеек — метрика ROC AUC, самая используемая метрика для оценки моделей бинарной классификации.
Что мы можем понять из таблицы? Что у нас получились модели хорошего качества. Я не буду по всем строкам пробегать — где-то лучше, где-то хуже — но, в среднем, мы получаем качество по всем моделям больше 0,75, и это хорошее качество ранжирования.
Давайте теперь приглядимся в таблицу и заметим, что чем больше срок прогноза, тем хуже качество. Это логично? Логично, потому что на горизонте 3 месяца нам легче прогнозировать и понять, что человек хочет кредитную карту, чем на горизонте 24 месяца. Но, кстати, и на таком длинном горизонте качество всё равно приемлемое. И это всё с помощью Feature Store.
Благодаря FS мы можем построить большой комплекс моделей очень быстро и с хорошим качеством.
Примечание. Если вы хотите узнать технологические внутренности Feature Store, то рекомендую прочитать статьи, где команда MLOPS Альфа-Банка подробно про это рассказывает.
— Как ускорить вывод ML-моделей в 4 раза, или Как может выглядеть экосистема МLOps в банке
— Что такое MLOps и как мы внедряли каскады моделей
— ANNA – сервис для автоматической разработки нейронных сетей
Итого
Итак, мы с вами рассмотрели задачу прогноза CLTV для Розничного клиента Банка.
Обсудили, что такое CLTV, какая бизнес постановка возникает и как мы эту постановку трансформировали в задачу для машинного обучения. Также увидели, как Feature Store помогает разрабатывать большое количество моделей хорошего качества за короткий срок.
Текущая система будет улучшаться:
Можем улучшать качество моделей или добавлять новые продукты. В банках не так много продуктов и из них отобрали шесть самых маржинальных продуктов, поэтому можем добавлять ещё страховки, лояльности, инвестиции и так далее.
Сейчас мы берём P&L из финансового департамента, а он просто средний по больнице. Значит мы можем над ним поработать — предсказывать, персонализировать.
Можно все автоматизировать. AutoML, мониторинги, обвесить всё метриками, чтобы у нас всё работало, а мы даже не прикасались. Но это тема уже другой статьи.
Рекомендованные статьи:
— Побеждаем рутину в Data Science: как перестать быть недопрограммистами и недоисследователями
— Почему нельзя сделать прогноз CLTV с помощью одной модели