Рекламодатель платит за показ, который должен увидеть человек. Если показ «увидел» бот, сервер в дата-центре или скрытый iframe размером 1×1 пиксель, деньги потрачены впустую, а статистика кампании искажена.

Такой трафик называют невалидным, или IVT (Invalid Traffic). В programmatic он особенно опасен: решения о покупке принимаются автоматически за миллисекунды, и один источник плохого трафика может за несколько часов получить заметную часть бюджета.

Для DSP качество трафика напрямую влияет на доверие рекламодателей. Для SSP и паблишеров это вопрос репутации и стабильного спроса. Поэтому фильтровать IVT приходится всем участникам цепочки.

Что такое невалидный трафик

Невалидный трафик — это показы и клики, которые не созданы реальным пользователем с реальным интересом к контенту. Сюда попадает не только намеренный фрод, но и вполне «честный» технический трафик: поисковые роботы, мониторинговые сервисы, предзагрузка страниц браузером.

Индустриальный стандарт делит IVT на две категории. Деление введено в рекомендациях MRC (Media Rating Council) и используется верификаторами и рекламными платформами по всему миру.

GIVT (General Invalid Traffic) — общий невалидный трафик. Его можно отсеять простыми правилами и списками:

• известные поисковые роботы и краулеры;
• трафик из IP-адресов дата-центров;
• запросы с нестандартными или «небраузерными» user agent;
• служебные сервисы мониторинга и проверки доступности;
• предзагрузка страниц (prefetch), при которой пользователь не видит рекламу.

SIVT (Sophisticated Invalid Traffic) — сложный невалидный трафик. Он специально маскируется под живых пользователей, и простыми правилами его не поймать:

• боты, имитирующие поведение человека: движения мыши, прокрутку, клики;
• заражённые устройства, которые открывают страницы в фоне без ведома владельца;
• подмена домена или приложения (domain spoofing, app spoofing);
• скрытые показы: ad stacking и pixel stuffing;
• мотивированный трафик и клик-фермы;
• подделка данных SDK в мобильных приложениях.

Основные схемы фрода в programmatic

Понимание схем помогает быстрее находить проблему в отчётах и задавать партнёрам правильные вопросы.

Domain spoofing. Мошенник отправляет в bid request чужой домен, например известного новостного сайта. DSP покупает «премиальный» инвентарь, а реклама показывается на сайте низкого качества или не показывается вовсе.

App spoofing. То же самое для мобильных приложений: в запросе указывается bundle ID популярного приложения, хотя реальный источник другой.

Ad stacking. Несколько объявлений размещаются друг над другом в одном слоте. Виден только верхний, а показ засчитывается всем.

Pixel stuffing. Объявление загружается в iframe размером 1×1 пиксель. Показ формально состоялся, но увидеть рекламу невозможно.

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

Мотивированный трафик. Пользователям платят или дают бонусы за просмотр рекламы или посещение сайта. Человек реальный, но интереса к рекламе у него нет.

Фрод в видео и CTV. Видеоинвентарь дороже, поэтому он особенно привлекателен для мошенников. Встречается подмена типа устройства (обычный веб-трафик выдаётся за Smart TV) и генерация фиктивных событий воспроизведения. Подробнее о том, как устроена передача видеорекламы и событий, мы писали в статье VAST в programmatic-рекламе.

Где в цепочке появляется IVT

Невалидный трафик может появиться на любом этапе: на сайте паблишера, у посредника, который перепродаёт инвентарь, или в самом запросе, который подменяют по пути к DSP.

Чем длиннее цепочка перепродаж, тем сложнее понять, откуда пришёл показ. Поэтому индустрия создала стандарты прозрачности, которые позволяют проверить, кто продаёт инвентарь и имеет ли он на это право.

ads.txt и app-ads.txt. Файл на домене паблишера или сайте разработчика приложения, где перечислены платформы, которым разрешено продавать его инвентарь. Если SSP нет в списке, а запрос пришёл от её имени, это повод насторожиться.

sellers.json. Файл на стороне SSP или биржи, в котором указано, с какими продавцами она работает: паблишерами напрямую или посредниками.

SupplyChain object (schain). Поле в OpenRTB-запросе, где перечислены все участники, через которых прошёл показ. DSP видит всю цепочку и может сверить её с ads.txt и sellers.json.

Подробнее о структуре запроса — в статье Что такое OpenRTB.

Фильтрация IVT — это не одна галочка в настройках, а набор проверок на каждом этапе: от источника трафика до отчёта после кампании.

Как SSP фильтрует невалидный трафик

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

Проверка источников при подключении. Модерация сайтов и приложений, проверка ads.txt и app-ads.txt, анализ того, откуда приходит аудитория.

Фильтрация до аукциона (pre-auction). Отсев запросов из дата-центров, от известных ботов, с подозрительными user agent и некорректными параметрами.

Контроль согласованности данных. Если в запросе указано мобильное устройство на iOS, а user agent принадлежит десктопному браузеру на Windows, это признак подмены.

Мониторинг аномалий. Резкие всплески трафика, необычное распределение по времени суток, слишком высокий CTR или слишком ровные графики.

Прозрачность для покупателей. Корректно заполненные sellers.json и schain позволяют DSP самостоятельно проверить цепочку поставки.

Как DSP фильтрует невалидный трафик

DSP принимает решение о ставке, поэтому для неё важнее всего не тратить бюджет рекламодателя на плохие показы. Защита работает на двух уровнях.

Pre-bid — до ставки. DSP анализирует bid request и решает, участвовать ли в аукционе:

• сверяет домен или bundle ID со списками и с ads.txt;
• проверяет schain и данные sellers.json;
• отсекает IP-адреса дата-центров и известных ботов;
• использует собственные чёрные и белые списки площадок;
• применяет данные внешних верификаторов, если они подключены.

Post-bid — после показа. DSP и верификаторы анализируют, что произошло после показа:

• была ли реклама видимой (viewability);
• как вёл себя пользователь: время на странице, клики, конверсии;
• совпадают ли данные показа с данными из запроса.

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

О других параметрах, которые важно проверить при выборе DSP, читайте в статье Как выбрать DSP-платформу.

Признаки невалидного трафика в отчётах

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

• CTR заметно выше обычного для формата и тематики;
• клики происходят практически сразу после загрузки страницы;
• трафик резко вырос без понятной причины: нет новой публикации, сезонности или рекламной кампании;
• большая доля показов приходится на ночное время в регионе аудитории;
• много запросов с одного IP-адреса или из одной подсети;
• в отчёте преобладает одна редкая версия браузера или ОС;
• высокая доля просмотров видео до конца при почти нулевых переходах и конверсиях;
• высокий CTR при отсутствии конверсий у рекламодателя.

Один признак ещё не доказывает фрод. Но несколько совпадений одновременно — повод разобраться с источником.

Типичные ошибки при работе с IVT

Полагаться только на одного участника. Ни SSP, ни DSP не видят всей картины. Надёжная защита строится на проверках с обеих сторон.

Проверять трафик только при подключении. Источник может быть чистым в начале и испортиться позже. Мониторинг нужен постоянно.

Игнорировать ads.txt и sellers.json. Это простые стандарты, которые закрывают значительную часть схем со спуфингом. Их отсутствие или ошибки — уже сигнал риска.

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

Не договориться о правилах заранее. Какие методы проверки используются, как считается IVT и что происходит с такими показами при расчётах — всё это лучше зафиксировать до запуска.

Чек-лист перед подключением нового партнёра

Для DSP при подключении SSP:

• есть ли у SSP опубликованный sellers.json;
• передаётся ли schain в bid request;
• как SSP проверяет сайты и приложения при подключении;
• какая фильтрация IVT работает до аукциона;
• как SSP реагирует на жалобы на качество трафика;
• как фиксируются и учитываются невалидные показы при сверке.

Для SSP при подключении DSP:

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

Главное

• IVT — это показы и клики, не созданные реальным заинтересованным пользователем.
• GIVT отсекается правилами и списками, SIVT требует поведенческого анализа и сверки данных.
• Основные схемы: спуфинг доменов и приложений, скрытые показы, боты, мотивированный трафик.
• ads.txt, sellers.json и schain делают цепочку поставки прозрачной.
• SSP фильтрует трафик до аукциона, DSP — до ставки и после показа.
• Правила оценки IVT и сверки лучше согласовать с партнёром до запуска.

Как Adtec может быть полезен

Adtec — технологическая платформа для programmatic-рекламы с собственной командой разработки. Мы работаем с DSP по OpenRTB и подключаем рекламный спрос к инвентарю сайтов и приложений.

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

Если вы DSP и ищете источники programmatic-трафика, расскажите о своих требованиях — мы обсудим, как выстроить интеграцию.