Как определить целевую переменную для прогноза повторной покупки

Для прогноза повторной покупки мало поставить единицу всем, кто когда-либо вернулся. Определим момент решения, горизонт и правила включения клиентов в обучающую таблицу.

Сформулируем действие, ради которого нужен прогноз

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

Начните с момента решения. Пусть каждое утро первого числа магазин выбирает получателей письма, а модель оценивает вероятность оплаченного заказа в следующие 30 дней. Тогда строка соответствует паре «клиент — дата решения». Признаки описывают прошлое этой даты, целевая переменная — строго последующие 30 дней. Определите также, какие заказы считаются: созданные, оплаченные или не отменённые спустя дополнительный срок.

Метка ноль означает, что весь горизонт прошёл и нужного события не было. Если выгрузку сделали раньше окончания горизонта, отсутствие заказа ещё не является нулём. Такие строки пока не готовы для обычной бинарной классификации. Их следует отложить до появления полного наблюдения; при другой постановке можно рассматривать модели времени до события.

Соберём метки с явной правой границей

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

В примере две строки уже созрели, третья ещё нет. Функция возвращает None для незавершённого наблюдения. Так недостаток будущего не маскируется под отрицательный исход. Список заказов здесь маленький; на больших данных тот же договор реализуется соединением и агрегацией в витрине.

from datetime import date, timedelta
cutoff = date(2026, 10, 20)
orders = {"a": [date(2026, 9, 12)], "b": [], "c": []}
decisions = [("a", date(2026, 9, 1)),
             ("b", date(2026, 9, 1)), ("c", date(2026, 10, 1))]
def label(client, start):
    end = start + timedelta(days=30)
    if end > cutoff:
        return None
    return int(any(start <= day < end for day in orders[client]))
result = [(client, label(client, start)) for client, start in decisions]
print(result)
assert result == [("a", 1), ("b", 0), ("c", None)]
assert label("a", date(2026, 8, 13)) == 0

Получим a=1, b=0, c=None. Заказ a от 12 сентября не попадает в интервал, начинающийся 13 августа: конец такого интервала — как раз 12 сентября, а правая граница исключена. Эта небольшая проверка защищает договор о датах при переносе расчёта из Python в SQL.

Дальше проверьте повторяющиеся строки клиента. При ежедневном прогнозе один заказ может попадать в горизонты нескольких дат. Это допустимо для ежедневного рабочего процесса, но создаёт зависимость наблюдений. Случайное разделение строк способно дать слишком похожие истории в train и test. Валидация должна повторять будущие даты применения и учитывать, нужно ли оценивать знакомых клиентов или выход на совсем новых.

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

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

Для следующего шага пригодится мониторинг модели до появления меток.

В платном курсе «ML Engineer / Data Scientist: табличные модели в продакшн» вы подготовите данные для классификации и построите корректную валидацию. Работа с обучающей таблицей и проверяемыми отчётами помогает связать целевую переменную с реальным решением продукта. Откройте программу курса.