Предсказание вероятности перехода каждого клиента компании в статус бывшего члена клуба

Авторы публикации — Дмитрий Сергеев и Юлия Петропавловская.

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

Подготовка данных

Большую часть времени провели в очистке, восстановлении и объединении данных, так как датасеты были сильно загрязнены и сгруппированы по четырём отдельным категориям:

• Контракты клиентов
• Посещаемость
• Заморозки
• Коммуникации между клиентами и клубом

Тестовые и тренировочные наборы данных были разбиты по месяцам. Train содержал информацию о клиентах за декабрь 2015 года, а Test — за март 2016. Для каждой из категорий мы объединили Train и Test части для дальнейшей обработки.

Контракты клиентов

Контракты стали первым набором данных, за который мы взялись, так как именно там содержалась целевая переменная — "продлил ли клиент свой договор", а также коды контрактов и клиентов в количестве 17631 штук, послуживших ключами для объединения всех остальных датасетов. Небольшое количество пропущенных значений в переменных были восстановлены модами. Затем создали фичи для сезона (зима, весна...), месяца и дня, в который был заключен контракт с клубом, и переменные "длительность контракта", "остаток дней заморозки" и "остаток бонусов на счету". Различные категориальные переменные, такие как возрастная группа, сегмент клуба и т.д. оставили без изменений.

Посещаемость

Начали с создания переменной — длительность разового похода в фитнес-клуб.



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

Также в датасете присутствовали категориальные переменные, градации которых мы решили сгруппировать в более общие категории. Например, "КатегорияТренера":

additional = ['Сотрудник СПА', 'Врач']
coach = ['Тренер мастер', "Тренер фитнес"]
coach_vip = ["Тренер персональный", "Тренер элит"]
other = ['Другое']

Аналогично — "НаправлениеУслуги":

sport = ["Тренажерный зал", "Водные программы", "Аэробика", "Боевые искусства", "Mind Body", 
         "Танцевальные программы", "Игровые программы", "Йога", "Групповые программы"]

health_beauty = ["Солярий", "Парикмахерские услуги", "Лечебный массаж", "Маникюр, педикюр", "Массаж_SF",
                "Терапевтические процедуры", "Физиотерапевтические процедуры", "Косметические услуги",
                "Аппаратная косметология", "Окрашивание", "Аппаратная косметология_SF", "Врачи", "Врачи_SF",
                "Продажа косметических товаров", "Инъекции", "Прочие услуги SPA", "Лечебное питание", "Инъекции_SF", "SPA"]

Наконец, добавили переменную с частотой посещения клуба в месяц и суммарные количества посещений в различные сезоны (зима, весна..) и сгруппировали данные по кодам клиентов, содержавшихся в датасете по контрактам. Итого, из 3 700 000 записей осталось ~15 000 наблюдений.

Заморозки

Изначально мы выяснили, что в датасете имеются дубликаты. После небольшого исследования оказалось, что один и тот же номер контракта с одинаковыми операциями по заморозке содержится и в Train, и в Test, так как клиентская история заморозок переносилась в тестовый набор. Чтобы в будущем избежать переобучения моделей, мы выкинули повторяющиеся значения из теста.

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

Коммуникации

В сырых данных было три основных столбца: "Дата", "Вид" и "Состояние" взаимодействия. Под "видом" скрывались такие варианты как "телефонный звонок", "встреча", "смс" и т.д., "состояние" же характеризовалось тремя уровнями: "состоялось", "отменено", "запланировано". Как и в заморозках, сначала мы удалили дубликаты из тестовых данных, чтобы очистить их от клиентской истории, а затем перешли к созданию переменных.

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

Сначала разбили переменную "Вид взаимодействия" на 3 дамми:

• личная встреча
• телефон
• другое

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

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

В результате, из 1 500 000 строк получили 15500 и объединили их с финальным датасетом. После преобразования категориальных переменных в дамми количество столбцов раздулось до 72 штук.

Машинное обучение

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

• Random Forest
• Neural Network
• SVM
• k-NN
• Naive Bayes
• Logit regression
• Decision Stumps

Каждый из классификаторов, в целом, показывал очень неплохие результаты на валидации. Random Forest на 1000 деревьев с 10-fold cv давал 0.9499 AUC, двухслойная нейронная сеть смогла поднять результат до 0.98, а гроза соревнований на Kaggle, XGB, показал впечатляющие 0.982. Также xgboost помог с визуализацией важности признаков:



Первая тройка достаточно ожидаема — "длина контракта", "остаток бонусных баллов" и "средняя длина визита". Также в первой десятке "количество успешных коммуникаций", "остаток дней заморозки" и, внезапно, "посещал ли фитнес зимой".

Остальные модели, кроме решающих пеньков, в среднем, давали по 0.92-0.94 AUC и были добавлены в ансамбль для уменьшения коррелированности между различными предсказаниями.

Ансамбль задумывался в виде двух уровней — на первом сотня decision stumps, предсказания по которым объединялись при помощи принципа большинства голосов (majority vote), т.е. если 51 пенёк был "за", а 49 "против", то ставилась единица. На втором — подключались предсказания по остальным классификаторам для последующего объединения.



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



aj — веса, с которыми предсказания входят в ансамбль
yj(x) — индивидуальные предсказания классификаторов
p — число используемых моделей

Веса определялись путём минимизации logloss-а ансамбля, при помощи замечательной функции minimize, возвращавшей оптимальные значения вектора весов x0.

from scipy.optimize import minimize
opt = minimize(ensemble_logloss, x0=[1, 1, 1, 1, 1, 1, 1])

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

В результате такого отбора отпала логистическая регрессия и, сожалению, все пеньки, зато AUC вырос ещё на пару тысячных процента и составил 0.98486. Totally worth it.

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



Если предположить, что Train и Test выборки были более-менее однородны, и число продлившихся должно быть примерно равно числу отказавшихся, то налицо более чем двукратное завышение моделями вероятности продления контракта. Однако мы решили довериться решению ансамбля и не стали наказывать его за излишнюю наглостьоптимистичность прогноза. И как оказалось — не зря.

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

Ссылка на репозиторий.