История проекта
Представьте себе работу в новом сервисе потоковой передачи музыки под названием «Sparkify». Чтобы использовать Sparkify, вам необходимо иметь учетную запись и подписаться на одну из двух моделей подписки: бесплатную или платную.
Поскольку вы небольшой стартап, вам нужна быстрорастущая пользовательская база с потенциалом стать платными участниками. Пользователь, удаляющий свою учетную запись, — это худшее, что может случиться с вашим сервисом. Вот почему вы принимаете меры и пытаетесь определить пользователей с высоким потенциалом ухода, чтобы дать им стимул остаться или получить отзывы о том, как улучшить сервис.
Используемые данные
Данные об использовании Sparkify доступны на основе того, какие функции для моделей могут быть получены. Доступно 20 ГБ данных, однако по причинам вычислительного характера только небольшое подмножество из 128 МБ используется для исследования данных, анализа признаков и экспериментов с моделями.
Предполагая, что данные подмножества являются репрезентативными для полных данных, выводы начального исследования должны хорошо обобщаться и могут быть масштабированы до полного набора.
Исследовательский анализ данных
Данные состоят из следующих признаков:
Принимая во внимание, когда большинство учетных записей было удалено, можно заметить, что пики приходятся на утро около 7 утра и днем.
Глядя на день, есть пик в начале месяца:
Большая часть аккаунтов была удалена в выходные:
Особое внимание уделяется функции «страница», поскольку она представляет события, которые выполнил пользователь. Функция «страница» может принимать следующие значения (первый столбец). Второй столбец представляет общее количество событий для каждой страницы, выполненных пользователем, вошедшим в систему:
Событие «Подтверждение отмены» будет использоваться для определения того, удалил ли пользователь свою учетную запись, и будет использоваться для обучения моделей.
Распределение событий страницы, разделенное по оттоку пользователей, можно наблюдать следующим образом (игнорируя событие «NextSong»):
красный = пользователи, которые удалили свою учетную запись
зеленый = все еще активные пользователи
Можно заметить, что наиболее существенными различиями являются количество событий «Мне нравится» и «Прокручивать рекламу».
Дополнительными показателями для оттока пользователей может быть количество времени, которое они проводят в сервисе.
У активных пользователей сессии почти в 3 раза длиннее (avgSessionDuration):
И воспроизводить больше песен за сеанс
Разработка функций
После анализа данных следующие функции могут сыграть роль в том, удалит ли пользователь свою учетную запись или нет:
- Количество песен за сессию
- Средняя продолжительность сеанса
- Количество сеансов в месяц
- Время с момента регистрации
- Пол
- Платный пользователь или бесплатный пользователь
- Соотношение: «большой палец вниз» на количество прослушанных песен
- Количество ошибок за сеанс
- Количество посещений страницы
Эти функции учитываются в кадре данных Spark. Затем числовые признаки масштабируются с помощью MinMaxScaler.
Предварительная обработка данных
Данные предварительно обрабатываются в следующие этапы:
- Создайте кадр данных для каждой функции из исходного набора данных.
- При необходимости создайте категориальные функции и приведите их к целому числу, если это необходимо.
- Разделите столбец «страница» на основе значений на отдельные функции, используя функции «groupby», «pivot» и «agg».
- Объедините все функции в один фрейм данных функции, соединив их слева (чтобы не потерять данные) на идентификаторе пользователя.
- Заполните все пропущенные значения, вызванные процессом построения признаков и левым соединением (например, для средних значений).
- Нормализуйте числовые признаки (не категориальные) с помощью MinMaxScaler
- Наконец, создайте VectorAssembler, чтобы преобразовать только те функции, которые следует использовать для обучения модели.
Моделирование
Оглядываясь назад на распределение данных между активными и удаленными учетными записями, можно увидеть, что наблюдается смещение 1:3 в сторону активных пользователей.
Вот почему точность не может быть использована должным образом в качестве метрики. Вместо этого использовалась оценка F1.
При определении лучшей модели я смотрел на показатели в дополнение к функциям, релевантным в каждой модели.
1. Наивная модель
Сначала я взял наивный подход за основу для сравнения с другими моделями. При таком подходе я всегда устанавливаю прогноз «без оттока пользователей». Эта модель привела к следующей точности и оценке F1:
2. Логистическая регрессия
Логистической модели потребовалось 74 минуты для обучения, по 42 минуты для прогнозирования обучающего и тестового набора.
Ниже приведены метрики, которые имеют более высокую точность, а также более высокий балл F1 как для обучающего набора, так и для тестового набора, чем наивный подход:
На приведенном ниже графике показаны коэффициенты функций, указывающих, какие из них имеют положительную и отрицательную корреляцию с удалением учетной записи пользователя.
3. Дерево с градиентным усилением
На обучение градиентного дерева ушло 108 минут, а на прогнозирование обучающего и тестового набора ушло 37 минут.
Метрики следующие:
Важность функции заключается в следующем:
4. Случайный лес
Для обучения модели случайного леса потребовалось 85 минут, по 36 минут для прогнозирования обучающего и тестового набора.
Метрики следующие:
Важность функции заключается в следующем:
Заключение
Мы прошли долгий путь, начав только с необработанных данных. Потребовалось несколько шагов, чтобы можно было даже начать строить модели.
После проверки набора данных на наличие аномалий я провел некоторый анализ признаков, чтобы получить некоторое представление о значении данных. Основываясь на этих выводах, я смог определить соответствующие данные и построить функции для модели.
Поскольку функции все еще были в необработанном, несмешанном состоянии, я предварительно обработал их с помощью методов машинного обучения.
Наконец, я достиг состояния, когда могу создавать модели для предсказания оттока пользователей. Начав с наивного подхода для сравнения более сложных моделей, я создал три дополнительных. Модели «логистическая регрессия», «дерево с градиентным усилением» и «случайный лес».
После использования трех разных моделей для прогнозирования оттока пользователей «Sparkify» я смог достичь оценки F1 0,85 со случайным лесом для тестового набора.
Результат можно улучшить, выполнив более глубокое исследование данных, что приведет к увеличению количества несвязанных функций и сокращению слишком большого количества коррелирующих функций. Кроме того, уменьшение размерности, такое как PCA, может быть использовано для сокращения времени и ресурсов вычислений.
Кроме того, гиперпараметры могут быть точно настроены для данной проблемы.
Сам проект дал мне больше информации об анализе данных с использованием Spark, поскольку раньше я использовал только Pandas. В будущем я хотел бы углубиться в аспект распространения анализа на разные машины, а также сравнить Spark с другими системами, такими как Hadoop.
Исходники этого проекта доступны на моем GitHub.
