Заявок стало больше, продаж меньше: защитные метрики CRO

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

Карточка гипотезы уже разобрана в материале об AI и A/B-тесте лендинга. Здесь задача уже: связать изменение формы с последующей квалификацией и заранее определить допустимый компромисс.

Сохраните группу до CRM

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

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

Согласуйте критерий квалификации с продажами и применяйте его одинаково. Например: обслуживаемый регион, подходящая задача и подтверждённая потребность. «Менеджеру понравился лид» трудно проверить. В справочнике свойств HubSpot этап жизненного цикла и статус лида описаны отдельно; название поля само по себе не задаёт ваше правило квалификации.

Почему нужны два знаменателя

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

Проблемы интерпретации метрик подробно разбирает исследование Microsoft о двенадцати типовых ошибках. Рабочая карточка ниже — мой способ применить осторожность к лидогенерации; это не готовый стандарт из исследования.

Вариант Б даёт на 50 заявок больше, но на 4 квалифицированных меньше. Обработка увеличилась на 12,5 часа. Числа условные и не доказывают статистически значимого ухудшения. Здесь нет данных об оплаченных сделках и марже, поэтому вывод о прибыли тоже отсутствует.

Заполненная карточка решения

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

В учебном примере можно принять операционный лимит 30 часов на поток. Б потребовал 37,5 часа и нарушил бы именно этот заранее заданный предел. Это основание остановить масштабирование даже до спора о вероятном эффекте на продажи. Нельзя задним числом придумать 30 часов потому, что вариант не понравился.

Когда продажи ещё не созрели

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

При недостающей квалификации результатом будет «данных недостаточно», а не автоматическая победа по отправкам. При техническом сбое сначала восстановите измерение. При конфликте качества и объёма посчитайте ограничение обработки и ожидаемую ценность на одинаковом горизонте. Правила статистического решения задаются до старта, как описано в разборе A/B-тестирования.

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