Ошибки при разработке форм

Недавно у одного из моих клиентов случилась проблема - сайт, который сделал их разработчик, перестал высылать письма и класть заявки в базу данных. Меня попросили помочь разобраться, чтобы не терять дни на простой рекламы, пока их разработчик вернется к работе.

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

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

Критические ошибки в формах

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

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

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

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

Отправка письма в самом начале

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

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

Отсутствие обработки ошибок

Мы отдали проект заказчику и все было отлично. В один момент недовольный клиент пишет нам "у нас не работают заявки" (вообще эта фраза в один момент была чуть ли не моим ночным кошмаром). Пытаюсь понять в чем дело, а потом выясняется, что администратор сменил пароль от базы данных и об этом, разумеется, мы узнали спустя почти сутки откручивания рекламы и отправки пустых заявок.

Что-то пойти не так может не только при отправке электронной почты. Может перестать работать база данных, смениться доступы, кончится место на диске. Убедитесь, что вы глобально настроили обработку всех ошибок. Причем вы должны совершенно точно узнать о том, что произошла та или иначе проблема. Я на своей стороне решил это путем оповещения в специальный чат в Telegram о том, что есть проблема.

Пара строк кода отправки сообщения при ошибке уже несколько раз спасала наши нервы и деньги наших клиентов.

Отсутствие логгирования отправленных форм

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

Да, по логам, конечно же, не получится сделать такой удобный поиск, как по индексированной БД, но в экстренной ситуации может спасти вас!

Синхронная обработка формы и ожидание в интерфейсе

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

  • Сохранение заявки в базу данных
  • Отправка сообщение на почту нескольким получателям (в цикле)
  • Отправка заявки в CRM систему
  • Отправка заявки в систему аналитики
  • Уведомление в Telegram о новой заявке

Все это это время пользователь просто ждал пока отправятся данные и не видел никакого движения (даже банального лоадера). Иногда были ситуации, что пользователь не дожидался и уходил - в некоторых таких ситуациях запрос не успевал обработаться до конца и обработка прекращалась, что приводило к потере лида.

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

Синхронный долгий скрипт, раскладывающий все по интеграциям

Продолжение предыдущего постулата. Если у вас на backend происходит очень долгая обработка и размещение формы заявки по интеграциям, то стоит воспользоваться асинхронной обработкой данных на backend. Давным давно я для этой цели использовал Gearman, но для начала сойдет просто складывать заявки в таблицу БД, показывать пользователю что все ОК. Дальше, по cron запускать обработку заявок и выполнять необходимые действия с интеграциями.

Закомментированная строка отправки самой формы

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

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

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

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