Надёжность формы заявки: антиспам, доставляемость и самопроверка на потерю заявок

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

1. Самая дорогая проблема — не то, что никто не заполняет, а то, что заполнили, но вы не получили

Одна заявка на сайте B2B обычно стоит 200–600 рублей на привлечение. По этим цифрам: если из 40 заявок в месяц теряется 4, вы ежемесячно выбрасываете на рекламу 800–2 400 рублей впустую. И эти 4 клиента вам ничего не скажут — тот, чью заявку молча потеряли, просто идёт к следующему.

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

Проявление сбоя	Настоящая причина	Что видит клиент	Сложность обнаружения
Нажал «Отправить» — ничего не происходит	Ошибка JS, запрос к интерфейсу не ушёл	Кнопка не меняется, большинство уходит	Средняя: по аналитике видно разницу между кликами и запросами
Показано «Успешно», но в базе пусто	Таймаут интерфейса или блокировка файрволом, фронтенд не проверил реально	«Спасибо за ваше сообщение»	Высокая: почти только по логам
В базе есть, но никто не знает	Письмо-уведомление попало в спам или отправка не удалась	Обычная страница успеха	Высокая: нужно сравнить число записей в базе и уведомлений
Пришло несколько одинаковых заявок	Пользователь нажал несколько раз, нет идемпотентности интерфейса	Незаметно	Низкая, но мешает вести работу с клиентом
Отправка с телефона не проходит	Таймаут запроса при слабой сети, нет механизма повторных попыток	Крутится, потом ошибка	Средняя: чем выше доля мобильных, тем сильнее влияние

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

2. Цепочка из пяти звеньев: у каждого свой способ ломаться

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

Этап	Типичный сбой	Типичные симптомы	Примерная частота	Действие
Валидация на фронтенде	Ошибки JS, неверные правила обязательных полей, кнопка перекрыта оверлеем	Клик не срабатывает, правило ошибочно блокирует	Средний	Оставить серверную валидацию как подстраховку, добавить текст ошибки
Отправка формы	Таймаут, блокировка CORS, ложное срабатывание защиты как атаки	Сообщение об успехе есть, данных нет	Средний и выше	Таймаут 10 секунд, при сбое API — понятная ошибка
Хранение данных	Сбой записи, обрезка длинного поля, ошибка кодировки	В админке нет поля или кракозябры	Низкий–средний	Проверять длину и кодировку поля до записи
Уведомление	Письмо попало в спам, сбой отправки, неверный получатель	В базе есть, никто не получил	Высокий	Перейти на надёжный канал отправки, настроить повтор при сбое
Подтверждение	Нет страницы успеха, нет письма-подтверждения, нет дальнейших касаний	Клиент не знает, получили ли вы его заявку	Средний	После отправки дать чёткое подтверждение и срок ответа

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

III. Четыре уровня антиспама: отсекать, но не бить по своим

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

Уровень	Метод	Что отсекает	Риск ложного срабатывания	Рекомендация
Уровень 1. Ловушка-приманка	В форму добавляется скрытое поле, невидимое пользователю, но заполняемое скриптом	Автоматические массовые отправки	Крайне низкая	Включено по умолчанию, автозаполнение браузера должно исключать это поле
Уровень 2. Метка времени и поведение	Фиксируется интервал от загрузки страницы до отправки, движения мыши и прокрутка	Скриптовые отправки за секунды	Низкая	Интервал меньше 3 секунд считается подозрительным, но нужен доступ к ручной проверке
Уровень 3. Контентные правила	Чёрный список слов, количество ссылок, проверка кодировки и языка	Явная реклама и ссылочный спам	Средний и выше	При срабатывании — в очередь на проверку, не удалять сразу
Уровень 4. Сторонняя проверка	Капча, сервисы антифрода, проверка существования почты	Распределённый и ручной спам	Низкая	Включать в зависимости от объёма отправок

Третий уровень — самый опасный. Я видел конфигурации, где в чёрный список попадали “test”, “quote”, “price” — и это отсекало реальных клиентов; видел и случаи, когда заявку признавали спамом за ссылку на конкурента, приложенную для справки. Правильный подход —при срабатывании правила отправлять в очередь на проверку, а не удалять сразу, сохраняя полный исходный текст, и раз в неделю пересматривать долю ложных срабатываний.

Признак спама	На что смотреть	Что делать
В тексте больше 3 внешних ссылок	Заметно отличается от нормальной заявки, обычный клиент редко вставляет несколько ссылок	В очередь на проверку, посмотреть вручную
Почта на одноразовом домене	Сверить со списком популярных одноразовых доменов	В очередь на проверку, отвечать можно, но без приоритета
С одного IP ≥5 отправок за 10 минут	Нужно хранить логи доступа	Временное ограничение скорости, без постоянной блокировки
Имя и название компании — случайные строки	Подряд идущие бессмысленные символы	Отбрасывать сразу, счётчик — для мониторинга
Интервал между отправками <2 секунд	Проверять вместе с полем временной метки	Отправлять на модерацию с выборочной ручной проверкой

4. Когда включать капчу: при каком объёме

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

Отправок в день	Стоит ли включать капчу	Опытный диапазон потерь конверсии	Более подходящая альтернатива
<10	Не рекомендуется	3–8 %	Достаточно honeypot-поля и проверки временной метки
10–30	Сначала очередь на модерацию	5%–10%	Контентные правила и проверка валидности email
30–100	Рекомендуется невидимая капча	5%–12%	Сначала невидимая проверка, картинка — потом
>100	Рекомендуется, вместе с антифродом	8–15 %	Невидимая капча + лимит по IP + очередь на модерацию

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

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

5. Три условия доставки писем и базовая конфигурация

Дойдёт ли уведомление — зависит от настроек домена отправителя, а не от того, насколько хорошо написано письмо.

Условие	Что настроить	Что будет без настройки	Как проверить
Аутентификация	Записи SPF и DKIM заполнены, DMARC минимум none или quarantine	Письмо признают подозрительным и отправят в спам	Проверьте DNS-записи или оцените через сервис тестирования отправки
Отправитель и адрес для ответа совпадают	Домен в From и Reply-To один и тот же, и это реальный адрес, принимающий письма	Ответ клиента не дойдёт или его сочтут подделкой	Ответьте на письмо-уведомление с внешнего ящика
Доставка в том же домене	Домен формы и домен отправителя совпадают, лендинг не отправляет данные на другой домен	Кросс-доменную отправку блокируют, часть ящиков письма не принимает	Проверьте action формы и домен страницы

В базовой конфигурации чаще всего пропускают третий пункт.Форма на домене A, а приём заявок на домене B — конфигурация, при которой заявки теряются чаще всего, потому что она одновременно включает ограничения браузера на кросс-доменные запросы и политику доставки части почтовых сервисов. При переносе сайта или смене платформы этот пункт нужно перепроверять в первую очередь.

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

6. Резервные каналы и самопроверка на потерю заявок

Полагаться только на email-уведомления — небезопасная схема. Принцип резервирования такой:Хотя бы один канал не должен зависеть от почты.

Канал	Зависит от почты	Рекомендация	Последствия при сбое
Хранение в базе данных	Нет	Обязательно, это база для любой самопроверки	Нет данных — невозможно понять, теряются ли заявки
Уведомление по email	Да	Оставить как основной канал напоминаний	Если письмо попадёт в спам, никто об этом не узнает
Сторонняя форма или резервная копия в CRM	Нет	Рекомендуется для перекрёстной проверки	На один независимый источник меньше
Push в мессенджере	Нет	Рекомендуется как самый быстрый канал	Остаётся только email, а задержка ответа заметна
Письмо-подтверждение клиенту об успешной отправке	Да	Рекомендуется, с указанием срока ответа	Клиент не знает, получили ли вы его заявку

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

Параметр сравнения	Источник данных	Норма	О чём говорит расхождение
Количество отправок	Логи фронтенд-трекинга или вызовов API	Эталонное значение	Заметно выше числа записей в базе: проблема с API или хранилищем
Количество записей в базе	База данных или бэкенд формы	Должно равняться числу отправок минус дубли и ошибки	Ниже числа отправок: запись не прошла или её заблокировали
Количество уведомлений	Логи отправки писем или push-уведомлений	Должно равняться числу записей в базе	Ниже числа записей: письмо не ушло или попало в спам

Частота самопроверки: сайтам с 30+ отправками в день — проверять три числа ежедневно, с 5–30 — раз в неделю, с менее чем 5 — раз в неделю вручную проверять одну заявку.При расхождении сначала сделайте три вещи: проверьте логи ошибок API, проверьте записи о неудачной отправке писем и отправьте реальную заявку с внешнего ящика. Обычно конкретное звено удаётся найти за 30 минут.

Семь: мониторинг и алерты, подстраховка при слабой сети и случаи, когда это не нужно

Цель мониторинга — не «чтобы был дашборд», а узнать о сбое раньше клиента.

Метрика	Нормальный диапазон	Порог алерта	Действие при срабатывании
Отправок в день	Среднесуточное за 30 дней ±40%	Падение до 0 или снижение >70%	Сразу отправить тестовую заявку
Доля успешных вызовов API	≥99%	<95% в течение 10 минут подряд	Проверить логи API и правила безопасности
Доля успешно отправленных уведомлений	≥98%	<90% за день	Проверить канал отправки и настройки домена
Доля спама	20%–50%	>70% за день	Проверить, не устарели ли правила для контента
Доля повторных отправок	<3%	>8%	Добавить идемпотентность API и защиту от двойного клика на фронтенде

Мобильные устройства и слабая сеть — ещё одна зона риска. Три типа сбоев требуют отдельной подстраховки:

Тип сбоя	Как распознать	Что делать
Таймаут запроса	На мобильных API отвечает заметно дольше, чем на десктопе	Поставить таймаут 10 секунд и одну автоматическую повторную попытку
Форма теряется при переключении страницы	Пользователь уходит проверить адрес в почте и возвращается	Сохранять содержимое формы локально и восстанавливать при возврате
Отправка прошла, но страница не отвечает	При слабой сети ответ блокируется	После отправки показывать понятную страницу успеха и срок ответа

Есть три случая, когда всё это делать не обязательно. Во-первых, для сайтов с менее чем 5 отправками в день затраты на подключение к системе мониторинга выше риска потери заявок — достаточно еженедельной ручной проверки. Во-вторых, если заявки приходят в основном через WhatsApp, внутренние сообщения на платформе и другие IM-каналы, а форма лишь дополняет их, требования к надёжности можно снизить, но этап сохранения в базу всё равно нужен — иначе не получится выстроить атрибуцию. В-третьих, если форма размещена на сторонней SaaS-платформе и логи недоступны, акцент можно сделать только на приёме уведомлений — настройте не менее двух каналов.

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

FAQ: частые вопросы

Клиент говорит, что отправил заявку, но у нас в админке её нет — как разобраться?

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

Спам-заявки составляют треть — стоит ли усилить фильтрацию?

Сначала посмотрите, сколько из этой трети — настоящий спам. Рекомендую вручную отобрать 30 заявок и разложить по трём категориям: «явно недействительные», «под вопросом», «на самом деле реальные». Если «на самом деле реальных» больше двух, значит текущие правила уже отсекают нужных клиентов. В такой ситуации лучше усилить очередь на проверку и ручную модерацию, а не повышать жёсткость фильтрации. Если всё же нужно ужесточить, начните с двух самых безопасных уровней: скрытого поля-приманки и проверки временной метки — они почти не дают ложных срабатываний; контентные правила и сторонние сервисы проверки оставьте на потом.

Включать ли капчу?

Смотрите на количество отправок в день. Меньше 10 — не нужно, хватит скрытого поля-приманки и временной метки, капча только отпугнёт реальных клиентов; от 10 до 30 — можно сначала обойтись очередью на проверку; больше 30 — стоит включить невидимую капчу: она остановит большинство автоматических отправок и почти незаметна для реальных пользователей. Картинку-капчу рассматривайте в последнюю очередь — она сильнее всего бьёт по пользователям мобильных устройств. Критерий — данные, а не ощущения: посчитайте реальные заявки за две недели до и после включения капчи.

Для формы использовать готовый плагин или писать самому?

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

Письма-уведомления не доходят до собственной корпоративной почты — что делать?

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

Несколько десятков заявок в день — нужна ли CRM?

Смотрите не на количество, а на то, вышел ли из-под контроля этап сопровождения. Есть три сигнала: одного клиента связывают два разных менеджера; более 20% заявок остались без записи о сопровождении; историю цен можно найти только перелистывая почту. Если совпали два — CRM окупится. Если заявок всего полтора-два десятка и все ведёт сам владелец, хватит общей таблицы с тремя обязательными полями (источник, статус, дата следующего контакта): слишком раннее внедрение системы только снижает желание вносить данные.

В заключение

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

Порядок внедрения такой: сначала проведите 15-минутный тест доставки по всей цепочке; затем сведите три цифры (число отправок, число записей в базе, число уведомлений) в одну таблицу и просматривайте её раз в неделю; в конце при необходимости добавьте канал уведомлений, не зависящий от почты. После этих трёх шагов большинство скрытых потерь заказов будет исключено.Достаточно запомнить один критерий: три числа не сходятся — значит, потеряли.