Когда адрес дата-центра, прокси или VPN означает невалидный трафик?

Почему по одному IP-адресу нельзя судить о посетителе?

Сайт и пиксель видят адрес последнего узла, от которого пришёл запрос. Между человеком и сервером стоят роутер, сеть офиса, оборудование оператора связи, VPN-сервер, прокси браузера или реле Apple, и каждое звено может выдать наружу свой адрес вместо адреса устройства. Ошибиться можно в обе стороны.

Один адрес на многих людей. Документ IETF RFC 6269 «Issues with IP Address Sharing» (июнь 2011 года) разбирает схемы, в которых оператор пропускает подключения многих абонентов через небольшой набор общих IPv4-адресов, например Carrier Grade NAT. Для такого адреса, по RFC, много попыток входа становится обычным делом, а блокировка адреса за злоупотребления бьёт и по соседям. Справка Яндекс Директа о запрете показов по IP-адресам добавляет две детали: при модемном подключении адрес выдаётся динамически и в следующий раз у того же человека может быть другим, а адреса частных подсетей вида 10.x.x.x и 192.168.x.x запретить нельзя, потому что они служат внутренним сетям компаний и в интернете не используются.

Много адресов на одну программу. Стандарт АРИР по SIVT среди сетевых сигналов автоматизированного трафика называет цепочки прокси, ротацию IP и аномальный профиль ASN, номера сети, к которой относится адрес. Бот, который через каждые несколько событий выходит с нового адреса, в разрезе по IP похож на толпу разных посетителей. Поэтому и «слишком много событий с одного адреса», и «каждое событие с нового адреса» остаются поводом посмотреть на действия, а не готовым выводом.

Какие бывают адреса и когда они означают невалидный трафик?

Колонка «Когда это невалидный трафик» опирается на стандарты MRC и АРИР, а не на правила конкретного измерителя: списки и пороги у каждого свои.

У Private Relay есть своя логика. По описанию Apple, один адрес реле могут одновременно получать несколько пользователей из одной местности. Apple прямо пишет, что проверки на мошенничество, основанные на IP, возможно, придётся поправить, чтобы не задеть легитимных пользователей, и предлагает обращаться с адресами реле как с адресами крупного NAT оператора связи (carrier-grade NAT) или корпоративными. Большинство поставщиков баз геолокации, по Apple, подписывают такие адреса в поле организации как iCloud Private Relay, а среди других полей бывают is_relay, is_hosting, privacy_service или privacy_proxy. Измеритель, который смотрит только на признак хостинга, рискует отправить эти показы в дата-центры. С апреля 2024 года MRC требует от измерителей не реже раза в год оценивать, насколько их проверки держатся на IP-адресе, user-agent и данных о пользователе, как на них влияют ограничения ради приватности и не прячется ли за такими ограничениями уход от проверки. Если возможности проверки существенно падают, измеритель изучает последствия и, как правило, раскрывает ограничения тем, кто пользуется его данными.

Как MRC и АРИР делят такой трафик между GIVT и SIVT?

Общий невалидный трафик (GIVT) отсеивают по спискам и стандартными проверками параметров, сложный (SIVT) находят расширенным анализом; разница разобрана на странице о рекламном фроде. Для сетевых признаков два набора правил устроены так.

Отсюда практический вывод: строка «трафик дата-центров» у разных измерителей означает разное. У одного это адреса из списка вместе с автоматическими действиями, у другого любой адрес хостинга. Сравнивать доли из двух отчётов можно, когда известно, по какому списку и с какими исключениями они посчитаны. Общий рыночный справочник дата-центров и сетевых признаков АРИР называет направлением кооперации участников, а не требованием действующей редакции стандарта.

Почему список дата-центров TAG не приговор?

Trustworthy Accountability Group (TAG), отраслевая организация рекламного рынка, каждый месяц выпускает Data Center IP List: адреса, которые вместе с отобранными компаниями признаны источниками высокого риска невалидного трафика. У списка три оговорки, и две из них пишет сама TAG.

• Список не отвечает за конкретный адрес. TAG не высказывает мнения, связан ли тот или иной адрес из списка с нечеловеческим трафиком, и предлагает пользователям списка проверять это своими инструментами и критериями.
• Список неполный по замыслу. По MRC он ограничен адресами дата-центров, откуда человеческий трафик не ожидается, и не включает смешанные адреса, где бывают и люди, и серверы. Поэтому измеритель ищет невалидный трафик дата-центров и за его пределами.
• Список закрытый. Его получают члены TAG для внутреннего использования, а включать его в продукт, который видят третьи лица, запрещено. Сам список рекламодатель не увидит, зато может спросить, по какой причине показ отнесён к GIVT.

Список отвечает на вопрос, откуда пришёл запрос. Невалидным показ делает ответ на другой вопрос: что произошло. Автоматический показ, клик без человека, повтор, который не объясняется общим адресом.

Что делать рекламодателю?

1. Не запрещайте показы по IP и диапазонам хостингов в кабинете. Директ в справке не советует запрещать показы по IP-адресу, даже если с него идёт подозрительная активность: недобросовестные клики и показы, по справке, отсеет антифрод. Широкий запрет задевает офисы, абонентов операторов и пользователей Private Relay; кого ещё теряют такие правила, разобрано на странице об антифроде и конверсии.
2. Просите разбивку по причинам. Сколько показов отнесено к дата-центрам, сколько к прокси и автоматизации и на каких местах показа, устройствах и браузерах. Сетевые причины, собранные на нескольких площадках, это предмет разговора. Сетевые причины, ровно размазанные по Safari и мобильному интернету, сначала повод спросить, как измеритель учитывает Private Relay и адреса операторов.
3. Отделите собственный трафик. Адреса офиса, агентства и подрядчиков, которые проверяют теги, и ID тестовых кампаний сообщите измерителю и площадке до старта. MRC разрешает убирать такой трафик из учёта, когда есть выделенные адреса или ID кампаний и подтверждение, что это тесты.
4. Проверьте, куда уходит непроверяемое. Если адрес скрыт прокси или сервером и данных для решения не хватило, по MRC такой показ не невалидный и не валидный, а неизвестный. Уточните, что такие показы не растворились ни в IVT, ни в чистом трафике.
5. Приносите площадке действия, а не адреса. Строку «показ из дата-центра» без событий легко оспорить: по обоим стандартам одного адреса мало. Прикладывайте время, место показа и то, что происходило с адреса. Как собрать обращение, показано на странице про отчёт о фроде.

Какие вопросы задать площадке и измерителю?

Площадке:

1. По какому списку вы относите адреса к дата-центрам и есть ли в нём исключения для iCloud Private Relay, корпоративных шлюзов и операторов связи?
2. Сколько показов и кликов кампании отсеяно по сетевым причинам и на каких местах показа?
3. Как отметить наш тестовый трафик: по адресам офиса или по ID кампаний?
4. Для видео с серверной вставкой: передаёт ли сервер склейки адрес и user-agent устройства зрителя?

Измерителю:

1. Какие списки дата-центров вы используете (перечень TAG, свои, сторонние), как часто их обновляете и как находите небольшие хостинги?
2. Что, кроме самого адреса, нужно, чтобы показ из дата-центра попал в GIVT?
3. В какой категории SIVT у вас учитываются прокси, VPN и ротация IP и может ли сетевой признак быть единственной причиной?
4. Как порог избыточной активности учитывает общие адреса: VPN-сервисы, мобильных операторов, офисы?
5. Исключены ли адреса iCloud Private Relay из списка дата-центров и когда список Apple сверялся последний раз?
6. Куда попадает показ, если адрес скрыт прокси или сервером и проверить его нельзя?
7. Насколько ваши проверки зависят от IP-адреса и что вы раскрываете о том, как на них влияют Private Relay и другие ограничения ради приватности?

По стандарту АРИР по SIVT верификатор раскрывает в методике роль списков IP-диапазонов, порядок их обновления и трактовку прокси и VPN, поэтому ответы на вопросы 1, 3 и 5 стоит искать прежде всего там.

Опора: дополнение MRC к стандартам по невалидному трафику (июнь 2020 года) и его промежуточное обновление (апрель 2024 года), стандарты АРИР по GIVT и SIVT, описание списка дата-центров TAG, страницы Apple об iCloud Private Relay и опубликованный список его адресов, RFC 6269, справки Яндекс Директа, VK Рекламы и Opera. Все источники открыты 21 октября 2026 года.