Аналитик Даурен работает с фитнес-клубом в Алматы: заявки приходят из Instagram и 2ГИС, менеджеры по ним перезванивают. Даурен восстанавливает прогноз покупки на 1 сентября. В выгрузке уже лежит оплата от 10 сентября, и модель взяла её в признаки. На исторических данных модель находит покупателей почти без ошибок. Но 1 сентября этой оплаты не существовало, и в работе модель такого результата не покажет.
Даты, суммы и результаты в уроке условные. Директору по маркетингу в таком проекте нужно ответить на два вопроса. Хорошо ли модель отбирает людей, если дать ей только то, что было известно на момент решения? И приносит ли пользу действие, которое последует за прогнозом? Это разные вопросы: модель может отлично находить тех, кто и так купит, и тогда скидка для них просто срежет выручку с покупок, которые случились бы без неё.
Данные на момент прогноза
Прогноз покупки на 1 сентября
Известно на 1 сентября
Прошлые визиты и покупки
Проверить, что данные были в системе 1 сентября
Будущая оплата
10 сентября
Не использовать как признак прогноза на 1 сентября
Историческая выгрузка с будущей оплатой даёт утечку данных. Рабочая система тогда её ещё не знала.
Определите событие и момент решения
«Найти хороших клиентов» - не цель: такой результат не проверишь. Проверить можно другое: оплату в течение 30 дней после заявки. Дальше назовите момент прогноза и действие, которое за ним последует: очередь звонков, предложение помощи, план закупки. Если действия нет, высокий балл так и останется числом в отчёте.
Для каждой записи храните три вещи: точку отсчёта, то, что было известно на эту дату, и результат после неё. У вчерашней заявки 30 дней не прошли. Записать её в «не купил» только потому, что оплаты сегодня нет, - ошибка: человек может заплатить на следующей неделе. Качество оценивают по записям, у которых окно наблюдения уже закрылось.
Что считать результатом, решите заранее. Оплата, выручка за вычетом возвратов и вклад после переменных расходов - три разных числа. Если Даурен обучил модель находить заявки, называть её прогнозом прибыли рано. Сначала нужно связать заявки с итогом, который нужен бизнесу, и проверить эту связь на данных.
Порог отбора зависит ещё и от того, сколько успеют обработать люди. Менеджеры клуба могут обзвонить 100 заявок, значит, сравнивать нужно качество этих 100 при одном и том же порядке работы. Правило, которое отдаёт менеджерам заметно больше записей, может выиграть просто за счёт объёма звонков, и вы перепутаете качество отбора с количеством усилий.
Восстановите то, что было известно до прогноза
Будущее пробирается в модель через неприметные поля. Текущий статус в CRM, общая сумма покупок и причина закрытия сделки содержат события, которых в момент решения ещё не было. Если поставить старую дату на сегодняшнюю строку клиента, исторического среза не получится: данные в строке всё равно сегодняшние.
У каждого поля выясните две даты: когда произошло событие и когда запись о нём появилась в системе. Менеджер мог внести вчерашний звонок только сегодня вечером. Звонок был, но прогноз, сделанный утром, его бы не увидел. Если у вас сохранилась история того, когда какие данные появлялись, вы сможете воспроизвести условия, в которых модель будет работать.
В курсе Google о мониторинге ML-систем разобраны и утечка результата в признаки, и расхождения между обучением и работой модели. На практике задача Даурена звучит проще: собрать ровно тот набор полей, который система получит до звонка.
Для проверки отложите данные, которых модель не видела при обучении и которые похожи на её будущую работу. Если делите по времени, у обучающих записей результат должен успеть наступить до границы, а при подготовке признаков в проверочную часть не заглядывают. Подумайте и о том, кому модель будет ставить баллы: новым людям или уже знакомым клиентам. Если проверка сделана на других, она отвечает на другой вопрос.
Посчитайте precision и recall на выбранной группе
В проверочной выборке 1 000 лидов, оплатили 50. Модель, которая всегда отвечает «не купит», угадает 950 раз. Accuracy, доля верных ответов, составит 950 / 1 000 = 95%, и при этом ни один покупатель не попадёт в очередь звонков.
Модель Даурена выбрала 100 лидов, из них купили 20. Теперь видно и тех, кого нашли, и тех, кого пропустили:
| Вопрос | Расчёт | Результат |
|---|---|---|
| Какая доля выбранных купила? | 20 / 100 | Precision = 20% |
| Какую долю всех покупателей нашли? | 20 / 50 | Recall = 40% |
| Сколько выбранных не купило? | 100 - 20 | 80 |
| Сколько покупателей осталось вне приоритета? | 50 - 20 | 30 |
Метрики классификации читают вместе. Выбранная группа может быть очень точной и при этом оставить за бортом большую часть покупателей. Порог выбирают, понимая, во что обходится каждая ошибка, сколько звонков успеют сделать и зачем вообще нужен отбор.
Балл 80 - это не вероятность 80%. Чтобы читать его как вероятность, нужна проверка калибровки: совпадают ли заявленные вероятности с тем, как часто исход случается на подходящих данных. Без неё балл годится, чтобы расставить записи по порядку, если этот порядок проверен. Подписывать его процентами не стоит.
Сравнивайте модель с простым правилом. Например, очередь можно строить по признаку, который менеджеры и так видят в CRM. Оба способа оценивают на сопоставимых данных и при одной нагрузке. Сложную модель стоит поддерживать, только если её результат нужен процессу и окупает поддержку.
Посчитайте стоимость действия отдельно от отбора
Допустим, обработка одного приоритетного лида стоит клубу 500 ₸ рабочего времени менеджера по внутренней ставке. Это число для расчёта, рыночную ставку оно не описывает. 100 лидов обойдутся в 100 × 500 = 50 000 ₸. Вклад дополнительной покупки после переменных расходов, но до расходов на контакт и модель, примем за 5 000 ₸.
Чтобы окупить это время, нужно 50 000 / 5 000 = 10 дополнительных покупок. Эти 50 000 ₸ - оценка часов менеджеров, новых выплат за ними нет. Создание и поддержка модели сюда не вошли, для полного решения их добавляют. И 20 покупателей, которых нашла модель, не равны 20 дополнительным покупкам: часть из них купила бы и без звонка.
Прогноз склонности к покупке (propensity) говорит, насколько вероятна покупка при текущих условиях. Эффект звонка или скидки - это то, насколько поведение изменилось из-за действия. Чтобы его измерить, подходящую аудиторию случайно делят на тех, кому звонят, и тех, кому нет, или находят другой обоснованный способ причинного сравнения. Вклад с учётом расходов на контакт и предложение считают отдельно.
Даже при хорошем отборе действие может оказаться лишним. Если скидку получили люди, готовые купить абонемент по полной цене, клуб отдаст часть вклада, а покупок не прибавится. Поэтому в отчёте рядом стоят два показателя: качество прогноза и результат проверенного действия. Первый второй не заменяет.
Решите заранее, что делать при ошибке и изменении данных
У прогноза должны быть владелец, срок годности и понятный следующий шаг для менеджера. Низкий балл - это оценка модели, о ценности человека он ничего не говорит. Договоритесь, что будет с заявкой, которая не попала в очередь: какую помощь человек получит всё равно, например ответ в WhatsApp или звонок позже.
Сохраняйте версию модели, входные данные, прогноз и то, что сделал менеджер. Пропало поле, поменялся источник, задержалось обновление - реагировать нужно сразу, пока неверные решения не накопились. На этот случай держите запасной вариант: ручную очередь или прежнее проверенное правило.
После запуска сравнивайте качество на новых заявках с закрытым окном и следите за нагрузкой менеджеров. Новый продукт или новый канал привлечения может поменять состав заявок. Хорошая оценка на истории - точка отсчёта, и её регулярно сверяют с текущей работой.
Задание: объясните 30 покупателей из 100
В другой выборке 1 000 лидов и 60 покупателей. Модель выбрала 100 лидов, из них купили 30. Посчитайте precision и recall и напишите, чего не хватает, чтобы оценить пользу звонка. Потом сделайте то же для своего проекта: запишите момент прогноза, целевое событие и поле, через которое в модель могло бы случайно попасть будущее.
Precision здесь 30 / 100 = 30%, recall - 30 / 60 = 50%. Ещё 30 покупателей в очередь не попали. Эти числа говорят только о качестве отбора. Чтобы записать покупки на счёт менеджера, нужно знать, как повели бы себя такие же люди без звонка, и сколько стоили звонки.
Если в вашем проекте нашлась утечка, первое исправление - собрать признаки, которые были доступны вовремя, и оценить прогноз заново. Если отбор хороший, а польза звонка неизвестна, следующий шаг - проверить само действие. Решение о внедрении опирается на обе части: на отбор и на эффект.