Лид-скоринг знает будущее: как найти утечку данных

В 10:00 поступил лид. В 10:01 его нужно поставить в очередь менеджера. Бюджет станет известен только после обеда, а оплату увидят через две недели. Если проверять скоринг по сегодняшней полной карточке, он получит сведения, которых в 10:01 ещё не существовало.

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

Восстановите историю одного учебного лида

Условный пример: задача скоринга — определить очередь сразу после заявки; момент решения t0 — 10:01 первого дня. Цель проверки — оплата в течение тридцати суток. Все события и суммы вымышлены.

День 1, 10:00:00 — сервер принял форму: источник=paid_search. День 1, 10:00:20 — заявка и источник появились в CRM. День 1, 10:01:00 — t0: требуется выбрать очередь. День 1, 10:04:00 — в CRM загрузилось посещение страницы цены, фактическое время посещения — 09:58:00. День 1, 14:00:00 — на звонке клиент назвал бюджет 150 000 ₽. День 2, 11:00:00 — обогащение добавило отрасль компании. День 4, 16:00:00 — проведена встреча. День 14, 12:00:00 — получена оплата; исход стал положительным.

Источник можно использовать: к t0 он уже получен. Посещение цены произошло раньше t0, но стало доступно системе позже. Для реально исполнимого решения в 10:01 оно пока не подходит. Поздний бюджет, обогащённая отрасль и встреча также не являются входами этого первичного балла.

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

Соберите снимок, который существовал к t0

scikit-learn определяет leakage как использование сведений, недоступных в момент предсказания. Для временного аудита каждого признака нужны как минимум ID записи, время события, время доступности, значение на t0 и основание допуска.

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

Допустим, старое правило начисляло баллы за бюджет, встречу и выставленный счёт. У учебного лида оно выглядит сильным на завершённой карточке. При восстановлении t0 все три поля отсутствуют. Ретроспективный балл не описывает работу исходной очереди; его нужно пересчитать на допустимых входах, не заполняя пробелы будущими значениями.

Проверьте также текущие свойства CRM. HubSpot переоценивает записи ретроспективно при включении и изменении score. Сегодняшнее значение не обязательно равно тому, которое видел менеджер месяц назад. Без сохранённой версии и снимка прежнее решение может оказаться невосстановимым.

Проверьте качество после удаления будущего

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

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

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

Общая схема CRM-маркетинга описывает место скоринга. Начните узко: восстановите один успешный лид на t0 и вычеркните всё, что пришло позже. Если после этого исчезает основное преимущество балла, расширять автоматическую очередь преждевременно.