Почему форма на сайте не приносит заявки и где теряются люди

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

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

Короткий ответ

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

Сначала найдите место потери

Общая формула «заявки / посещения» слишком грубая. Низкий результат может означать, что форму почти никто не видел, что люди бросили конкретный вопрос или что успешная отправка не дошла до CRM. Ниже приведены рекомендуемые имена событий, а не готовые события stepFORM. GA4 может автоматически собирать form_start и form_submit; остальные события настройте отдельно и проверьте все события на опубликованной форме. Автоматический form_submit не равен серверно подтверждённому ответу.

1. eligible_page_view - посетитель открыл страницу, на которой форма могла быть показана.
2. form_impression - форма действительно попала в область экрана и была доступна для взаимодействия.
3. form_start - человек изменил первое поле или выбрал первый вариант.
4. form_step_view - открылся очередной шаг многошагового сценария.
5. form_submit_attempt - пользователь попытался отправить данные.
6. form_submit_success - сервер принял ответ и вернул подтверждение.
7. lead_delivery_success - заявка появилась в нужной системе доставки.
8. lead_qualified - менеджер подтвердил, что обращение соответствует целевой аудитории.

Из них получаются отдельные коэффициенты: показ формы к просмотру страницы, начало к показу, переход с шага на шаг, попытка отправки к началу, успешная отправка к попытке, доставка к подтверждённой отправке и целевая заявка к доставленной. Так можно отличить выход на конкретном вопросе от ошибки валидации и отказа сервера. Для коэффициентов считайте уникальные прохождения формы по неперсональному идентификатору, а не сырое число событий: повторный клик не должен создавать вторую «конверсию». Для каждого процента храните числитель, знаменатель и период. Пять отправок из десяти и пятьсот из тысячи дают одинаковые 50%, но совсем разную уверенность.

В GA4 автоматически измеряемое событие form_submit полезно как отправная точка, но его нужно сверить с поведением вашей формы. В официальной документации Google перечислены параметры формы, а также отдельно указано, что в Analytics нельзя отправлять персональные данные. Для надёжной воронки лучше различать попытку и подтверждённый успех сервера. Документация stepFORM по Google Analytics описывает старый интерфейс Universal Analytics, поэтому текущую передачу GA4-событий проверяйте на живой форме через Realtime или DebugView. В Яндекс Метрике стандартная цель на отправку тоже может сработать при попытке отправки, даже если обязательное поле заполнено неверно. Поэтому финальное событие следует подтвердить тестом и серверными данными.

Если событий пока нет, не откладывайте проверку. Пройдите ручной 30-минутный аудит ниже с пронумерованной тестовой заявкой, а затем настройте события на найденном проблемном участке.

Девять причин, из-за которых форма не приносит заявки

1. На страницу приходит мало людей или не тот трафик

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

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

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

2. Форму не замечают или не понимают призыв

Симптом: просмотров страницы достаточно, но form_impression или form_start заметно меньше ожидаемого. Причина может быть простой: форма находится далеко ниже первого экрана, вкладка не открыта, виджет заблокирован или кнопка обещает непонятное «Продолжить».

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

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

3. Неясно, что человек получит после отправки

Симптом: форму видят, но откладывают начало. Заголовок говорит только «Оставьте заявку», а посетитель не знает, кто позвонит, что подготовит, сколько займёт ответ и не начнётся ли навязчивая продажа.

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

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

4. Форма требует больше данных, чем нужно сейчас

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

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

Исправление: оставьте минимум для ближайшего действия, сделайте второстепенные поля необязательными или объясните, зачем они нужны. Не ориентируйтесь на универсальное число полей. Сравнивайте форму с её собственной базовой версией и качеством заявок.

5. Первый вопрос и порядок шагов создают лишнее усилие

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

Проверка: пройдите каждую логическую ветку, включая вариант «другое» и возврат назад. В stepFORM условия обрабатываются сверху вниз, поэтому сложную комбинацию нужно проверять в том же порядке, в котором записаны строки. Убедитесь, что fallback ведёт к осмысленному шагу.

Исправление: начните с простого вопроса, который подтверждает намерение и меняет дальнейший маршрут. Группируйте длинные формы по логическим этапам и показывайте прогресс. Именно такой подход рекомендует W3C для многостраничных форм: понятные шаги, индикатор прогресса и сохранение уже введённых данных.

6. Мобильный ввод неудобен

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

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

Исправление: в stepFORM выбирайте подходящий тип поля, например телефон, email или цифровой ввод. Атрибут inputmode настраивайте только в собственной HTML-форме или кастомном коде, если он используется. Не делайте горизонтальную прокрутку и не прячьте подпись внутри placeholder. Элементы stepFORM адаптивны и доступны режимы предпросмотра, но финальный тест всё равно нужно провести на устройстве.

7. Ошибка непонятна, появляется поздно или стирает данные

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

Проверка: намеренно оставьте каждое обязательное поле пустым, введите неверный email и телефон, превысьте лимит символов и отправьте форму. Ошибка должна находиться рядом с полем, объяснять исправление и не уничтожать остальные ответы. Эти принципы также описаны в рекомендациях W3C по уведомлениям формы.

Исправление: сообщайте не только о факте, но и о способе исправления: «Введите телефон из 11 цифр» полезнее, чем «Ошибка». Проверяйте и клиентскую, и серверную валидацию. В stepFORM для текста доступны ограничения длины, у email и телефона есть встроенная проверка, а у множественного выбора можно задать минимум и максимум вариантов.

8. Интерфейс показал успех, но ответ не дошёл

Симптом: пользователь видит страницу благодарности, однако менеджер не находит письмо или сделку в CRM. Это уже не проблема длины формы. Нужно отделить сохранение ответа от его доставки в отдельный канал.

Проверка: отправьте уникальный тест и сначала найдите его во вкладке «Ответы» stepFORM. Если запись есть, форма сработала. Затем отдельно проверяйте подтверждение email, Telegram, сопоставление полей Bitrix24, ответ webhook, спам-папку и правила CRM. Если превышен лимит тарифа, новые ответы продолжают сохраняться, но могут не отображаться до покупки дополнительного лимита.

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

9. Аналитика считает не то событие

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

Проверка: сделайте три пронумерованных теста: успешный, с ошибкой валидации и с отключённым каналом доставки. Сверьте время и количество в сетевом журнале браузера, DebugView, ответах stepFORM и CRM. В GA4 используйте Realtime или DebugView для проверки события, но источником истины о полученных данных оставляйте серверную запись.

Исправление: разведите form_submit_attempt, form_submit_success и lead_delivery_success. Передавайте технические параметры вроде неперсонального внутреннего form_id, версии формы, номера шага и кода ошибки. Подтверждённую отправку можно дополнительно сопоставить с рекомендуемым событием GA4 generate_lead, если его определение совпадает с вашей целью. Не отправляйте в GA4 email, телефон и ответы пользователя.

Диагностика формы за 30 минут

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

1. 0-5 минут: доступность. Откройте публичную ссылку в инкогнито на телефоне и компьютере. Проверьте, что форма не скрыта настройкой, загружается внутри сайта и не перекрыта другим элементом.
2. 5-10 минут: обычный путь. Заполните форму как реальный клиент. Отметьте непонятные подписи, лишние обязательные поля, неверную клавиатуру и отсутствие объяснения следующего шага.
3. 10-15 минут: ошибки. Оставьте обязательные поля пустыми, введите неверный формат, вернитесь назад, смените ветку и повторите отправку. Введённые данные не должны исчезать без причины.
4. 15-20 минут: подтверждение. Убедитесь, что после успешного ответа появился ожидаемый финал, а тест записался в «Ответах» stepFORM. Если записи не видно, сначала проверьте лимит ответов и доступность сверхлимитных записей.
5. 20-25 минут: доставка. Найдите тот же тест в почте, Telegram, CRM или webhook-логе. Не считайте отсутствие письма доказательством отсутствия ответа.
6. 25-30 минут: аналитика. Если события уже настроены, сверьте начало, попытку, успех и доставку. Если нет, зафиксируйте доступные ручные подтверждения и участок, который нужно измерить.

Если на одном из этапов найден технический сбой, исправьте его до A/B-теста текста или дизайна. Эксперимент бесполезен, когда исходный вариант часть заявок просто не доставляет.

Как проверить исправление, а не просто увидеть случайный рост

Сформулируйте одну гипотезу до изменения: «Если объяснить результат рядом с формой, вырастет доля начала среди увидевших форму». Назначьте одну основную метрику и несколько защитных. Для этой гипотезы основной будет form_start / form_impression, а защитными могут быть доля завершения и качество заявки.

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

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

Что проверить в stepFORM

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

После теста найдите запись во вкладке «Ответы». Только потом переходите к каналам: email необходимо подтвердить и активировать, Telegram подключить к нужному аккаунту или группе, а для Bitrix24 проверить приложение, воронку и сопоставление полей. Для webhook проверьте на стороне принимающего endpoint или в RequestBin, пришёл ли POST JSON, и изучите логи или HTTP-ответ там. Доступность интеграций зависит от тарифа, поэтому актуальные условия лучше сверять на странице тарифов stepFORM.

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

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