Лид-скоринг

Происхождение и развитие

Развитие метода можно проследить по переходу от экспертного отбора к моделям с обратной связью. В исследовании 2013 года Йерун Д’Хаен и Дирк Ван ден Пул описали трёхэтапное ранжирование потенциальных клиентов для продаж между компаниями. Сначала модель искала организации, похожие на существующих клиентов; после получения результатов квалификации использовала положительные и отрицательные исходы; затем объединяла оценки ^[6].

Эта историческая работа показывает важный шаг: список кандидатов перестал быть только результатом разового выбора, а результаты дальнейшей работы стали входом следующего расчёта. Авторы оговорили, что полноценное испытание всей модели в реальных условиях ещё необходимо ^[6]. Поэтому их исследование не служит обещанием роста продаж для любой компании.

В современных инструментах сосуществуют оба подхода: HubSpot позволяет задавать правила баллов, а Dynamics 365 Sales — получать оценку из прогнозной модели ^{[1; 2]}. Автоматизация расчёта и способность обучаться на результатах — разные свойства системы.

Как получается оценка

Первый вопрос — какой результат нужен компании. Это может быть состоявшаяся встреча, квалифицированное обращение или оплата. В Dynamics 365 Sales описана оценка перехода лида в opportunity — возможность продажи, ещё не завершённую покупку. Более высокий балл означает более высокое место по этому признаку ^[1]. Подмена встречи оплатой меняет саму задачу оценки.

Затем выбирают сведения, доступные к моменту расчёта. В HubSpot различаются свойства записи и события: например, размер компании и действие на сайте. Правила могут учитывать частоту событий, время их совершения и предел баллов в группе ^[2]. Это помогает явно задать, чем отличается единичное действие от многократного повторения.

После расчёта нужен способ использовать результат. Порог — значение, начиная с которого лид попадает в выбранную группу. В HubSpot пороги задаются отдельно от правил начисления ^[2]. Поэтому изменение порога может изменить очередь без изменения баллов самих клиентов.

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

Какие бывают оценки

Для объяснения способов расчёта различим ручные правила и прогнозную модель. В первом случае человек заранее задаёт баллы за признаки; во втором алгоритм использует данные для получения оценки. Это обобщение двух рассмотренных реализаций, а не единая классификация всех систем ^{[1; 2]}.

По содержанию оценки HubSpot предлагает другой разрез ^[2]:

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

Учебный пример начисления

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

В пределах одного выбранного периода обе организации соответствуют профилю. Компания А запросила расчёт и не открывала письма: её оценка — семьдесят баллов. Компания Б не запрашивала расчёт, но открыла десять писем: за открытия ей начисляют десять баллов с учётом предела, всего получается пятьдесят.

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

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

Как проверить отбор и выбрать порог

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

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

Precision, или точность отбора, показывает долю успешных исходов среди отобранных. Recall, или полнота, показывает, какая доля всех успешных исходов найдена ^[3].

Precision = успешные среди отобранных / все отобранные = 20 / 40 = 50%.

Recall = успешные среди отобранных / все успешные = 20 / 50 = 40%.

Первая величина означает: встреча состоялась по половине выбранных заявок. Вторая: система нашла только две пятых всех заявок со встречами. Знаменатели разные, поэтому показатели не взаимозаменяемы.

Допустим, при снижении порога отобраны восемьдесят заявок, из них тридцать пять со встречами. Теперь точность составляет 43,75%, а полнота — 70%. В этом примере команда получает больше подходящих обращений, но должна обработать вдвое больше заявок. Выбор зависит от стоимости ошибок и доступного времени; такой подход к выбору метрик описан в руководстве Google ^[3].

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

Ошибки и ограничения

Для нашей проверки принципиально, что исход известен по всем заявкам. Если встречи фиксировали только для верхней части очереди, число всех успешных исходов неизвестно: рассчитанная «полнота» не отвечает заявленному вопросу. Аналогично нельзя сравнивать заявку недельной давности с заявкой, которую наблюдали месяц, не учитывая различие сроков.

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

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

Для систем с ИИ NIST выделяет надёжность, объяснимость, защиту приватности и управление вредными смещениями среди характеристик доверия. Рамка добровольная, а отдельная выполненная рекомендация не гарантирует надёжность всей системы ^[4]. Для лид-скоринга это повод проверять данные и последствия использования оценки, а не считать автоматический балл заведомо объективным.

Правовой аспект

В России при обработке персональных данных применяется закон № 152-ФЗ, в редакции от 26.07.2026 на дату проверки 28.10.2026. Статья 5, части 2, 4–7 связывает обработку с определёнными целями, ограничивает избыточность данных и устанавливает требования к их точности и хранению ^[5].

Статья 15, часть 1 требует предварительного согласия для обработки данных ради продвижения через прямые контакты с потенциальным потребителем средствами связи. Статья 16, части 1–2 регулирует решения, основанные исключительно на автоматизированной обработке и затрагивающие права и законные интересы человека, с предусмотренными там исключениями ^[5]. Поэтому рейтинг не заменяет проверку допустимости конкретного использования. Этот обзор не является юридическим разрешением внедрить модель; её применение требует отдельной правовой оценки.

Частые вопросы

Связанные термины

• lid
• kvalifikatsiya-lida
• crm-marketing
• crm-sistema
• voronka-prodazh
• segmentatsiya-bazy-klientov