Фреймворк для анализа оттока

Пошаговое руководство по анализу оттока клиентов с использованием смоделированного набора данных

Введение

«Отток» стал общеупотребительным деловым словом, которое относится к понятию скорости оттока, определяемому Википедией как:

«доля договорных клиентов или подписчиков, которые покидают поставщика в течение определенного периода времени»

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

Итак, когда мы разрабатываем «модель оттока», мы должны использовать существующие данные с двумя целями:

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

Прогнозирование оттока требует большой работы, и это непростая задача, но, что более важно, это даже не конечная цель: это отправная точка для разработки и реализации стратегии удержания клиентов!

В этой статье основное внимание будет уделено реализации платформы анализа оттока, вдохновленной книгой: [1]"Борьба с оттоком с помощью данных" Карла С. Голда. Это отличная книга, которую я рекомендую всем, кто работает с данными об оттоке: книга содержит множество деталей и примеров (с объясненным кодом!), показывающих сквозной анализ оттока. Из всех предложенных шагов я выбрал наиболее актуальные и успешные в своем опыте и адаптировал их к контексту и набору данных, с которыми я знаком. В этой статье фреймворк был применен к смоделированному набору данных, вдохновленному реальным бизнес-кейсом (ссылка на репозиторий Github).

Содержание:

1- Данные
1.1- Какие данные следует учитывать при разработке модели оттока?
1.2- Необработанные данные
2- Предварительная обработка данных: показатели оттока< br /> 2.1- Создание клиентских метрик
2.2- Анализ метрик оттока
3- Прогнозирование оттока с помощью машинного обучения
3.1- Логистическая регрессия
3.2- Случайный лес
3.3- XGBoost
4- Создание прогнозов оттока
5- Следующие шаги
Ссылки

1. Данные

1.1 Какие данные следует учитывать при разработке модели оттока?

Это не тривиальный вопрос! С оттоком может быть связано много разной информации, и установление общих правил никогда не охватит все возможные предприятия, системы, контексты и т. д. Например, размышляя об информации, связанной с оттоком, мы можем рассмотреть:

Демографическая информация о клиентах (или учетных записях): пол, местонахождение, возраст, срок пребывания в должности, …
Информация, связанная с подписками: продукты, на которые подписались клиенты, активированные надстройки, даты активации и отмены…
Информация об оплате: Сколько платят клиенты? Какой способ оплаты они используют? Платят регулярно? …
Информация об использовании продукта: информация для входа в систему, информация о кликах, минуты взаимодействия с продуктом, …
Информация, связанная с взаимодействием со службой поддержки: чаты или звонки клиентов, рейтинг служб поддержки, детали претензий, …
…

При переводе в системы эти данные должны поступать из различных транзакционных систем (CRM, ERP, биллинга и т. д.) и должны быть должным образом организованы в некое хранилище данных/хранилище данных (в идеале — делать частые моментальные снимки, охватывающие несколько месяцев). Учитывая, что это происходит, должно быть доступно много ноу-хау, чтобы понять, какое поле представляет какую информацию, и, как правило, для доступа к этим данным требуется множество разрешений, особенно если какой-то внешний консультант захочет их использовать.

По моему опыту, все эти данные (и связанная с ними значительная история) редко доступны. Обычно то, что доступно и упорядочено, — это данные, которые компании обязаны хранить и использовать в соответствии с финансовыми или юридическими нормами или просто потому, что данные необходимы для ведения повседневной деятельности. Эти данные должны быть доступны где-то.

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

По всем этим причинам, чтобы статья была простой и реалистичной, я сосредоточусь на «небольшом» наборе данных, в идеале на основе данных, которые должны быть доступны в любой CRM.

1.2 Исходные данные

Давайте представим, что мы — компания B2C (от бизнеса к потребителю), предлагающая онлайн-видеокурсы через наш веб-сайт. Наш бизнес работает следующим образом:

Новый пользователь мог подписаться на курсы по двум доменам: машинное обучение (домен А) и гитара (домен Б). Они могут приобрести несколько подписок, которые позволяют им одновременно входить в систему с разными пользователями. Кроме того, они могут включить «дополнение», которое заключается в получении еженедельных сеансов в прямом эфире со специалистом из выбранного домена.
После подписки пользователь получает ежемесячный платеж и может иметь или не иметь скидки. Они могут отменить свою подписку в любое время, а это означает, что подписка не будет продлена в конце месяца.
Пользователи могут открыть чат и связаться со службой поддержки по любому вопросу.

Необработанные данные будут выглядеть следующим образом:

Этот бизнес-контекст довольно распространен и должен применяться к любому бизнесу B2C с ежемесячной подпиской и возможностью включения надстройки к базовому предложению (например, такие компании, как: медиа-контент по запросу, телекоммуникации, коммунальные услуги, электронная коммерция, страхование, и премиальное программное обеспечение).

2. Предварительная обработка данных: показатели оттока

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

Поскольку наша цель — прогнозировать отток клиентов для разработки стратегии удержания, нам нужно заранее знать, будет ли отток клиентов, чтобы мы могли что-то сделать, чтобы повлиять на это решение.

2.1 Создание клиентских метрик

Какие KPI мы можем получить, учитывая исходные данные выше? Вот несколько идей (это столбцы нашего набора данных):

«mrr_ratio» = ежемесячный регулярный доход от подписки. Итак, для каждого клиента: суммируем([ежемесячная плата — скидка]) по каждой активной подписке, считаем количество активных подписок и делим два.
«mrr_ratio_A» и «mrr_ratio_B» = ежемесячные текущие доходы по доменам (A — машинное обучение; B — гитара) с учетом mrr и количества активных подписок по доменам.
«subs_A» и «subs_B» = количество активных подписок по доменам.
«discount_ratio» = % скидки, которая есть у клиента, полученная как: 1 — ([ежемесячная плата — скидка] / [ежемесячная плата])
«has_addon» = флаг, указывающий, есть ли у клиента хотя бы одна подписка с надстройкой
«support_chats» = количество чатов, инициированных клиентом за период
«is_churn» = флаг, указывающий, собирается ли клиент уходить (1) или нет (0)

На мой взгляд, лучший способ использовать наши исторические необработанные данные для расчета этих KPI:

Определите некоторый фиксированный период наблюдения (например, 20-го числа каждого месяца), оставив некоторое разумное время для нашего обновления (которое, как мы предполагаем, произойдет 30-го числа каждого месяца).
Создайте таблицу «А», в которую для каждого «потерянного» клиента мы включаем даты его прошлых оттоков.
Создайте еще одну таблицу «В», в которой для каждого клиента 20-го числа месяца мы рассчитываем KPI на основе данных за последние 30 дней. Другими словами, мы делаем скриншоты клиентских метрик ежемесячно, но делаем это 20-го числа каждого месяца.
Мы объединяем таблицы «A» и «B» по идентификатору клиента и помечаем все строки, которые окажутся в оттоке к следующей дате наблюдения.

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

(Примечание: это смоделированный набор данных. Все непрерывные показатели были взяты из многомерного распределения Гаусса, которое аппроксимирует реальные данные. Вот почему у нас есть отрицательные значения и десятичные значения в KPI, которые не должны быть отрицательными или десятичными. . Кроме того, каждая строка должна соответствовать идентификатору клиента, но эта информация не имеет значения).

2.2 Анализ показателей оттока

Как только у нас появятся метрики, мы наконец сможем начать проверять, как они связаны с оттоком.

Наиболее интуитивный способ исследовать эту взаимосвязь — использовать когортный анализ. Обычно 10 когорт создаются путем разделения данных каждой метрики на 10 сегментов одинакового размера в зависимости от их значений. Затем мы связываем каждую метрику с флагом «is_churn», вычисляя уровень оттока в каждой когорте. Если метрика не является непрерывной и имеет менее 10 категориальных значений, то мы просто рассматриваем одну когорту на категорию.

На левом графике мы видим, что клиенты с более высоким mrr_ratio в среднем отдают больше, так как платят больше за подписку:

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

Напротив, если мы видим метрики, которые, независимо от среднего значения когорты, не влияют на отток (например, горизонтальная линия), то мы можем рассмотреть возможность исключения метрики из модели.

3. Прогнозирование оттока с помощью машинного обучения

Теперь мы будем использовать набор данных для прогнозирования оттока.

Обратите внимание, что отток клиентов непросто предсказать. Решение об оттоке является субъективным и не всегда может быть логичным выбором: один клиент может уйти из-за проблем, связанных с затратами, а другой может уйти из-за качества. Кроме того, плохое обслуживание клиентов или предполагаемое негативное отношение к продукту/бренду могут спровоцировать субъективное решение об уходе.

По этим причинам производительность модели не будет такой высокой, как в других задачах машинного обучения. По словам Карла С. Голда [1], здоровая модель прогнозирования оттока будет работать с показателем AUC от 0,6 до 0,8.

Некоторые соображения, которые следует учитывать:

Отток — это задача бинарной классификации: модель научилась бы предсказывать, относится ли запись к классу 1 (удаленный клиент) или классу 0 (не отток). Однако нас будет интересовать вероятность того, что каждая запись принадлежит каждому классу. Учитывайте это при выборе модели.
Производительность модели не может быть измерена с помощью показателя точности. Обычно небольшое количество клиентов уходит, и поэтому наш набор данных несбалансирован: всего ок. 10% фиктивных данных относятся к классу 1 (ушедшие клиенты). Любая модель, которая всегда предсказывает класс 0, будет иметь точность 90%, но такая модель совсем не поможет. Вместо этого мы будем использовать показатель roc_auc для измерения производительности.
Мы будем использовать перекрестную проверку для настройки гиперпараметров моделей. Поскольку мы работаем с временным набором данных, мы не можем просто использовать случайное назначение записей для каждой складки. Нам нужно обучить нашу модель использовать настоящие или прошлые данные и никогда не использовать будущие данные. Таким образом, рекомендуется использовать Разделение временных рядов (из sklearn [2]), которое работает с любым набором данных, отсортированных по времени.

(Примечание: при перекрестной проверке обычно используется 10 разделений. Здесь было использовано 3 из-за ограниченного размера данных и очень несбалансированных данных по отношению к классу 0).

Давайте теперь сравним три модели классификации.

3.1 Логистическая регрессия

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

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

3.2 Случайный лес

Случайный лес — это ансамблевый древовидный метод.

Методы на основе дерева — это очень мощные алгоритмы классификации (или регрессии), которые заключаются в разбиении данных о поездах по нескольким узлам принятия решений. Каждый узел принятия решений выполняет «разделение» с решением «Истина/Ложь» на основе определенного признака. Решение о разделении определяется таким образом, чтобы на следующем уровне дерева «энтропия» нашего набора данных уменьшалась больше всего. Энтропия — это мера беспорядка данных, и она связана с «приростом информации», который мы можем получить в нашей задаче классификации/регрессии.

Например, в задаче бинарной классификации, если мы заметим, что, разбивая данные по признаку, мы получаем — для каждой результирующей ветви «Истина/Ложь» — 95 % данных, принадлежащих одному классу, и 5 %, принадлежащих противоположному классу. , то нам удалось получить больше информации из наших данных, снизив уровень их беспорядка или «энтропии».

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

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

Давайте теперь настроим гиперпараметры RF в нашем наборе данных, выберем лучшую модель и покажем наиболее «важные» функции (то есть частоту, показывающую, как часто каждая функция используется для создания разделения решений):

3.3 XGBoost

XGBoost расшифровывается как Extreme Gradient Boosting и представляет собой еще один метод ансамбля на основе деревьев, который, подобно RF, позволяет комбинировать прогнозы, сделанные несколькими деревьями решений.

XGBoost — это эволюция («Extreme») методологии «Повышение градиента». Итак, чтобы проиллюстрировать XGBoost, давайте рассмотрим эти два аспекта по отдельности.

В методах «повышение градиента», в отличие от RF, построенные деревья очень тесно связаны между собой. Прогнозы делаются «слабыми учениками» (то есть простыми деревьями), которые улучшаются снова и снова. Обычно исходным прогнозом является среднее целевое значение, которое затем уточняется путем создания новых деревьев. Каждое новое дерево строится из ошибок предыдущих деревьев: поэтому, начиная с остатков/неправильных прогнозов предыдущих «слабых учеников», строится новое дерево, минимизируя функцию стоимости и присваивая больше весов атрибутам, вызвавшим ошибки. . Наконец, результаты объединяются путем взвешивания результатов каждого дерева.
Начиная с «повышения градиента», «Экстремальное усиление градиента» представляет собой полный алгоритм, который включает в себя несколько улучшений метода повышения градиента, таких как: оптимизация производительности и параметр регуляризации (что позволяет избежать переобучения). Самое главное, благодаря этим дополнительным элементам XGBoost может работать на простых машинах, таких как обычные ноутбуки.

4. Создание прогнозов оттока

Наиболее эффективной моделью является XGBoost, и теперь мы будем использовать ее для прогнозирования вероятности оттока тестового набора (содержащего новые записи, не использованные на этапе обучения).

После импорта тестового набора мы вычисляем для каждой записи предсказанные моделью вероятности принадлежности к классу 1 (ушедшие клиенты) и строим показатель ROC_AUC:

Давайте добавим предсказанный класс к исходным данным. По умолчанию все записи с прогнозируемой вероятностью ≥ 0,5 будут отнесены к классу 1. Мы можем снизить этот порог и сравнить полученные матрицы путаницы:

Снижая пороговое значение, мы можем идентифицировать больше уходящих клиентов (истинные положительные и ложные срабатывания), но по-прежнему существует значительное количество клиентов, которые уйдут, но мы не сможем их идентифицировать (ложноотрицательные результаты), несмотря на хорошие характеристики нашей модели xgboost.

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

Для клиентов с прогнозируемой_пробой > 0,75 = высокий риск оттока мы можем разработать «сильную» стратегию удержания. Поскольку мы ожидаем мало ложных срабатываний, мы можем позволить себе инвестировать в этих клиентов с большей уверенностью.
Клиенты с прогнозируемой_пробой от 0,5 до 0,75 = умеренный риск оттока и «умеренная» стратегия удержания.
Клиенты с прогнозируемой_пробой от 0,25 до 0,5 = низкий риск оттока и «слабая» стратегия удержания.

5. Следующие шаги

На этом этапе у нас должна быть рабочая модель, которая может присваивать «вероятность оттока» любым новым данным.

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

Вот несколько идей для решения этих вопросов:

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

Давайте объединим важность признаков, показанных выше, с нашими прогнозами. Например, обе древовидные модели оценили «subs_B» как наиболее часто используемую функцию в деревьях. Нам нужно больше вникнуть в это и понять, как выглядят уходящие и не уходящие клиенты по отношению к subs_B. Здесь поможет когортный анализ, рассмотренный ранее:

Кажется, что клиенты с высоким оттоком имеют минимальное значение (т. е. 0 подписок, данные были преобразованы, поэтому значения по оси X здесь мало интерпретируются) или слишком большое количество «subs_B». Мы должны быть осторожны, чтобы сделать некоторые причинно-следственные выводы между «subs_B» и «is_churn», поскольку этот анализ не доказывает никакой причинно-следственной связи. Тем не менее, мы можем проверить некоторые гипотезы:

Кажется, что клиенты довольны нашим продуктом Б. Может ли это помочь в перекрестных продажах «Б» клиентам, у которых есть только продукт А, чтобы уменьшить отток клиентов?
Мы также должны понимать, в чем бизнес-причина клиентов с таким количеством подписок категории «В». Мы можем обучать их более эффективному использованию наших продуктов и сокращению количества подписок категории B.

Как измерить успех наших действий:

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

A/B-тесты — очень распространенный способ сделать это:

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

План развертывания:

Предлагая действия по удержанию, мы не должны забывать учитывать другие контекстуальные аспекты. Вот некоторые из них: какой отток вызывает беспокойство? (т. е. много ли привлечено новых клиентов, чтобы компенсировать отток?) Каков бюджет для решения проблемы? как долго мы должны ждать, чтобы увидеть результаты? Можем ли мы использовать какие-либо другие данные для улучшения наших моделей? что уже сделано?

Это поможет нам понять, осуществимо ли то, что мы предлагаем.

Спасибо за чтение!!