Формы в разных CMS устроены по-разному, но задача у них одна: принять данные посетителя, сохранить обращение и передать его менеджеру или в CRM. Поэтому защита от спам-заявок должна встраиваться не в дизайн кнопки, а в серверный маршрут обработки.
Ниже — общая архитектура для Netcat, 1С-Битрикс, WordPress и Tilda. Названия событий, модулей и плагинов меняются между версиями, поэтому перед внедрением конкретный хук нужно сверить с документацией используемой CMS и форм.
Единая схема для любой CMS
- Посетитель отправляет обычную форму.
- Сайт нормализует имя, телефон, email и комментарий.
- Сервер сохраняет исходный технический контекст заявки.
- Обращение передаётся в NoiseCut для проверки.
- Результат сохраняется вместе с заявкой.
- Подтверждённые и подозрительные обращения направляются по разным маршрутам.
Проверка должна выполняться до создания обычной сделки в CRM или до отправки подтверждённой конверсии в аналитику. При этом спорную заявку безопаснее не удалять, а пометить и оставить доступной для ручной проверки.
Какие данные нужны интеграции
Минимальный набор зависит от формы, но обычно включает имя, телефон, email, текст обращения и идентификатор сайта. Для поведенческого контекста полезны стабильный form_id и IP, сохранённый именно в момент исходной отправки.
Если проверка запускается из очереди или фонового задания, нельзя подставлять REMOTE_ADDR обработчика: это будет адрес технического процесса, а не посетителя. Актуальная структура запроса и правила подписи приведены в документации NoiseCut API.
Netcat
В Netcat проверку удобно ставить в серверную обработку добавления объекта или в проектный обработчик формы до дальнейшей отправки данных. Результат можно сохранить в отдельных полях объекта: статус, причины проверки и служебный идентификатор.
- используйте фактический сайт и его ключ, а не тестовый ID;
- передавайте стабильный идентификатор формы или инфоблока;
- сохраняйте исходный IP до запуска отложенной обработки;
- не смешивайте вердикт проверки с успешностью сохранения объекта.
1С-Битрикс
В Битрикс точка подключения зависит от того, чем создана форма: веб-формой, CRM-формой, компонентом или собственным обработчиком. Проверку следует выполнять на серверном событии до передачи обращения в основную очередь CRM.
Важно не менять ядро системы. Размещайте интеграцию в локальном модуле или проектном коде, журналируйте ошибки связи отдельно и задайте понятный сценарий на случай временной недоступности внешней проверки.
WordPress
В WordPress интеграция зависит от плагина форм: Contact Form 7, Gravity Forms, WPForms и другие предоставляют собственные фильтры и события. Код лучше оформить отдельным небольшим плагином, а не помещать в тему — тогда смена оформления не отключит защиту.
Проверяйте nonce и права штатными средствами WordPress, очищайте входные данные, а результат NoiseCut добавляйте в метаданные заявки или передавайте в CRM как отдельный статус.
Tilda
В Tilda форма часто отправляет данные во встроенный приёмник или напрямую во внешний сервис. Для полноценной серверной проверки нужен промежуточный обработчик: webhook поступает на ваш сервер, там выполняется анализ, после чего заявка маршрутизируется в CRM.
Не размещайте секретный ключ в JavaScript страницы. Подпись запроса и взаимодействие с NoiseCut должны оставаться на сервере. Если форма уже отправляет данные одновременно в несколько сервисов, убедитесь, что подозрительная заявка не успевает попасть в CRM по обходному маршруту.
Что делать при ошибке связи
Сетевой сбой не должен превращаться в незаметную потерю лидов. Заранее выберите политику: сохранить заявку с пометкой «не проверена», поставить её в очередь повторной проверки или передать менеджеру. Для большинства лид-форм безопаснее сохранить обращение и явно обозначить отсутствие вердикта.
Безопасный запуск
- Сначала включите режим наблюдения без автоматического удаления.
- Сохраняйте результат и причины рядом с заявкой.
- Сопоставляйте статусы с итогами звонков менеджеров.
- Проверяйте каждую форму и каждый маршрут отправки отдельно.
- Только после проверки автоматизируйте распределение обращений.
Такой подход помогает заметить нестандартные формы, фоновые обработчики и параллельные интеграции, которые иначе обходят единый фильтр.
Главное
Для всех четырёх CMS действует одно правило: анализ должен происходить на сервере, а результат — сопровождать заявку до CRM. Различается только место, где подключается обработчик.
Начните с инвентаризации форм, сохраните технический контекст исходной отправки и используйте отдельные статусы для реальных, подозрительных и непроверенных обращений. Общий подход к защите разобран также в статье о спам-заявках с сайта.