Введение

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

Задания

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

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

Проблема

Помощь музыкальному сервису Sparkify в прогнозировании оттока.

Набор данных

Набор данных для этой задачи — Sparkify от Udacity. Исходные данные, которые я собрал, составляют примерно 12 ГБ; хранение и обработка могут потребовать больше времени и ресурсов; однако из-за этих ограничений я выбрал один процент от общего объема данных, что составляет 128 МБ, что эффективно для создания модели.

  • ts: метка времени (в миллисекундах; целое число)
  • auth: указывает, вошел ли пользователь в систему (строка).
  • userId: уникальный идентификатор пользователя (число, сохраненное в виде строки).
  • firstName: имя пользователя (строка).
  • lastName: фамилия пользователя (строка).
  • gender: пол пользователя (строка)
  • registration: время регистрации пользователя (в миллисекундах; целое число).
  • level: уровень подписки пользователя (строка)
  • местоположение: город и штат пользователя (строка)
  • sessionId: уникальный идентификатор сеанса (целое число).
  • itemInSession: уникальный идентификатор внутри сеанса (целочисленная последовательность).
  • страница: страница, к которой обращается пользователь (строка)
  • artist: исполнитель песни (строка)
  • песня: название песни (строка)
  • length: продолжительность песни (в секундах; с плавающей запятой)
  • статус: код возврата HTTP (целое число)
  • метод: метод HTTP (строка)
  • userAgent: агент пользователя HTTP (строка)

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

Во время исследования данных я обнаружил некоторые важные особенности, которые можно вывести из существующих атрибутов, а именно:

  • пол: является ли пользователь мужчиной (1) или женщиной (0)
  • уровень: является ли пользователь платным (0) или бесплатным (1)
  • понижение: 1, если пользователю не нравится событие, иначе 0
  • churn (метка): 1, если пользователь отменил событие, иначе 0
  • num_songs (количество): количество песен пользователя.
  • num_thumbs_up: количество лайков пользователем
  • num_thumbs_down: количество отметок "палец вниз" пользователем
  • num_playlist: Количество песен, добавленных пользователем в свой плейлист
  • num_friends: количество друзей, добавленных пользователем
  • sum_listened: Длина прослушанных пользователем песен.
  • avg_song_session: Среднее количество песен во всех сеансах пользователя.
  • num_artists: количество художников, на которых подписан пользователь
  • days_member: Количество дней, в течение которых пользователь оставался на мероприятии.
  • num_session: количество сеансов пользователя
  • dur_session: продолжительность сеанса

Исследование данных

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

Отмена: определяет, останется ли пользователь на мероприятии или отменит его. 1, если пользователь отменяет событие, иначе 0.

Из приведенного выше графика мы можем наблюдать следующее:

  • Около 170 пользователей сохраняют события.
  • Около 50 пользователей отменяют мероприятия.

Понижение: определяет, понизит ли пользователь рейтинг события или нет. 1, если пользователь понижает версию события, иначе 0.

Из приведенного выше графика мы можем наблюдать следующее:

  • Около 100 пользователей мужского пола и 75 пользователей женского пола понижают рейтинг событий.
  • Около 20 пользователей мужского пола и 28 пользователей женского пола не понижают рейтинг мероприятия.

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

Из приведенного выше графика мы можем наблюдать следующее:

  • Медиана пользователей, сохраняющих событие, составляет 75 дней. Он имеет много выбросов и положительно искажен.
  • Медиана пользователей, отменяющих мероприятие, составляет 50 дней. Он имеет несколько выбросов и выглядит нормально.

Страница. Содержит информацию о различных действиях пользователей во время мероприятия. Тип активности: «Следующая песня», «Войти», «Палец вверх» и т. д.

Из приведенного выше графика мы можем наблюдать следующее:

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

Дизайн решения

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

Я разделил набор данных на обучающий (80 процентов) и тестовый (20 процентов) наборы и построил конвейер, который собирает вышеупомянутые функции, масштабирует их, а затем запускает модель машинного обучения. Ниже приведены модели классификации, которые я использовал:

  • Логистическая регрессия
  • Дерево решений
  • Случайный лес
  • Дерево повышения градиента

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

Результаты и анализ

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

Из всех моделей мы видим, что дерево повышения градиента является лучшим, потому что его точность и оценка F-1 высоки и близки друг к другу, что указывает на то, что оно работает хорошо. Другие модели обеспечивают наибольшую точность, но когда дело доходит до оценки F-1, они проигрывают. В результате оптимальной моделью является дерево повышения градиента.

Рекомендации

https://medium.com/@olivier.klein/sparkify-udacity-data-scientist-nanodegree-capstone-project-65e3181ea2b0

Данные: https://github.com/celestinhermez/sparkify_customer_churn/blob/master/mini_sparkify_event_data.json

Исходный код: https://github.com/krishnakanth-G/Sparkify-Churn-prediction