Проверке рекламы нужна согласованность региона и языка

Снимок для проверки рекламы отвечает на узкий вопрос: какое объявление и какую страницу приземления получил запрос с указанными объявленными свойствами в этом регионе. BotBrowser документирует геоданные, производные от прокси, и ручные переопределения часового пояса, локали и языков, которые документация связывает с лицензией ENT Tier1, поэтому регион, который заявляет снимок, можно указать явно, а не наследовать от машины запуска. Он не генерирует рекламный трафик, не делает ставки и не управляет тем, что вернёт рекламный сервер; каждый снимок по-прежнему зависит от того, разрешают ли его условия платформы.

Кратко

• Снимок определяется двумя входными данными: точкой выхода запроса и языком, который объявляет браузер. Если они расходятся, снимок не описывает ни одного согласованного региона.
• Смена региона выхода может изменить объявление, которое получает запрос. Смена объявленного языка может изменить страницу приземления.
• Расхождение, не изменившее ни того ни другого, всё равно обесценивает сравнение: два снимка больше не описывают один и тот же запрос.
• Запускайте проверку согласованности до съёмки и сохраняйте класс IP выхода, часовой пояс и список языков рядом с каждым принятым снимком.
• ads.txt объявляет, какие системы издатель разрешает к продаже инвентаря. О допустимости снимка там нет ничего.

Содержание

• Два входных данных, которые снимок объявляет
• Что меняет расхождение и что не меняет
• Проверка перед первым снимком
• Запись согласованности для каждого принятого снимка
• Где действует ads.txt и где он заканчивается
• Условия и границы до выбора инструментов
• Практический вывод

Два входных данных, которые снимок объявляет

Любой HTTP-запрос несёт больше, чем URL. Он несёт значение Accept-Language, в котором перечислены предпочитаемые клиентом естественные языки, и приходит с сетевого адреса, который сервер или третья сторона может преобразовать в приблизительное местоположение. RFC 9110 определяет этот заголовок как набор предпочитаемых в ответе естественных языков, а Vary как поле, сообщающее кэшу, какие поля запроса повлияли на выбранное представление. Когда ответ содержит Vary: accept-language, сервер заявляет, что выбор языка сыграл роль.

Справочник MDN добавляет существенную для съёмки деталь: браузеры формируют заголовок из активного языка интерфейса, и как Accept-Language, так и navigator.languages могут намеренно опускать часть списка предпочтений ради защиты от fingerprinting. Поэтому снимок фиксирует объявленный список предпочтений, а не полный языковой профиль человека.

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

Из этой пары следуют два вывода. Во-первых, снимок может быть внутренне согласованным или нет: список языков и часовой пояс либо соответствуют региону выхода, либо описывают место, откуда запрос не приходит. Во-вторых, согласованность свойство снимка, а не бинарного файла браузера, поэтому её нужно записывать, а не подразумевать.

Что меняет расхождение и что не меняет

Полезное деление не «согласовано против сломано», а «что именно это расхождение изменило в ответе». Рекламные системы различаются, поэтому таблица ниже перечисляет три класса расхождений и одну контрольную строку с наблюдением, которое поддерживает каждый из них. Это вспомогательная классификация, а не утверждение о поведении конкретного рекламного сервера.

Условие снимка	Объявление	Страница приземления	Что подтверждает снимок
Регион выхода изменён, список языков тот же	Может отличаться	Может отличаться	Два региональных наблюдения; ни одно не база для другого
Список языков изменён, регион выхода тот же	Может отличаться	Может отличаться	Наблюдение согласования контента в одном регионе
Список согласован с поясом, выход иной	Изменений не видно	Изменений не видно	Вывода нет: запрос не описывает одно место
Контроль: все три совпадают, источник изменился	Может отличаться	Может отличаться	Изменение на стороне источника, а не эффект региона

Первая строка чаще всего читается неверно. Команда оставляет список языков en-US,en и переносит выход из одной страны в другую. Если объявление меняется, соблазнительный вывод система таргетирует по географии. Наблюдение подтверждает лишь то, что два снимка различаются, и различие может с равным успехом объясняться расписанием, изменением бюджета кампании, правилом частоты или региональным режимом согласия. Чтобы разделить эти причины, нужен третий снимок в исходном регионе в то же время, а не более сильное утверждение о первых двух.

Вторая строка обратная. Если оставить выход неизменным и сменить список языков с en-US,en на de-DE,de, может измениться страница приземления, на которую перенаправляется запрос, поскольку согласование языка именно то, что описывает RFC 9110. Тем самым различие страниц приземления становится ожидаемым результатом объявленного изменения, а не признаком чего-то необычного.

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

Четвёртая строка охватывает подлинное изменение на стороне источника. Если все три входных данных идентичны, а объявление всё равно отличается, различие находится в состоянии самой рекламной системы: правки таргетинга, расписание показов, ограничения частоты или назначение эксперимента. Именно корректная запись согласованности делает этот вывод возможным, потому что исключает снимок как объяснение.

Режим согласия тот смешивающий фактор, который чаще всего переживает первые три строки. Запрос из страны с действующим режимом согласия может вернуть другое объявление или промежуточный экран перед страницей приземления, и это различие выглядит как региональный таргетинг, хотя на деле это регуляторный барьер. Поскольку барьер обычно привязан к региону, а не к языку, сравнение списков языков его не обнаружит. Держите отдельное поле: было ли взаимодействие согласия и в каком режиме. Серия, смешивающая запуски с барьером и без него, не является региональной серией, что бы ни говорили её географические входные данные.

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

Проверка перед первым снимком

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

const EXPECTED = 'DE';
const REGION_LANGUAGES = { DE: ['de-DE', 'de'], US: ['en-US', 'en'], JP: ['ja-JP', 'ja'] };
const REGION_TIMEZONES = { DE: 'Europe/Berlin', US: 'America/New_York', JP: 'Asia/Tokyo' };

const languages = navigator.languages.slice();
const timezone = Intl.DateTimeFormat().resolvedOptions().timeZone;

// The primary language decides the region, not any match anywhere in the list:
// ["en-US", "de-DE"] still asks for English first, which is the mix this check must reject.
const languageOk = REGION_LANGUAGES[EXPECTED].includes(languages[0]);
const timezoneOk = timezone === REGION_TIMEZONES[EXPECTED];
// navigator.languages is the preference list, not the transmitted header; some browsers add
// fallback tags. Treat this as an estimate and read the real header from the captured request.
const acceptLanguageEstimate = languages
  .map((tag, i) => (i === 0 ? tag : `${tag};q=${(1 - i * 0.1).toFixed(1)}`))
  .join(',');

console.log(
  JSON.stringify({ expected: EXPECTED, languages, timezone, acceptLanguageEstimate, languageOk, timezoneOk }, null, 2)
);
if (!languageOk || !timezoneOk)
  throw new Error('capture would describe more than one region; fix inputs before capturing');

Смысл проверки именно в первом элементе. Список en-US,de-DE тоже содержит немецкий тег, но запрос по-прежнему первым требует английский, поэтому проверка, принимающая любое совпадение в списке, пропустила бы ровно тот смешанный запрос, который должна остановить. На сконструированном примере, где браузер объявляет en-US,en и сообщает America/New_York, а оператор ожидает DE, вывод называет обе ошибки:

{
  "expected": "DE",
  "languages": ["en-US", "en"],
  "timezone": "America/New_York",
  "acceptLanguageEstimate": "en-US,en;q=0.9",
  "languageOk": false,
  "timezoneOk": false
}
Error: capture would describe more than one region; fix inputs before capturing

Проверка не доказывает точку выхода, поскольку страница не может надёжно прочитать собственный публичный адрес. Держите проверку выхода отдельно: подтвердите класс IP выхода на стороне оператора через отчёты провайдера прокси или явное значение --proxy-ip, как описано в руководстве BotBrowser по GeoIP, и запишите это значение в снимок. Проверка в странице покрывает два входных данных, которые страница может наблюдать; проверка оператора тот, который она наблюдать не может.

Запускайте обе до первого снимка серии и повторно при любом изменении прокси, профиля или языковых настроек. Проверка, запускаемая только при настройке, перестаёт описывать прогон, как только кто-то изменит флаг.

Два режима отказа переживают даже письменную проверку, если её вывод никто не читает. Первый устаревшее ожидание: оператор меняет целевой регион в инструкции, но оставляет EXPECTED с прежним значением, поэтому проверка проходит, хотя и скрипт, и снимок описывают неверное место. Второй частичное переопределение: прокси меняют, а явный --bot-timezone от прошлого запуска остаётся в аргументах, и производный часовой пояс молча проигрывает флагу. Оба дешёво ловятся выводом разрешённых значений вместо одного булева результата поэтому пример печатает список языков, часовой пояс и собранный заголовок перед выбросом ошибки.

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

Запись согласованности для каждого принятого снимка

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

Поле записи	Что содержит	Почему нельзя опустить
expected_region	Код ISO 3166-1 alpha-2, на который нацелен прогон	Даёт каждому последующему сравнению фиксированный субъект
exit_ip_class	Адрес выхода по отчёту провайдера	Отделяет «тот же регион» от «тот же провайдер, другой город»
accept_language_estimate	Заголовок, оценённый по navigator.languages	Показывает, что страница считает отправленным; реальный заголовок берите из запроса
timezone_reported	Часовой пояс IANA, который вернул браузер	Выявляет профиль, противоречащий собственному прокси
creative_ref	Идентификатор, хеш или ссылка на файл	Позволяет сравнивать, не распространяя материал
landing_url	Итоговый URL после перенаправлений	Отделяет согласование от клиентского перенаправления
observed_at	Время снимка в UTC	Упорядочивает наблюдения и выявляет смену расписания показов
alignment_result	aligned или названное расхождение	Не даёт несогласованной строке попасть в серию

Две детали в этой таблице легко пропустить и дорого восстанавливать. Первая разница между запрошенным URL и итоговым адресом приземления. Цепочка перенаправлений может переместить запрос после согласования, и запись только запрошенного адреса скрывает шаг, который на деле объясняет различие. Вторая ссылка на объявление. Хранение хеша или идентификатора на стороне издателя сохраняет запись проверяемой при соблюдении ограничений хранения и позволяет более позднему прогону отличить «то же объявление» от «та же кампания, новый материал».

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

Хранение заслуживает отдельного решения, поскольку ссылки на объявления могут нести больше веса, чем кажется. Хеша материала обычно достаточно, чтобы различить два наблюдения, но URL приземления может содержать идентификаторы, относящиеся к конкретному запросу показа. Удаляйте или хешируйте параметры с идентификатором показа перед сохранением URL и сохраняйте неизменённое значение только если это разрешают и условия платформы, и ваша политика хранения. Запись профиля с ротацией прокси использует тот же подход для идентичности сессии: сохранять стабильную ссылку и отбрасывать поперечный деталь, добавляющую риск без сравнимости.

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

Где действует ads.txt и где он заканчивается

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

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

Полезное применение уже и всё же стоит усилий: когда снимок сравнивают с размещением, о котором сообщил партнёр, запись ads.txt может показать, включает ли объявленный список продавцов домена систему, названную партнёром. Расхождение там вопрос цепочки поставок для партнёра, а не вывод о региональном таргетинге. Держите оба вывода в отдельных полях, чтобы поздний читатель не слил их в один вердикт.

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

Сопротивляйтесь искушению считать объявленного продавца сигналом качества. Спецификация описывает разрешение продавать инвентарь, и её область намеренно узка: это не утверждение о качестве объявления, видимости, безопасности бренда или точности любого отчёта. Разговор с партнёром, которому нужны такие ответы, должен опираться на отчёты самого партнёра, а запрос к ads.txt даёт ровно один факт.

Условия и границы до выбора инструментов

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

Отсюда два практических ограничения. Первое: наблюдение не равно участию. Загрузить страницу и записать, что она вернула, иное действие, чем создавать показы, клики или события видимости, и второе выходит за рамки конвейера съёмки. Второе: различие между двумя снимками это наблюдение, а не вывод о мошенничестве или неверном показе; такие выводы принадлежат сторонам, у которых есть журналы показов и договорные отношения.

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

Вопросы и ответы

Обесценивает ли расхождение региона снимок, даже если объявление выглядит одинаково?

Да. Снимок больше не описывает одно согласованное место, поэтому его нельзя сравнивать с корректно согласованным снимком ни из одного региона. Одинаковый результат делает запись внешне чистой, оставляя её непригодной для сравнения.

Может ли проверка согласованности заменить проверку выхода?

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

Показывает ли ads.txt, законно ли рекламное размещение?

Нет. Он объявляет, какие системы издатель разрешает к продаже инвентаря на этом домене. Он не описывает выбор объявления, оплачиваемый показ или разрешение на сбор.

Делает ли BotBrowser так, что снимок приходит из конкретной страны?

Он применяет выход через прокси и выводит из этого адреса значения по умолчанию для часового пояса, локали и языков. Документация указывает, что ручные переопределения этих трёх значений требуют лицензии ENT Tier1. Полученный снимок всё равно отражает то, что решит вернуть рекламная система, а вывод на уровне города может быть приблизительным.

Источники

• IAB Tech Lab ads.txt
• Спецификация ads.txt версии 1.1
• MDN Accept-Language
• RFC 9110, семантика HTTP
• База GeoIP в BotBrowser
• Часовой пояс, локаль и языки в BotBrowser

Практический вывод

Рассматривайте регион выхода, сообщённый часовой пояс и объявленный список языков как одно свойство снимка. Запускайте проверку согласованности перед первым снимком и повторно после любого изменения прокси, профиля или языка. Сохраняйте три входных данных вместе со ссылкой на объявление, итоговым URL и временем наблюдения и помечайте строку согласованной только когда все три совпадают с регионом, который прогон заявляет как представляемый. Там, где различие появляется при сохранённой согласованности, объяснение находится на стороне источника, и именно запись делает этот вывод доступным.