Не только Google Ads: защита от скликивания в нишевых DSP, тизенных сетях и Push-трафике

Введение: Иллюзия безопасности за пределами гигантов

Современный ландшафт цифровой рекламы (Digital Ad Landscape) четко разделен на две неравные части: «Огороженные сады» (Walled Gardens) в лице экосистем Google и Meta, и так называемый Open Web — пространство открытого интернета, где господствуют технологии программатика (Programmatic), RTB (Real-Time Bidding), тизерные сети и Push-уведомления.

Если в первом случае рекламодатель находится под “зонтиком” многомиллиардных инвестиций платформы в защиту от фрода (Ad Fraud Protection), то выходя за пределы этих экосистем, вы попадаете на цифровую территорию «Дикого Запада». Здесь правила диктуют не единые стандарты качества, а сложнейшие цепочки поставок трафика, где каждый посредник заинтересован в объеме, но не всегда — в чистоте данных.

В этом введении мы деконструируем миф о том, что базовые настройки таргетинга спасут бюджет, и разберем, почему архитектура нишевых сетей (DSP, Native, Push) технически предрасположена к генерации Sophisticated Invalid Traffic (SIVT).

Проблема «слепых зон»: Почему стандартные решения здесь бессильны

Фундаментальная ошибка многих медиабайеров и технических директоров заключается в попытке перенести опыт работы с Google Ads (GAds) на альтернативные источники трафика. В GAds вы платите не только за клик, но и за колоссальную инфраструктуру пре-фильтрации. Google отсеивает до 90% General Invalid Traffic (GIVT) еще до того, как запрос на показ рекламы достигнет аукциона.

В нишевых DSP и тизерных сетях ситуация диаметрально противоположная по трем техническим причинам:

1. Фрагментация Supply Chain (Цепочки поставок):В отличие от прямой закупки, в RTB путь от паблишера (владельца сайта) до рекламодателя проходит через SSP (Supply-Side Platform), Ad Exchange и DSP. На каждом этапе («хопе») происходит обогащение данных, но также теряется прозрачность. Технология reselling (перепродажа инвентаря) позволяет «отмывать» трафик: ботнет генерирует показы на сайте-однодневке, который через цепочку реселлеров маскируется под премиальный инвентарь (Domain Spoofing).
2. Отсутствие единого арбитра:В Push-сетях и нативных (тизерных) платформах часто отсутствуют строгие стандарты проверки паблишеров, аналогичные ads.txt или sellers.json от IAB Tech Lab, которые стали стандартом в крупном программатике. Это создает «слепые зоны», где паблишер может безнаказанно использовать методы Click Injection или Iframe Stuffing.
3. Техническая природа форматов:Сами форматы (Push, Pop-under, Native) технически уязвимы. Например, Push-уведомления базируются на технологии Service Workers. Злоумышленники могут манипулировать подписками, отправляя “призрачные клики” (ghost clicks) напрямую на трекинговую ссылку без фактического взаимодействия пользователя с устройством, просто инициируя fetch запрос программно.

Важно: Стандартные системы аналитики (Google Analytics 4, Яндекс.Метрика) фокусируются на поведении пользователя, а не на технической валидации соединения. Они могут отфильтровать примитивных ботов, но спасуют перед эмуляторами на базе Puppeteer с прокачанными профилями (“прогретыми куки”).

Экономика фрода: Статистика и скрытые потери бизнеса

Мошенничество с рекламой — это не просто мелкое хулиганство, а высокоорганизованная индустрия с маржинальностью, превышающей торговлю наркотиками. Согласно отчетам Juniper Research, к 2028 году глобальные потери от Ad Fraud могут превысить $170 миллиардов. Однако для конкретного бизнеса, закупающего трафик в DSP или Push-сетях, эти цифры трансформируются в конкретные, болезненные метрики.

Потери можно классифицировать на два уровня:

Уровень 1: Прямые финансовые потери (Cash Drain)

Это бюджет, списанный за фейковые показы и клики. В агрессивных нишах (Crypto, Gambling, Nutra) в тизерных сетях доля бот-трафика может достигать 40–60% без использования сторонних трекеров и антифрод-систем.

• Пример: Вы покупаете Push-рассылку по модели CPC $0.10. Бот-ферма генерирует 10 000 кликов. Убыток — $1 000 чистого кэша за час.

Уровень 2: Отравление данных (Data Poisoning)

Это более опасная и долгосрочная угроза, о которой редко говорят.

• Искажение ML-моделей: Если вы используете авто-биддинг (smart bidding) или обучаете собственные ML-модели для предикта конверсий, фродовый трафик вносит “шум”. Алгоритмы начинают оптимизироваться под поведение ботов, считая их целевой аудиторией, что приводит к спирали неэффективности.
• Разрушение атрибуции: Атаки типа Click Spamming (генерация тысяч кликов в фоне) нацелены на перехват атрибуции органических установок (Organic Install Hijacking). Вы платите за пользователя, который и так бы установил ваше приложение.

Таблица 1.2: Сравнительная оценка риска фрода по каналам (Оценка экспертов 2024)

Цель статьи: Построение контура In-house защиты

В условиях, когда рекламные сети часто находятся в конфликте интересов (они зарабатывают на объеме трафика, даже если он “серый”), единственная жизнеспособная стратегия для технически подкованной компании — это подход Zero Trust (Нулевое доверие).

Данная статья не является маркетинговым обзором существующих SaaS-решений. Это техническое руководство (White Paper) для разработчиков, DevOps-инженеров и аналитиков данных. Мы ставим перед собой цель разобрать архитектуру защиты, которую можно развернуть на стороне рекламодателя (In-house).

В рамках материала мы детально разберем:

• Как реализовать Client-Side Fingerprinting для сбора энтропии браузера и выявления подмены параметров (Spoofing).
• Как анализировать TCP/IP стек на уровне сервера для выявления несоответствий между User-Agent и реальными сетевыми пакетами (Passive OS Fingerprinting).
• Какие метрики (Time-to-Click, Mouse Velocity) действительно указывают на нечеловеческое поведение.

Мы уйдем от абстрактных понятий к конкретике: примерам кода на Python и JavaScript, разбору HTTP-заголовков и анализу логов веб-сервера. Если вы готовы взять контроль над качеством трафика в свои руки и перестать оплачивать счета ботнетов — этот гайд для вас.

Архитектура и рынок CFaaS: Взгляд изнутри подпольной индустрии

Понятие Click Fraud as a Service (CFaaS) возникло как логический ответ на усложнение систем защиты Google Ads, Meta Ads и других гигантов. Сегодня это не просто набор скриптов, а полноценная сервисная модель с техподдержкой 24/7, API-интеграцией и регулярными обновлениями, обходящими паттерны безопасности. CFaaS – это высокодоходный, масштабируемый бизнес, работающий по принципам DevOps, но нацеленный на мошенничество.

Экономика и бизнес-модели подпольных площадок

Рынок CFaaS — это теневая экономика, которая использует публичные и закрытые площадки для транзакций. Продажа услуг фрода сегментирована на несколько уровней в зависимости от сложности атак и целей заказчика (конкурентное скликивание, накрутка CPA/CPI, монетизация некачественного трафика).

Основные торговые площадки сосредоточены в Darknet (форумы типа Exploit или XSS), а также, что более опасно, в специализированных закрытых SaaS-платформах и приватных Telegram-каналах, куда доступ осуществляется только по инвайтам.

Основные модели монетизации CFaaS:

• «Клик-пакеты» (PPC-модель): Заказчик покупает определенное количество кликов (от 1000 до 100 000) по конкретным ключевым словам, объявлениям конкурентов или партнерским ссылкам. Цена варьируется от $10 до $500 за 1000 кликов в зависимости от сложности ГЕО (трафик из США, Канады, Западной Европы стоит дороже из-за более высокого CPM/CPC) и типа устройства (мобильный трафик дороже десктопного).
• Аренда инфраструктуры (SaaS-подписка): Клиент получает доступ к веб-панели управления (Control Panel) — аналогу рекламного кабинета. Через эту панель он сам настраивает параметры атаки: время запуска, интенсивность, паттерны поведения, ротацию User-Agent’ов, а главное — целевые URL и рефереры.
• Партнерские программы (Affiliate Fraud): Владельцы мусорных сайтов или недобросовестные арбитражники покупают бот-трафик на свои площадки, чтобы искусственно завышать метрики (количество показов, CTR) и получать максимальные выплаты от рекламных сетей (AdSense, Media.net и др.), используя так называемый Domain Spoofing (подмену домена).

Техническая инфраструктура: Анатомия ботнета нового поколения

Современная архитектура CFaaS строится на трех критически важных столпах: управляющий узел (C&C Server), транспортный уровень (прокси) и движок имитации пользователя (Browser Engine).

Двигатели имитации (Browser Engines)

Для генерации кликов, которые способны выполнить сложный JavaScript и пройти проверку на рендеринг, больше не используются простые HTTP-запросы. В основе лежат браузеры на базе Chromium или Gecko (Firefox), работающие в режиме headless (без графического интерфейса), но полностью имитирующие реальный рендеринг страницы.

• Puppeteer и Playwright: Это стандарты индустрии автоматизации. Сами по себе они легко детектируются, поэтому CFaaS используют кастомные сборки с плагинами типа puppeteer-extra-plugin-stealth, которые вносят тысячи микроскопических изменений в window и navigator объекты, чтобы скрыть флаги автоматизации (см. Главу 4).
• Антидетект-браузеры: Профессиональные инструменты (например, Dolphin, Multilogin) позволяют программно изменять сотни параметров отпечатка браузера: от версии ядра и заголовков HTTP до установленных шрифтов, WebGL параметров и часового пояса. Это позволяет одному ботнету генерировать трафик, который выглядит как сотни тысяч уникальных устройств.

Транспортный уровень: Резидентные и мобильные прокси

Это критически важный компонент, обеспечивающий «легитимность» IP-адреса. Если запросы исходят из дата-центра (помеченные ASN — Autonomous System Number), любая система антифрода их заблокирует. Поэтому CFaaS активно используют:

1. Residential Proxies (Резидентные прокси): IP-адреса реальных домашних провайдеров (ISP). Они получаются путем внедрения вредоносного или, чаще, «серого» SDK в бесплатные мобильные приложения или десктопные утилиты, которые неявно используют трафик пользователя для редиректа. Эти IP имеют высокое Доверие (Trust Score).
2. Mobile Proxy (4G/LTE): Самый дорогой и эффективный тип. Поскольку тысячи реальных пользователей могут иметь один и тот же внешний IP (из-за механизма CGNAT — Carrier-Grade Network Address Translation), системы защиты не могут блокировать такие адреса, чтобы не отсечь легальных пользователей целого оператора. Боты здесь используют быструю ротацию IP.

Таблица 3: Сравнительный анализ эффективности прокси для CFaaS

Технический стек: Реализация «невидимости»

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

1. Синтез поведения (Human-like behavior): Вместо мгновенного клика бот выполняет последовательность действий, моделируя когнитивные процессы человека:
   • Плавный скроллинг страницы с переменной скоростью и случайными микро-остановками.
   • Движение курсора по сложным кривым Безье (без идеальных прямых линий), имитируя дрожание руки.
   • Time-to-Click Latency: Использование задержек (waitForTimeout) между загрузкой страницы, скроллингом и финальным кликом, имитирующих время, необходимое человеку для прочтения объявления.
2. Эмуляция аппаратного обеспечения и Fingerprinting: С помощью JavaScript-инъекций и плагинов подменяются сотни параметров, которые используются для идентификации устройства:
   • Canvas & WebGL Spoofing: Внесение минимального шума в выходные данные рендеринга, чтобы создать уникальный и «чистый» отпечаток.
   • Подмена Device/OS Info: Манипуляция значениями navigator.hardwareConcurrency, deviceMemory и screen.width/height для соответствия реалистичной конфигурации (например, iPhone 15 Pro Max).

Пример кода: Псевдокод “Human-like Interaction” в CFaaS

Этот фрагмент демонстрирует, как в современных инструментах имитируются сложные, нелинейные движения:

Python

# Псевдокод: Имитация движения мыши с использованием кривых
def move_mouse_humanlike(browser_instance, target_x, target_y):
    start_x, start_y = browser_instance.mouse.position 
    # Генерация контрольных точек для кривой Безье
    control_point_1 = (start_x + random.randint(50, 200), start_y - random.randint(50, 200)) 
    control_point_2 = (target_x - random.randint(50, 200), target_y + random.randint(50, 200))

    # Рассчитать и выполнить движение по сегментам (steps)
    for t in range(0, 100, 5): # Движение за 20 шагов
        # Формула кубической кривой Безье
        x = calculate_bezier_x(t/100, start_x, control_point_1[0], control_point_2[0], target_x)
        y = calculate_bezier_y(t/100, start_y, control_point_1[1], control_point_2[1], target_y)
        browser_instance.mouse.move_to(x, y)
        time.sleep(random.uniform(0.01, 0.05)) # Небольшие случайные задержки

    browser_instance.click(target_x, target_y)
    # Задержка после клика, имитирующая ожидание загрузки
    time.sleep(random.uniform(1.0, 3.5)) 

Интеграция с сервисами обхода CAPTCHA и репутационным менеджментом

Для поддержания высокого уровня «доверия» ботнеты интегрируются с внешними сервисами:

• Обход CAPTCHA: Если рекламная площадка или целевой сайт выбрасывает CAPTCHA (reCAPTCHA v3, hCaptcha), сервисы CFaaS автоматически используют API-интеграцию с крупными решателями капч. Здесь задействуется либо Human-in-the-loop (реальные операторы решают CAPTCHA за доли цента), либо продвинутые ML-модели для автоматического распознавания простых задач, получая валидный токен доступа.
• Репутация профилей (Cookie Farming): Перед началом целевой атаки на рекламный баннер, бот может быть «прогрет» — он посещает несколько легитимных сайтов (Google, Wikipedia, новости), собирает куки и историю, чтобы выглядеть как пользователь, который не пришел «из ниоткуда».

Совет эксперта: Поиск скрытых флагов автоматизации в окружении window — это первое, что должна делать ваша клиентская антифрод-библиотека. Проверки типа if (window.navigator.webdriver)или наличие глобальных переменных, характерных для Puppeteer или Selenium, часто позволяют отсеять ботов, которые не использовали или плохо настроили stealth-плагины.

Технический стек детектирования: Методы и алгоритмы

Эффективная защита от фрода в RTB и Push-сетях не может строиться на одной «серебряной пуле». Боты эволюционируют: они научились исполнять JavaScript, сохранять куки и даже имитировать движения мыши. Поэтому архитектура современной Anti-Fraud системы должна быть многослойной (Defense in Depth).

Мы разделим наш стек детектирования на три уровня:

1. Client-Side: Сбор данных непосредственно в браузере пользователя (активный фингерпринтинг).
2. Server-Side: Анализ сетевых пакетов и аномалий трафика (пассивный анализ).
3. Behavioral Biometrics: Анализ кинематики взаимодействия пользователя со страницей.

Клиентский анализ (Client-Side Detection): Сбор цифрового слепка

В основе клиентского детектирования лежит концепция Browser Fingerprinting. Мы собираем сотни параметров браузера и устройства, чтобы создать уникальный идентификатор (Hash) и сверить его с заявленными характеристиками. Если User-Agent говорит, что это iPhone, а GPU рендеринг выдает драйверы Windows, перед нами бот.

Выявление Headless-браузеров (Puppeteer, Selenium, Playwright)

Большинство ботов построено на базе Headless Chrome (без графического интерфейса). Несмотря на попытки разработчиков скрывать это (пакеты типа puppeteer-extra-plugin-stealth), существуют фундаментальные признаки автоматизации.

Ключевые векторы проверки:

1. Свойства Navigator:
   • navigator.webdriver: Стандарт W3C, который обязан быть true, если браузером управляет скрипт. Боты часто пытаются перезаписать это свойство через Object.defineProperty, но это можно отловить через проверку прототипов.
   • navigator.plugins и navigator.languages: У “голых” ботов эти массивы часто пусты или содержат дефолтные значения (например, только en-US для якобы пользователя из СНГ).
2. Canvas Fingerprinting:Мы просим браузер отрисовать невидимый текст с наложением слоев и смайликов. Из-за различий в GPU, драйверах видеокарт и алгоритмах сглаживания (anti-aliasing) на разных ОС, бинарный результат отрисовки будет отличаться.
   • Признак фрода: Уникальность хеша Canvas составляет 100% (уникален для каждого запроса) — признак рандомизации параметров (Canvas Noise), либо хеш совпадает с известными сигнатурами Linux-серверов.
3. Проверка прав доступа (Permissions API):Многие Headless-браузеры некорректно обрабатывают запрос прав на notifications (уведомления) в контексте несоответствия состояния granted/denied и реального поведения.

Пример JS-кода для сбора “отпечатков” и детектирования ботов:

Этот скрипт должен загружаться асинхронно в <head> вашего лендинга.

JavaScript

(function() {
    const fraudScore = {
        score: 0,
        flags: []
    };

    // 1. Проверка на автоматизацию (WebDriver)
    // Проверяем не просто наличие свойства, а его поведение
    const isHeadless = () => {
        if (navigator.webdriver) return true;
        // Проверка на наличие специфичных свойств Chrome, которые пропадают в headless
        if (window.chrome && !window.chrome.runtime) {
             // Часто встречается в старых версиях Puppeteer
        }
        // Проверка User-Agent на наличие слов 'Headless'
        if (/HeadlessChrome/.test(navigator.userAgent)) return true;
        return false;
    };

    if (isHeadless()) {
        fraudScore.score += 100;
        fraudScore.flags.push('HEADLESS_BROWSER_DETECTED');
    }

    // 2. Проверка разрешения экрана и глубины цвета
    // Боты часто имеют 0x0 или стандартные серверные разрешения (800x600, 1024x768) без панелей инструментов
    const checkScreen = () => {
        const width = screen.width;
        const height = screen.height;
        const availWidth = screen.availWidth;
        const availHeight = screen.availHeight;
        
        // Если доступная высота равна полной высоте (нет таскбара) на десктопной ОС - подозрительно
        if (width === availWidth && height === availHeight && !/Mobile/.test(navigator.userAgent)) {
            fraudScore.score += 20;
            fraudScore.flags.push('FULLSCREEN_NO_TASKBAR');
        }
        
        if (screen.colorDepth < 24) {
             fraudScore.score += 50;
             fraudScore.flags.push('LOW_COLOR_DEPTH');
        }
    };
    checkScreen();

    // 3. Canvas Fingerprinting (Упрощенный пример)
    const getCanvasHash = () => {
        try {
            const canvas = document.createElement('canvas');
            const ctx = canvas.getContext('2d');
            ctx.textBaseline = "top";
            ctx.font = "14px 'Arial'";
            ctx.textBaseline = "alphabetic";
            ctx.fillStyle = "#f60";
            ctx.fillRect(125,1,62,20);
            ctx.fillStyle = "#069";
            ctx.fillText("AdFraud_Check_Win88", 2, 15);
            ctx.fillStyle = "rgba(102, 204, 0, 0.7)";
            ctx.fillText("AdFraud_Check_Win88", 4, 17);
            
            // Получаем Data URI и хешируем его
            const dataURI = canvas.toDataURL();
            // ... здесь должна быть функция хеширования (например, MurmurHash3) ...
            return dataURI.length; // Для примера возвращаем длину
        } catch (e) {
            return 0;
        }
    };
    
    // Отправка данных на сервер для анализа
    const payload = {
        score: fraudScore,
        canvasLength: getCanvasHash(),
        timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
        hardwareConcurrency: navigator.hardwareConcurrency // Кол-во ядер CPU
    };
    
    // Используем Beacon API для гарантированной отправки даже при закрытии страницы
    navigator.sendBeacon('/api/fraud-check', JSON.stringify(payload));

})();

Серверный анализ (Server-Side Analysis): Пассивный фингерпринтинг OS

Если JS можно обмануть или заблокировать, то подделать сетевой стек TCP/IP гораздо сложнее. Это требует прав root на машине, генерирующей трафик, и пересборки ядра ОС, что слишком дорого для массовых ботнетов.

TCP/IP Stack Fingerprinting (p0f)

Каждая операционная система устанавливает свои значения по умолчанию для параметров TCP-пакета при инициации соединения (SYN packet).

Анализируя эти параметры на уровне Load Balancer (например, Nginx или HAProxy), мы можем определить реальную ОС.

Ключевые параметры для анализа:

• TTL (Time To Live): Обычно 64 для Linux/Mac/Android и 128 для Windows.
• Window Size: Размер окна TCP. У Windows и Linux характерные паттерны изменения размера окна.
• TCP Options: Порядок и наличие опций (MSS, SACK, Timestamp).

Логика детекции:

Если в HTTP-заголовке User-Agent указано Windows 10, а входящий пакет имеет TTL=64 и порядок опций, характерный для Linux Kernel 5.x — это 100% фрод. Скорее всего, это Node.js скрипт, запущенный на сервере, или проксирование через Linux-роутер.

Анализ временных меток (Time-to-Click & Velocity)

В RTB и Push-рекламе критически важен анализ времени.

1. Time-to-Click (TTC): Время от показа объявления (impression) до клика.
   • < 500ms: Человек физически не способен распознать визуальный образ и нажать на него быстрее ~300-400мс. Клики быстрее 500мс в Display-рекламе — это случайные клики или боты.
   • Распределение: Если построить график времени кликов, у людей это логнормальное распределение. У ботов — либо равномерное (Random), либо резкие пики (Spikes) на определенных секундах (таймеры скриптов).
2. Click Injection Check: Для мобильного трафика. Если клик происходит до того, как загрузились ресурсы объявления (срабатывание события onload рекламного контейнера), это инъекция клика.

Поведенческие биометрики (Behavioral Biometrics)

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

Движение мыши (Mouse Tracking)

Боты либо не двигают мышью вовсе (телепортация курсора: координаты (0,0) -> (X,Y) за 0 мс), либо используют библиотеки для эмуляции движений (например, GhostCursor для Puppeteer).

Что отличает человека:

• Энтропия (Дрожание): Курсор человека никогда не движется по идеальной прямой. Всегда есть микро-колебания.
• Кривые Безье: Даже если бот использует кривые Безье для сглаживания, он часто делает это математически идеально. Человек же меняет скорость (Acceleration/Deceleration) — разгоняется в начале и замедляется перед кликом, чтобы “прицелиться”.

Touch-события (Для мобильных устройств)

В мобильном вебе клик мыши (mousedown/mouseup) эмулируется. Реальное взаимодействие — это touchstart -> touchmove (опционально) -> touchend.

Признаки фрода в Touch-интерфейсе:

1. Отсутствие Radius/Force: Реальный палец имеет площадь (свойство touch.radiusX / touch.radiusY) и силу нажатия (force). У эмуляторов эти значения часто равны 0 или 1 (константны).
2. Идеальное позиционирование: Тапы всегда происходят в геометрический центр кнопки. Человек обычно мажет и тапает ближе к краю, который удобнее для большого пальца.
3. Ghost Clicks (Push-специфика): Если сервер фиксирует переход (HTTP request), но JS на странице не регистрирует ни одного события touchstart в первые секунды загрузки — это “призрачный клик”, сгенерированный программно без открытия браузера пользователем.

Резюме раздела:

Эффективный детектор — это скоринговая модель. Мы не блокируем пользователя по одному признаку (кроме явных, типа Headless). Мы суммируем баллы:

• Странный Canvas (+20 баллов)
• Несоответствие TCP/IP и User-Agent (+50 баллов)
• Клик быстрее 200мс (+30 баллов)
• Итог: 100 баллов = Блокировка и пометка источника как Fraud.

Практическая реализация: Код и архитектура

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

В этом разделе мы реализуем два уровня защиты: «минное поле» на фронтенде (Honey-Pots) и тяжелую артиллерию на бэкенде (анализ ASN и логов).

Создание Honey-Pots (Ловушек для ботов)

Honey-Pot («Горшочек с медом») в веб-разработке — это элемент, который специально создан, чтобы приманить бота. Логика проста: боты-парсеры сканируют DOM-дерево и взаимодействуют с элементами (ссылками, формами) программно, часто игнорируя CSS-стили, отвечающие за видимость.

Если пользователь кликнул по ссылке, которую физически невозможно увидеть на экране — это бот.

Невидимые ссылки и поля (The Invisible Trap)

Самая распространенная ошибка — скрывать ловушки через display: none или visibility: hidden. Современные парсеры (Smart Crawlers) умеют определять вычисленные стили (getComputedStyle) и игнорируют такие элементы.

Правильная реализация (Best Practice):

Мы используем методы, которые формально оставляют элемент в потоке документа (DOM flow), но делают его недоступным для визуального контакта и случайного клика мышью.

Пример HTML/CSS реализации:

HTML

<form action="/submit-lead" method="POST">
    <input type="text" name="username" required placeholder="Ваше имя">
    
    <div class="hp-wrapper">
        <input type="text" name="extra_email_field" id="hp_input" tabindex="-1" autocomplete="off">
    </div>

    <button type="submit">Отправить</button>
</form>

<style>
/* CSS для скрытия ловушки */
.hp-wrapper {
    position: absolute;
    left: -9999px; /* Выносим за пределы экрана */
    top: -9999px;
    opacity: 0;      /* Делаем полностью прозрачным */
    width: 0;
    height: 0;
    overflow: hidden; /* Гарантируем, что контент не вылезет */
    z-index: -1;      /* Убираем под основной контент */
}
</style>

Логика обработки на сервере (Backend):

Если сервер получает POST-запрос, в котором заполнено поле extra_email_field, запрос немедленно сбрасывается, а IP-адрес отправителя заносится в Blacklist на 24 часа. Важно: Не возвращайте ошибку 403 сразу. Лучше вернуть код 200 (OK), чтобы бот «думал», что отправка прошла успешно. Это называется Tarpitting (замедление или обман атакующего).

Проблема доступности (Accessibility / a11y)

Жесткое скрытие элементов может навредить пользователям с ограниченными возможностями, использующим скринридеры (Screen Readers, например, NVDA или VoiceOver). Скринридер может прочитать скрытое поле, и слепой пользователь честно его заполнит, попав в бан.

Решение: Используйте атрибуты ARIA и tabindex.

• tabindex="-1": Исключает поле из навигации по клавише Tab.
• aria-hidden="true": Указывает скринридерам игнорировать этот элемент.
• Добавьте <label> с текстом: “Если вы человек, оставьте это поле пустым”. Это последний рубеж защиты от ложноположительных срабатываний.

Анализ IP-адресов и ASN: Data Science против ботнетов

Блокировка по конкретному IP-адресу в 2025 году малоэффективна: мобильные операторы используют NAT (один IP на тысячи абонентов), а ботнеты ротируют IP каждые несколько запросов.

Эффективная защита строится на анализе ASN (Autonomous System Number) и поведенческих паттернов подсетей. Нам нужно отделить “жилых” провайдеров (ISP) от хостингов (Hosting/DataCenter).

Источники данных (GeoIP Databases)

Для обогащения данных необходимо использовать базы типа MaxMind GeoIP2 или IP2Location. Нас интересуют поля:

• connection_type: (Cable/DSL, Corporate, Cellular, Hosting).
• autonomous_system_organization: Название владельца сети (Amazon, Google Cloud, DigitalOcean, Rostelecom).

Правило блокировки: Трафик из тизерной сети или DSP никогда не должен приходить с IP-адресов облачных хостингов (AWS, Azure, Hetzner, Leaseweb). Это 100% аномалия. Реальные люди сидят через мобильных операторов (MNO) или домашних провайдеров (ISP).

Анализ логов с помощью Python и Pandas

Ниже приведен пример скрипта для анализа Access-логов веб-сервера (Nginx/Apache). Скрипт выявляет аномалии: высокую частоту кликов (Velocity) и концентрацию трафика в подозрительных подсетях.

Задача: Найти подсети (/24), генерирующие много кликов, но 0 конверсий.

Python

import pandas as pd
import numpy as np
import ipaddress
import re

# Настройка отображения
pd.set_option('display.max_columns', None)
pd.set_option('display.width', 1000)

def parse_nginx_log(log_path):
    """
    Парсер логов (упрощенный regex для Nginx combined format)
    Извлекает: IP, Timestamp, User-Agent, Request URL, Status Code
    """
    log_pattern = re.compile(
        r'(?P<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) - - \[(?P<timestamp>.*?)\] '
        r'"(?P<method>\w+) (?P<uri>.*?) HTTP/1.1" (?P<status>\d+) .*? "(?P<user_agent>.*?)"'
    )
    
    data = []
    with open(log_path, 'r') as f:
        for line in f:
            match = log_pattern.match(line)
            if match:
                data.append(match.groupdict())
    
    df = pd.DataFrame(data)
    df['timestamp'] = pd.to_datetime(df['timestamp'], format='%d/%b/%Y:%H:%M:%S %z')
    return df

def analyze_fraud(df):
    print("--- Начало анализа фрода ---")

    # 1. Обогащение данных (имитация получения ASN и Subnet)
    # В реальном коде здесь используется библиотека geoip2
    df['subnet_24'] = df['ip'].apply(lambda x: '.'.join(x.split('.')[:3]) + '.0/24')
    
    # 2. Расчет Velocity (Скорость кликов)
    # Сортируем по IP и времени, считаем дельту времени между соседними запросами
    df = df.sort_values(by=['ip', 'timestamp'])
    df['time_diff'] = df.groupby('ip')['timestamp'].diff().dt.total_seconds()
    
    # ФЛАГ 1: "Пулеметчик". Более 5 запросов с интервалом < 1 секунды
    rapid_fire_ips = df[df['time_diff'] < 1.0].groupby('ip').size()
    suspicious_ips_velocity = rapid_fire_ips[rapid_fire_ips > 5].index.tolist()
    print(f"Выявлено IP с аномальной скоростью: {len(suspicious_ips_velocity)}")

    # 3. Кластерный анализ подсетей (Subnet Analysis)
    # Группируем по подсетям класса C (/24)
    subnet_stats = df.groupby('subnet_24').agg({
        'ip': 'count',          # Всего кликов
        'user_agent': 'nunique' # Уникальных User-Agents
    }).rename(columns={'ip': 'total_clicks', 'user_agent': 'unique_ua'})

    # ФЛАГ 2: "Низкая энтропия". 
    # Много кликов с подсети, но мало уникальных устройств (или наоборот, слишком много - ротация UA)
    # В данном примере ищем подсети, где на 100+ кликов приходится всего 1-2 уникальных UA
    subnet_stats['ua_diversity_ratio'] = subnet_stats['unique_ua'] / subnet_stats['total_clicks']
    
    fraud_subnets = subnet_stats[
        (subnet_stats['total_clicks'] > 50) & 
        (subnet_stats['ua_diversity_ratio'] < 0.05) # Менее 5% разнообразия
    ]
    
    print("\n--- Подозрительные подсети (Low Entropy) ---")
    print(fraud_subnets.sort_values(by='total_clicks', ascending=False).head(5))

    return suspicious_ips_velocity, fraud_subnets.index.tolist()

# Пример использования (Закомментирован для статьи)
# df = parse_nginx_log('access.log')
# banned_ips, banned_subnets = analyze_fraud(df)
# export_to_firewall(banned_ips)

Разбор алгоритма:

1. Velocity Check: Мы ищем IP-адреса, которые делают запросы с нечеловеческой скоростью (интервал менее 1 секунды). Это характерно для простых скриптов (curl/requests), которые не имитируют задержки чтения («think time»).
2. Subnet Entropy: Мы смотрим не на отдельный IP, а на всю подсеть. Если с подсети 192.168.1.0/24 пришло 1000 кликов, но все они имеют одинаковый User-Agent (или всего два варианта), это признак того, что вся подсеть контролируется одним ботоводом, использующим один и тот же профиль браузера.

Архитектура обработки данных (Pipeline)

Для высоконагруженных проектов (HighLoad), где трафик измеряется миллионами хитов в сутки, анализ “на лету” внутри PHP/Python бэкенда может замедлить отдачу контента. Необходима асинхронная архитектура.

Рекомендуемый стек:

1. Nginx/OpenResty (L7 Edge): Первый рубеж. Блокирует по GeoIP (отсекает страны не из таргета) и простым сигнатурам User-Agent (пустые UA, curl, python-requests).
2. Application (Collector): Скрипт приема трафика (Tracker). Собирает данные, запускает JS-фингерпринтинг, отдает пиксель. Данные о визите не пишутся в БД напрямую.
3. Message Queue (Kafka / RabbitMQ): Данные о клике («сырое событие») летят в очередь. Это обеспечивает минимальную задержку ответа пользователю (Latency).
4. Analytical Engine (ClickHouse): ClickHouse идеально подходит для хранения логов рекламы. Он позволяет выполнять SQL-запросы по миллиардам строк за миллисекунды.
5. Fraud Detection Service (Python/Go): Воркер, который раз в минуту читает данные из ClickHouse, агрегирует их по правилам (описанным выше) и формирует списки блокировок.
6. In-Memory Cache (Redis): Списки заблокированных IP/SubID выгружаются в Redis, к которому обращается приложение при каждом новом входе.

Резюме раздела:

Практическая защита — это баланс между точностью и производительностью. Honey-pots отсеивают примитивных ботов бесплатно (не нагружая БД). Глубокий анализ логов через Python позволяет выявлять сложные паттерны (кластеры IP, временные аномалии), которые не видны в реальном времени.

Сравнительный анализ: Особенности защиты по каналам (Таблицы)

Универсального антифрод-решения не существует, потому что техническая природа взаимодействия пользователя с рекламой в DSP, тизерных сетях и Push-уведомлениях кардинально различается. То, что является аномалией для баннера (например, CTR 10%), может быть нормой для качественного Push-уведомления. И наоборот: отсутствие Referrer-заголовка — норма для SSL-переходов, но критический маркер фрода для RTB-аукциона.

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

Таблица 1: Матрица угроз и методов защиты

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

Специфика защиты в Push-трафике: Работа с токенами и TTL

Push-трафик требует особого внимания, так как это единственный формат, где доставка рекламы и клик могут быть разнесены во времени на часы.

A. Валидация токенов (Token Sanity Check)

Многие рекламные сети продают клики от “мертвых” подписчиков. Ботнет хранит базу старых токенов и эмулирует клики от их имени.

• Решение: Если у вас есть доступ к токенам (в случае сбора своей базы), регулярно проводите “сухую” проверку (Dry Run) через API Firebase Cloud Messaging (FCM) или Apple Push Notification Service (APNs). Если API возвращает ошибку NotRegistered или InvalidRegistration, то любой клик с этого ID — фрод.

B. Анализ времени жизни клика (Click TTL Analysis)

У реальных пользователей распределение времени реакции на пуш (Time to Click) подчиняется закону логнормального распределения:

1. Пик кликов приходится на первые 1–5 минут после рассылки.
2. Далее идет длинный “хвост” (до 24 часов).
3. Аномалия: Если вы видите равномерное распределение кликов в течение 24 часов (например, ровно 100 кликов в час) — это работа скрипта (Cron Job), который “размазывает” нагрузку, чтобы не вызывать подозрений.

Специфика защиты в DSP: Supply Chain Transparency

В RTB главная проблема — непрозрачность цепочки реселлинга.

• Объект schain: В спецификации OpenRTB 2.5+ появился объект supplyChain. Он показывает всех посредников, через которых прошел запрос.
• Анализ: Если в цепочке более 3-4 узлов, вероятность фрода возрастает экспоненциально. Каждый посредник “размывает” данные. Настройте DSP на покупку инвентаря только с короткими цепочками (direct или 1 посредник).

Таблица 2: Пороговые значения для автоматической блокировки (Thresholds)

Эту таблицу можно использовать для настройки автоматических правил (Rules Engine) в вашей системе аналитики или трекере (Keitaro, Binom, Voluum).

Важно: Приведенные цифры являются ориентировочными для “серых” ниш (Crypto, Nutra, Gambling). Для белого E-commerce пороги могут быть строже.

Стратегия работы с Black/White листами

Блокировка — это не разовое действие, а процесс.

1. Уровень площадки (SubID/PlacementID): Это основная единица блокировки. Если площадка превысила пороги из Таблицы 2 — она летит в Blacklist навсегда.
2. Уровень приложения (BundleID): Часто одно приложение генерирует фрод через разные SubID. Блокируйте весь Bundle.
3. White-listing: В агрессивных сетях (особенно Push и Native) стратегия “блокировать плохое” менее эффективна, чем “разрешать только хорошее”. После тестового пролива (Test Run) выделите 10-20% площадок, дающих конверсии, добавьте их в Whitelist и выкупайте оттуда трафик с повышенной ставкой, отключив остальные.

Стратегии блокировки и оптимизации бюджета

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

Ключевой вопрос: когда и как именно блокировать трафик?

Pre-bid vs Post-bid фильтрация: Где сэкономить?

Существует два основных подхода к фильтрации трафика в программатике, которые также применимы к CPC-моделям в тизерных и Push-сетях:

Pre-bid фильтрация (До ставки/клика)

Это самый эффективный, но и самый сложный метод.

• Механика: Система Anti-Fraud принимает решение о качестве трафика до того, как вы совершите ставку (в RTB) или прежде, чем клик будет зарегистрирован и перенаправлен на лендинг (в Push/Teasers).
• Критерии блокировки: Используются только самые надежные и быстрые проверки, не требующие исполнения JavaScript:
  • Блокировка по ASN/IP (дата-центры, VPN-выходы).
  • Блокировка по Blacklist (ранее заблокированные PublisherID, SubID, BundleID).
  • Блокировка по Header Mismatch (например, пустой или заведомо фродовый User-Agent).
• Преимущество: Полная экономия бюджета. Вы не платите ни копейки за показ, клик или инсталл. Это оптимально для RTB.
• Недостаток: Высокий риск ложноположительных срабатываний (False Positives). Если заблокировать слишком много, вы рискуете отсечь реальных пользователей.

Post-bid фильтрация (После ставки/клика)

• Механика: Трафик разрешен к переходу, но на целевой странице (лендинге) запускаются тяжелые проверки (JS-фингерпринтинг, поведенческий анализ). Только после того, как все проверки завершены, принимается решение о фиксации конверсии.
• Критерии блокировки: Используются медленные, но точные проверки:
  • Canvas/WebGL фингерпринтинг.
  • Анализ движения мыши и Touch-событий.
  • Проверка Honey-Pots.
• Преимущество: Максимальная точность. Вы минимизируете риск ложноположительных срабатываний.
• Недостаток: Увеличение затрат. Вы платите за клик, даже если он оказался фродовым. Однако, этот клик не попадет в вашу статистику конверсий, и вы сможете запросить Refund (возврат средств) у рекламной сети.

Оптимальная стратегия:

Используйте гибридную схему: Pre-bid для 100% известных фродовых источников (Blacklist, Datacenter IP) и Post-bid для тонкой, поведенческой оценки, с последующей отправкой Postback-уведомления о фроде.

Настройка Postback для передачи статуса fraud

Postback — это обратное уведомление, которое ваш трекер или Anti-Fraud система отправляет рекламной сети. Это ключевой элемент оптимизации.

Схема работы:

1. Пользователь кликает в рекламной сети. Сеть передает вам уникальный идентификатор клика (ClickID или SubID).
2. Ваша система Anti-Fraud анализирует клик.
3. Если клик признан чистым, вы отправляете стандартный Postback с информацией о конверсии.
4. Если клик признан фродовым, вы отправляете специализированный Postback (или S2S-запрос) обратно в сеть, помечая этот ClickID как Invalid.

Что дает Postback о фроде:

• Обучение алгоритмов: Рекламная сеть может исключить фродовые источники из своего алгоритма оптимизации, переставая покупать трафик у этих паблишеров (если сеть технически поддерживает такой фидбек).
• Доказательная база: У вас фиксируется timestamp, когда сеть получила уведомление о недействительном клике. Это критически важно для дальнейшего диспута о возврате средств.

Создание Black/White листов: Автоматизация и пороговые значения

Самая частая ошибка: ручное ведение списков. В высокоскоростном Programmatic-трафике списки должны обновляться автоматически.

Динамический Blacklisting (Бан по PublisherID)

Вместо того чтобы банить IP-адреса, баньте источники, которые их поставляют.

Правила автоматического занесения в Blacklist (Пример):

1. Показатель конверсии (CR): Если PublisherID сгенерировал более 500 кликов, а CR (Conversion Rate) ниже 0.01% (один на 10 000) при среднем по кампании 1%, занести в Blacklist.
2. Показатель отклика JS: Если с PublisherID пришло 1000 кликов, и более 80% не выполнили JS-фингерпринтинг (браузер закрыт, JS отключен или это просто curl), занести в Blacklist.
3. Поведенческий скоринг: Если суммарный Anti-Fraud Score за последние 24 часа превысил 500 баллов, занести в Blacklist.

White-listing (Лучшая практика для агрессивных сетей)

В тизерных и Push-сетях, где уровень фрода изначально высок, стратегически выгоднее работать по Whitelist-модели.

1. Тестовый период (Discovery Phase): Закупайте трафик широко, но с минимальной ставкой, фиксируя все метрики.
2. Сегментация: Определите топ-5% PublisherID, которые дали хотя бы одну реальную конверсию с высоким LTV (LifeTime Value).
3. Изоляция: Выделите эти площадки в отдельную кампанию (Whitelist Campaign).
4. Усиление: Поднимите ставку только для этих площадок (Bid Optimization) и исключите их из всех автоматических проверок на Pre-bid уровне (так как они уже доказали свою чистоту).

Экспертный совет: В Whitelist-кампаниях можно использовать более агрессивные креативы, так как вы уверены в лояльности и чистоте источника. Это способ максимизировать доход с самых ценных паблишеров.

Оптимизация бюджета через регулирование ставок (Bid Optimization)

Фильтрация — это только защита. Оптимизация — это рост.

1. Bid Down (Снижение ставки): Для источников, которые имеют “пограничный” Anti-Fraud Score (т.е. они не чистые, но и не 100% боты). Вместо блокировки, снизьте ставку на 50%. Пусть эти паблишеры конкурируют за низкую цену. Если они продают трафик за копейки, это может быть приемлемо.
2. Bid Up (Повышение ставки): Для площадок, которые стабильно дают высокий LTV и имеют Fraud Score = 0. Здесь вы конкурируете за объем и готовы платить премию за качество.

Пример автоматического правила Bid Optimization:

• IF Fraud_Score > 40 AND Conversion_Rate > 0.5% THEN Bid = Bid * 0.5 (Снизить ставку, но оставить трафик, если есть конверсии).
• IF Fraud_Score = 0 AND Conversion_Rate > 2% THEN Bid = Bid * 1.2 (Повысить ставку за премиальный трафик).

Правильно настроенные стратегии блокировки и оптимизации превращают вашу систему Anti-Fraud из простого “выключателя” в мощный инструмент управления ROI (Return on Investment).

Юридические и технические нюансы возврата средств (Refunds)

Если Pre-bid фильтрация защищает ваш бюджет, то процесс возврата средств (Refund) позволяет минимизировать потери, понесенные из-за трафика, пропущенного Post-bid фильтром. Этот процесс редко бывает простым: рекламные сети, по своей природе, не заинтересованы в автоматическом возврате денег. Вы должны предоставить неопровержимые технические доказательства мошенничества.

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

Как доказать рекламной сети, что трафик был фродовый

Для успешного диспута ваша доказательная база должна соответствовать трем ключевым требованиям: Актуальность, Детализация и Согласованность.

Актуальность (Timestamp Consistency)

• Проблема: Если вы обнаружили фрод через неделю после покупки, сеть может заявить, что за это время трафик мог “испортиться” или стать жертвой атак на ваш сайт.
• Требование: Ваша Anti-Fraud система должна фиксировать обнаружение фрода в течение 24–48 часов после клика. Если вы использовали Postback о фроде (см. п. 6.2), это уведомление является решающим доказательством вашей оперативности.

Детализация (Granularity)

Вы не можете предоставить сети просто список ClickID и сказать: “Это фрод”. Вы должны объяснить почемукаждый клик является мошенническим.

Минимальный набор данных для каждого фродового клика:

1. ClickID / SubID: Уникальный идентификатор, полученный от сети.
2. Timestamp: Время клика по UTC.
3. Fraud Score: Общий балл (например, 150/100).
4. Flags Triggered (Сработавшие флаги): Перечисление конкретных технических причин, например:
   • HEADLESS_BROWSER_DETECTED (Flag 100)
   • TCP_UA_MISMATCH (Flag 50)
   • NO_MOUSE_MOVEMENT (Flag 30)

Согласованность (Third-Party Validation)

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

• GeoIP / ASN: Включите в отчет данные GeoIP от общепризнанных провайдеров (MaxMind, IP2Location), показывая, что трафик пришел с IP-адресов, помеченных как Hosting/DataCenter.
• Public Blocklists: Сверьте IP-адреса с публичными списками (например, Spamhaus, VirusTotal) и укажите в отчете, если IP-адрес уже был помечен как источник спама или ботнета.

Подготовка технических логов: Шаблон для диспута

Ваш лог-файл (или выгрузка из ClickHouse) должен быть структурирован для максимальной убедительности. Создайте сводный отчет, а затем предоставьте детальный лог по конкретным фродовым площадкам.

Шаблон сводного отчета (Summary Report)

Этот отчет должен быть кратким и четким, фокусируясь на объеме потерь по каждому источнику.

Детальный лог (Detailed Proof)

Для каждой фродовой площадки в отчете должны быть предоставлены 50–100 примеров (для статистики) с полным набором технических данных, которые доказывают мошенничество.

Пример строки в детальном логе (JSON или CSV):

JSON

{
  "click_id": "ABCDEF1234567890",
  "timestamp_utc": "2025-12-15T14:30:00Z",
  "fraud_score": 120,
  "ip_address": "88.204.10.5",
  "asn_org": "Amazon Data Services Ireland",
  "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36...",
  "fraud_reasons": [
    "ASN_TYPE_HOSTING",
    "CANVAS_HASH_MISMATCH", 
    "ZERO_MOUSE_EVENTS" 
  ],
  "time_to_click_ms": 150,
  "was_honey_pot_hit": false
}

Составление диспута (Chargeback Request)

После того как техническая база собрана, необходимо составить грамотное обращение.

1. Официальное уведомление: Отправьте электронное письмо в отдел качества (Quality Assurance, QA) или юридический отдел сети (не в поддержку менеджера). Тема должна быть формальной: “Dispute: Invalid Traffic Claim for Campaign [ID] – Period [Dates]”.
2. Ссылка на стандарты: Ссылайтесь на общепризнанные отраслевые стандарты, такие как MRC (Media Rating Council) определения GIVT/SIVT или спецификации IAB Tech Lab. Укажите, что трафик нарушает пункт “Non-Human Traffic” в их собственном пользовательском соглашении.
3. Предложение по решению: Требуйте возврата средств, а не перезапуска трафика. Четко укажите сумму.
4. Приложение: Прикрепите Сводный отчет и предоставьте защищенную ссылку на скачивание Детального лога (например, CSV-файл на S3 или Google Drive с ограничением доступа).

Совет по ведению переговоров: Не запрашивайте 100% возврата сразу. Начните с честного показателя, например, 70% от списанной суммы. Это оставляет пространство для компромисса и увеличивает шансы на быстрое урегулирование.

Официальный отказ: Если сеть отказывает, требуйте письменного объяснения, почему они считают ваши технические доказательства недействительными. Этот ответ можно использовать для дальнейшего обращения к независимому арбитру (например, IAB, если сеть является членом).

Юридическая перспектива: Условия оферты

Процесс возврата средств всегда регулируется Условиями предоставления услуг (Terms of Service, ToS) или Офертой рекламной сети.

• Изучите пункты: Найдите раздел, касающийся Invalid Clicks, Non-Human Traffic или Fraud.
• Сроки претензий: Большинство сетей устанавливают жесткие сроки (например, 7 или 14 дней) для предъявления претензий. Нарушение этого срока — законное основание для отказа.

Вывод:

Отдел Anti-Fraud должен работать в тесной связке с финансовым и юридическим отделами. Технические логи — это финансовый документ. Их чистота, детализация и своевременность подачи определяют ваш успех в возврате десятков и сотен тысяч долларов, потерянных на ботах.

Заключение: Будущее борьбы с фродом

Мы проанализировали архитектуру угроз и построили многоуровневую систему защиты. Наш стек включает: Pre-bid фильтры, Honey-Pots, сложный Client-Side Fingerprinting и глубокий Post-bid анализ логов.

Роль Machine Learning в выявлении аномалий (Unsupervised Learning)

Построение правил (IF CTR > 15% THEN BLOCK) всегда будет запаздывать. Боты меняют паттерны быстрее, чем мы успеваем обновлять правила.

Будущее Anti-Fraud — в Unsupervised Machine Learning (Обучение без учителя).

1. Кластеризация (Clustering): ML-модель обучается на “чистом” трафике и создает кластеры “нормального” поведения (например, Кластер 1: iOS, Safari, Германия, Высокая скорость прокрутки).
2. Обнаружение аномалий (Anomaly Detection): Любой новый визит, который не попадает ни в один из существующих кластеров, или находится на значительном расстоянии от них, помечается как аномалия.
   • Пример: Поток трафика, где все пользователи имеют одинаковое значение hardwareConcurrency и нулевое смещение Canvas, но разные IP, будет объединен в “Ботовой Кластер 7” и автоматически заблокирован, даже если такого паттерна не было в вашей базе правил.

Чек-лист: 10 шагов для защиты вашей кампании прямо сейчас

1. Внедрите Client-Side Fingerprinting: Сбор отпечатков Canvas, WebGL и проверка navigator.webdriver.
2. Настройте Honey-Pots: Добавьте невидимые поля-ловушки на все формы.
3. Анализируйте ASN: Блокируйте IP-адреса дата-центров (AWS, Google Cloud) в DSP и тизерных сетях.
4. Контролируйте TTC: Установите порог 200–500 мс для блокировки моментальных кликов.
5. Верифицируйте Referrer: В RTB и Push-трафике, где реферер часто отсутствует, используйте ClickID и Timestamp для проверки валидности.
6. Включите Postback о фроде: Настройте S2S-уведомление сети о недействительных кликах.
7. Автоматизируйте Blacklisting: Создайте правила, которые банят PublisherID на основе пороговых значений (Таблица 2).
8. Переходите на Whitelist: Сосредоточьтесь на выкупе трафика только с доказано качественных площадок.
9. Сохраняйте все логи: Храните сырые логи (RAW logs) не менее 30 дней для диспутов.
10. Проводите аудит: Раз в квартал пересматривайте свои правила, так как боты постоянно меняются.

Список источников и полезных материалов

1. IAB Tech Lab: OpenRTB Specification, Version 2.6 – Основа протокола для DSP и SSP, детальное описание объекта bidrequest.

7. W3C (World Wide Web Consortium): WebDriver Specification (navigator.webdriver) – Официальный стандарт для обнаружения автоматизации браузера.
8. MDN Web Docs: HTML Canvas API Documentation – Техническое описание работы с Canvas для фингерпринтинга.
9. MDN Web Docs: WebGL API Documentation – Описание API для выявления GPU-признаков (для дополнительного фингерпринтинга).
10. MDN Web Docs: Service Workers API – Техническая основа для понимания механизма Push-уведомлений и атак типа Ghost Clicks.
11. Github: Headless detection libraries (e.g., Puppeteer-Extra Stealth Plugin repository) – Репозиторий для изучения методов маскировки ботов.
12. p0f (Passive OS Fingerprinting): Official Project Documentation – Инструмент и методология для пассивного анализа TCP/IP стека.

14. Cloudflare: Understanding the Anatomy of Bot Attacks – Обзор современных векторов атак (Spoofing, Injection).

19. Python Pandas Library: Official Documentation – Инструмент для анализа больших объемов данных (логов) на стороне сервера.
20. IP2Location: IP-Geolocation and ASN Data Services – Коммерческий поставщик баз данных для определения типа соединения (Hosting vs ISP).
21. MaxMind: GeoIP2 Databases (ASN and Connection Type) – Основной поставщик гео-данных, используемый в Anti-Fraud индустрии.
22. Google: Firebase Cloud Messaging (FCM) API Documentation – API для проверки статуса токенов Push-подписки.
23. Apple: APNs (Apple Push Notification Service) Documentation – API для работы с iOS Push-токенами.
24. Nginx: Http Access Log Module Documentation – Детализация логгирования для серверного анализа.
25. ClickHouse: Official Documentation and SQL Dialect – Высокопроизводительная СУБД для хранения и анализа рекламных логов.

27. Kaggle/Academic: Anomaly Detection with Isolation Forest – Примеры использования ML-алгоритмов для обнаружения аномальных кластеров трафика (Unsupervised Learning).

Похожие публикации:

10 статистических фактов, подтверждающих, что вам нужна защита от скликивания

Проверенные методы защиты от скликивания рекламы на Google Ads

Как защитить кампании в Google Ads от скликивания

Будущее скликивания рекламы: как AI-боты изменят правила игры в Google.Ads и Яндекс.Директ

Автоматические стратегии Google Ads: Помогут ли они защититься от скликивания?

Google Ads vs Facebook Ads: что лучше для вашего бизнеса в 2023 году?

Google Ads vs. Facebook Ads: какой лучший выбор для вашего бизнеса?

Контрольные показатели Google Ads и Microsoft Ads для каждой отрасли промышленности