Использование ML для прогнозирования CLTV

1. Формула CLTV и постановка задачи

Из прошлой статьи мы узнали, что CLTV (customer lifetime value) — метрика, используемая для оценки прибыли, которую компания может получить от своего клиента за время его пользования продуктами и сервисами компании.

Разберем, что означает каждая буква в определении CLTV (customer lifetime value). Кто такой клиент, что мы понимаем под lifetime и ценностью, которую приносит нам клиент. 

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

Под lifetime мы понимаем не полный жизненный цикл клиента от момента заключения договора до момента его закрытия, а пятилетний горизонт, который мы отсчитываем от текущего момента времени. То есть, если мы строим прогноз от января 2023 года, то прогноз будет построен помесячно до декабря 2027 года. Почему 5 лет? Этот срок был определен опытным путем — при нем достигается баланс между качеством предсказаний и потребностью в бизнес-процессах.

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

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

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

Также есть расходы, которые мы считаем на уровне клиентских сегментов. Это Advertising & Marketing, Salaries & Benefits и General & Administrative. Для этих расходов мы считаем среднюю ставку коста на одного абонента. А для получения прогноза расходов на конкретного абонента рассчитанную ставку коста умножаем на вероятность выживаемости этого абонента на горизонте прогнозирования CLTV.

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

CLTV = SM Mobile + SM FMC fix + SM FTTB - SAC cost - DATA mobile opex cost - VOICE mobile opex cost - SALARIES & BENEFITS cost -  GENERAL & ADMINISTRATIVE cost - ADVERTISING & MARKETING cost

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

2. Выбор целевой переменной

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

Остальные компоненты формулы CLTV прогнозируем напрямую — их у нас 6 (задача регрессии). Здесь требуется преобразование целевых переменных — они собирается помесячно, и их нужно привести к среднедневному значению. Например, сервисная маржа у абонента в июле равна 100 рублям, эти 100 рублей мы делим на количество дней в июле и подаём в модель. Это делается потому, что величина абонентской платы и других денежных показателей зависит от количества дней в месяце (сказывается подневное списание абонентской платы). Без такого преобразования регрессионные модели в феврале и месяцах с 30 днями завышают прогноз, а в месяцах с 31 днём — занижают.

Отдельно стоит рассмотреть вопрос выбора горизонта прогнозирования для ML-моделей. С одной стороны, можно обучить модели прогнозировать целевые переменные на 5 лет вперёд. Но при таком длинном горизонте прогнозирования качество прогноза будет очень низким, к тому же за 5 лет данные для моделей сильно меняются в силу изменения экономической ситуации, роста цен, появления новых тарифов. После нескольких экспериментов было установлено, что наиболее оптимальный горизонт прогнозирования для ML-моделей составляет 24 месяца. А получаемый прогноз на 24 месяца можно экстраполировать на 5 лет (об этом будет отдельная статья).

Итого получается 8 моделей, которые можно разделить на три группы:

1. Объём абонентской базы = выживаемость: 

• Прогнозы выживаемости по paid, active базам. Используются для расчёта непрямых расходов, а также как признаки в моделях регрессии.

2. Выручка: 

• SM Mobile, SM FMC, SM FTTB — прогнозы сервисной маржи. 

3. Расходы: 

• Data — прогноз потреблённого дата трафика (в гб), далее умножается на стоимость гигабайта.

• Voice — прогноз потреблённого голосового трафика (в минутах), далее умножается на стоимость минуты.

• SAC — прогноз затрат на привлечение абонентов.

3. Принцип формирования обучающей выборки

У нас есть 8 целевых переменных и 8 моделей, которые нужно обучить прогнозировать эти целевые переменные на горизонт от 1 до 24 месяцев вперёд. Этого можно добиться благодаря добавлению в модели горизонта прогнозирования [h=1...24] в качестве признака.

Таким образом, при сборе выборки для каждого абонента в зависимости от горизонта h необходимо определить правильный лаг для сбора признаков. Для абонента с целевой переменной за месяц T и горизонтом h нужно присоединить признаки за месяц T - h.

Алгоритм сбора выборки:

1. Выбираем интервал [T1, T2] сбора целевых переменных. Берём последние 13 месяцев, например с 2022-07-01 по 2023-07-01.

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

   a. Фиксируем горизонт = h [h=1...24].

   b. Получаем интервал сбора признаков абонентов [T1 - h, T2 - h].

   c. Собираем целевые переменные за интервал [T1, T2] и признаки за [T1 - h, T2 - h].

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

3. Объединяем полученные на 2 шаге выборки в одну. 

Полученная выборка для обучения случайно разбивается на train/val/test. Также отдельно выделяется выборка out of time, которая включает в себя последний месяц по целевым переменным.

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

4. Модели

Лучше всего и в классификации, и в регрессии у нас сработал CatBoost.

Для классификации loss_function — Logloss, eval_metric - AUC.

Для регрессии loss_function — Huber:delta, eval_metric - WAPEs.

Формула Huber:

Функция потерь Хубера работает как комбинация MSE и MAE одновременно. Параметр дельта позволяет задать границу того, что мы будем считать выбросами. То есть для значений ошибок меньших дельта используется MSE, для больших дельта — MAE.

Формула WAPEs:

Для нашей задачи мы взяли WAPE (weighted average percentage error) и сделали её симметричной (нам важно, чтобы модель одинаково штрафовалась как за перепрогноз, так и за недопрогноз).

4.1 Конфигурирование моделей

У нас 8 в каком-то смысле однотипных моделей (8 моделей CatBoost): у них разные целевые переменные и признаки, но клиентская база одна. Поэтому для удобства и экономии времени на обучении моделей мы собираем один общий датасет для всех моделей, который содержит признаки и целевые переменные сразу всех моделей. Мы поняли, что будет неудобно поддерживать код для 8 однотипных моделей, поэтому написали единую кодовую базу для работы с ними. Для решения этой задачи мы создали конфиги для параметров, признаков и других настроек моделей на основе pydantic. А также написали единый класс Learner для обучения и предсказания.

Далее на упрощённом примере (на две модели) покажем, как мы это сделали.

from typing import List, Optional
 
from pydantic import BaseSettings
 
 
class SubModelConstructor(BaseSettings):
    # параметры CatBoost
    iterations: int
    learning_rate: Optional[float] = None
    loss_function: str
    grow_policy: str
    eval_metric: str
 
 
class SubModelFitParams(BaseSettings):
    # параметры обучения CatBoost
    use_best_model: bool = True
    early_stopping_rounds: int = 100
    verbose: int = 100
    cat_features: List[str] # список всех категориальных признаков в обучающей выборке

cat_cols = ["f1"] # список категориальных переменных
 
 
class SubModelProfile(BaseSettings):
    model_id: str # напрмер paid
    feature_cols: List[str] # cписок признаков
    constructor: SubModelConstructor
 
    @property
    def fit_params(self) -> SubModelFitParams:
        return SubModelFitParams(cat_features=sorted(set(cat_cols) & set(self.feature_cols))) # получаем список категориальных признаков для модели
 
    @property
    def target_col(self) -> str:
        return f"{self.model_id}_fact" # название целевой переменной модели
 
    @property
    def score_col(self) -> str:
        return f"{self.model_id}_pred" # название колонки с предсказанием модели
 
    def get_dict(self):
        # получение конфига модели в dict
        result = self.dict()
        result.update(
            {
                "fit_params": self.fit_params.dict(),
                "target_col": self.target_col,
                "score_col": self.score_col
            }
        )
        return result
 
 
class ModelProfile(BaseSettings):
    paid: SubModelProfile = SubModelProfile(
        model_id="paid",
        feature_cols=["f1", "f2"],
        constructor=SubModelConstructor(iterations=1000, grow_policy="Depthwise", loss_function="Logloss",
                                        eval_metric="AUC"),
    )
    aab: SubModelProfile = SubModelProfile(
        model_id="aab",
        feature_cols=["f1", "f3"],
        constructor=SubModelConstructor(iterations=1000, grow_policy="Depthwise", loss_function="Logloss",
                                        eval_metric="AUC"),
    )
    
    def dict(self):
        # нужен для инициализации модели по model_name
        model_names = self.__dict__.keys()
        result = {}
        for model_name in model_names:
            result[model_name] = getattr(self, model_name).get_dict()
        return result

from typing import Dict
 
import numpy as np
import pandas as pd
from catboost import CatBoostClassifier, CatBoostRegressor
 
classification_tasks = ["paid", "aab"] # две модели для примера
regression_tasks = []
 
 
class Learner:
    def __init__(self):
        self.cfg = ModelProfile().dict()
        self.learners = {}
        self._init_learners()
 
    def _init_learners(self):
        # инициализируем модели
        for model_id, params in self.cfg.items():
            if model_id in regression_tasks:
                self.learners[model_id] = CatBoostRegressor(**params["constructor"])
            elif model_id in classification_tasks:
                self.learners[model_id] = CatBoostClassifier(**params["constructor"])
            else:
                raise Exception
 
    def fit(self, model_list: List[str], X_train: pd.DataFrame, y_train: pd.DataFrame, X_val: pd.DataFrame, y_val: pd.DataFrame) -> None:
        for model_id in model_list:
            self.learners[model_id].fit(
                X_train[self.cfg[model_id]["feature_cols"]],
                y_train[self.cfg[model_id]["target_col"]],
                eval_set=(X_val[self.cfg[model_id]["feature_cols"]], 
                          y_val[self.cfg[model_id]["target_col"]]),
                **self.cfg[model_id]["fit_params"]
            )
 
    def predict(self, model_list: List[str], X: pd.DataFrame) -> Dict[str, np.ndarray]:
        scores = {}
        for model_id in model_list:
            df = X[self.cfg[model_id]["feature_cols"]]
            if model_id in classification_tasks:
                pred = self.learners[model_id].predict_proba(df)[:, 1]
            elif model_id in regression_tasks:
                pred = self.learners[model_id].predict(df)
            else:
                raise Exception
            scores[model_id] = pred
        return scores

model = Learner()
# в X собраны признаки всех моделей, в y - целевые переменные
# обучение моделей
model.fit(["aab", "paid"], X_train, y_train, X_val, y_val)
# прогноз
scores = model.predict(["aab", "paid"], X_oot)

Валидация

При валидации качество моделей смотрим по всем сплитам (выборка разделена на train, val, test, oot), в разрезе по горизонтам.

Для классификации смотрим:

• Brier score

• ROC AUC

• Калибровку моделей 

Для регрессии смотрим:

• Bias

• MAE

• R2

• RMSE

• WAPEs

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

5. Вывод в прод, шедулинг и переобучение моделей

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

Обученные модели сохраняем в mlflow. Шедулинг реализован на Argo Workflow — по мере поступления данных раз в месяц поднимается docker-контейнер, в котором загружаются модели из mlflow и скорят данные (данные в Hadoop, используем Spark).

6. Заключение

В одной из следующих статей расскажем о том кто и как использует прогнозы наших моделей.