Вопросы о защите заявок.
Нормальные ответы.

Представьте охранника перед входом в CRM. Форма сайта передаёт заявку SafeLead. Система проверяет несколько признаков: капчу, скрытые ловушки, скорость заполнения, источник отправки и наличие контакта. Подозрительная заявка останавливается. Нормальная идёт дальше в системы клиента.

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

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

Нет. SafeLead может использовать Yandex SmartCaptcha или другой captcha-токен как один из слоёв. Но идея шире: несколько серверных проверок собираются в единый фильтр перед конечными системами клиента.

Это проверка, которую нельзя просто выключить в браузере. Заявка приходит на серверный endpoint SafeLead, и сервер решает, пропускать её дальше или нет. Только после успешной проверки запрос отправляется в CRM, Домопланер, Битрикс, webhook или другую систему клиента.

Это невидимое обычному посетителю поле. Человек его не видит и не заполняет. Простой бот часто пытается заполнить все поля формы и сам выдаёт себя. На сервере заполненная ловушка становится причиной отклонить заявку. Такой слой называется honeypot, но клиенту не нужно разбираться в термине — важна логика.

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

Обещать 100% навсегда было бы нечестно. Боты меняются, а некоторые имитируют поведение человека. Задача SafeLead — существенно усложнить автоматическую отправку, отсечь массовый мусор несколькими уровнями и вести понятные логи причин блокировки.

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

В системы самого клиента: CRM, Домопланер, Битрикс24, AmoCRM, webhook, email или другой API. SafeLead не должен менять привычный процесс продаж. Он лишь ставит фильтр перед ним.

Нет. Сайт safelead.ru — витрина услуги и инструмент проверки. Для клиента разворачивается свой экземпляр SafeLead Core. Клиентские заявки не должны идти через публичный сайт SafeLead.

В инфраструктуре, согласованной с клиентом: например, Yandex Cloud Functions / Serverless, VPS клиента или другой сервер клиента. Конкретная схема зависит от сайта и существующих интеграций.

Да. Типовая схема: раньше Tilda отправляла форму прямо в CRM или webhook. После установки Tilda отправляет её в endpoint SafeLead Core клиента. Core проверяет заявку и затем передаёт чистую заявку в прежнюю систему.

В passthrough-режиме задача SafeLead — сохранить привычный формат заявки настолько, насколько это возможно. Имя, телефон, email, комментарий, UTM, tildaspec-поля и нужные cookies не должны удаляться без причины. Перед отправкой дальше убираются в основном служебные поля защиты.

Есть два основных варианта. Если раньше форма уходила в Битрикс через webhook, SafeLead может после проверки повторить привычный запрос. Если используется REST API, Core аккуратно сопоставляет поля: имя, телефон, email, комментарий и UTM — с полями Битрикс24.

Webhook Домопланера убирается из публичной настройки формы и хранится в серверном конфиге Core. Tilda отправляет заявку в SafeLead Core клиента. После успешной проверки Core передаёт почти тот же webhook-запрос в Домопланер клиента.

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

Секретные ключи, закрытые webhook, OAuth-токены и API-ключи должны храниться только на сервере в конфиге клиентского экземпляра Core. В HTML или Tilda допустимы публичный sitekey капчи, endpoint Core и обычные поля формы, но не серверные секреты.

Он безопасно анализирует открытые данные сайта: ищет формы, попапы, капчу, признаки скрытых ловушек, прямые внешние обработчики, CRM/аналитику и возможные ранние рекламные цели. Бесплатный режим не отправляет тестовые заявки и не называет недоказанную защиту «работающей».

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

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

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