Как защитить формы Tilda от спам-заявок

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

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

Сначала определите, какой спам попадает в форму

Словом «спам» часто называют разные проблемы, а значит, и способы защиты будут отличаться.

Автоматические массовые отправки

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

Заявки с несуществующим или ошибочным номером

Посетитель или скрипт вводит комбинацию, которая проходит проверку формата, но по ней невозможно связаться. Маска телефона не решает эту задачу: она проверяет количество и расположение цифр, а не доступ к номеру.

Использование чужого номера

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

Повторные заявки одного пользователя

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

Атака на стоимость доставки

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

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

Почему CAPTCHA не закрывает задачу целиком

CAPTCHA отвечает на ограниченный вопрос: похож ли текущий посетитель на автоматический скрипт. Современные проверки делают это по поведению, токену или заданию. Но после успешного прохождения пользователь всё равно может ввести чужой телефон, допустить опечатку или несколько раз отправить одну форму.

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

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

Базовая многоуровневая защита формы Tilda

Практичная схема выглядит так:

1. Браузер проверяет обязательные поля и формат значений.
2. Защитный слой оценивает частоту и подозрительные признаки запроса.
3. Пользователь подтверждает телефон кодом.
4. Форма получает нормализованный результат проверки.
5. Только после успеха Tilda отправляет заявку.
6. CRM проверяет контакт на дубли и применяет бизнес-правило.
7. Журнал и аналитика помогают обнаружить аномалию.

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

Уровень 1. Проверяйте данные до создания заявки

Сделайте обязательными только действительно нужные поля. Чем сложнее форма, тем больше в ней нестандартных состояний и возможностей для неправильной отправки.

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

Проверка формата отсекает пустые значения и очевидные ошибки, но не подтверждает существование номера. Поэтому не помечайте такой контакт в CRM как проверенный.

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

Уровень 2. Подтверждайте телефон до отправки формы

Правильный порядок принципиален: сначала код, затем заявка. Если Tilda отправит данные до подтверждения, мусорный контакт уже окажется в CRM, а успешная или неуспешная проверка позже ничего не исправит.

В сценарии с VerifyBox форма передаёт номер и запрашивает проверку. VerifyBox создаёт сессию, генерирует код, применяет лимиты и проверяет ввод. Подключённый клиентом провайдер доставляет SMS или звонок. После успеха форма получает единый результат и разрешает финальную отправку.

Пошаговая настройка разобрана в инструкции «Как добавить подтверждение номера телефона в форму Tilda». До подключения можно посмотреть поведение в демо-модуле VerifyBox.

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

Уровень 3. Ограничивайте получение и ввод кода

Кнопка «Получить код» — отдельная публичная точка, которую тоже нужно защищать. Минимальный набор ограничений:

• пауза перед повторной отправкой;
• лимит запросов на один номер;
• лимит запросов на проект;
• максимальное число попыток ввода;
• срок действия кода;
• временная блокировка после серии ошибок.

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

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

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

Уровень 4. Не доверяйте успешному виду кнопки

Цвет, CSS-класс, скрытое поле и надпись «Номер подтверждён» существуют в браузере пользователя. Их можно изменить через инструменты разработчика. Бизнес-логика не должна принимать такое состояние как доказательство.

Для API-сценария результат проверки подтверждается на серверной стороне. Для Tilda используйте штатный контур интеграции: именно он должен разрешать отправку после нормализованного ответа VerifyBox. Не собирайте собственную «проверку» из смены класса и поля verified=true без защищённого подтверждения.

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

Уровень 5. Защитите финальную отправку

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

• блокировка кнопки на время запроса;
• идемпотентность или уникальный идентификатор заявки;
• защита от повторной отправки при обновлении страницы;
• понятный экран успеха;
• логирование результата передачи в CRM.

Не очищайте форму до того, как Tilda или ваш обработчик подтвердит приём данных. Иначе пользователь увидит успех, а заявка потеряется между сайтом и CRM.

Уровень 6. Настройте дедупликацию в CRM

Подтверждённый номер остаётся одним и тем же номером. Для повторов определите бизнес-правило заранее:

1. В коротком окне не создавать новую сделку, а добавить активность к существующей.
2. При повторном обращении через несколько дней открыть новую сделку, сохранив связь с контактом.
3. Для записи на событие запретить вторую активную бронь.
4. Для разных продуктов разрешить отдельные сделки с одним контактом.

Одного универсального правила нет. Но отсутствие правила почти гарантирует, что повторные клики превратятся в дубли.

Сохраняйте источник, страницу, рекламную кампанию и время подтверждения. Это поможет понять, пришёл ли повтор с того же экрана или клиент осознанно вернулся через другой канал.

Уровень 7. Наблюдайте за воронкой, а не только за лидами

Для диагностики полезно разделить события:

• форма показана;
• начато заполнение;
• запрошен код;
• код принят провайдером доставки;
• номер успешно подтверждён;
• форма отправлена;
• CRM приняла заявку;
• контакт признан дублем.

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

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

Как не потерять конверсию реальных пользователей

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

Практические правила:

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

Не обещайте «код придёт мгновенно»: оператор или провайдер может задержать доставку. Лучше сообщить, что отправка выполнена, и дать понятный путь для повтора после таймера. Если сообщения не приходят, используйте чек-лист диагностики кода подтверждения.

Безопасность и персональные данные

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

Никогда не записывайте одноразовый код:

• в URL страницы;
• в открытые события аналитики;
• в карточку CRM;
• в клиентские логи;
• в сообщения поддержки без необходимости.

Для диагностики достаточно идентификатора сессии, времени, проекта, канала и нормализованного статуса. Секреты интеграции также нельзя размещать в HTML Tilda.

План внедрения без резкого риска

Лучше запускать защиту поэтапно.

Этап 1. Измерение

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

Этап 2. Тестовая страница

Продублируйте форму, подключите тестовый проект VerifyBox и пройдите позитивные и негативные сценарии. Используйте актуальный код из открытой документации.

Этап 3. Ограниченный трафик

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

Этап 4. Рабочий запуск

Подключите платный тариф и провайдера, настройте лимиты и правила дублей. Актуальная модель для Tilda и API показана в разделе стоимости.

Этап 5. Корректировка

Через несколько дней проверьте, не блокируются ли реальные пользователи и не появился ли новый тип злоупотребления. Изменяйте один параметр за раз, чтобы понимать эффект.

Тесты, которые стоит пройти перед публикацией

Частые ошибки защиты форм

Добавить только сложную CAPTCHA

Сложное задание раздражает реальных посетителей, но не проверяет телефон и не удаляет дубли. Используйте CAPTCHA как один сигнал, а не как весь контур.

Разрешить бесконечный повтор кода

Это создаёт риск расходования баланса и жалоб получателей. Нужны серверные лимиты и прозрачный таймер.

Отправлять данные в CRM до проверки

Тогда цель не достигается: менеджер уже получил непроверенный контакт. Финальная передача должна происходить после успешного результата.

Блокировать один IP навсегда

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

Считать каждый повтор мошенничеством

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

Вопросы о защите форм Tilda

Можно ли полностью убрать спам из формы?

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

Достаточно ли подтверждения номера?

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

Что лучше: CAPTCHA или SMS-код?

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

Кто оплачивает SMS?

В рабочем сценарии SMS и звонки доставляет подключённый клиентом провайдер на его условиях. VerifyBox создаёт и проверяет код. Telegram через канал VerifyBox доступен на Business за 2,5 ₽ за отправку.

Где настраивать удаление дублей?

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

Итог

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

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