Капча мешает отправить заявку: как проверить защиту от спама и удобство формы

Сначала найдите место, где прерывается обращение

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

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

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

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

Как работает проверка и почему галочки недостаточно

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

У подтверждения есть ограничения. Например, в документации Yandex SmartCaptcha указано, что токен проверки одноразовый и действует пять минут. Это правило конкретного сервиса, а не универсальное время для всех капч. Для установленного у вас решения разработчик должен проверить его собственную документацию.

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

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

Что проверить на телефоне

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

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

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

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

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

Доступность: сможет ли человек пройти форму иначе

Капча, которую легко проходит разработчик с мышью, может стать препятствием для посетителя с нарушением зрения или моторики. В обзоре W3C о доступности CAPTCHA рассмотрены ограничения визуальных, звуковых и других заданий. Наличие звуковой альтернативы само по себе ещё не делает любую проверку доступной всем людям.

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

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

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

Когда загружать защиту и что показывать во время ожидания

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

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

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

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

Как отличить ошибку капчи от ошибки формы

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

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

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

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

Что включить в задание разработчику

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

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

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

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

Как принять результат и не вернуть проблему следующей правкой

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

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

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

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

Практический итог для маркетолога

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

Если требуется разобраться, на каком шаге теряются заявки, ШТАБ ИТ может помочь с проверкой и доработкой формы сайта. Для начала нужны адрес формы, описание проблемы и время нескольких неудачных попыток без персональных данных клиентов. По этим сведениям можно определить, проверять ли защиту, обработчик или передачу обращения.