Прогнозирование оттока клиентов с помощью Spark
Уровень оттока клиентов является серьезной головной болью для большинства компаний электронной коммерции. Почему клиенты уходят? Каковы основные факторы взбалтывания? Существуют ли какие-либо закономерности, которые позволяют нам прогнозировать уровень оттока?
Рост оттока клиентов сильно влияет на доходы компаний электронной коммерции. Поэтому их прогнозирование и факторы, влияющие на отток, имеют большое значение для таких компаний.
В этой статье рассматриваются эти проблемы и показано, как прогнозировать уровень оттока для вымышленной компании Sparkify.
Для этого проекта я использую Apache Spark и Python (PySpark).
Обзор проекта Sparkify
Sparkify — это вымышленный сервис потоковой передачи музыки с тысячами песен и авторами, имитирующий популярный потоковый сервис Spotify. Пользователи Sparkify транслируют музыку и взаимодействуют с приложением. В приложении есть два уровня подписки: бесплатная и платная.
Данные, содержащиеся в Sparkify, велики. Для его обработки я работаю с фреймворком Apache Spark.
Общий подход состоит в том, чтобы протестировать алгоритм на меньшем подмножестве данных (около 230 МБ), а затем развернуть его в кластере Spark и протестировать на всем наборе данных.
Сначала я очищаю данные и визуализирую некоторые корреляции между переменными.
В качестве второго шага я преобразовываю некоторые функции в числовые, а также создаю новые функции на основе существующих.
Затем я тестирую три основных алгоритма на этом подмножестве данных. Основываясь на их характеристиках, я выбираю один для окончательного анализа.
Описание данных и разработка функций
Подмножество данных Sparkify доступно в формате json, содержащем примерно 226 пользователей.
Данные Spakrify имеют следующую структуру:
root |-- artist: string (nullable = true) |-- auth: string (nullable = true) |-- firstName: string (nullable = true) |-- gender: string (nullable = true) |-- itemInSession: long (nullable = true) |-- lastName: string (nullable = true) |-- length: double (nullable = true) |-- level: string (nullable = true) |-- location: string (nullable = true) |-- method: string (nullable = true) |-- page: string (nullable = true) |-- registration: long (nullable = true) |-- sessionId: long (nullable = true) |-- song: string (nullable = true) |-- status: long (nullable = true) |-- ts: long (nullable = true) |-- userAgent: string (nullable = true) |-- userId: string (nullable = true)
Несмотря на то, что данные относительно небольшие, они содержат много информации о взаимодействии пользователя с приложением. Чтобы извлечь некоторую релевантную информацию, я сначала очищаю и реструктурирую данные.
В качестве первого шага я удаляю дубликаты, нулевые значения и некоторую менее важную информацию. На втором этапе я рассчитываю некоторые новые функции на основе существующих.
Я также создаю функцию оттока из набора данных на основе функции «подтверждение отмены», включенной в набор данных.
Обработанный набор данных выглядит следующим образом:
+-------------+----------+---------+-----------+-----------------+---------+-----+ |song_per_user|gender_num|thumbs_up|thumbs_down| listening_time|level_num|label| +-------------+----------+---------+-----------+-----------------+---------+-----+ | 381| 1| 17| 5|66940.89735000003| 0| 0| | 381| 1| 17| 5|66940.89735000003| 0| 0| | 381| 1| 17| 5|66940.89735000003| 0| 0| | 381| 1| 17| 5|66940.89735000003| 0| 0| | 381| 1| 17| 5|66940.89735000003| 0| 0| +-------------+----------+---------+-----------+-----------------+---------+-----+
*label — функция оттока.
Потенциальные факторы оттока — визуализация
Прежде чем внедрять более продвинутые инструменты анализа, я сначала смотрю на данные с помощью некоторых визуализаций. Этот подход позволяет мне проверить, есть ли какие-то прямые отношения, визуально очевидные во взаимодействиях с пользователем.
Связан ли отток с определенной переменной времени, например с часом дня?
Уходят ли платные пользователи больше, чем пользователи бесплатной подписки?
Зависит ли отток от географического положения?
Из этих трех визуализаций только географическое положение имеет какое-то отношение к оттоку клиентов. В некоторых штатах уровень оттока выше, чем в других. Однако мы не можем проверить, есть ли другие факторы, влияющие на скорость оттока в каждом географическом местоположении.
Моделирование
В среде Apache Spark поддерживаются не все алгоритмы машинного обучения. Моя стратегия моделирования должна учитывать этот факт.
В качестве первого шага я реализую три основных алгоритма без какой-либо конкретной настройки параметров:
- Логистическая регрессия
- Рэндом Форрест
- Повышение градиента
Из-за того, что набор данных сильно несбалансирован между пользователями, которые ушли, и теми, кто не ушёл, я использую показатель F1 в качестве индикатора успешного прогноза.
Базовый подход: логистическая регрессия, случайный лес и бустинг Gardient
В базовом подходе тестируются три алгоритма: логистическая регрессия, случайный лес и повышение градиента, чтобы проверить их производительность по показателю F1.
Алгоритм повышения градиента работает лучше всего с оценкой F1 99%. Однако эта оценка также указывает на серьезное переоснащение, которое, скорее всего, вызвано небольшой выборкой клиентов, которые ушли из тестовой выборки.
Поэтому в качестве следующего шага я дополнительно пытаюсь решить эту проблему, более равномерно разделив выборку поезда/теста.
На следующем шаге я реализую повышение градиента с параметрами, настроенными следующим образом:
- 3-кратная перекрестная проверка
- максимальное количество итераций: 5, 10
- максимальная глубина: 4, 12
После реализации этой стратегии оценка F1 остается на уровне 99%.
Результаты и заключение
На основе этой стратегии наиболее эффективным алгоритмом является бустинг Гардиента, хотя настройка параметров не улучшает производительность алгоритма. Высокий балл F1, вероятно, вызван небольшим размером выборки тестовой группы.
Основываясь на представленной выше визуализации, факторы, в наибольшей степени влияющие на уровень оттока, следующие: количество песен, воспроизводимых каждым пользователем, вовлеченность пользователей, отображаемая количеством отметок (вниз или вверх) и общее время прослушивания.
Код для этого анализа можно найти в моем профиле на Github.
Автор: Александра Клофат, специалист по данным @ datenvertstehen.de
