Существует множество блогов о построении моделей прогнозирования оттока с помощью scikit-learn, R или других расширенных инструментов машинного обучения. Однако для большинства из них требуются сильные инженерные навыки, а также навыки работы с данными. Тем не менее, теперь можно создавать надежные модели, используя SQL и базовые знания науки о данных, используя инструменты, разработанные такими компаниями, как Google, для демократизации машинного обучения.

В этом посте мы будем использовать BigQueryML от Google вместе с данными о потоках кликов, собранными и предоставленными с помощью платформы RudderStack. Эти данные представляют собой события, такие как вращения игрового автомата, связанные с игрой в мобильном казино. Объем данных типичен для таких сценариев, и, как мы увидим, анализ оттока легко доступен и эффективен без необходимости тратить целое состояние на инфраструктуру.

Что такое отток клиентов и почему нас это волнует

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

Отток клиентов может происходить по многим причинам, включая, помимо прочего:

  • Низкое качество продукции
  • Неудовлетворительное обслуживание клиентов
  • Потребители теряют интерес (особенно это касается игр)
  • Просто характер самого продукта

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

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

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

Сбор данных и настройка инфраструктуры доставки

В нашем случае мобильная игра интегрировала Unity SDK от RudderStack для генерации событий. Затем эти события отправлялись в плоскость данных с открытым исходным кодом RudderStack, откуда они направлялись в Google BigQuery для дальнейшего анализа.

Мы храним все события, маршрутизируемые RudderStack, в таблице track в BigQuery со всей полезной нагрузкой JSON в виде столбца. Кроме того, мы также создаем отдельные таблицы для каждого типа событий со свойствами событий в виде столбцов. Это важно, потому что таким образом мы можем получить доступ ко всему событию, если нам нужно, используя отличную поддержку BigQuery для полуструктурированных данных. Мы также можем оптимизировать использование BigQuery, разделив данные в зависимости от времени события. Это позволяет нам оптимизировать как время выполнения запроса, так и стоимость.

На следующих изображениях показаны два примера таблиц, созданных в BigQuery - одна для определенного типа событий, а другая - для всех событий:

Как видно выше, таблица для конкретного события содержит атрибуты, относящиеся к этому событию, тогда как вторая таблица содержит информацию, не зависящую от события. Две таблицы могут быть связаны с помощью поля id.

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

Исследовательский анализ данных и стратегия прогнозирования оттока

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

Чтобы определить отток, мы используем график ниже, который показывает распределение количества дней между первым платежом и оттоком. Хотя невозможно узнать, действительно ли кто-то ушел, мы приняли семь дней бездействия в качестве критерия оттока. Мы делаем это предположение на основе отзывов, полученных от менеджера по продукту игры, учитывая более широкое понимание оттока клиентов в этой конкретной отрасли. Для этой игры (и большинства других игр) люди обычно очень активны и играют несколько раз в день. Если в какой-то момент они просто покидают игру - и хотя они могут вернуться - по общему мнению, чем дольше пользователь неактивен, тем меньше вероятность их возвращения. Учитывая этот фактор, семь дней бездействия - хорошая отправная точка для исследования оттока клиентов с помощью наших данных.

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

Стратегия прогнозирования оттока

Самый простой способ уменьшить отток - разослать предложение или что-то еще после нескольких дней бездействия. Однако это не лучший подход. Если мы выберем слишком низкий порог, мы будем выдавать слишком много предложений. С другой стороны, если мы будем ждать слишком долго, пользователь давно бы ушел, возможно, даже удалил игру. Цель состоит в том, чтобы предсказать с очень высокой точностью, откажется ли кто-то до того, как он действительно откажется. Итак, вопрос в том, как мы можем оптимизировать этот подход, включив точную модель прогнозирования оттока?

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

Разработка функций для прогнозирования оттока клиентов

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

Следующие функции были определены как релевантные для прогнозирования оттока после разговора с менеджером по игровому продукту:

  • coin_balance: если у кого-то осталось много монет, он с большей вероятностью продолжит игру.
  • total_bet / total_win / total_spins: Более активные люди, как правило, более заядлые игроки и, следовательно, с меньшей вероятностью уйдут. Суммируя суммы / числа по всем событиям «вращения» пользователя, можно определить общую сумму или количество ставок / выигрышей или вращений.
  • number_of_distinct_games: как и выше, люди, которые играют больше игр, с большей вероятностью останутся в игре.
  • total_jackpot: Люди, которые выигрывают случайные джекпоты, с большей вероятностью будут чувствовать себя позитивно и, следовательно, продолжить.
  • коэффициент выигрыша (total_win / total_bet): как и выше, люди, которые выигрывают больше, с меньшей вероятностью уйдут.
  • signup_to_first_pay: Люди, которые платят сразу после регистрации, скорее всего, являются более заядлыми игроками и вряд ли уйдут оттуда. Люди, которые долго платят, скорее всего, являются любителями и с большей вероятностью откажутся от оплаты после совершения платежа.

Проверка функций

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

Очевидно, что отталкиватели вели себя совсем не так, как не отталкиватели. Диаграммы, созданные ниже, относятся только к одному из случаев - количество total_jackpot s и разницу между людьми, которые оттока, и теми, кто не оттянут, можно идентифицировать.

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

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

Построение модели прогнозирования оттока клиентов с помощью BigQueryML

Основываясь на выявленных нами функциях, пришло время построить модель прогнозирования оттока. Для этого мы воспользуемся Google BigQuery.

Шаг 1. Создание обучающего набора

Первым шагом является создание набора данных путем создания всех функций и объединения их в одно представление.

Для вычисления функции требуются следующие шаги:

  • Поиск пользовательских дат событий. Например, когда они впервые зарегистрировались, когда они впервые заплатили, их последний день активности и т. Д. Как упоминалось выше, RudderStack поддерживает таблицу треков со всеми событиями, поэтому сопоставление этих действий по сути - это поиск даты, когда произошло конкретное событие. в таблице track. Функция RANK () удобна тем, что позволяет нам связывать монотонно увеличивающееся число rank с каждым возникновением события для каждого пользователя.
  • Запрос выглядит так, как показано ниже:
CREATE TABLE FIRST_REV_DATE_TABLE AS 
     SELECT
     anonymous_id, rev_date as first_rev_date
 FROM
     ( 
     SELECT anonymous_id,     
         DATE_TRUNC('d', sent_at) as rev_date,
         RANK() OVER (PARTITION by anonymous_id ORDER BY sent_at DESC) as rank,
     FROM
                RUDDER.track
     WHERE
               event=’revenue’         
     )
 WHERE
    rank = 1

Аналогичным образом можно вычислить и другие таблицы, зависящие от даты, например SIGNUP_DATE_TABLE (дата первого действия), LAST_SPIN_DATE_TABLE (последнее вращение пользователя).

  • Используя приведенные выше таблицы дат, можно вычислить характеристики. Например, чтобы узнать количество вращений между регистрацией и first_rev, нужно присоединиться к таблице RUDDER.spin, SIGNUP_DATE_TABLE и LAST_SPIN_DATE_TABLE. RUDDER.spin таблица - это таблица для конкретных событий, которую создает RudderStack. Запрос выглядит следующим образом:
CREATE TABLE NUM_OF_SPINS AS 
SELECT anonymous_id
     SUM(RUDDER.spin.no_of_spins) as no_of_spins
FROM 
     SIGNUP_DATE_TABLE, 
     FIRST_REV_DATE_TABLE,
     RUDDER.spin table
WHERE
     SIGNUP_DATE_TABLE.anonymous_id = RUDDER.spin_table.anonymous_id
     AND SIGNUP_DATE_TABLE.anonymous_id = RUDDER.spin_table.anonymous_id
     AND FIRST_REV_DATE.first_rev_date >= RUDDER.spin_table.sent_at
GROUP BY anonymous_id
  • Следующим шагом является вычисление столбца метки. Пользователь совершил отток за 3 дня, если разница между LAST_SPIN_DATE и FIRST_PAY_DATE составляет ‹= 3 дня и 7 дней (порог оттока) прошли с LAST_SPIN_DATE. Это снова простой SQL-запрос, объединяющий FIRST_REV_DATE и LAST_SPIN_DATE. Это добавлено как еще одна таблица 3_day_churn.
  • Наконец, все эти функции можно объединить в одну гигантскую функцию, объединив anonymous_id.

Шаг 2: Построение модели

Теперь, когда у нас есть окончательный набор данных, выбрав и сгенерировав все необходимые функции данных, пора построить модель непосредственно из нашего хранилища данных с помощью BigQuery ML. BigQuery ML поддерживает создание моделей машинного обучения с использованием только SQL. Это значительно упрощает итерации построения модели и возможное развертывание.

В настоящее время BigQuery ML поддерживает только некоторые базовые модели, такие как логистическая и линейная регрессия, но не поддерживает NBD / Pareto (обычно наиболее эффективные для оттока). Однако цель здесь заключалась в том, чтобы показать, как можно быстро выполнить итерацию, построить и ввести в действие свою модель машинного обучения, используя только SQL из хранилища данных.

Следующий запрос показывает, как создать модель в BigQueryML.

CREATE OR REPLACE MODEL `BigQueryMLModel
OPTIONS (model_type='LOGISTIC_REG',auto_class_weights=TRUE,data_split_method='NO_SPLIT', input_label_cols=['within_3_days'],max_iterations = 15) 
AS SELECT anonymous_id,first_spin_to_first_pay,total_jackpot,total_bet,total_win,total_spins, number_of_distinct_games, event_count,coin_balance,SUM_WIN_BY_BET, within_3_days
FROM '3DAY_CHURN_MODEL_ALL_FEATURES'
WHERE dataframe = 'training'

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

Мы запускаем следующий запрос, чтобы оценить нашу модель:

SELECT * FROM ML.EVALUATE (MODEL `BigQueryMLModel`, 
   (SELECT Anonymous_id,first_spin_to_first_pay,total_jackpot,total_bet,total_win,total_spins, number_of_distinct_games, event_count,coin_balance,SUM_WIN_BY_BET, within_3_days
    FROM `3DAY_CHURN_MODEL_ALL_FEATURES`
    WHERE dataframe = 'test’
    )
 )

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

Анализ эффективности модели прогнозирования оттока

Мы получаем следующие показатели производительности для модели:

Кривая ROC для отзыва и точности показана ниже:

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

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

Тестирование вне выборки

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

В нашем случае мы проверяем ложноположительные / отрицательные результаты теста вне выборки. Мы записываем эти цифры в таблицу, как показано:

Когда модель делает прогноз, она также связывает вероятность быть правильным или достоверность для каждого прогнозируемого класса. Для порога 0,1 или 10% класс, который был спрогнозирован с достоверностью более или равной 10% в качестве класса для конкретного пользователя - отзыв составляет 70%, а частота ложных срабатываний составляет 10%. Это означает, что модель правильно определила 70% пользователей, которые фактически отказались в качестве кандидатов на отток. Только 10% пользователей, которые не отказались, были ошибочно классифицированы как кандидаты на отток.

Вывод

На основе проведенного нами упражнения по построению модели можно сделать несколько ключевых наблюдений и выводов:

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

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