Решение проблемы оттока клиентов с помощью современного стека данных

В этой статье мы подробно рассмотрим вариант использования оттока/удержания клиентов. Он должен содержать все необходимое для начала работы с вариантом использования, а предприимчивые читатели также могут попробовать это сами и пройти через связанный репозиторий GitHub.

Обзор

Можно с уверенностью сказать, что почти у каждой компании есть понятие «клиент» и явное желание понять его и лучше удовлетворить его потребности. По мере старения компании неизбежно, что некоторые клиенты уйдут; невозможно сделать всех счастливыми, и некоторый отток неизбежен. То, как определяется отток, может варьироваться от бизнеса к бизнесу; Компании B2B могут совершать сделки по контрактам, B2C — по подписке или полностью через точки продаж и т. д. Однако отток клиентов — это то, что каждая компания должна стремиться максимально минимизировать.

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

Помимо того факта, что отток клиентов широко применим и имеет решающее значение для большинства предприятий, еще одна причина, по которой я хотел затронуть его, заключается в том, что я не часто вижу его в правильном свете. Хотя это вариант использования, который часто рассматривается в руководствах по машинному обучению, я обнаружил, что многие источники чрезмерно упрощают этот вариант использования. Например, каноническим примером является набор данных Telco Customer Churn. Это полезнее, чем прогнозирование выживших на Титанике с точки зрения реальных вариантов использования, но я считаю, что данные обычно не очень хорошо отражают реальную проблему, которую настоящая компания. Тем не менее, это не мешает специалистам по данным пытаться смоделировать проблему оттока клиентов аналогичным образом, и в результате результаты оставят желать лучшего.

Здесь мы будем использовать другой подход. В этой статье мы сформулируем методологию решения проблемы оттока и используем общедоступный набор данных, гораздо более близкий к тому, что будет использовать реальный бизнес. Это временной набор данных, который также должен соответствовать тому, что существует на платформе данных любой компании. К этой статье также прилагается отработанный пример в нашей документации. Прочитав это, мы предлагаем всем подписаться на бесплатную пробную версию Continual и попробовать построить модель оттока клиентов. Мы решили использовать Snowflake в качестве резервного хранилища данных, но его должно быть достаточно просто использовать независимо от того, какое облачное хранилище данных использует ваша компания (Свяжитесь, если у вас возникнут какие-либо проблемы!). Этот пример также содержит резервный репозиторий GitHub, в котором есть все артефакты, необходимые для обучения и развертывания модели в Continual. Мы надеемся, что вы сможете использовать его в качестве вдохновения и аналогичным образом смоделировать свои собственные варианты использования. Кроме того, примечание для пользователей dbt: в этом репозитории есть проект dbt, который можно использовать для быстрого запуска этого варианта использования.

Теперь давайте поговорим о самом важном в этом варианте использования: как мы определяем отток?

Определение оттока

В абстрактной форме вариант использования ML объяснить просто: выберите входные сигналы (также известные как функции) и значение для прогнозирования (также известное как цель), передайте их в алгоритм, и вуаля, рождается модель машинного обучения. Детали немного сложнее.

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

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

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

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

Период прогнозирования: частота, с которой мы хотим делать прогнозы оттока. т.е. мы можем захотеть делать прогнозы каждую неделю, месяц или квартал. Мы назовем это периодом прогнозирования. Обычно мы делаем прогнозы в определенный день периода, например, в начале недели/месяца/квартала.
Порог оттока: количество дней после истечения срока действия учетной записи, которое мы считаем оттоком клиента. Это будет сильно зависеть от нашего бизнеса, но это может быть 0 дней, 30 дней, 60 дней и т. д. Мы будем называть это порогом оттока.
Диапазон времени. Даты начала и окончания каждой транзакции клиента. т.е. когда им нужно обновить свой аккаунт?

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

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

Этот подход представлен на следующем рисунке:

Эту логику можно довольно просто применить в SQL для определения цели оттока, как показано ниже:

case
    — no next transaction and expired beyond churn threshold
    when (next_transaction is NULL and days_expired > churn_threshold) then True
    — there is a next transaction, but it is beyond the churn threshold
    when (next_transaction is not NULL and datediff(days,expiration_dt,next_transaction) > churn_threshold ) then True
    else False
end as is_churn

Разработка функций

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

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

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

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

В случае оттока часто полезно выполнять эти простые оконные функции для агрегирования данных до начала периода прогнозирования. Важно выполнять их до границы прогнозируемого периода, чтобы будущая информация не просачивалась в модель. Это может быть очень вредным и быстро ухудшать производительность модели на реальных данных. Хорошей стратегией является вычисление операции скользящего окна (среднее, сумма и т. д.) для любой интересующей функции и регистрация ее как набора функций в Continual. Когда этот набор функций связан с определением модели в Continual, система автоматически извлечет самое последнее значение, которое даст нам последние скользящие значения для любой функции по состоянию на начало периода прогнозирования.

Эти операции можно легко выполнить в SQL, как показано ниже:

SELECT
    user_id,
    timestamp,
    avg(daily_usage) over (partition by user_id order by timestamp desc rows between 1 following and 30 following) as avg_usage_30d
FROM user_logs

Вопросы машинного обучения

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

Несбалансированные данные. Проблема оттока (будем надеяться!) связана с несбалансированными данными. Другими словами, на самом деле уходит небольшой процент клиентов. Хотя это хорошо для бизнеса, это означает, что в обучающей выборке будет много примеров удержания и относительно мало случаев оттока (довольно распространено ‹5–10%). Если мы не будем осторожны, мы можем построить модель, которая на самом деле не делает ничего, кроме предсказания удержания для каждого клиента (и это правильно в 90+% случаев!). В этом случае проще всего выбрать метрику производительности модели, которая хорошо работает с несбалансированными данными. В частности, ROC AUC и F1, как правило, хорошо работают с несбалансированными данными, тогда как нам следует избегать использования точности в качестве показателя производительности.
Недостаточно данных. Недостаток данных может быть вызван либо отсутствием достаточного количества наблюдений для обучения (например, сотни или несколько тысяч), либо отсутствием достаточного количества признаков. Сосредоточив внимание на временном характере взаимодействия клиента с компанией, мы можем лучше построить надежное определение модели. Поиск достаточных функций является постоянной задачей. Поговорите с бизнес-пользователями и узнайте, какие существуют данные, которые могут помочь в решении проблемы. Также можно сделать вывод, что данных недостаточно для построения хорошей модели. Это упражнение должно, по крайней мере, создать в системе хорошую основу для решения проблемы оттока и создать некоторые базовые модели для сравнения будущей производительности. С Continual новые модели строятся быстро по мере поступления новых данных, чтобы увидеть, произошло ли какое-либо повышение.
Утечка данных из скрытых функций. Иногда легко попасть в ловушку, когда функция может утечь информацию о цели, но на первый взгляд это не так. Что касается варианта использования оттока, я регулярно вижу, как люди используют функцию, соответствующую возрасту учетной записи клиента. Хотя на первый взгляд это выглядит невинной особенностью, в большинстве компаний, вероятно, верно то, что пожилые клиенты также являются более лояльными клиентами — есть причины, по которым они существуют уже 5, 10, 20 лет и т. д. В то же время это это не то, что может получить новый клиент, поэтому вполне возможно, что модель будет придавать большое значение этой функции, а затем не учитывать другие тонкости в данных. Здесь нужно проверить, насколько сильно коррелируют возраст аккаунта и цель. Если это так, удалите его из набора функций, а также проверьте прогнозы между различными популяциями, чтобы проверить, сильно ли отличается производительность модели между ними.
Не забывайте об общей картине. Хотя этот вариант использования обычно называют оттоком клиентов, важно не забывать о более широком бизнес-контексте, в котором мы все работаем. Прогнозировать отток — это весело, но если мы не активно предотвращаем отток клиентов, мы не влияем на бизнес. Благодаря Continual пользователи получают замкнутый рабочий процесс для создания и поддержки моделей и прогнозов поверх своего облачного хранилища данных. Мы можем корректировать наши данные, строить отличные модели и быстро вносить прогнозы в нужную базу данных. Оттуда мы рекомендуем использовать отличный партнерский инструмент, такой как Hightouch, для синхронизации данных из хранилища данных обратно в инструменты, которые использует бизнес. Что касается оттока, было бы здорово синхронизировать эти прогнозы с Salesforce или Hubspot, чтобы отдел продаж имел лучшее представление о риске бегства своих аккаунтов!
Что такое хорошая производительность модели? Здесь нет правильного ответа, так как производительность модели во многом зависит от того, насколько хороши наши данные и содержат ли они сигналы для нашей цели. Постарайтесь установить реалистичные ожидания: неразумно ожидать, что мы сможем создать модель, идеально подходящую для классификации всех оттока и удержания клиентов. Мы подробно рассмотрели это в рабочем примере, но мы можем настроить нашу модель, чтобы генерировать больше прогнозов оттока за счет увеличения количества ложных срабатываний (т. е. прогнозировать отток клиентов, которые не будут уходить). Работайте с бизнесом, чтобы понять, какова стоимость каждого результата, и соответствующим образом оптимизируйте усилия. Кроме того, помните, что некоторый отток неизбежен, и (помните общую картину!) Модель машинного обучения может только давать прогнозы, она не может устранить причину, по которой клиенты недовольны.

Рабочий пример

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

Двигаясь дальше

Это только начало пути оттока клиентов! После того, как у нас есть базовый набор, есть много способов расширить вариант использования. Вот несколько быстрых идей:

Попробуйте разные пороги оттока: у разных компаний разные требования, и могут быть интересны несколько прогнозов для разных периодов оттока: 30 дней, 60 дней, 90 дней и т. д. Как только у нас появится одна модель и работает, это очень быстрое редактирование, чтобы начать создавать другие.
Возвращаются ли когда-нибудь ушедшие клиенты? Действительно, это довольно интересный вопрос, и при наличии правильных данных и исходных данных мы можем ответить и на него! Во многих отношениях ушедшие клиенты могут представлять собой идеальных потенциальных клиентов — они уже знают бренд компании, и очевидно, что в какой-то момент продукт/услуга им что-то нравилось. Это начинает перетекать в вариант использования подсчета лидов (о котором будет рассказано в следующей статье!), но не будет безумием думать о том, что нужно сделать, чтобы ушедший клиент снова превратился в платного клиента.
Добровольный и недобровольный уход: некоторые компании любят проводить различие между клиентами, которые активно разрывают свои отношения (добровольно), и теми, кто просто допускает разрыв отношений (недобровольно). Их можно рассматривать как отдельные модели или как одну задачу многоклассовой классификации. Лучшее понимание сил, стоящих за добровольным и непреднамеренным оттоком, скорее всего, даст преимущество в понимании того, кто, вероятно, является кандидатом на отток, чтобы заманить обратно платежеспособных клиентов.
Отток доходов. Все это время мы фокусировались на клиентах, но можем смотреть на это исключительно через призму продавца и утверждать, что не все клиенты одинаковы. Действительно, некоторые из них тратят большие деньги, а некоторые нет, и вопрос о том, следует ли нам уделять больше внимания оттоку клиентов или оттоку доходов, остается спорным. В последнем случае мы теперь прогнозируем непрерывную переменную, а не дискретную переменную, так что это переносит проблему с проблемы классификации на проблему регрессии, но в основном это одни и те же данные, которые рассматриваются в обоих случаях использования.

Попробуйте отток клиентов с Continual сегодня

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

(Примечание: эта статья впервые появилась в Постоянном блоге.)