Чому заявок багато, а користі немає
Рахувати заявки за кількістю — самообман. Форма збирає все підряд: справжніх клієнтів, ботів, помилкові номери, спам із рекламою «просування» і відвертий фрод. Відділ продажів тоне у смітті, витрачає час на неіснуючі контакти і пропускає реальних клієнтів між рядками.
Якість важливіша за кількість: десять валідних заявок, за якими можна додзвонитися, кращі за сотню, де половина — «asdf» і +0000000. Добра новина: більшу частину сміття відсікають нескладні технічні заходи прямо на вході — до того, як заявка потрапить у CRM і до менеджера.
Види сміттєвих заявок
Щоб боротися прицільно, корисно розрізняти джерела сміття:
- Боти — автоматично заповнюють будь-які форми, які знаходять; дають сплеск безглуздих заявок.
- Спам-розсилки — реальні люди або напівавтомати, що пропонують «SEO», «трафік» та «інвестиції» через вашу ж форму.
- Помилкові дані — справжній інтерес, але одрук у телефоні чи email, через який зв'язатися неможливо.
- Фрод — навмисно неправдиві заявки: накрутка, злив бюджету конкурента, підміна даних.
Кожен тип лікується по-своєму, але майже все закривається трьома шарами: антибот, валідація даних і обмеження частоти.
Honeypot і антибот без капчі
Капча дратує і знижує конверсію — а більшість ботів ловляться і без неї. Найпростіший прийом — honeypot: приховане поле, невидиме людині, але помітне боту. Людина його не заповнить, а бот заповнить — і таку заявку мовчки відкидають. Нуль тертя для реального користувача.
Додатково допомагають перевірка часу заповнення (форма, надіслана за долі секунди, — майже напевно бот), токени проти автоматичних надсилань і фільтрація за вмістом. Це ті самі прийоми, що захищають форми від спаму загалом, і вони не псують досвід живому відвідувачу на відміну від капчі.
Валідація на клієнті та на сервері
Валідація — це два різні рубежі, і потрібні обидва.
- На клієнті — швидка підказка: підсвітити незаповнене поле, перевірити формат email, допомогти ввести телефон. Це про зручність, але покладатися на неї не можна — бот шле запит напряму, минаючи браузер.
- На сервері — обов'язкова перевірка: саме тут вирішується, прийняти заявку чи ні. Формат email, довжина полів, відсікання керуючих символів, санітизація — усе це робиться на бекенді, бо лише йому можна довіряти.
Правило просте: клієнтська валідація — для зручності, серверна — для безпеки. Форма без серверної перевірки вразлива, яким би акуратним не був фронтенд.
Перевірка телефону й email
Найбільше порожніх заявок — через неробочий телефон. Мінімальна перевірка ловить левову частку: привести номер до міжнародного формату E.164, визначити країну за кодом і переконатися, що довжина укладається в стандарт. Це відсікає одруки й завідомо невалідні номери ще до передачі менеджеру. Швидко перевірити один номер можна нашим інструментом перевірки телефону, а у формі — вбудувати таку саму логіку.
З email аналогічно: перевірка синтаксису відсікає грубі помилки, перевірка домену (чи є в нього поштові записи) — частину вигаданих адрес. Для важливих сценаріїв додають підтвердження за кодом або посиланням. Що раніше відсікається невалідний контакт, то чистіші дані в CRM.
Обмеження частоти і захист
Навіть пройшовши валідацію, форму можна завалити обсягом. Обмеження частоти (rate limiting) не дає одному джерелу надіслати сотні заявок: ліміт на IP і загальний ліміт на форму гасять і ботів, і спроби злити бюджет. Прийом той самий, що захищає від накруток партнерські та платіжні модулі.
Корисно вести список стоп-слів і підозрілих доменів, ховати реальну адресу форми за проксі на кшталт Cloudflare і логувати відхилені спроби — щоб бачити картину атак і підлаштовувати правила. Усе це працює тихо: справжній відвідувач нічого не помічає.
Як вимірювати якість лідів
Щоб покращувати якість, її треба вимірювати. Дивіться не на число заявок, а на частку валідних: скільки дійшло до розмови, скільки виявилося спамом, скільки — з неробочим контактом. Ця воронка показує, де втрачається сенс, і які заходи реально працюють.
Докладно про те, які метрики важливі і як не обманювати себе цифрами, ми писали у статті про вебаналітику і метрики сайту. А щоб якісних заявок було більше на вході, допомагає і сама структура форми та сторінки — про це в матеріалі про продавальний лендінг.
Часті запитання
Чи потрібна капча, щоб захиститися від ботів?
У більшості випадків ні. Honeypot, перевірка часу заповнення і серверна валідація ловлять переважну частину ботів, не дратуючи живих користувачів. Капча помітно знижує конверсію, тому її залишають на крайній випадок — за масових цільових атак.
Чому не можна обмежитися перевіркою в браузері?
Бо бот надсилає запит напряму, минаючи ваш фронтенд, — і будь-яка клієнтська перевірка для нього не існує. Клієнтська валідація потрібна для зручності людини, а рішення прийняти чи відхилити заявку завжди має ухвалюватися на сервері.
Як відсіяти заявки з неробочим телефоном?
Перевіряти формат номера: приводити до E.164, визначати країну за кодом і контролювати довжину. Це ловить одруки й завідомо невалідні номери. Глибша перевірка оператора і spam-ризику можлива через платні сервіси, але базова валідація формату вже сильно чистить потік.
Що робити зі спам-заявками від реальних людей?
Проти ручного спаму допомагають стоп-слова і фільтрація за вмістом, обмеження частоти і, за потреби, модерація. Повністю прибрати такий спам складно, але можна знизити його до одиниць і не пускати в основну воронку продажів.
Чи зіпсує захист досвід справжніх клієнтів?
Ні, якщо зробити його непомітним. Honeypot, серверна валідація і rate limiting не видні живому відвідувачу. Проблеми створює лише агресивна капча — тому її й варто уникати на користь тихих методів.
