Как понять, что вы теряете клиентов? Это способ предсказать эти события, чтобы вы могли принять меры, пока не стало слишком поздно?

Введение

Отток клиентов – это действие, которое представляет собой событие, когда клиент перестает использовать продукт или отказывается от конкретной услуги. Отток клиентов может быть очень дорогим, особенно в сфере подписки. Затраты на привлечение клиентов (CAC) для новых клиентов часто значительно превышают затраты на сохранение существующей клиентской базы. Именно по этой причине важно иметь точную модель прогнозирования, которая поможет нам предсказать, когда клиенты вот-вот уйдут, чтобы мы могли предлагать стимулы или скидки, чтобы удержать их, и это потенциально сэкономит нашему бизнесу миллионы доходов. Таким образом, сокращение оттока клиентов в конечном итоге приводит к устойчивому росту бизнеса. В этом посте мы проведем вас через процесс анализа данных о событиях клиентов, предоставленных Udacity (из завершающего проекта программы Udacity Data Scientist Nano Degree). Затем мы выбираем набор функций, который будет использоваться при обучении моделей машинного обучения, на основе информации, которую мы узнали из набора данных. Наконец, мы создадим решение для прогнозирования с помощью машинного обучения, которое сможет прогнозировать отток клиентов.

Обзор проекта

Sparkify — вымышленный сервис потоковой передачи музыки, созданный Udacity. Он похож на сервисы потоковой передачи музыки Spotify, Pandora, Apple и Amazon.
С помощью Sparkify пользователи могут слушать музыку бесплатно (с рекламой) или подписаться на платформу по фиксированной ставке. Пользователи могут обновить, понизить или отменить свои подписки. Каждый раз, когда пользователь взаимодействует со службой, например, воспроизводит песни, обновляет, понижает, отменяет или лайкает песню, он генерирует журналы пользовательских событий. Наша задача — спрогнозировать пользователей, которые планируют уйти (то есть потенциальных подписчиков, которые вот-вот уйдут), чтобы мы могли принять меры, например, предложить им большую скидку или предоставить платные услуги бесплатно за 3 месяца до того, как они отменят подписку. Чтобы выполнить эту задачу, мы будем обрабатывать и анализировать журналы пользовательских событий (предоставляемые службами потоковой передачи Sparkify) с кластерами Apache Spark, размещенными на платформе Databricks. Мы создадим соответствующие функции для прогнозирования оттока. Мы также будем использовать PySpark MLlib для создания моделей машинного обучения с большими наборами данных, что выходит далеко за рамки того, что можно было бы сделать с помощью нераспределенных технологий, таких как scikit-learn. Мы будем использовать F1 Score в дополнение к Accuracy в качестве показателя производительности для оценки производительности модели, поскольку набор данных несбалансирован (т. е. количество оттока пользователей (52) намного меньше, чем количество пользователей без оттока (173) в данных. набор).

Ниже приведены шаги, которые мы предпримем:

  1. Исследовательский анализ данных (определение оттока и изучение данных)
  2. Разработка функций
  3. Моделирование
  4. Полученные результаты
  5. Заключение и улучшения

Исследовательский анализ данных (EDA)

Мы будем использовать подмножество (128 МБ) полного доступного набора данных (12 ГБ) под названием «mini_sparkify_event_data.json», предоставленного Udacity, для выполнения EDA. Данные, которые мы анализируем, содержат 286500 записей данных о событиях, и каждая запись имеет 18 столбцов. Ниже приведена схема этого набора данных.

Пример набора данных:

Получение описательной статистики по каждому столбцу

Из приведенного выше фрейма данных мы обнаружили, что как sessionId, так и userId имеют значение 286500, что соответствует общему количеству записей о пользовательских событиях. Это указывает нам на то, что у нас нет пропущенных значений в sessionId и userId. Но исполнитель, имя, фамилия, пол, длина и т. д. имеют нулевые или отсутствующие значения.

sessionId имеет минимальное значение 1, но userId имеет минимальное значение пустую строку. Таким образом, у нас есть userId, содержащий пустую строку, которая является анонимным userIds. Анонимные идентификаторы пользователей не передают значимой информации, когда мы хотим предсказать, будут ли конкретные пользователи уходить (покинут/отменят потоковые сервисы) или нет. Таким образом, мы удаляем записи, в которых userId представляет собой пустую строку. Необходимо удалить 8346 записей, связанных с анонимными идентификаторами пользователей.

В наборе данных есть столбец с именем «страница», в котором содержится информация о действии, предпринятом пользователем. Существует 19 уникальных значений действий: ['О программе', 'Дом', 'Справка', 'Мне нравится', 'Мне нравится', 'Добавить друга', 'Следующая песня', 'Добавить в плейлист', 'Настройки', ' Сохранить настройки», «Свернуть рекламу», «Ошибка», «Выход», «Обновление», «Отправить обновление», «Понижение версии», «Отправить понижение версии», «Отмена», «Подтверждение отмены»]. Большинство записей пользовательских событий имеют значение страницы = «NextSong». Это действие указывает на то, что пользователи слушают песни. Имеется 228 108 записей со значением страницы = ‘NextSong’.

Определить отток

Отток определяется как пользователи, у которых есть страница = «Подтверждение отмены». Мы добавляем имя столбца «churnFlag», которое имеет значение 1, когда пользователь отменяется (т. е. пользователи, у которых есть страница = «Подтверждение отмены»), и имеет значение ноль, когда пользователь не отменяется. В этом наборе данных 52 (23%) пользователя, которые уходят, и 173 (77%) пользователя, которые не уходят.

Сравните поведение оттока и неоттока пользователей.

Уровень. Уровень подписки пользователей. Это либо «платные», либо «бесплатные» пользователи. «Бесплатных» пользователей больше, чем «платных». У «бесплатных» пользователей показатель оттока немного выше, чем у «платных».

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

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

Общее количество песен, прослушанных каждой группой: без оттока и оттока пользователей. Поскольку пользователей, которые не уходят (173 человека), намного больше, чем ушедших (52 пользователя). Таким образом, общее количество песен, прослушанных пользователями без оттока (168 808), намного выше, чем у пользователей с оттоком (33 195).

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

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

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

Среднее время сеанса (в часах), проведенное каждой группой пользователей (ушедших и не ушедших) на платформе. Среднее время сеанса пользователей без оттока составляет 5,047 часа, а среднее время сеанса у оттока — 4,718 часа.

Среднее количество дней на платформе. Это среднее количество дней с момента регистрации в сервисах ушедших или не ушедших пользователей. Среднее количество дней, в течение которых уходящие пользователи регистрировались на платформе, составляет 52,65 дней, а среднее количество дней, в течение которых не уходящие пользователи регистрировались на платформе, составляет 67,15. дней

Разработка функций

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

Возможности:

  • isMale – целочисленный тип данных. Его значение получено из столбца «пол», который является типом данных категории. isMale = 1, если пол = «М», и isMale = 0, если пол = «Ж».
  • isPaid – целочисленный тип данных. Его значение получено из столбца «уровень», который является типом данных категории. isPaid = 1, если уровень = «оплаченный», и isPaid = 0, если пол = «F»
  • registration_days — количество дней с момента регистрации пользователя в службе.
  • avg_session_time – среднее время сеанса в час.
  • avg_songs_played – среднее количество песен, воспроизводимых за каждый сеанс.

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

  • Добавить друга. Количество друзей пользователя в службе.
  • Добавить в плейлист. Количество песен, которые пользователь добавил в свой плейлист.
  • Ошибка. Количество ошибок, с которыми столкнулся пользователь при использовании службы.
  • Домашняя страница: сколько раз пользователь переходил на домашнюю страницу службы.
  • NextSong: количество песен, которые прослушал пользователь.
  • Roll Advert: сколько раз пользователь прослушал рекламу.
  • Палец вниз: количество песен, которые не понравились пользователю с опущенным пальцем.
  • Большие пальцы вверх: количество песен, которые понравились пользователю с поднятыми большими пальцами.

Ярлык

Это ярлык «churnFlag». Это единица, если у пользователя есть отток, и ноль, если у пользователя нет оттока.

Мы векторизовали признаки с помощью VectorAssembler.и затем мы стандартизируем признаки, удаляя средний компонент и масштабируя дисперсию с помощью StandardScaler.

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

Моделирование

Перед моделированием мы разделяем набор данных на обучающие и тестовые наборы. мы используем 80% набора данных для обучения, а оставшиеся 20% — для тестов. мы использовали PySpark MLLIB для создания моделей машинного обучения. Затем мы выполним поиск по сетке с трехкратной перекрестной проверкой при настройке наших моделей, чтобы найти лучшую модель.

Мы выбираем модель-победитель на основе оценки F1 в качестве основной метрики для оценки производительности модели в дополнение к оценке точности, поскольку уходящие пользователи составляют только 23% всех пользователей, что приводит к несбалансированности данных.

Точность определяется как:

точность = (количество правильных прогнозов) / (общее количество прогнозов)

Оценка F1 определяется как:

F1 = 2*точность*отзыв / (точность + отзыв)

где

точность = (количество правильно идентифицированных оттоков)/(общее количество идентифицированных оттоков)

отзыв = (количество правильно идентифицированных оттоков)/(общее количество реальных оттоков)

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

Ниже приведены четыре модели, которые мы используем для прогнозирования оттока клиентов:

  1. Логистическая регрессия
  2. Метод опорных векторов (SVM)
  3. Случайный лес
  4. Дерево с градиентным усилением (GBT)

Полученные результаты

Ниже приведены результаты оценки модели с использованием их гиперпараметров по умолчанию.

GBT добился наилучших результатов (F1 = 1 в наборе тестовых данных и точность = 0,973 в наборе тестовых данных), и для обучения требуется больше всего времени, которое составляет 1,48 минуты.

Логистическая регрессия требует наименьшего времени для обучения, которое составляет 0,64 минуты, и достигла третьего лучшего результата (F1 = 0,808 в наборе тестовых данных и Точность = 0,864 в наборе тестовых данных).

SVM является худшим исполнителем (F1 = 0,545 в наборе тестовых данных и точность = 0,973 в наборе тестовых данных), и для обучения требуется 0,73 минуты.

2. Ниже приведены результаты оценки модели с настройкой гиперпараметров.

Мы применяем те же четыре модели для настройки с поиском по сетке и трехкратной перекрестной проверкой. Ниже приведены коды для обучения модели GBT с настройкой гиперпараметров.

GBT добился наилучших результатов (F1 = 0,946 в наборе тестовых данных и точность = 0,973 в наборе тестовых данных), и для обучения требуется больше всего времени, которое составляет 11,62 минуты.

Random Forest достиг вторых близких результатов (F1 = 0,944 в наборе тестовых данных и точность = 0,973 в наборе тестовых данных), и для обучения требуется второе наименьшее время, которое составляет 2,82 минуты.

SVM требует наименьшего времени для обучения, которое составляет 2,16 минуты, и является наихудшей производительностью (F1 = 0,675 в наборе тестовых данных и точность = 0,757 в наборе тестовых данных), а обучение занимает 0,73 минуты.

Заключение и улучшения

  • Мы создали модели машинного обучения, чтобы достаточно точно прогнозировать отток клиентов, что является серьезной проблемой для любых сервисов потоковой передачи музыки. Для этой цели мы использовали PySpark MLLIB, что обеспечивает масштабируемость, поэтому мы можем применять одни и те же коды без каких-либо изменений к полному набору данных (12 ГБ).
  • Модель GBT кажется переобученной, потому что она может достичь оценки F1, равной единице, с небольшим подмножеством (128 МБ) полного доступного набора данных (12 ГБ). Мы должны изучить методы недостаточной выборки, чтобы сбалансировать распределение данных между отточившими и не отточившими пользователями, чтобы увидеть, повлияет ли это на показатели оценки для этих четырех моделей и исправить проблему переобучения.
  • Поиск по сетке — это операция, требующая больших вычислительных ресурсов при применении настройки гиперпараметров, но с большими ресурсами размера кластера Spark и большим количеством времени мы можем обучать эти модели машинного обучения с помощью более обширного поиска по большему набору данных и пространству гиперпараметров, что позволит настроить модель. дальше, и это, вероятно, улучшит общую точность.

Подробную информацию о работе над этим проектом см. на моем Github. Не стесняйтесь оставлять мне любые комментарии или отзывы.