Коли рекламодавець вирішує захиститися від ботів, перше питання зазвичай технічне: «Блокувати за IP чи ставити скрипт на сторінку?» Це два різні способи дивитися на візит. Блокування за IP оцінює, звідки прийшов запит. JavaScript-перевірка оцінює, що за програма його надіслала. Кожен підхід має свою сліпу зону, і саме тому серйозний захист не обирає, а поєднує їх.
Далі розбираємо, як працює кожен підхід, що він ловить добре, де помиляється і як налаштувати їхню спільну роботу, щоб не втратити швидкість сторінки.
Блокування за IP: як воно працює
Сервер отримує запит і знає про нього небагато: IP-адресу, заголовки браузера, адресу сторінки, з якої прийшли. Але з IP можна дізнатися чимало корисного:
- кому належить мережа: домашній провайдер, мобільний оператор, хостинг, хмара (за номером автономної системи, ASN);
- країну й місто з точністю, якої вистачає для гео-фільтра;
- позначки в базах: відомий VPN, проксі, Tor, адреса зі спам-пасток;
- історію: скільки разів ця адреса вже приходила і чим це закінчувалося.
Рішення ухвалюється до того, як сторінку віддано відвідувачу. Це головна перевага підходу: він нічого не коштує за швидкістю й працює навіть проти програм, які не вміють виконувати скрипти.
Що ловить блокування за IP
- Серверних ботів. Більшість дешевих ботів, парсерів і сканерів працюють у дата-центрах. Блок за ASN хостингу прибирає їх майже без помилок. Детальніше в статті VPN, проксі та IP дата-центрів.
- Відомі VPN і серверні проксі. Їхні адреси регулярно потрапляють у бази.
- Адреси, що повторюються. Ліміт кліків з одного IP і чорний список IP відсікають набридливих візитерів і конкурента, який клікає з офісу.
- Чуже гео. Клік із країни, на яку ви не таргетувалися, майже ніколи не покупець.
Слабкі місця блокування за IP
- Резидентні й мобільні проксі. Бот виходить у мережу через адресу домашнього абонента або SIM-картку оператора. Для фільтра за IP це звичайна людина. Цьому присвячена окрема стаття: резидентні та мобільні проксі.
- Спільні адреси. За однією мобільною адресою сотні абонентів, за офісною десятки співробітників. Блок такої адреси відсікає живих.
- Ротація. Бот, який змінює адресу на кожен клік, обходить ліміти частоти й чорні списки.
- Запізнення баз. Нова адреса потрапляє в базу за години чи дні, і за цей час встигає зробити свою справу.
- Немає погляду всередину. IP нічого не каже про те, браузер це чи скрипт, чи є в нього екран і чи рухається миша.
JavaScript-перевірка: як вона працює
Сторінка віддає відвідувачу невеликий скрипт. Він виконується в браузері й збирає те, що видно лише зсередини:
- ознаки автоматизації: прапорець
webdriver, сліди інструментів керування браузером, характерні для headless-режиму особливості; - відбиток пристрою: екран, відеокарта, шрифти, перелік можливостей браузера;
- налаштування системи: часовий пояс, мова, розкладка;
- узгодженість: чи збігається те, що заявляє заголовок
User-Agent, з тим, що браузер уміє насправді; - поведінку: рухи миші й пальця, прокручування, час до першої дії.
Скрипт надсилає результат на сервер, сервер ухвалює рішення. Як влаштований відбиток і де його підробляють, розповідаємо в статті headless-браузери та відбиток браузера.
Що ловить JavaScript-перевірка
- Програми без браузера. Парсери й прості боти, які завантажують сторінку, але не виконують скрипт, не повернуть відповіді взагалі. Це сильна ознака.
- Headless-браузери та автоматизацію. Навіть на резидентній адресі бот на керованому браузері залишає сліди.
- Підробку пристрою. «iPhone» із серверною відеокартою та екраном 1920×1080 видає себе суперечністю.
- Розбіжність мережі й системи. IP з Німеччини, а пояс і мова азійські. Мережа цього не бачить, скрипт бачить.
- Механічну поведінку. Рівні рухи, миттєвий вихід, клік без жодного руху перед ним.
Слабкі місця JavaScript-перевірки
- Час. Скрипт треба завантажити, виконати й дочекатися відповіді сервера. Це затримка, якої блокування за IP не має.
- Не всі візити її виконують. Вбудовані браузери соцмереж іноді вантажать сторінку у фоні й заморожують таймери; старі телефони виконують скрипт повільно; частина людей іде раніше, ніж перевірка закінчилася.
- Її можна підробити. Дані приходять від клієнта, отже просунутий бот може їх підмінити. Антидетект-браузери для цього й створені.
- Хибні спрацювання на незвичних пристроях. WebView у застосунках, браузери з посиленою приватністю, розширення, що блокують відбиток: усе це схоже на «підробку», хоча за екраном людина.
- Залежність від місця встановлення. Скрипт працює лише там, де він стоїть. Якщо посилання веде на сторінку без скрипту, перевірки не буде.
Порівняння підходів
| Блокування за IP | JavaScript-перевірка | |
|---|---|---|
| Коли вирішує | до віддачі сторінки | після завантаження скрипту |
| Вплив на швидкість | майже немає | десяті частки секунди |
| Серверні боти | ловить чудово | ловить, але пізніше й дорожче |
| Боти на резидентних і мобільних IP | майже не бачить | бачить за браузером і поведінкою |
| Програми без JavaScript | ловить, лише якщо адреса серверна | ловить за відсутністю відповіді |
| Підробка | адресу підміняють проксі | дані підміняють антидетект-браузери |
| Головний ризик помилки | спільні адреси, широкі блоки | WebView, приватні браузери, повільні телефони |
Таблиця добре показує головне: слабкі місця двох підходів майже не перетинаються. Те, чого не бачить мережа, бачить браузер, і навпаки.
Чому їх поєднують
Якщо поставити лише блокування за IP, крізь фільтр пройде весь фрод на резидентних і мобільних адресах, а це якраз найдорожча його частина: кліки виглядають як живі й оплачуються за повною ціною. Якщо поставити лише скрипт, кожен серверний бот отримуватиме сторінку, завантажуватиме скрипт і навантажуватиме сервер, а прості боти, що не виконали перевірку, будуть невідрізненні від людей, які не дочекалися завантаження.
Робоча схема виглядає так:
- Мережа як перший шар. Жорстко відсікаються дата-центри, відомі боти, адреси з чорного списку й чуже гео. Це дешево, швидко й майже без помилок.
- Браузер як другий шар. Усе, що пройшло мережу, перевіряє скрипт: автоматизацію, відбиток, пояс і мову, поведінку.
- Оцінка довіри замість заборон. М'які сигнали (позначка про проксі, мобільна адреса, розбіжність поясу, відсутність мітки кліку) не блокують візит самі по собі, а складаються. Рішення ухвалюється за сумою.
- Статистика за джерелом як третій погляд. Навіть найкраща перевірка одного візиту не замінить погляду на майданчик загалом: частка підозрілих візитів, конверсії, апрув. Саме так видно кліки з ферм і систематичний фрод у рекламі.
Так помилки складаються на користь рекламодавця: живу людину з VPN не відріже одна ознака, а бот на домашній адресі не пройде лише тому, що адреса чиста.
Як це впливає на швидкість сторінки
Швидкість важлива не лише для зручності: кожна зайва секунда завантаження знижує конверсію, і захист, що відлякує покупців, обходиться дорожче за ботів. Що можна зробити:
- Вирішувати мережеве заздалегідь. Поки браузер вантажить скрипт, сервер уже може перевірити IP, ASN і бази. На момент, коли скрипт надішле дані, половина рішення готова.
- Маленький скрипт і одне з'єднання. Що менше запитів і що ближче сервер до відвідувача, то коротше очікування. Стиснений скрипт і повторне використання з'єднання заощаджують десятки мілісекунд на мобільному інтернеті.
- Не чекати поведінку там, де вона не потрібна. Перевірка рухів миші вимагає, щоб відвідувач щось зробив на сторінці. Її вмикають для суворих джерел, а не для всього трафіку.
- Відсікати серверних ботів до скрипту. Якщо бота відсіяно за мережею, йому не потрібно віддавати скрипт: це економить ресурси сервера й робить статистику чистішою.
- Вимірювати. Дивіться на час від кліку до показу сторінки на реальних візитах, а не на лабораторний замір на швидкому комп'ютері.
Підсумок щодо швидкості: за розумної реалізації комбінована перевірка додає до завантаження частки секунди. Це помітно менше, ніж губиться на важких картинках і сторонніх лічильниках, і незрівнянно дешевше за оплачені кліки ботів.
Приклад: три візити очима двох шарів
Щоб побачити, як підходи доповнюють один одного, розберемо три кліки за однією кампанією з таргетингом на Німеччину.
Візит А. Адреса хмарного хостингу у Франкфурті, заголовок браузера: свіжий Chrome на Windows. Мережевий шар відсікає візит одразу: мережа хостингу в рекламному трафіку означає сервер, а не покупця. Скрипт навіть не знадобився, сторінку не віддавали, сервер не витратив ресурсів.
Візит Б. Адреса домашнього провайдера в Мюнхені, у базах чисто, мітка кліку на місці. За мережею придратися нема до чого. Скрипт повідомляє: прапорець автоматизації ввімкнено, відеокарта програмна, часовий пояс America/New_York, рухів миші до кліку не було. Блокування за IP пропустило б цей візит, і ви заплатили б за нього як за живий. Браузерний шар його зупиняє.
Візит В. Мобільна адреса німецького оператора, позначена як спільна, вбудований браузер соцмережі, пояс Europe/Berlin, мова німецька. Скрипт виконався із затримкою, бо застосунок вантажив сторінку у фоні. Якби фільтр різав мобільні адреси або вимагав миттєвої відповіді скрипту, цього покупця було б втрачено. Оцінка довіри бачить, що ознаки узгоджені, і пропускає візит.
У цьому прикладі кожен шар окремо помилився б хоча б раз: сама мережа пропустила б візит Б, а жорсткий скрипт без оцінки довіри ризикував відсікти візит В. Разом вони розібрали всі три правильно. На реальному потоці так само: більшу частину сміття знімає дешевий мережевий шар, браузерний добирає те, що замасковано під людей, а сума ознак страхує від зайвих відмов.
Де перевірка не потрібна або шкодить
- Сторінки без платного трафіку. Якщо на сторінку не веде реклама, сувора перевірка браузера частіше заважає, ніж допомагає.
- Джерела, де майже весь трафік іде через вбудований браузер. Там варто пом'якшити вимоги до виконання скрипту й спиратися на оцінку довіри.
- Пошукові роботи на основному сайті. Захищати варто посадкові сторінки кампаній, а не весь сайт із SEO-трафіком. Детальніше про вибір у статті антибот для сайту.
Як це влаштовано в ArtisanClo
ArtisanClo використовує обидва шари: мережеві перевірки відсіюють трафік дата-центрів, VPN і проксі, а перевірка браузера ловить автоматизацію й підробку пристрою на адресах, які за мережею виглядають чистими. Кожен клік у журналі має код причини рішення, тож одразу видно, що спрацювало: мережа чи браузер. Вбудований трекер рахує витрати, конверсії, прибуток і ROI за кампаніями, тому видно, скільки грошей пішло на сміттєвий трафік і яке джерело його приносить. Усі перевірки перелічено на сторінці можливостей.
Коротко
Блокування за IP і JavaScript-перевірка відповідають на різні питання: «звідки прийшов візит» і «що за програма його надіслала». Перше швидке, дешеве й надійне проти серверних ботів, але сліпе до проксі на домашніх і мобільних адресах. Друга бачить браузер зсередини, але коштує часу, підробляється просунутими ботами й помиляється на незвичних пристроях. Їхні слабкі місця майже не перетинаються, тому мережу ставлять першим шаром, браузер другим, м'які ознаки складають в оцінку довіри, а підсумок перевіряють статистикою за джерелами. Як порахувати, у що обходяться пропущені боти, читайте в статті скільки бюджету втрачається на ботах.
