Технические требования к формам на сайте

Форма — это способ о чём-то спросить посетителя сайта. Маркетолог принимает решение — когда, как и о чём нужно спросить, а разработчик разрабатывает нужную форму.

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

Асинхронная отправка данных формы

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

Двойная проверка введённых данных

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

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

Защита от внедрения стороннего кода

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

Защита от дублей

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

Защита от спама

Спам — это когда с сайта приходят сотни сообщений с классическими спам-предложениями перейти на какой-то сайт и т.п.

Популярны следующие варианты защиты от спама.

1. Регистрация пользователя с подтверждение email адреса. Действия такого пользователя не требуется проверять.
2. Переменный обработчик формы. Спам-системы запоминают не саму форму, а адрес до серверного скрипта, который обрабатывает форму. Изменять обработчик буквально не обязательно, просто нужно добавить параметр, значение которого меняется непрогнозируемым образом и проверяется при отправке на сервере. Скажем, версия сайта. Не самый надёжный, но позволяющий снова и снова перекрывать поток спама.
3. Доступно бесплатное решение от Google — ReCAPTCHA. Это более тяжёлое и мощное решение. Работа последней версии невидима для пользователя. Окошко с выбором светофоров уже не появляется. При подключении, на сайте показывается иконка Google в нижнем правом углу сайта — это плата за использования этого решения.

Все защиты можно обойти, но для небольших проектов, которые не рассчитывают на персональное внимание какого-то спам-хакера — варианты приемлемы. Что-то должно быть обязательно.

Оповещать менеджера там, где это удобно менеджеру

Сообщения с сайта могут отправляться на несколько адресов почты, в Telegram, WhatsApp. В популярные CRM, такие как Bitrix24, Мегаплан, AmoCRM.

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

Резервная копия данных формы

Интернет не самая надёжная среда. Письмо может не отправиться, а сервис с CRM может быть недоступен. Последний “рубеж обороны” это создание резервной копии с сообщением пользователя на сервере сайта. Ценность Лида может быть очень значительной и если возникли проблемы со связью Лид всё равно можно сохранить, когда форма отправлена и данные сервером получены, даже если почта или CRM недоступны.

Сохранение и восстановление введённых пользователем данных

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

После каждого изменения, сделанного пользователем, данные можно автоматически сохранять и восстанавливать при переходах или обновлении страницы. Сохранять данные можно на сервере или в браузере — localStorage, IndexedDB.

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

Отправка данных о достижении цели

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

ym(XXXXXX, 'reachGoal', 'Lead'); //Яндекс.Метрика
dataLayer.push({'event': 'Lead'}); //Google Tag Manager
fbq('track', 'Lead'); //Pixel Facebook

UTM-метки и данные об источнике перехода на сайт

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

C UTM-метками есть сложность, так как есть временной разрыв между переходом на сайт с меткой и отправкой формы. Сначала нужно UTM-метку перехода сохранить, обычно в браузере пользователя, а потом добавить информацию о ней в данные формы.

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

Географические данные пользователя

Интернет так устроен, что всегда известен IP адрес пользователя, а зная IP адрес можно определить регион. Это не всегда достоверные данные, но они могут помочь менеджеру сделать более адекватное предложение. Недостоверный IP, из-за использования VPN, часто легко заметить, если компания работает в Росси, а заявка на русском языке пришла из Швейцарии. Другое дело если заявка пришла из Москвы или из Архангельска.

Гидратация

Недолжно быть разрыва между тем, когда форма показалась и когда способна работать. Это называется “Гидратацией клиентской части”. Современные технологии разработки сайтов, из-за стремления максимально быстро показать, что-то пользователю, допускают такой разрыв. Активация и обработка действий пользователя на сайте откладываются пока не покажется весь интерфейс и не загрузятся все скрипты и библиотеки.

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

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

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

Часто используется вариант, когда сначала загружаются скрипты, а потом показывается интерфейс, в таком случае остаётся только своевременно “повесить” обработчики на элементы формы. Но в этом случае появится проблема со скоростью загрузки основного контента LCP.

Лучший вариант не использовать общий файл скриптов (js bundle), а разделить код. C каждым блоком выполнять свою часть кода.

Если форма и её код покажутся и выполнятся в одном такте отрисовки, то ситуация с нерабочей формой будет исключена. Такая проблема “из коробки” при серверном рендеринге сайта (SSR) и без него есть у большинства современных фреймворков, в том числе и react, и vue. Если дополнительно “поколдовать”, то проблему можно везде исключить.

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

<form></form>
<form style="opacity:0"></form>
<script type="module"></script>
<script async type="module"></script>
<script></script>

Скорость работы формы

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

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

Библиотеки для обработки формы должны находиться на том же сервере, где и сайт. Использование популярных бесплатных CDN может приводить к неожиданным заметным задержкам. Даже если работа сайта менее стабильна, чем публичные CDN, главное — если загружается сайт, то загрузятся и нужные библиотеки, а работа формы будет зависеть только от работы сайта. Лучше не добавлять зависимость от стороннего сервиса, при которой сайт может работать, а форма нет. Трудно представить более раздражающей ошибки — сайт работает, реклама есть, а заявок нет… пфф.