Отток клиентов — ключевая проблема для многих отраслей. Увеличение темпов убыли — это потенциальные потери для компании или поставщика услуг.

В этом блоге мы проанализируем отток клиентов для компании sparkify с помощью Pyspark. Спасибо Udacity за предоставленный набор данных и побуждение нас вести блог.

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

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

Постановка проблемы.Sparkify ведет журнал данных о событиях, в котором фиксируются все события, совершенные их клиентом, как указано выше. На основе этого журнала мы должны создать модель, которая поможет прогнозировать отток клиентов для компании. Чтобы сделать этот прогноз, сначала мы изучим набор данных, затем извлечем функции и, наконец, построим модель. Мы будем использовать PySpark, который позволяет нам взаимодействовать с RDD в apache spark, а также может быть развернут в облаке либо в AWS, либо в IBM Watson Studio.

Анализ данных.Набор данных содержит информацию о пользователях Sparkify за два месяца. авиационный журнал. Исследование проводилось на подмножестве 128 МБ полного набора данных 12 ГБ. Он содержит около 2 86 500 записей, относящихся к данным о событиях за два месяца для 226 пользователей.

Вот схема набора данных. Файл журнала имеет формат JSON. Каждая строка содержит сеанс пользователя с большим количеством значимых данных и фиксирует информацию о пользователе (пол, идентификатор пользователя, регистрация, уровень, статус) и информацию об использовании (идентификатор сеанса, страница, метод, длина, песня, ts, userAgent).

Кратко о собранных данных. Эти данные фиксируют действия, такие как воспроизведение песен пользователем, переходы на разные страницы в приложении, такие события, как поднятие большого пальца, переход на домашнюю страницу, приглашение друзей и изменение настроек. Хотя это небольшое подмножество данных, оно содержит ~286500 записей для 226 пользователей за два месяца.

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

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

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

Другой анализ функций основан на поведении людей на платформе, таком как продолжительность сеанса, itemInSession, количество песен за сеанс, добавление в плейлист или добавление друга, что даст нам дополнительную информацию.

Еще одна интересная особенность — «ts», отметка времени, которая является отметкой времени UNIX. Он был преобразован в формат даты и времени, из которого мы создали новую функцию «ежедневные сеансы» и «ежемесячные сеансы».

Изучая распределение этих функций, мы видим, что itemInSession, thumbsUp, addFriend и addToPlaylist разбросаны по среднему значению. Это важно, поскольку модели полагаются на изменчивость, чтобы учиться и делать прогнозы.

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

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

Настало время шоу!! Созданный набор данных загружается в конвейер и обучается с помощью трех различных алгоритмов Random Forest, Logistic Regression и Gradient Boosting для оценки их точности и оценки F1 на тестовом наборе.

Random Forest имеет хорошую точность и оценку F1 по сравнению с двумя другими моделями. И логистическая регрессия, и градиентное усиление работали более или менее одинаково. Кроме того, мы решили настроить модель случайного леса с помощью перекрестной проверки и использования поиска по сетке, чтобы найти наилучшее сочетание параметров. Мы использовали следующие гиперпараметры для оптимизации модели

  • minInfoGain (минимальный прирост информации для разделения, который будет учитываться в узле дерева): 0, 1
  • maxDepth (максимальная глубина дерева): 5, 10
  • numTrees (количество деревьев): 20, 50

Результаты. Оптимизация модели с помощью поиска по сетке не повышает производительность нашей модели, возможно, это связано с очень маленьким набором данных, включающим всего около 191 пользователя. В результате были получены лучшие гиперпараметры: 50 деревьев и максимальная глубина 10. Модель показала точность 73% и оценку F1 0,72. мы можем эффективно классифицировать пользователей по двум категориям без существенной разницы в производительности при прогнозировании одной или другой. Мы даже оценили надежность модели путем обучения и прогнозирования с различными случайными состояниями и обнаружили, что точность модели была очень стабильной для них.

Вывод. Подводя итог, мы загружаем набор данных json в фрейм данных, очищаем набор данных, анализируем функции, создаем новые функции путем преобразования и объединения существующих функций. Создан конвейер для преобразования данных в числовые и загрузки набора данных в три классификатора, таких как случайный лес, логистическая регрессия и классификатор повышения градиента. Оценивали модель, используя точность и балл F1. Наконец, мы оптимизировали модель, используя GridSearchCV, передавая сетку параметров и используя перекрестную складку с тройным сгибом.

Наконец, у нас есть модель с точностью 73% на тестовом наборе и с 0,72 балла F1. Теперь Sparkify может использовать нашу модель для выявления пользователей, которым грозит отток, с точностью 73 %. Для достижения наилучших результатов требуется регулярное обучение модели. Теперь Sparkify может проводить персонализированные почтовые кампании и предоставлять предложения/скидки, которые помогают им удерживать пользователей в своих услугах/подписках.

Возможное улучшение. Наконец, чтобы лучше понять модель, мы могли бы использовать значения SHAP или важность перестановки, чтобы понять, как отдельные функции влияют на прогнозы модели. Мы также будем использовать алгоритм K-fold для оптимизации модели для повышения производительности. Другим очевидным улучшением будет поиск экземпляров Submit Downgrade вместо событий отмены. Это будет отслеживание пользователей, которые собираются перейти с платного на бесплатный. Для этого потребуется другой набор функций, вероятно, более сложных, поскольку потребуется разделить разные пользовательские периоды по уровням.

Код можно найти в моем репозитории Github!!