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

Фильтрацию общего недействительного трафика стройте сами, а обнаружение сложного покупайте у вендора верификации, если только не можете позволить себе собственную команду по борьбе с фродом. Общий недействительный трафик, например известные адреса дата-центров, заявленные боты и невидимые объявления 1x1, ловится списками и правилами. Ваши инженеры могут применять их, когда приходит запрос, и ещё раз в логах. Для сложного недействительного трафика, например захваченных устройств и поддельных приложений, нужны данные с гораздо большего объёма трафика, чем видит одна платформа, и аналитики, которые его изучают. Программы сертификации, такие как у TAG, тоже ждут фильтрации квалифицированной третьей стороной.

Что считается недействительным трафиком?

Media Rating Council (MRC) — американская организация, которая аккредитует измерение рекламы. Её стандарт Invalid Traffic Detection and Filtration Standards Addendum (обновление июня 2020 года, прочитано 27 октября 2026 года, как и остальные источники здесь) делит недействительный трафик на два вида. Общий недействительный трафик, или GIVT, — это «трафик, выявляемый рутинными способами фильтрации с помощью списков или других стандартизованных проверок параметров». Среди примеров MRC:

• Известный недействительный трафик из дата-центров
• Боты, пауки и другие краулеры
• Запросы от небраузерных user agent или неизвестных браузеров
• Страницы, загруженные или отрисованные заранее, которые потом не увидел ни один реальный пользователь
• Невидимые размещения, например объявления размером 0x0 или 1x1 пикселей

Сложный недействительный трафик, или SIVT, охватывает «более трудные для обнаружения ситуации, для анализа и выявления которых нужны продвинутая аналитика, сопоставление и координация из нескольких точек, значительное участие людей и т. п.». Среди примеров MRC:

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

Какие фильтры могут построить наши собственные инженеры?

Общий вид задуман одинаковым для всех. MRC пишет, что фильтрация GIVT «должна быть единообразной у разных вендоров», поэтому она опирается на общие списки. Команда внутри компании работает с двумя из них:

• IAB/ABC International Spiders & Bots List, который Alliance for Audited Media ведёт от имени IAB Tech Lab
• Data Center IP List, который Trustworthy Accountability Group (TAG) выпускает каждый месяц

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

Для измерительных компаний, которые проверяет MRC, она задаёт отправную точку по трафику дата-центров. Они должны отфильтровывать недействительный трафик с IP-адресов «трёх крупнейших известных хостинг-компаний: Amazon AWS, Google и Microsoft». Исключения нужны, чтобы реальные пользователи, выходящие в интернет через эти сети, не отсеивались по ошибке.

Фильтровать можно в два момента. Заранее платформа блокирует рекламный запрос или отказывается делать по нему ставку. Позже она удаляет недействительные события из логов и подсчётов. MRC пишет: «У каждого подхода есть свои сильные и слабые стороны, и обоим есть место в хорошо выстроенной стратегии защиты трафика». Ранняя блокировка ещё и экономит на обработке запроса, который потом всё равно выбросили бы.

Списки теряют силу, когда браузеры и приложения передают меньше данных. В обновлении 2024 года MRC сформулировала это так: «Ограниченный IP-адрес или его отсутствие и менее детальная строка User Agent (UA) могут ослабить подходы на основе списков».

Когда стоит платить вендору верификации?

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

Сертификация может решить вопрос за вас. Программа TAG Certified Against Fraud называет одним из ключевых требований, чтобы «100% монетизируемых транзакций фильтровались для выявления и удаления IVT квалифицированной третьей стороной». TAG позволяет паблишерам выполнить его через supply-side платформу с действующим сертификационным знаком. Если ваши покупатели или партнёры просят сертификацию TAG, одних фильтров, построенных своими силами, для этого требования не хватит.

MRC публикует список сервисов, которые она аккредитует. В её цифровом списке есть компании верификации, такие как DoubleVerify, HUMAN, Integral Ad Science, Pixalate и Protected Media. Аккредитация распространяется на конкретные сервисы и метрики, поэтому спросите вендора, какие из его сервисов аккредитованы и входит ли туда сложный недействительный трафик.

Строить, покупать или совмещать: что покрывает каждый путь?

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

Что платформа должна записывать в логи при любом пути?

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

• Тип события, ID транзакции и временную метку
• IP-адрес, включая заголовок X-Forwarded-For, когда трафик идёт через прокси
• Полную строку user agent и тип устройства
• Идентификатор приложения или полный URL страницы, где показали объявление
• ID паблишера, сайта и размещения, а также данные ads.txt или app-ads.txt паблишера
• Атрибуты OpenRTB из запроса на ставку

Сырые и отфильтрованные цифры в отчётах нужно держать отдельно. Для отчётов по кампаниям стандарт MRC перечисляет «Gross Metrics (Completely Unfiltered)» и «Net Metrics (Filtered for GIVT Requirements)». Там, где это применимо, цифры с фильтрацией сложного недействительного трафика идут отдельным шагом. Если ваш конвейер событий уже теряет события или считает их дважды, сначала исправьте это: фильтрация не исправит цифры, которые были неверны до неё.

Что спросить у фирмы, которая встраивает фильтрацию в нашу платформу?

• Где в пути ставки работает каждый фильтр и сколько времени он добавляет к запросу?
• Если проверка вендора не ответила вовремя, запрос проходит или отбрасывается?
• Как обновляются списки и кто проверяет, что реальных пользователей не отсекают по ошибке?
• Как валовые и отфильтрованные цифры будут выглядеть в наших отчётах и в отчётах наших партнёров?
• Какие поля каждого запроса хранятся, как долго и по каким правилам приватности?

Последний вопрос важен и для MRC. В её обновлении 2024 года сказано, что «правила о приватности — не барьер, который нужно обойти инженерными средствами, а жёсткие требования, которые необходимо соблюдать».

Где здесь место amBrain?

amBrain, который ведёт этот блог, строит системы, к которым подключается фильтрация. Одна из его строк звучит так: «amBrain строит ad-серверы: таргетинг, ограничение частоты показов и отчётность». Другая: «amBrain строит пайплайны событийной аналитики для AdTech: сбор и обработка событий показов и кликов и отчётность по ним». В его работе в AdTech есть RTBBidder — demand-side платформа, которую он построил для клиента.

Компания делает софт с 2019 года и работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов».

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