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

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

Этот проект выполняется в Amazon Web Services с использованием EMR Notebook, интегрированного с сеансами Elastic MapReduce и Pyspark. Наш набор данных для анализа имеет объем 12 ГБ, предоставленный Udacity Data Scientist Nanodegree. Наш анализ следует процессу CRISP-DM. Коды можно найти на Мой Github.

Понимание бизнеса

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

Понимание данных

Набор данных имеет 26259199 записей, 18 столбцов. Лучше посмотрите на атрибуты данных, как показано ниже.

# Data types
[('artist', 'string'), ('auth', 'string'), ('firstName', 'string'), ('gender', 'string'), ('itemInSession', 'bigint'), ('lastName', 'string'), ('length', 'double'), ('level', 'string'), ('location', 'string'), ('method', 'string'), ('page', 'string'), ('registration', 'bigint'), ('sessionId', 'bigint'), ('song', 'string'), ('status', 'bigint'), ('ts', 'bigint'), ('userAgent', 'string'), ('userId', 'string')]
#First Row
Row(artist='Popol Vuh', auth='Logged In', firstName='Shlok', gender='M', itemInSession=278, lastName='Johnson', length=524.32934, level='paid', location='Dallas-Fort Worth-Arlington, TX', method='PUT', page='NextSong', registration=1533734541000, sessionId=22683, song='Ich mache einen Spiegel - Dream Part 4', status=200, ts=1538352001000, userAgent='"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36"', userId='1749042')

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

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

Мы предлагаем две причины разницы в записях:

  1. Гости также посещают и используют Sparkify, поэтому они оставляют записи без идентификации. Это означает, что в имя, пол, фамилия, местоположение, регистрация, пользовательский агент есть пустые значения. Гости не будут учитываться, поскольку они не являются пользователями и не связаны с оттоком пользователей.
  2. Действия пользователей не обязательно связаны с потоковой передачей музыки. Логично, что исполнитель, длина, песня имеют значение null, когда пользователи не слушают музыку. Записи не будут засчитываться во время прослушивания.

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

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

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

Уровень показывает вероятность подписки пользователя, поскольку премиум-пользователи с меньшей вероятностью покинут Sparkify.

Страница показывает различные действия пользователей, что является отличным индикатором их поведения.

Между тем, мы замечаем четыре функции, производные от исходных функций:

  1. Дни регистрации: старые пользователи больше привязаны к Sparkify.
  2. Подсчет исполнителей: пользователи, активно слушающие больше музыки, больше привязаны к Sparkify.
  3. Общая активность: пользователи, активно работающие с приложением, больше привязаны к Sparkify.
  4. Активность за последнюю неделю: пользователи, покидающие Sparkify, становятся менее активными за последнюю неделю. Средняя активность пользователей без отмены — 352, а у пользователей с отменой — 228, менее активно.

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

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

Spark ML похож на пакет Python sklearn, но есть заметные отличия. VectorAssembler стремится объединить независимые функции в векторы для машинного обучения. Набор данных обрабатывается в VectorAssembler — StandardScaler. Все функции, кроме оттока (метка для прогнозирования), userId (не имеет отношения к оттоку), page_Cancel и page_Cancellation (сильно связаны с оттоком, не имеют значения для прогнозирования), объединены в VectorAssembler. Функции масштабируются с использованием чистого стандартного скейлера, деленного на стандартное отклонение.

Для классификации оттока пользователей мы применяем и сравниваем три модели классификации: логистическую регрессию, классификатор опорных векторов и классификатор дерева градиентного усиления. Наши наборы данных для выбора модели представляют собой обучающий набор данных с 50% записей и набор данных для тестирования и проверки с 25% записей каждый. Мы измеряем модели, используя наборы данных для проверки и тестирования, а также точность и оценку f1.

Уточнение

Идея использования трех моделей классификации возникла в результате исследования мини-набора данных размером 128 МБ. Jupyter Notebook для анализа мини-наборов данных также доступен в моем проекте Github. Три модели применимы для больших наборов данных, но эксперименты показывают, что для обучения модели доступно только около 200 записей, а производительность модели нестабильна. Мы думаем, что реализация выбора модели для большего набора данных Sparkify будет лучшим улучшением.

Оценка

Производительность трех моделей классификации показана ниже.

Судя по приведенным выше результатам, Gradient Boosting Tree Classifier превосходит другие модели классификации с 0,82 ~ 0,83 балла F1 как при проверке, так и при тестировании наборов данных.

Вывод

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

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

Другое возможное открытие связано с действиями пользователя на странице. Из распределения действий на странице мы заметили, что действия, связанные с музыкой, такие как Thumbs Up, Thumbs Down, Next Song, активны среди действий на странице. Это открытие дает представление о том, что рекомендуемая музыка связана с этими действиями, а это означает, что мы можем исследовать влияние рекомендации на отношение пользователей и их отток. Исходный набор данных не улавливает рекомендации пользователей, но это хорошее направление для улучшения модели.