Вы когда-нибудь замечали, что кажется, что приложения знают, что вы рассматриваете возможность отмены подписки? Они всегда приходят с каким-то предложением или поощрением (снижение комиссий и т. д.) в нужный момент. Это не может быть просто совпадением… не так ли?
Специалист по данным во мне начал думать об этом феномене и понял, что они, вероятно, смотрят на любые данные, которые они собирают (время входа в систему, действия и т. д.), чтобы предсказать, собираюсь ли я двигаться дальше (также известное как «отток»). Будучи от природы любопытным человеком, я хотел выяснить, как они могут это делать.
Данные
Благодаря курсу, который я проходил в Udacity, я смог получить данные для вымышленного музыкального приложения под названием Sparkify. Этот набор включал записи действий для группы пользователей за период в несколько месяцев. Каждое действие включает в себя:
- информация о пользователе (ID#, пол, тип подписки)
- предпринятое действие (следующая песня, палец вверх/вниз, прослушать рекламу, подписаться и т. д.)
- временная метка действия
- дополнительные метаданные о действии
Это казалось мне идеальным набором для изучения, чтобы определить, могу ли я предсказать отток пользователей. Одной из проблем является размер сдвига набора данных. Для облегчения процессов обработки данных требовались инструменты для работы с большими данными. Для этого Spark использовался в среде Python (пакет pyspark).
Подход
Мой подход состоял из 4 основных шагов:
- Почувствуйте набор данных. Это включает в себя понимание того, насколько грязным он может быть.
- Исследуйте данные. Изучите потенциальные интересующие особенности и способы обобщения данных таким образом, чтобы это было интересно.
- Особенности инженера набора. Создайте конвейер ETL (извлечение, преобразование, загрузка) для преобразования массивного набора в обобщенный, включающий интересующие функции, которые лучше подходят для дальнейшей работы.
- Создайте модель машинного обучения для прогнозирования оттока (используя библиотеку pyspark.ml)
В этой статье я сосредоточусь на интересных шагах: исследовании данных и построении модели. Для тех, кто заинтересован в более глубоком погружении, полный анализ можно найти здесь.
Изучение данных
Чтобы направить свое исследование данных, я выдвинул ряд гипотез о том, что, по моему мнению, может быть характеристиками использования того, кто покинет приложение. По общему признанию, я не эксперт в области музыкальных приложений, но как пользователь у меня были некоторые идеи.
Гипотеза 1. Участники с бесплатными аккаунтами чаще уходят
Мои, хотя здесь бесплатные участники должны слушать рекламу. Прослушивание рекламы может подтолкнуть пользователя к оттоку. Чтобы понять, так ли это, я просто посмотрел на количество пользователей, которые ушли и не ушли, и посмотрел на уровень их подписки.
+-----+-----+------+
|level|churn|count |
+-----+-----+------+
| paid| No | 166 |
| free| Yes | 196 |
| paid| No | 31 |
| free| Yes | 21 |
+-----+-----+------+
Судя по этому беглому взгляду, моя гипотеза неверна. Из ушедших пользователей около 40% были бесплатными. Для остальных пользователей ›50% бесплатно. Хотя моя интуиция была отключена, это все еще кажется интересной особенностью, поскольку она показывает дифференциацию.
Гипотеза 2. Уходящие пользователи реже заходят на сайт
Чтобы проверить эту гипотезу, я посмотрел на процент дней, в течение которых пользователь заходил на сайт. Это было определено путем подсчета количества дней, в течение которых пользователь совершал действия, и деления на количество дней в течение периода времени, в течение которого пользователь был участником. Среднее значение этого процента, а также распределения были исследованы.
+-----+-------------------+
|churn|Mean % days visited|
+-----+-------------------+
| Yes | 52.5 |
| No | 34.2 |
+-----+-------------------+
Опять моя интуиция была отключена. Похоже, что уходящие пользователи на самом деле используют приложение чаще (в процентах от посещенных дней). Это заставило меня задуматься… может быть, уходящие пользователи посещают сайт чаще, но слушают меньше музыки в день, чем другие пользователи. Поэтому я копнул глубже, чтобы исследовать это.
+-----+-----------------------+
|churn|Average # songs (daily)|
+-----+-----------------------+
| Yes | 62.5 |
| No | 65.0 |
+-----+-----------------------+
Что ж, моя интуиция относительно пользователей музыкальных приложений выглядит не очень хорошо. Количество песен, посещаемых в день для оттока пользователей, меньше, но незначительно.
Глядя на всю эту информацию, бросается в глаза то, что существует значительная разница между группами при взгляде на процент посещенных дней. Таким образом, мы включим эту функцию.
Гипотеза 3. Уходящие пользователи посещают некоторые страницы чаще или реже, чем другие пользователи
Мысль здесь заключается в том, что есть определенные действия (посещения страниц), которые может предпринять ушедший пользователь, но другие этого не сделают. Например, они могут чаще получать страницы с ошибками или чаще посещать страницу справки. Для этого я собрал количество посещений для каждой страницы (действия) по группам. Затем я просмотрел страницы в порядке ранжирования, чтобы определить, есть ли определенные страницы, которые значительно выше или ниже в рейтинге.
При сравнении двух рейтингов есть ряд действий, которые имеют значительно разные рейтинги, а также некоторые, которые отображаются в одном, но не в другом. Однако важно отметить, что некоторые действия, такие как «Отмена» или «Подтвердить отмену», не отображаются только для оттока пользователей, поскольку это прямое указание на отток. Поскольку такая осторожность необходима, чтобы убедиться, что мы не используем эти детерминированные элементы в нашей модели. Выявленные элементы делятся на 3 класса:
- Действия со значительными отличиями: Roll Advert, Error
- Действие на одном, но не на другом (недетерминированное): Войти, Зарегистрироваться, Отправить регистрацию.
- Детерминированные элементы в одном списке: Отменить, Подтвердить отмену
Мы должны включить нормализованное количество действий для первых двух сегментов в качестве интересующих функций. Важно отметить, что они должны быть нормализованы, чтобы мы могли измерить количество относительно общего количества (для группы или пользователя, в зависимости от обстоятельств).
Построение модели
Теперь, когда у нас есть интересующие функции, пришло время разработать модель для прогнозирования оттока пользователей для приложения. Были предприняты следующие шаги:
- Создавайте базовые модели с помощью ряда алгоритмов классификации (используя библиотеку pyspark.ml для повышения эффективности обработки) на обучающем наборе.
- Выберите наиболее эффективную модель на основе точности модели в проверочном наборе.
- Настройте параметры модели, используя перекрестную проверку
- Определите результаты модели на тестовом наборе данных
Построение базовых моделей
Для этого были выбраны три модели из библиотеки pyspark.ml: RandomForestClassifier, LogisticRegression и GBTClassifier. Были выбраны все эти модели классификации, обычно используемые для схожих типов задач, и их довольно легко понять. Для этого базового уровня было решено оставить параметры, близкие к значениям по умолчанию.
Для каждой модели был построен конвейер, который берет набор данных, созданный с помощью функций, и масштабирует количество страниц (путем нормализации), один из них кодирует категориальную функцию (тип учетной записи), векторизует функции, а затем применяет модель. Все пайплайны соответствовали тестовому набору данных.
Оцените модели
Каждая из трех базовых моделей использовалась для прогнозирования проверочного набора данных. Оценка F1 использовалась для измерения и сравнения производительности моделей. Оценка F1 была выбрана, поскольку она сочетает в себе точность и полноту моделей. Поскольку доля пользователей, которые уходят, невелика, было бы непредвзято рассматривать любой из этих показателей независимо друг от друга.
Результаты базовой модели были следующими:
- RandomForestClassifier: F1 = 0,648
- Логистическая регрессия: F1 = 0,648
- Классификатор GBT: F1 = 0,740
На основании этой оценки был выбран GBTClassifier для перехода к настройке.
Настроить модель
Модель GBTClassifier была настроена с использованием CrossValidator pyspark.ml и ParamGridBuilder. Для этой работы был использован комбинированный набор для обучения и проверки с применением трехкратного подхода. Для простоты и экономии времени изучались только параметры maxIter и maxDepth.
Оценка окончательной модели
После настройки окончательная модель использовалась для прогнозирования тестового набора данных. Этот тестовый набор никогда не подвергался воздействию модели во время разработки и обучения, чтобы избежать переобучения. Для этой оценки был измерен процент точно предсказанных пользователей. Настроенная модель на этом тестовом наборе дала точность 80%. Учитывая относительную простоту этой модели, я был весьма впечатлен.
Вывод
Мне удалось получить некоторое представление о том, как приложения используют свои данные для прогнозирования поведения пользователей. С относительно скромным набором семплов из вымышленного музыкального приложения нам удалось:
- Выявление интересующих функций: используя данные о действиях пользователя (аналогичные данным, которые собирает любое приложение), мы использовали гипотезы относительно ожидаемого поведения пользователя, чтобы определить интересующие функции.
- Обучение модели: мы использовали определенные интересующие функции для обучения нескольких базовых моделей и использовали метрику F1 для сравнения моделей. Затем мы выбрали лучшую модель для дальнейшего развития и настройки.
- Оцените нашу модель: затем мы оценили нашу модель и обнаружили, что она дает 80% точных прогнозов на тестовом наборе данных.
В конечном счете, с небольшим количеством времени, скромным набором данных и просто интуицией в отношении использования приложений мы получили довольно приличную модель. Легко представить, что компания, разрабатывающая приложения, обладающая ресурсами, опытом и огромным стимулом, может очень точно предсказывать поведение пользователей. На самом деле можно с уверенностью сказать, что их успех в бизнесе может зависеть от способности делать это хорошо.
В целом я доволен результатами моих моделей первого прохода… теперь дело за вами
Как вы улучшите эту модель?
Чтобы увидеть подробности этого анализа, перейдите на мой Github.
