Как прогнозировать количество качественных лидов диапазоном

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

Автоматические планировщики стали лучше учитывать сезонность и отложенные конверсии, но они прогнозируют выбранное действие в рекламной системе, а не самостоятельно определяют, какие заявки клиент считает качественными. Поэтому задача маркетолога сегодня — соединить прогноз трафика с данными CRM и заранее зафиксировать, что именно будет считаться результатом.

Сначала определите, какой лид нужен клиенту

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

Удобно разделить воронку на четыре наблюдаемые стадии: принятая заявка, маркетинговый квалифицированный лид (MQL), лид, подтверждённый отделом продаж (SQL), и сделка. Актуальная документация HubSpot по стадиям жизненного цикла относит MQL к контактам, которые маркетинг подготовил для передачи продавцам, а SQL — к потенциальным клиентам, квалифицированным отделом продаж; при этом стандартные стадии разрешено дополнять собственными.

До расчёта клиент и подрядчик должны записать критерии перехода. Например, MQL может одновременно соответствовать целевой отрасли, региону и минимальному размеру компании, а SQL — дополнительно иметь подтверждённую задачу и согласие на разговор с продавцом. Просмотр страницы, скачивание файла или участие в вебинаре могут служить сигналами, но не обязаны автоматически означать готовность к покупке.

Соберите данные без смешения когорт

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

Собирайте когорты по дате создания заявки и наблюдайте каждую до окончания установленного окна: например, 14 дней до MQL, 30 дней до SQL и 90 дней до сделки. Конкретные окна выбирают по фактическому циклу клиента, а не по этому условному примеру. Для каждой записи нужны источник, кампания, дата входа в стадию, дата выхода, причина отклонения и итоговый статус.

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

Рассчитайте переходы, а не один общий процент

Для каждой пары соседних стадий используйте простой коэффициент: число контактов, перешедших на следующую стадию, делится на число контактов, которые могли совершить этот переход. Тогда прогноз количества SQL записывается так: прогноз принятых заявок × доля перехода заявок в MQL × доля перехода MQL в SQL.

Если клиенту важны продажи, цепочка продолжается: прогноз клиентов = прогноз заявок × переход в MQL × переход MQL в SQL × переход SQL в сделку. Такой расчёт показывает, где именно изменилось ожидание. Падение объёма трафика, ухудшение качества заявок и снижение эффективности продавцов больше не маскируются одним итоговым коэффициентом.

Прогноз рекламной платформы можно использовать как верхнюю часть модели, но его цель должна совпадать с вашей метрикой. описание Performance Planner от Google уточняет, что прогноз строится для типа конверсии из отчётной колонки или выбранной цели, обновляется ежедневно на основе последних 7–10 дней с поправкой на сезонность и учитывает задержку конверсии для поддерживаемых кампаний. Если целью формы считается любая отправка контактов, такой прогноз ещё не равен количеству MQL или SQL из CRM.

Покажите три сценария на одних исходных данных

Рассмотрим условный расчёт для 200 принятых заявок. В базовом сценарии 30% заявок становятся MQL, половина MQL проходит квалификацию продажами, а четверть SQL заканчивается сделкой. Модель даст 60 MQL, 30 SQL и 7,5 ожидаемой сделки; в отчёте последнее значение разумно описать как математическое ожидание около 7–8 сделок, а не обещание получить половину клиента.

Теперь зададим проверяемые границы сценариев. Для осторожного варианта используем переходы 20%, 35% и 15%: это 40 MQL, 14 SQL и около двух сделок. При значениях 40%, 65% и 40% оптимистичный вариант даст 80 MQL, 52 SQL и примерно 21 сделку. Эти границы являются сценарными допущениями, а не доверительным интервалом; клиент должен видеть, какие коэффициенты требуется подтвердить фактическими данными.

Сценарии следует менять не одновременно «на глаз», а по известным факторам. Если увеличивается бюджет в прежнем канале, можно варьировать объём заявок и возможное снижение их качества. При запуске нового предложения меняются переходы после заявки. Если отдел продаж перегружен, отдельно корректируются скорость обработки и доля MQL, которые успеют получить квалификацию.

Добавьте статистическую неопределённость

Историческая доля перехода — оценка, а не постоянная характеристика бизнеса. Если из 80 заявок получилось 24 MQL, наблюдаемая конверсия равна 30%, но следующая когорта не обязана повторить её. Чем меньше наблюдений, тем опаснее представлять процент как точное значение.

Для долей можно рассчитывать доверительный интервал Уилсона средствами таблицы или статистического пакета. справочник NIST по интервалам для пропорций отмечает, что этот метод не даёт невозможной отрицательной нижней границы и подходит для широкого сочетания объёма выборки и наблюдаемой доли; при совсем малых выборках также рассматривается точный биномиальный метод.

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

Что должно быть в прогнозе для клиента

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

Затем представьте осторожный, базовый и оптимистичный сценарии с ожидаемым количеством MQL, SQL и сделок. Рядом укажите, какая команда отвечает за каждую стадию и когда прогноз будет пересчитан. Обновление требуется после изменения рекламной цели, формы, предложения, правил квалификации или процесса продаж — старые коэффициенты после таких изменений уже описывают другую систему.

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

Прогноз качественных лидов: диапазон честнее одной цифры