Отток в офлайн-ритейле — как увеличить возврат клиентов ПРО на 20%?29.01.2024 12:15

Привет, Хабр! Меня зовут Никита Мелентьев, я Lead Data Scientist в команде дата-акселератора «Леруа Мерлен». Сегодня мы с коллегой Алексеем Зубаревым поделимся нашим кейсом по использованию ML для прогнозирования оттока и возврата профессиональных (ПРО) клиентов в «Леруа Мерлен». 

Коснемся не только модели прогнозирования, но также подхода к построению ML-продуктов, который мы используем: от оценки эффекта перед разработкой — до продуктивизации сервиса и интеграции в системы компании. Разберем методологии разметки ушедших клиентов и A/B-тестирования. И, конечно, затронем тему метрик. Оставайтесь, будет интересно!

Проблематика оттока

Простыми словами, отток в ритейле — это когда клиент не совершает покупки в течение какого-то времени, а затем и вовсе перестает взаимодействовать с компанией. Почему это важно, можно почитать исследование тут. 

У «Леруа Мерлен» большое разнообразие профессиональных клиентов: от девелоперов и строительных компаний до бригад и отдельных мастеров. У крупных есть личный менеджер, который находится с ними в постоянном контакте, видит проблемы и вовремя их решает. Но таких клиентов немного — и этот подход не масштабируем: для покрытия всех клиентов потребовался бы несоразмерный штат специалистов. Получается, в случае с большинством клиентов ПРО мы не можем оперативно среагировать на проблему и рискуем лишиться ценного партнера. В это же время удержание и реактивация клиентов происходит вручную, без оценки эффективности.

Чтобы разобраться с этими проблемами, мы решили стандартизировать процесс работы с клиентом и разработать ML-продукт, который позволит вовремя заметить покупателей в зоне риска. Мы сфокусировались на средних и небольших клиентах — как ИП, так и ООО.

Разметка ушедших клиентов на исторических данных

Чтобы обучить машину делать выводы на основе каких-либо новых данных, сперва нужно скормить ей данные, выводы по которым уже сделаны.

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

За основу можно было бы взять экспертное понимание оттока в «Леруа Мерлен» — считается, что 90 дней достаточно для выявления «уснувшего» клиента. Но этот подход не берет в расчет сезонных клиентов, которые совершают покупки с периодичностью в полгода или год. Поэтому, ушедшим мы будем считать клиента, не покупавшего более 365 дней.

Оценим данную методолгию по метрике Precision. Она равна 83% на 12-м месяце (читай: через год после выставления клиентам метки «отток» 17% из них вернутся). Моделью ML мы будем стараться увеличить данную метрику, и свести к минимуму лишний контакт с клиентами, которые вернутся сами.

Оценка точности методологии разметки оттока (365 дней) на горизонте 12 месяцев

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

• Так как целевая аудитория продукта — это средние и малые клиенты, у многих недостаточно истории покупок для сегментации.

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

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

Поэтому для MVP мы использовали простой бейзлайн (больше года без покупок = отток), а все мысли о разработке более сложной сегментации положили в бэклог будущих доработок.

Модель оттока

В качестве модели использовали бинарную классификацию catboost classifier. Таргет: 1 — был отток, 0 — не было оттока. Так как есть дисбаланс классов (2:1), то для нормализации их весов при обучении применили параметр 'auto_class_weights': 'Balanced».

Важный шаг — убрать из данных лики. То есть убрать из датасета клиентов, которые «утекли» задолго до обучения модели. Например, модель обучаем на данных до 1 мая 2022 года — это будет train dataset. Данные таргета берем с 1 мая 2022 по 1 мая 2023 года. Но даже на 1 мая 2022 у нас есть клиенты, которые не покупали годами — на них модель сильно переобучается.

На этапе построения MVP для нас важна скорость разработки, поэтому мы выбрали жадный алгоритм генерации и добавления фичей — используем все, что положительно влияет на ключевую метрику Precision. Так как отток клиента является лишь симптомом проблемы, у которой множество самых разных причин, в датасет собрали почти все, что мы знаем о клиенте. Основные источники — это транзакции, рейтинги, данные о доставке и взаимодействии с менеджерами, данные товаров. Внизу показаны топ-20 признаков (по важности) внутри алгоритма catboost. Именно они дают ему основную предсказательную способность.

Наиболее важные признаки в модели оттока по версии Catboost

Где:

• (X дней) — используется отношение текущих значений признаков к значениям X дней назад;

• / — деление признаков;

• Recency — давность последней покупки (дни);

• Lifetime — время (дни) от первой покупки до сейчас;

• Lifetime (покупок) — время (дни) от первой покупки до последней покупки;

• RFM кластер — закодированный кластер клиента от 111 до 333 по Recency, Frequency, Monetary с квантилями 33%, 66%;

• Сезонность Y месяца — доля покупок клиента, приходящихся на этот месяц.

В качестве еще одного рычага максимизации Precision использовали удобный метод catboost: select_threshold. Передали в этот метод желаемый FPR (False Positive Rate) — и он автоматически рассчитал отсечение (threshold), которое нужно применить для его достижения. На наших данных threshold около 90% — это значит, что мы считаем клиента ушедшим только при прогнозной вероятности выше 90%.

Обучение модели

Процесс обучения модели состоял из следующих частей:

• Разбиваем на train / holdout (test) (9:1, train_test_split + стратификация по классу);

• При помощи cross-validation (StratifiedKFold, folds=10) подбираем количество итераций обучения, при этом learning_rate и другие гиперпараметры алгоритма фиксируем заранее;

• Оцениваем модель на holdout датасете, используя select_threshold и sklearn classification_report;

• Обучаем модель на всех доступных данных.

Все это позволило добиться вполне неплохих результатов по Precision: 92% точности.

Оценка качества обученной модели на holdout тестировании

Инференс модели

Внимательный читатель заметит подвох: вы обучались на данных годичной давности — где гарантии, что модель не устарела / показывает удовлетворительные метрики и сейчас?

Мы задались этим же вопросом и придумали следующие решения.

• На этапе разработки модели сверять точность train / inference метрик — они должны быть максимально близки.

• Проверять дата-дрифт числовых признаков через библиотеку evidently.

• Проверять и уметь обрабатывать появление новых категориальных признаков.

• Все вышеупомянутое мониторить на проде, делать алерты, если что-то пошло не так.

Посмотрим успехи модели через призму прошедшего года: сколько клиентов, предсказанных с меткой «отток», вернутся сами?

Сначала сравним метрики на клиентах, которые к моменту прогнозирования уже имели метку «отток» по нашей методологии — т. е. больше года не совершали покупок. При обучении мы таких клиентов из датасета убирали, а сейчас можем смело использовать для оценки модели «в бою». За счет машинного обучения удается поднять Precision с 83% до 94% (12-й месяц после прогноза).

Оценка качества обученной модели на горизонте 12 месяцев после прогноза

Улучшение базовых метрик — это хорошо. Но самый важный плюс модели — то, чего не может сделать простая методология отсечения по 365 дней, — умение сказать, кто из активных клиентов (тех, кто, например, совершил покупку в прошлом месяце) также может уйти. Ведь таких покупателей намного проще вернуть. Precision MVP-модели на таких клиентах — 86,2% через 12 месяцев после прогноза. А в среднем, для всех клиентов, значение Precision — 90%.

Имея достаточно стабильную модель (метрики train сходятся с inference) с сильной предсказательной способностью, идем дальше, в реальный мир коммуникации с клиентом.

Оценка — A/B-тесты

На этапе POV (Proof-of-value) перед командой стоит вызов показать реальную пользу от исследований.

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

Протестировать все три канала можно или последовательно, или параллельно.

Первый вариант хорош тем, что мы могли бы использовать для тестирования всех клиентов, а также уделить отдельным тестам больше внимания. Однако лимит на пропускную способность и стоимость теста не позволит извлечь большую выгоду от этого решения (например, мы не можем обзвонить всю базу клиентов в реальные сроки и за разумные деньги). С учетом сжатости этапа POV оставалось только одно — проводить A/B-тесты параллельно. В этом помогло выделение целевой аудитории с учетом бюджета и ожидаемого эффекта.

• Для ПРО-менеджеров в магазинах выбираем активных клиентов (покупка < 90 дней), у которых есть персональные менеджеры. Из этого множества возьмем топ-15% по вероятности оттока.

• Для телемаркетинга выбираем активных клиентов, у которых нет персональных менеджеров. Возьмем топ-10% по вероятности оттока.

• Для e-mail-рассылки берем оставшихся неактивных клиентов (покупка > 90 дней), топ-35% по вероятности оттока.

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

Разбиение ПРО (B2B) клиентов по каналам A/B-тестирования

Методология АБ

Прежде чем перейти к результатам A/B-теста, скажем пару слов о методологии его проведения.

Основной метрикой в нашем случае является Retention_N — доля вернувшихся клиентов через N месяцев после проведения теста. Метрика лежит в промежутке от 0 до 1 и имеет хорошую чувствительность, более того, является прямым результатом деятельности в рамках A/B-теста.

Действие теста — краткосрочное взаимодействие с клиентом (e-mail, ряд звонков или встреч), поэтому не нужно заранее знать, сколько «держать» тест. Ожидается, что клиент, если и вернется, то сделает это в ближайшие месяцы (Retention_1 или Retention_2, через 1 и 2 месяца соответственно) — на этом промежутке мы мониторим изменение lift в группах A и B по каждому каналу, а также производим расчет MDE для проверки статистической значимости результатов.

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

1. Для каждого клиента рассчитывается показатель recency — число дней с его последней покупки. Область возможных значений recency делится на 150 равных по длине отрезков (бинов).

2. Множество клиентов случайным образом делится на две равные группы —  с учетом того, что распределения recency в обеих группах должны быть похожи. В этом поможет функция train_test_split из модуля sklearn.model_selection, где stratify=«recency».

3. Проводится АА-тестирование методологии на исторических данных. Путем многократного сэмплирования генерируется ~10000 случайных разбиений на группы A/B, затем для каждого проводится статистический тест и считается процент ошибок (разбиений, в которых группы получились различными, более формально — была отвергнута нулевая гипотеза о равенстве метрик). В нашем случае для метрик Retention_1 и Retention_2 используем proportions_ztest из пакета statsmodels с уровнем значимости alpha = 0.05 и мощностью power = 0.8.

4. Для каждого из трех каналов A/B-тестирования проводится отдельный АА-тест. На примере теста в call-центре оценка дала результат FPR = 95,2%, (4,8% ошибок на все 10000 итераций), что соответствует нашим ожиданиям.

В дополнение к АА-тестированиям по Retention, полезно проверить распределения главных метрик (визуально и через тест Колмогорова-Смирнова): Recency, RFM-класс, Товарооборот, Вероятности оттока по клиентам. Внизу пример проверки Recency, для остальных метрик вывод аналогичный — они схожи.

Проверка распределения Recency в группах А/А-теста

Результаты АБ-тестов

Теперь к оценкам результатов.

• Подготовка A/B-тестов: ~1 месяц (подготовка материалов и действие на клиента);

• Метрика: Retention_2 (замер результатов через 2 месяца после действия на клиента);

• Когда проводили: зимой, в спокойный сезон после Нового года.

Канал телемаркетинга (call-центра) становится целевым для завершения MVP и интеграции на этапе продуктивизации.

Продуктивизация

Скоуп продуктивизации ML-продукта выглядит следующим образом:

• Версионирование кода на Git;

• Версионирование докеров в Jfrog;

• Версионирование пайплайнов в Kubeflow;

• Версионирование артефактов (модели, датасеты, метрики) в S3;

• Автоматизация CI/CD через Jenkins;

• Секреты в Vault;

• Мониторинг через Grafana;

• Retry при поломке пайплайна;

• Алертинг в Телеграм — если retry не помогли;

• Еженедельный автоматический запуск обучения и скоринга модели;

• Ежедневный автоматический запуск передачи данных о скоринге в API call-центра;

• Все входные и генерируемые данные лежат в хранилище Greenplum и покрыты DQ.

Общая архитектура MLops в «Леруа Мерлен»

Про этот стек MLops мы обязательно сделаем отдельную статью. Здесь же остановимся только на интересных моментах, касающихся разработки продукта.

Train pipeline. Информация и поведение клиента не меняется ежедневно, а чтобы на него подействовать, требуется время — так что нам не нужен real-time прогноз. Достаточно обучать модель и скорить клиентов на предмет оттока еженедельно.

API pipeline. Интеграция в систему call-центра происходит через API, туда данные на коммуникацию с клиентом отправляются ежедневно (за исключением выходных и праздников). Для этого сделан отдельный пайплайн загрузки данных из прогноза.

Шаги пайплайнов обучения модели и отправки данных в API

Главная логика пайплайна обучения модели состоит из четырех достаточно простых шагов: сбор данных train → обучение модели → сбор данных для inference → inference. Логика обогащается версионированием модели и выбором лучшей (прод или новая), этот функционал реализован через S3 и кастомную библиотеку. Для выбора продовой модели подготавливается отдельный набор данных train / val. Замена продовой модели происходит, если метрики новой версии не хуже продовой на валидационном датасете.

Датасеты и метрики версионируются в S3 — они связаны друг с другом и с версией модели. Логи лежат в отдельном хранилище Minio (под Kubeflow) — и доступны при необходимости найти ошибку в выполнении пайплайна.

Во время работы пайплайна собираются как технические метрики, так и метрики данных / модели. В конце пайплайна есть отдельный шаг, который отсылает эти метрики в Grafana.

Ниже пример пяти метрик.

• Precision / Recall / F1 для шага обучения модели.

• Precision / Recall для 1-го месяца после Inference. Когда наберется история, добавим 3-й и 12-й месяцы после Inference. Чтобы создать динамику, в оценку взят самый свежий прогноз, у которого накопилось достаточно истории. Важное условие — чтобы клиенты, на которых мы замеряем точность, не подверглись целевому действию (ведь если мы предсказали отток, а потом сами же вернули клиента — это не ошибка модели). Поэтому эти метрики считаются на 5% отложенных клиентов, на которых мы не будем воздействовать в рамках ML-продукта. Сам список обновляется каждые 3 месяца, чтобы обновить актуальность и взять предыдущих клиентов в работу.

• Технические метрики по train / inference — RAM (GB) и время выполнения скрипта.

• Распределение оттока на positive / negative.

Продовые метрики в Grafana 

Второй пайплайн отвечает за передачу данных в NextContact, систему для коммуникации с клиентом для магазинов и центрального офиса, при помощи REST API. Информацию о клиентах, с которыми нужно вступить в коммуникацию, передаем ежедневно.

Изначально была идея выдавать клиентов с наибольшей вероятностью оттока. Но у такого подхода есть явный минус: наиболее вероятные к уходу клиенты — это «старые» клиенты, у которых не было покупок уже очень давно. Таких клиентов очень сложно вернуть. Напомню, что на этапе первого A/B-теста call-центра мы ограничивали клиентов по дате последней покупки — не более 90 дней назад. При этом совсем не брать клиентов старше 90 дней — значит потерять большую часть клиентской базы.

Исходное распределение

Попробовав различные варианты сортировки клиентов, мы пришли к равномерному распределению по важным для нас метрикам — времени последней покупки, товарообороту и частоте покупок.

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

Равномерное распределение

У нас была возможность проверить новое распределение клиентов на повторном A/B-тесте — результаты получились положительные, на уровне первого A/B.

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

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

• Ежедневный сбор аналитических данных по итогам коммуникации с клиентами. Эти данные выводятся в дашборд и используются менеджментом в центральном офисе и магазинах;

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

Выводы / дальнейшие планы

Нам удалось уменьшить уход клиентов на 20% при помощи ML-продукта, взяв за основу идею команды и экспертизу внутри «Леруа Мерлен». За год команда прошла путь от защиты дата-продукта и разработки алгоритмов до продуктивизации и настройки отчетности. По пути нам удалось решить проблему разметки оттока, проведения A/B-тестов, выбрать итоговый канал взаимодействия с клиентом и настроить синхронную работу всех систем.

Next step — собрать аналитику с коммуникаций клиентов и переходить к построению uplift-модели, которая будет ранжировать клиентов не с точки зрения вероятности оттока, а по вероятности совершить целевое действие, в нашем случае — вернуться к покупкам.

© Habrahabr.ru