[БЕЗ_ЗВУКА] В
этом видео мы разбираем одну из наиболее актуальных задач в области анализа
поведения пользователей — задачу прогнозирования оттока.
Эта задача активно решается в самых разных предметных областях, например,
в таких областях, как банкинг или телекоммуникация.
Здесь важно успевать отслеживать переходы клиентов банка в другие банки
или переходы клиентов одной телекоммуникационной компании в
другие и вовремя проводить методики по удержанию таких клиентов.
Причем задача является актуальной не только для таких крупных областей,
она также очень актуальна для сферы ритейл, для интернет-маганизов,
для сферы досуговых сервисов, например, онлайн-кинотеатры или онлайн-игры.
Теперь давайте обсудим, почему же эта задача является экономически обоснованной.
Вообще говоря, для большинства сервисов справедливо следующее замечание:
чем больше клиентов, чем больше пользователей у сервиса есть,
тем лучше он монетизируется и тем больше прибыли он приносит.
Поэтому с этой точки зрения нам всегда выгодно иметь много пользователей.
Возникает вопрос: как же этого добиться?
Вообще говоря, добиться этого можно двумя способами: во-первых, больше пользователей
может появиться за счет того, что мы очень активно их привлекаем,
и у нас есть постоянный приток новых пользователей, а также за счет того,
что мы очень активно предотвращаем отток, удерживаем старых пользователей,
и у нас сокращается тем самым уменьшение активной пользовательской базы.
Соответственно, нам важно хорошо решать обе эти задачи.
Часто удержать одного пользователя стоит существенно дешевле,
чем привлечь нового пользователя.
Более того, когда мы удерживаем пользователя, мы понимаем, какого именно
клиента мы удерживаем, и нам очень важно удерживать наших ключевых клиентов,
которые приносят сервису много денег.
С другой стороны, когда мы привлекаем одного нового пользователя, мы никогда
не знаем, как сложится его взаимодействие с сервисом и перейдет ли он, скажем,
в группу лояльных пользователей.
Соответственно, задача удержания важна еще с этой точки зрения.
Возникает вопрос: а как же нам ее решать?
Кажется, что нам выгодно удерживать всех пользователей, которые у нас есть.
Но с другой стороны, мы понимаем, что процесс удержания — не бесплатный.
Для того чтобы пользователя удержать,
нам нужно какое-то количество средств в это инвестировать.
Соответственно, удерживать абсолютно всех пользователей мы можем далеко не всегда.
Это дорого.
Для того чтобы эффективно управлять процессом удержания, нам нужно уметь
адресно удерживать тех пользователей, которые, с одной стороны, нам важны,
а с другой стороны, тех пользователей, которые действительно склонны к оттоку.
Плюс нужно учитывать тот факт, что процесс удержания происходит не мгновенно — нам
нужно уметь выделять пользователей, склонных к оттоку, до того,
как они приняли решение о том, чтобы от нас уйти, и непосредственно это сделали.
Теперь давайте формализуем постановку задачи.
Прежде всего, нам нужно определиться с тем, как мы формализуем понятие оттока.
Далеко не всегда пользователи оставляют нам официальное заявление о том,
что они прекращают пользоваться сервисом в течение десяти дней — это, скорее,
вымышленная ситуация.
Поэтому для того чтобы строить прогнозные модели — модели,
которые умеют прогнозировать отток, нам нужно формализовать его определение.
Следующий шаг — это определиться с типом модели, которую мы будем строить.
Должна ли это быть модель регрессии или классификации?
Должна быть классификация бинарной или многоклассовой?
Какие классы нас интересуют?
Далее мы уже говорили о том, что процесс удержания — не мгновенный, нам нужно
какое-то время, для того чтобы связаться с пользователем через выбранный канал,
провести процесс удержания, и поэтому нам важно прогнозировать отток заранее.
Соответственно, нам важно оценить, сколько времени нам нужно, для того чтобы
удерживать пользователей и прогнозировать отток с заданным горизонтом.
После того как мы определили горизонт прогнозирования,
нам важно зафиксировать методику оценки качества модели.
Это важно сделать до того, как мы непосредственно начали строить модель,
для того чтобы мы могли сформулировать некоторые гипотезы,
построить предположения и оценки того, какое качество модели должно быть,
и дальше оптимизировать заданную метрику и проверять,
соответствует ли она нашим ожиданиям.
Также нам очень важно зафиксировать дизайн эксперимента.
Понятно, что большинство моделей строится по историческим данным — мы оцениваем
данные, которые нам уже известны о пользователях,
которые пользовались сервисом раньше либо пользуются им сейчас.
И на основании этих данных строим модель оттока.
Однако офлайна и оценки качества моделей часто недостаточно.
Нам важно проверить модель в онлайне, важно провести какие-то эксперименты, для
того чтобы подтвердить, работает ли наша модель в данном сервисе или не работает.
Вот задача того, как мы будем это делать, построение и дизайн такого эксперимента,
очень важна.
Ее также нужно зафиксировать до того,
как мы непосредственно перешли к построению модели оттока.
И также нам важно зафиксировать требования к модели.
Нам важно понимать, нужна ли нам вероятностная модель, важно ли нам знать,
с какой вероятностью каждый пользователь собирается от нас уйти, важно ли нам,
чтобы модель была интерпретируемой,
хотим ли мы потом пользоваться интерпретацией и понимать причины,
почему мы каждого пользователя отнесли к классу «отток» или «неотток».
И также нам нужно понимать, есть ли у нас технические ограничения,
как часто мы хотим модель применять, как часто мы ее хотим обновлять,
переобучать и насколько вычислительно эффективно она должна работать.
Давайте рассмотрим пример.
Предположим, что мы работаем с некоторым медийным сервисом,
который предоставляет своим клиентам доступ к своему контенту по подписке.
Это может быть электронная библиотека,
онлайн-кинотеатр или какой-то музыкальный сервис.
Как в этом случае можно формализовать понятие оттока?
Мы можем выбрать следующее определение: пользователь разрывает договор
подключения к сервису.
Это такой формальный критерий, который мы с вами можем явно померить.
Давайте предположим, что мы хотим строить модель бинарной классификации.
В этом случае мы хотим относить каждого пользователя к одному из двух классов:
либо класс «отток» —пользователь прекращает пользоваться сервисом,
либо — «неотток».
Предположим, что нас устраивает горизонт прогнозирования в две недели.
Это значит, что двух недель нам достаточно, для того чтобы выбрать канал
взаимодействия и применить к пользователю методику удержания,
скажем, связаться с ним каким-то образом по телефону, отправить SMS либо отправить
сообщение на электронную почту и предложить ему некоторые условия,
выяснить, доволен он или нет, и как-то с ним провзаимодействовать,
попытаться его удержать.
Далее давайте выберем методику оценивания модели.
Так как мы решаем задачу бинарной классификации,
мы можем остановиться на чем-нибудь достаточно простом.
Допустим, мы будем использовать метрику AUC для оценки качества модели.
И далее — дизайн эксперимента.
Давайте будем проводить классический А/Б тестинг: построим модель прогнозирования
оттока, далее выберем некоторый сегмент пользователей, скажем, 10 % случайных
пользователей, применим к ним нашу модель и попробуем удержать тех пользователей,
которые будут относиться к классу «отток», с помощью существующих методик удержания.
Далее оставшихся пользователей мы трогать не будем.
И будем сравнивать долю оттока и другие метрики на нашем сегменте,
на тестовом сегменте, с остальными пользователями.
Будем ожидать, что на нашем сегменте, где мы занимаемся удержанием,
отток уменьшится.
Теперь давайте подумаем,
какие определения оттока можно было бы в этой задаче использовать.
Первое определение мы с вами уже обсудили — это формальный разрыв договора,
когда пользователь явно нам сообщает, что начиная с некоторой даты,
он прекращает свою подписку и больше нашим ресурсом пользоваться не планирует
— хороший формальный критерий.
С другой стороны, мы понимаем,
что не всегда пользователи явно хотят сообщать нам о своих намерениях.
Поэтому мы можем строить некоторые правила, некоторые эвристические критерии,
которые позволят нам с той или иной вероятностью понять,
что пользователь больше не с нами.
Во-первых, это может быть отсутствие платных транзакций в том случае,
если сервис их предполагает.
Например, отсутствие платных транзакций в течение десяти дней и более либо
отсутствие платных транзакций в течение 90 дней — вот два таких хороших критерия.
С другой стороны, мы можем смотреть не обязательно на платные транзакции,
мы можем измерять отсутствие пользователя на сервисе,
скажем, отсутствие его в течение 14 дней или 28 дней.
Возникает вопрос: вот у нас уже сформулированы пять различных критериев,
как же нам из них выбрать, какой из них наиболее правильный,
какой из них нам больше подходит?
Давайте попробуем их каким-то образом провалидировать.
И первое, на что предлагается смотреть в рамках такой валидации, это какая доля
пользователей попадает под наш критерий, попадает под это определение оттока.
Вот предположим, что если мы с вами померим по историческим данным, то есть по
тем пользователям, которые уже были у нас на сервисе и в какой-то момент ушли,
какая доля из этих пользователей попадает под каждое из определений оттока.
Вот начнем с первого: разрыв договора.
Предположим, что в нашем сервисе под это определение попадает всего лишь 0,1 %
пользователей, то есть всего лишь 0,1 % пользователей явно нам сообщила,
что вот с некоторой даты они прекращают пользоваться сервисом.
Теперь давайте проанализируем остальные показатели.
Предположим, что отсутствие платных транзакций в течение десяти дней — под
это определение попадает 22 % пользователей по историческим данным.
Отсутствие платных транзакций в течение 90 дней — под это определение попадает 5 %
пользователей.
Отсутствие на сервисе в течение двух недель — под него
попадает 16 % пользователей.
И отсутствие на сервисе в течение 28 дней — 9 % пользователей.
Мы видим, что процентные соотношения очень сильно отличаются.
С одной стороны, мы понимаем, что когда под это определение попадает довольно
много пользователей, большая группа — 16, 20 %, кажется, что это довольно много,
и интуитивно понятно, что, скорее всего, это слишком «мягкое» правило.
Скорее всего, под это правило попадает очень много пользователей, которые,
на самом деле, и не собираются от нас уходить.
С другой стороны, если мы рассматриваем первый вариант разрыва договора,
то мы видим, что под этот критерий попадает очень мало пользователей.
То есть, скорее всего, если мы на нем ограничимся, то конечно же, мы найдем тех
пользователей, которые явно хотят от нас уйти, но, возможно, мы упустим достаточно
большой сегмент тех, кто хочет от нас уйти, но явно нам об этом не сообщает.
Соответственно, нам нужны еще какие-то критерии, для того чтобы принять решение о
том, какое из этих определений нам больше подходит.
Давайте проделаем следующие измерения.
Давайте по историческим данным оценим, какая доля пользователей из тех,
что подходит под каждое определение оттока, на самом деле возвращается,
то есть какая доля пользователей из тех, кого мы с вами отнесли к оттоку,
к каждому из определений, на самом деле оттоком не являлась.
Вот давайте это оценим.
Предположим, что для первого определения мы получили 0 %.
Это логично — если пользователь явно разорвал договор, то значит,
действительно, он хотел от нас уйти.
Теперь давайте проанализируем остальные.
Кажется, что если у пользователя отсутствовали платные транзакции в течение
небольшого периода времени, скажем, в течение десяти дней,
то 80 % из этих пользователей на самом деле не планировало от нас уходить.
Возможно, у них были какие-то другие дела, они были в отпуске или еще что-то,
то есть это очень слабые критерии, которые совсем недостоверны.
Хорошо, давайте рассмотрим следующий — отсутствие платных
транзакций более 90 дней.
Это уже более хороший критерий, потому что мы видим,
что мы ошибаемся всего лишь в 12 % случаях.
Большинство пользователей из тех, кто действительно попал под этот критерий,
правда, от нас ушли.
Аналогичным образом мы можем оценить последние два критерия.
Теперь у нас есть много дополнительной информации,
для того чтобы принять решение о том, какое определение оттока выбрать.
С одной стороны, нам известна доля пользователей,
которая попадает под каждое определение оттока, с другой стороны, нам известно,
насколько каждое из определений достоверно по историческим данным.
Вот исходя из этой информации, вы можете выбрать то определение,
которое вам кажется наиболее правильным.
В данном случае я предлагаю остановиться на определении «отсутствие платных
транзакции более 90 дней».
С одной стороны, под него попадает достаточное количество пользователей — это
5 %, а с другой стороны, оно достаточно достоверное — всего
лишь 12 % пользователей из тех, кого мы к ним отнесли, после возвращаются на сервис.
Теперь давайте подумаем про горизонт прогнозирования.
Для того чтобы оценить, какой горизонт прогнозирования нам необходим,
нам нужно отталкиваться от нескольких предположений.
Во-первых, нужно понимать, как быстро мы можем связаться с пользователем.
Это очень сильно зависит от специфики сервиса, который мы анализируем.
В частности, скажем, отправить электронное сообщение может быть достаточно быстрым,
а для того чтобы связаться с пользователем с помощью оператора из колл-центра и
поговорить с ним — вот этот процесс может занять существенно дольше времени.
Соответственно, это первый критерий, на который нужно смотреть — как быстро мы
можем провзаимодействовать с пользователем и какие каналы нам для этого доступны.
Следующий критерий — это то, какие методики удержания мы используем.
Нам важно понимать, сколько занимает сам процесс удержания,
сколько пользователю требуется времени на то, чтобы принять решение.
Важно понимать, что на разных этапах принятия решения об отказе использования
сервиса, требуется разное время, для того чтобы удержать пользователя.
Скажем, в самом начале пользователь еще не уверен,
хочет ли он действительно отказаться от сервиса, и нам проще его удержать.
С другой стороны, если мы дотерпели до самого конца, то пользователь, возможно,
уже выбрал некоторый аналог, изучил его, и в этом случае нам сложнее его удержать —
нам на это требуется гораздо больше ресурсов и больше времени.
Еще один важный момент,
на который нужно обратить внимание — это качество модели прогнозирования.
Понятно, что чем дальше во времени от момента сейчас расположено событие оттока,
событие отказа пользователя от использования нашего сервиса,
тем сложнее нам его прогнозировать, тем меньше свидетельств, событий или каких-то
фактов изменения поведения пользователя мы с вами наблюдаем.
Теперь давайте поговорим о данных.
Для того чтобы строить хорошую, уверенную модель прогнозирования,
нам нужно убедиться в том, что у нас есть достаточное количество данных.
Во-первых, нам нужно проанализировать то, какие данные о пользователях нам,
в принципе, доступны: доступен ли нам лог поведения пользователя, знаем ли мы все
события, все основные события, которые происходят с пользователем на сервисе.
Второй важный вопрос — это то,
за какой исторический период нам доступны данные, как долго мы их храним, правда ли,
что нам доступны данные за долгую историю или мы храним только последние события.
Если же мы храним только последние события, достаточно ли их для обучения,
или нам нужно позаботиться заранее о том, чтобы начать хранить больше событий,
то есть историю за более длительный период.
Далее нужно понимать, что данные могут храниться в разных источниках,
в разных системах хранения данных, в разных базах данных.
Они могут храниться в разных форматах, поэтому нам важно заранее продумать то,
каким образом нам следует объединять данные,
как мы будем склеивать данные по пользователям, правда,
что у нас есть ключи, по которым мы можем объединить, скажем, данные о покупках
пользователей на сервисе с данными о его заходах на этот сервис, о просмотрах.
То есть нам важно понимать,
как мы будем объединять наши данные в один цельный dataset.
Далее важно понимать, содержится ли в данных сигнал, то есть есть ли у
них та информация, на основе которой у нас получится строить модель.
Ведь нам важно не просто иметь какие-то абстрактные данные о пользователе,
нам важно иметь те данные, исходя из которых мы сможем делать предположения,
делать выводы о том, что поведение пользователей изменилось таким образом,
что, скорее всего, он собирается от нас уйти.
И нам важно понимать то, каким образом данные следует обрабатывать,
как их правильно чистить, какие события следует учитывать, какие события — нет.
Теперь, когда мы убедились, что нам доступны данные про пользователей,
эти данные доступны за достаточно длительный исторический период, и
также в данных предположительно содержится сигнал, на основании которого мы сможем
строить модель прогнозирования, нам важно посмотреть на эти данные более пристально,
то есть нам нужно выполнить первичный анализ данных.
Для этого важно решить задачу визуализации данных.
Нам важно понять, какие ключевые характеристики есть у наших пользователей.
Для этого часто бывает полезно разбить пользователей на два
класса: на целевой класс и нецелевой класс по историческим данным,
ведь для исторических данных мы знаем, какие пользователи от нас уже ушли,
поэтому мы с вами можем анализировать пользователей в разрезе двух классов.
Дальше нам важно посмотреть,
по каким ключевым характеристикам эти пользователи отличаются.
Важно понять, отличается ли у них, скажем, время использования сервиса,
отличается у них средний чек, или ARPU, и другие важные характеристики.
Более того, часто бывает очень полезно решить задачу сегментации,
особенно на классе оттока, то есть на нашем целевом классе.
Нам важно понять,
из чего этот класс строится и какие группы пользователей в него входят.
Может так оказаться, что в рамках этого класса существует несколько больших групп
пользователей, например группа пользователей, которые пришли
на сервис недавно, скажем, всего лишь один или два дня назад, посмотрели на сервис,
изучили его и просто поняли, что он им не подходит, поэтому и решили уйти.
С другой стороны, это могут быть пользователи, которые давно и активно
пользовались сервисом и далее по каким-то причинам решили от него отказаться.
Понятно, что нам с вами гораздо интереснее и гораздо важнее удержать вторых
пользователей — тех, кто сервисом пользовались активно.
Более того, про них мы знаем гораздо больше, у нас есть больше информации,
и, скорее всего, задачу для них получится решить с более высоким качеством.
Соответственно, мы с вами после этапа проведения сегментации сможем ответить на
вопрос, из каких сегментов складывается наш отток, можем ли мы одинаково хорошо
для каждого из этих сегментов решить эту задачу и хотим ли мы этого, то есть
нужно ли нам действительно удерживать пользователей из всех сегментов.
Часто в процессе сегментации нам полезно не просто проанализировать получившиеся
сегменты, то есть рассчитать на них аудиторные показатели, сравнить и оценить
их в целом, но и провести так называемый ручной анализ данных, то есть выбрать по
одному или нескольким пользователям из каждого сегмента — особенно нас интересуют
те сегменты, которые представляют больший интерес с экономической точки зрения,
— и посмотреть глазами на историю их взаимодействия с сервисом.
Это бывает невероятно полезно, для того чтобы понять,
по каким причинам эти пользователи могли принять то или иное решение,
и дальше разработать некоторые методики по их удержанию.
А мы с вами на этом заканчиваем.
В этом видео мы разобрали постановку задачи прогнозирования
оттока пользователей.
Хочется обратить ваше внимание на то, что в рамках постановки задачи важно,
во-первых, убедиться в том, что задача обоснована с точки зрения бизнеса.
Также важно поставить формально постановку задачи, то есть постановку задачи
с точки зрения анализа данных, с точки зрения машинного обучения.
А также важно провалидировать полученную постановку.
На следующем видео мы продолжим разбирать задачу прогнозирования
оттока пользователей и обсудим построение и оценку модели.