Как понять, что сайт теряет заявки из-за неудобной формы обратной связи?

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

Как проверить, на каком этапе «отваливаются»

Я бы проверял форму в 4 слоя — от общего к частному, чтобы быстро отделить UX-проблему от технической.

1) Воронка по событиям (обязательный минимум)

• form_view — форма показана (страница или модалка).
• form_start — пользователь начал ввод (первый фокус/первый ввод).
• field_interaction — взаимодействие с ключевыми полями (телефон, email, комментарий).
• form_error — ошибки валидации (с указанием поля и типа ошибки).
• form_submit_click — клик по кнопке отправки.
• form_submit_success — успешная отправка (сервер подтвердил, показан thank you/статус success).
• form_submit_fail — попытка отправки, но ошибка (таймаут, 4xx/5xx, блокировка, капча и т. п.).

Ключевой момент: конверсией считается только form_submit_success. Частая ошибка — считать клики по кнопке «Отправить» заявками.

2) Полевой анализ (что именно мешает)

• Drop-off по каждому полю: сколько начали вводить поле и сколько дошли до следующего.
• Время на поле и число повторных попыток (особенно телефон, email, ИНН/компания).
• Ошибки по типам: неправильный формат, обязательность поля, маска телефона, «слишком коротко» и т. д.
• Автозаполнение: срабатывает ли autofill на мобильных (атрибуты autocomplete), не ломает ли маска вставку номера.

3) Сегменты: мобильные, источники, новые/возвратные

• Мобильные: чаще всего проблема в мелких полях, клавиатуре, масках, перекрытии кнопки, скролле, pop-up’ах.
• Источник/кампания: бывает, что “плохие” кампании дают много заходов на форму без реального намерения — это не проблема UX, а настройка трафика/оффера.
• Повторные визиты: если пользователи возвращаются и всё равно не отправляют — форма явно мешает или не вызывает доверия.

4) Качественная диагностика: записи сессий и тепловые карты

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

Технологическая логика: почему форма «съедает» заявки

• Слишком ранний сбор данных: вы просите то, что бизнесу нужно “когда-то”, но пользователю это не нужно “сейчас”.
• Жёсткая валидация: маски телефона, требования к домену email, запрет символов — всё это увеличивает ошибки.
• Технические сбои: форма визуально отправляется, но запрос падает (CORS, 500, таймаут, блокировщики, капча, конфликт скриптов).
• Потеря доверия: непонятно, что будет дальше, нет политики/согласия, форма выглядит подозрительно, агрессивная капча.
• Проблемы атрибуции: отправка уходит, но вы не связываете лид с источником (UTM не сохраняются, нет client_id/cookie bridging), и маркетинг “не видит” часть заявок.

Как упростить форму без потери качества лидов

Мой рабочий принцип: минимум полей до контакта + добор данных после.

1) Оставьте 1–2 обязательных поля

• B2C/услуги: телефон или email (одно обязательное) + кнопка.
• B2B: корпоративный email или телефон + необязательное «Компания».
• Все остальное (сфера, бюджет, сроки) — необязательно или вторым шагом после отправки.

2) Перенесите квалификацию на «после отправки»

• Progressive profiling: после успешной заявки покажите короткий второй шаг “Уточните 2 вопроса, чтобы быстрее помочь”.
• Автоквалификация: подставляйте в CRM UTM, страницу, продукт/категорию, регион (по IP), устройство, время, повторный визит.
• Lead scoring: качество лида оценивайте правилами в CRM/CDP (источник, поведение на сайте, страницы, глубина), а не количеством полей в форме.

3) Сделайте ввод «безошибочным»

• Понятные подсказки формата (пример рядом с полем, а не только в плейсхолдере).
• Мягкая валидация: не ругаться до попытки отправки, подсвечивать конкретную причину.
• Корректные атрибуты autocomplete и правильные типы полей (email/tel).
• Минимум капчи: если нужна защита — предпочтительнее невидимые/поведенческие механики + rate limit на backend.

4) Проверьте технику: успех должен фиксироваться сервером

• Отправка должна возвращать явный success и показывать подтверждение.
• Логи ошибок отправки (fail) с причинами.
• Дедупликация лидов в CRM (иначе вы будете «бояться» упрощать форму из-за дублей).
• Сохранение UTM и идентификаторов (client_id/ym_uid) вместе с лидом.

Практический план на 3–7 дней

1. Инструментируйте события: view/start/error/click/success/fail, плюс имя поля и тип ошибки.
2. Постройте воронку по устройствам и источникам, найдите узкое место (например: много start, мало submit_click → UX; много click, мало success → техника).
3. Соберите топ-3 проблемных поля по ошибкам/времени/отвалу.
4. Сделайте упрощённый вариант: уберите 1–3 поля, ослабьте валидацию, добавьте подсказки, проверьте мобайл.
5. Запустите сравнение (A/B или по очереди с фиксированным трафиком) и оценивайте не только отправки, но и долю целевых в CRM: дозвон, квалификация, продажа.

Типичные ошибки, из-за которых выводы будут неверными

• Считать конверсией клик по кнопке вместо подтверждённой отправки.
• Не разделять проблемы UX и проблемы backend/интеграции (поэтому нужен submit_fail).
• Оценивать качество лида по “заполненности”, а не по факту обработки в CRM (дозвон/встреча/оплата).
• Делать форму короче, но не усиливать антиспам на backend — получите мусор и разочаруетесь в упрощении.
• Ломать атрибуцию: лид приходит, но без источника, и маркетинг «наказывает» хорошие изменения.

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