Привет, Хабр! В последнее время все чаще приходится наблюдать, что ожидания работодателей и потенциальных ученых по данными сильно отличаются. Компания, инвестируя в новые разработки в первую очередь ждет возврат на инвестиции, а не очередную модель. Специалист же, окончивший всевозможные курсы ждет на вход чистые и понятные данные, а на выходе хотел бы отдать модель прикрепив к ней метрики качества. А дальше «пусть менеджеры разбираются», как это все будет встроено в процесс и как именно полученная модель будет использоваться. В результате возникает пропасть и непонимание между бизнесом и учеными.

По факту оказывается, что модели сами по себе никому не нужны, а на деле приходится заниматься очень большим количеством рутинных задач.

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

Начнем с самого распространенного примера. Представьте, что вы закончили вуз, хорошо разбираетесь в машинном обучении, знаете, что такое xgboost, деревья решений и прочие непонятные простому нормальному человеку алгоритмы. Приходите работать в b2c компанию (допустим, с большим «c» — где средний чек с клиента берется регулярно и на протяжении долгого периода времени), основной целью которой является по-сути максимизация LTV, скажем, все тот же телеком-оператор. Вы, наслышавшись рассказов на конференциях про свойства таких бизнесов («проще удержать старого клиента, чем привлечь нового», «важно управлять оттоком», «надо балансировать между лояльностью и увеличением ARPU») ничуть не удивляетесь, когда Вам предлагают улучшить/построить модель оттока. Ведь это правда важно — в таких компаниях лояльность (обычно измеряемая с помощью NPS или LT) стоит на первом месте. Все понимают, что это важно (но по-своему).

Что происходит дальше? Вам, разумеется, рисуется в голове бинарная классификация, вы уже мысленно расчехляете свой xgboost и ждете, когда на выходе будет та самая заветная таблица с ярко-выраженным отдельным столбцом (называемой вами целевой переменной) и метрика качества, по которой будут судить об успешности алгоритма (хотя, метрику вы и сами, наверное, придумаете — из списка roc-auc, precision, recall и т д). Но этого не происходит. Потому что даже непонятно, что такое отток. Вы только что закончили ВУЗ, никогда не работали в операторе, для вас отток «это когда клиенты перестают пользоваться услугами компании». Да, алгоритмы машинного обучения универсальные и могут решить любую задачу, но вот правильно сформулировать (а это и есть большая часть работы), могут только те, кто хорошо (или не очень) понимает, как компании управляют оттоком. Например, автору этой заметки известно как минимум пару десятков (и их вариаций) определения оттока, но не известно, какое же определение самое правильное (и неизвестно никому).

Ну допустим, с оттоком определились. А что такое клиент сотового оператора? Нормальному человеку понятно, что клиент — это клиент и добавить нечего, что за дурацкий вопрос? Надо взять client_id и по нему выгрузить признаки. Но факт в том, что в компании уже N-ый год идет какой-нибудь большой проект под названием MDM, в котором до сих пор так и не определелились, что же считать клиентом. А считать можно много чего — начиная от номера телефона, заканчивая номером приложения обслуживания или лицевого счета (на котором может обслуживаться несколько номеров). Но, допустим, Вам и в этом случае повезло, и в компании нашелся скромный сотрудник, который подсказал Вам, что можно взять в качестве абонента и Вы можете смело броситься выгружать долгожданные features.

И тут вы думаете, какие данные есть у оператора связи, влияющие на отток — идете читать статьи великих ученых, не находя в них конкретики. Потом идете спрашивать старших товарищей, которые стабильно выгружают данные из витрины «какого-нибудь оракла», а конкретно — берут вот эти столбцы, названия которых известны, но вот что они означают и как считаются — «вроде бы была где-то документация», это «вот когда вендор нам внедрял это все — осталась от него». Не получив исчерпывающее понимание по фичам (а иначе бы вас на нанимали) вы начинаете заниматься креативом. И тут обнаруживаете, что ваши самые крутые становятся нереально сложными, а сложности начинаются даже на самых простых вещах. Например, вам совершенно очевидно, что на отток влиет такой известный показатель как ARPU (=примерно средний чек), и вот Вы снова идете к старшим товарищам, дабы разузнать, где его можно взять — а оказывается, что есть платежи (то, что заплатил клиент), а есть начисления (то, что начислил биллинг). В теории, конечно, же эти 2 величины должны быть очень похожи, но только в теории. Понятно, что платежи — более показательный параметр, но — происходят они редко. А вот начисления генерятся практически «налету» после каждой транзакции. И, скорее всего, придется именно их и брать в качестве фичи и именно по ней считать оценку APRU.

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

Так вот, с фичами разобрались. Выгрузили (скорее всего не своими руками). А дальше можно (или нет?) вздохнуть, потому что теперь то есть та самая заветная таблица. Тут вы как обычно строите (часто — нет) графики, смотрите на зависимости, тренируете модель, получаете огромные рок-ауки, реколлы, пресижны и прочие какие-то числа и сообщаете руководству. «Качество получилось 100500%», «технологии машинлернинга работают», сейчас мы передадим джупайтер-тетрадку нашим разработчикам — пускай переписывают это все «в продакшн» и все.

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

По-сути, теперь работа только начинается. Например, в схеме описанной выше «берем наиболее нелояльных, и их удерживаем» — логика отличная для нормального человека, работающего в найме (=не теряющего свои деньги). Но любой, кто хоть раз имел бизнес с кол-вом потенциальных клиентов, из которых можно выбирать, скажет вам одно простое правило — «не все клиенты равны и относиться к ним нужно соответственно», есть клиенты — с которыми проще не работать. И тут приходит понимание, что реально удерживать надо далеко не всех, а только самых ценных (вот тут то обычно и говорят много слов про CLTV). А это означает, что целевой сегмент, для которого мы разрабатывали модель — вовсе ограниченный и, возможно, вообще не стоило строить модель, а просто оценить, какое кол-во людей в него попадает. Проще говоря, давайте для начала поймем, сколько людей нам НЕ надо удерживать — тогда и окажется, что, некоторым выгодно дать личного клиентского менеджера в помощь, а на кого-то и IVR в качестве поддержки жалко будет, а остальной сегмент настолько мал, что модель строить ненадо — а проще раз в месяц им всем звонить.

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

• А как оценивать ценность клиентов?
• А сколько клиентов при таком подходе мы охватываем?
• А почему нельзя охватить всех?
• Какова стоимость удержания?
• Сколько мы можем позволить потратить себе на клиента?
• Какую превентивную меру использовать?
• Какими метриками измерять качество алгоритмов в данном случае?
• Может быть предсказывать не отток, а ожидаемые потери?
• А может быть имеет построить несколько моделей?
• А что делать с клиентами, по которым есть не все фичи? Может быть имеет смысл для них построить отдельную модель?
• Как часто нужно проводить превентивные меры?
• А сколько клиентов выбирать для удержания?
• Что делать с теми, кому мы предложили, а они уходить не собирались? Есть ли способы увеличить сниженный ARPU?

Отвечать на такие вопросы — бесценно, для всего остального есть xgboost=)

Этому ремеслу мы и учим в нашей Школе.

К сожалению, наш опыт показывает, что даже участие и успешное выступление в соревнованиях Kaggle не помогают при решении индустриальных задач (к похожему заключению пришли и любители соревнований по спортивному программированию – участие в соревнованиях типа ACM имеет мало общего с индустриальной разработкой ПО). Более того, данный опыт приобретается лишь методом проб и ошибок и никогда не будет описан в книгах – даже мы на своих лекциях рассказываем не все тонкости, которые применили на практике.

Напоминаем о датах начала наших курсов:

• Курс для аналитиков — 22 мая
• Курс для менеджеров — 23 мая
• Курс в Санкт-Петербурге — 22 мая

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

Записаться на подготовительный курс можно здесь.

P.S. Полная версия статьи доступна тут