Эта страница переведена с помощью Cloud Translation API.

API защищенной аудитории (ранее FLEDGE)

В рамках Privacy Sandbox Chrome предложил Protected Audience API — API-интерфейс в браузере, который позволяет рекламодателям и компаниям, занимающимся рекламными технологиями, показывать рекламу, ориентированную на группы интересов, не полагаясь на сторонние файлы cookie, одновременно защищая пользователей от межсайтового отслеживания.

Chrome запускает пробную версию API Protected Audience. Авторизованные покупатели имеют право участвовать в тестировании API Protected Audience API на инвентаре издателя Менеджера рекламы. Тестируя API защищенной аудитории, участники торгов могут добиться следующих результатов:

Продолжайте работать и узнайте об эффективности потоков API Protected Audience.
Оставляйте отзывы о потенциальных улучшениях API на общедоступных форумах, например GitHub .
Подготовьтесь к поддержке персонализированной рекламы через API, не полагаясь на сторонние файлы cookie.

Авторизованным покупателям, заинтересованным в тестировании, следует ознакомиться с подробностями в разделе «Онбординг» .

Примечание. Когда API защищенной аудитории (ранее известный как FLEDGE) станет общедоступным в Chrome, Менеджер рекламы начнет постепенно увеличивать объем трафика, включенного в его тестирование. Мы будем отслеживать влияние на доходы издателей, поскольку постепенно увеличиваем процент трафика, и не будем увеличивать его дальше, если будет заметно негативное влияние. Мы ожидаем, что к концу 2023 года до 10 % трафика Chrome будет доступно для тестирования API Protected Audience.

Сводка потока обслуживания

Ниже приведен краткий обзор процесса показа рекламы для защищенной аудитории партнерами Авторизованных покупателей:

Flow diagram

Участник торгов работает со своими рекламодателями, чтобы поддерживать группы интересов для каждого рекламодателя. Зачастую рекламодатели добавляют тег участника торгов на страницу рекламодателя, чтобы добавить браузер в группы по интересам.
Конечный пользователь посещает страницу рекламодателя. Страница может содержать тег участника торгов.
Тег участника торгов вызывает API защищенной аудитории joinAdInterestGroup() . Этот вызов запрашивает браузер добавить пользователя в группу по интересам.
Конечный пользователь посещает веб-страницу издателя. Браузер пользователя запрашивает рекламный тег издателя Google.
Тег объявления издателя Google отправляет запрос контекстного объявления на сервер Google.
Google отправляет контекстные запросы ставок участвующим участникам торгов. Дополнительную информацию см. в разделе «Изменения запроса ставок» .
Участник торгов возвращает BidResponse с interest_group_bidding . Если участник торгов не указывает interest_group_bidding , Google не включает происхождение участника торгов в interestGroupBuyers в конфигурации аукциона . Ответ на заявку также может interest_group_bidding.per_buyer_signals . per_buyer_signals будут переданы в функцию назначения ставок участника во время аукциона в браузере. Дополнительную информацию см. в разделе «Изменения ответов на запросы ставок» .
Google запускает аукцион на стороне сервера и возвращает ответ на запрос ставки в браузер. Аукцион на стороне сервера учитывает традиционные ставки на стороне сервера. Ответ на заявку может содержать информацию о контекстной выигрышной ставке (если таковая имеется).
Ответ на заявку содержит конфигурацию аукциона в браузере. Сюда могут входить контекстные сигналы от каждого участвующего покупателя (которые были отправлены interest_group_bidding.per_buyer_signals ), контекстную информацию о победителе и настройки приемлемости ставок.
Тег издателя Google вызывает API защищенной аудитории runAdAuction() чтобы инициировать аукцион группы по интересам на устройстве. Google включает в конфигурацию аукциона только тех покупателей, которые ранее вернули interest_group_bidding как interestGroupBuyers .
Google передает per_buyer_signals каждого участника, имеющего право на участие в торгах, в конфигурацию аукциона Защищенной аудитории.
Если группы интересов данного участника торгов trustedBiddingSignalsUrl , браузер отправляет запрос trustedBiddingSignalsUrl каждой группы для получения сигналов в реальном времени для каждой группы. Подробности см. в спецификации API Protected Audience .
Браузер вызывает generateBid() участника торгов для каждой группы интересов, которая приняла участие и имеет право участвовать в аукционе в браузере. На этом этапе рассчитывается ставка и выбирается креатив. generateBid() имеет доступ к per_buyer_signals предоставленным участником торгов, и доверенным сигналам торгов для данной группы интересов.
Браузер вызывает scoreAd() продавца (в данном случае Google), чтобы присвоить рейтинг каждой ставке на аукционе рекламы по группам интересов. Ставки ранжируются и фильтруются на основе защиты издателей, рекламной политики и других ограничений.
Браузер запускает аукцион с подходящими ставками для групп интересов. Контекстная ставка, занявшая первое место, участвует в аукционе в браузере.
После аукциона, если есть победитель группы интересов, браузер вызывает reportResult() продавца и reportWin() участника торгов, чтобы уведомить каждую сторону о победителе аукциона в браузере.
Если побеждает объявление группы интересов, тег издателя Google отображает объявление в iframe.

Подробности потока обслуживания

Перед показом рекламы

Креативный обзор

Креативы должны быть проверены и одобрены Google, прежде чем их можно будет показывать на аукционах Защищенной аудитории в браузере. Вы можете отправить креативы на рассмотрение через API назначения ставок в реальном времени или с помощью автоматического сканирования креативов . Креативы для аукционов объявлений для защищенной аудитории в браузерных группах по интересам должны включать в себя renderUrls для проверки.

Требования к renderUrls :

renderUrl отправленный через API, должен совпадать с renderUrl , использованным в аукционе объявлений группы по интересам.
Каждый renderUrl может представлять только одного рекламодателя или рекламную кампанию. Данный renderUrl не может использоваться для показа рекламы от имени нескольких рекламодателей. Каждый renderUrl должен соответствовать одному объявлению.
renderUrl должен быть доступен и доступен для загрузки автономными системами проверки объявлений Google в течение 7 дней после последней ставки по объявлению.

API для ставок в реальном времени

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

Автоматическое творческое сканирование

Участники торгов могут настроить автоматическое сканирование креативов, которые не загружаются через API назначения ставок в реальном времени.

Если вы настроите автоматическое сканирование объявлений, Google найдет их на аукционе в браузере и автоматически сканирует их, чтобы они могли участвовать в будущих аукционах.

Вот как включить автоматическое сканирование объявлений:

Добавьте все источники renderUrl креатива группы по интересам в учетную запись Авторизованного покупателя.

Добавьте следующие пользовательские HTTP-заголовки в HTTP-ответ креатива:

Authorized-Buyers-Creative-ID

нить

Идентификатор объявления, присвоенный конкретному покупателю. Максимальная длина идентификатора креатива — 128 байт.

Authorized-Buyers-Click-Through-URLs

нить

Набор объявленных целевых URL для объявления, закодированного в соответствии с RFC2396 .

Пример:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Срок действия креатива истек

Креативы рассматриваются в течение 15 дней. Если вы отправляете креативы с помощью API назначения ставок в реальном времени, вам придется повторно отправить креатив через 15 дней. Если вы полагаетесь на автоматическое творческое сканирование, процесс сканирования автоматически сканирует их повторно.

Идентификатор отчетности покупателя

Вы можете разбить показатели отчета (например, показы) с помощью параметров, предоставленных покупателем (например, идентификатор кампании или идентификатор рекламодателя). Чтобы добавить измерение расходов по группам интересов, укажите buyerAndSellerReportingId для своего объявления при добавлении устройства пользователя в группу интересов. Дополнительные сведения см. в документации по защищенной аудитории .

Ниже приведен пример добавления buyerAndSellerReportingId в конфигурацию группы интересов:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

buyer_reporting_id появится в качестве нового измерения в Инструменте создания отчетов для авторизованных покупателей как измерение идентификатора отчетности покупателя .

Серверный аукцион

Изменения запроса ставки

Ниже приведены ранние версии поддерживаемых протоколов для использования в эксперименте:

Ранняя ссылка на протокол Google RTB
Ранняя ссылка OpenRTB

Укажите поддержку аукциона группы по интересам

В запросах ставок появилось новое поле auction_environment .

Протокол Google RTB: BidRequest.adslot.auction_environment
OpenRTB: BidRequest.imp.ext.auction_environment

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

SERVER_SIDE_AUCTION (OpenRTB JSON: 0 ): традиционные серверные аукционы.
ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1 ): запросы с поддержкой защищенной аудитории, в которых контекстный аукцион запускается на серверах биржи, а ставки по группам интересов и окончательный аукцион запускаются в браузере.

Укажите размер рекламного места для защищенной аудитории

Запрос ставки включает следующие поля, позволяющие указать размер рекламного места для защищенной аудитории:

Протокол Google RTB:
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height
ОпенРТБ:
- BidRequest.imp.ext.interest_group_auction . width
- BidRequest.imp.ext.interest_group_auction . height

В этих полях указывается размер рекламного места для аукциона Protected Audience в пикселях.

Этот размер может отличаться от размеров контекстного запроса ( Adslot.width и Adslot.height или в OpenRTB: BidRequest.imp.banner.format ).

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

Укажите возможность отображения рекламы для защищенной аудитории

Объявления для защищенной аудитории могут отображаться или не отображаться в зависимости от текущего этапа интеграции (см. эксперимент без отображения ). Поле render_interest_group_ads в запросе ставки указывает, будет ли показано выигравшее объявление для защищенной аудитории.

Протокол Google RTB: BidRequest.adslot.interest_group_auction.render_interest_group_ads
OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads

Минимизируйте использование идентификаторов пользователей

Контекстные запросы ставок, включенные в тестирование API Protected Audience, могут по-прежнему содержать традиционные идентификаторы на основе файлов cookie, если они доступны в браузере, например google_user_id ( BidRequest.user.id в OpenRTB) и hosted_match_data ( BidRequest.user.buyerid в OpenRTB). поля. Наличие таких идентификаторов в запросах ставок по-прежнему будет регулироваться любой существующей политикой конфиденциальности. Мы рекомендуем вам не полагаться на идентификаторы на основе файлов cookie для целей таргетинга и назначения ставок во время тестирования, чтобы лучше подготовиться к эффективным покупкам, когда сторонние файлы cookie больше не доступны.

Google также может провести небольшие эксперименты, в которых идентификаторы на основе файлов cookie будут удаляться из запросов ставок в рамках тестирования API Protected Audience. Это делается для того, чтобы оценить потенциальное влияние прекращения поддержки сторонних файлов cookie.

Тестирование устаревания сторонних файлов cookie с помощью Chrome

Чтобы подготовиться к прекращению поддержки сторонних файлов cookie (3PCD) в 2024 году, Chrome теперь предлагает тестирование с помощью Chrome .

Сайты и поставщики могут использовать тестирование с помощью Chrome для тестирования своих систем в соответствии с 3PCD. В ходе теста браузеры Chrome отнесены к экспериментальной группе 3PCD (режим A или режим B). Каждому браузеру присваивается согласованная метка, соответствующая определенной экспериментальной группе 3PCD, к которой вы можете получить доступ через Chrome API в браузере.

Google передает немодифицированную метку из Chrome API в запросе ставки RTB. Из-за небольшого объема трафика отдельного ярлыка Google не всегда включает его в контексты с ограниченной конфиденциальностью.

Вот поля, в которых можно просмотреть метку:

Протокол Google RTB: BidRequest.device.cookie_deprecation_label
OpenRTB: BidRequest.device.ext.cdep

Изменения ответа на запрос ставки

Укажите участие в аукционе группы по интересам

Вы несете ответственность за явное указание своего намерения участвовать в аукционе в браузере, возвращая объект InterestGroupBidding в ответе на контекстную ставку:

Протокол Google RTB: BidResponse.interest_group_bidding
OpenRTB: BidResponse.ext.igbid

Вы должны предоставить контекстный ответ на заявку. Ответ не обязательно должен включать контекстную ставку. Объект InterestGroupBidding должен содержать origin владельца группы интересов, который должен совпадать с одним из источников, настроенных участником торгов для его учетной записи. origin добавляется в interestGroupBuyers конфигурации аукциона, когда тег издателя Google вызывает runAdAuction() .

Распространение контекстных сигналов покупателя (perBuyerSignals).

Вы можете включить сигналы покупателя в контекстный ответ на ставку, который Google передает в виде объекта JSON в свою функцию назначения ставок на устройстве через аргумент perBuyerSignals . Это может быть включено в ответ на заявку со следующими полями в зависимости от протокола:

Google RTB: BidResponse.interest_group_bidding.per_buyer_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata

Распространение сигналов контекстной визуализации покупателя.

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

Вы можете включить сигналы рендеринга покупателя, сериализованные в виде URL-безопасной строки, в контекстный ответ на заявку, который Google заменит в URL рендеринга выигравшей группы интересов, создав макрос ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]} .

Сигналы рендеринга можно указать в ответе на заявку со следующими полями в зависимости от протокола:

Google RTB: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.rsig

В ответ на запрос ставки можно включить до трех наборов сигналов рендеринга с разными макросуффиксами, чтобы различать разные сигналы. Например, суффикс можно использовать для сопоставления определенного набора сигналов, применимых только к объявлениям, с соответствующим макросом в их URL-адресе отображения, что позволяет уменьшить размер передаваемых данных.

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

Укажите максимальную цену ставки в браузере

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

В качестве меры по снижению риска, поддерживаемой Google во время тестирования API Protected Audience API для своих RTB-партнеров, вы можете указать ожидаемое максимальное значение ставки в каждом ответе на контекстную ставку. Ожидаемая максимальная ставка – это максимальная цена ставки, которую должна вернуть ваша функция назначения ставок. Если выигрышная ставка, зарегистрированная на аукционе в браузере, превышает эту сумму, то выигрышная ставка не учитывается как оплачиваемое событие. Этот подход может быть изменен.

В ответе на заявку вы можете указать ожидаемое максимальное значение ставки в следующих полях:

Протокол Google RTB: BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (выражено в микроцене за тысячу показов)
OpenRTB: BidResponse.igbid.igbuyer.maxbid (выраженный в денежных единицах цены за тысячу показов)

Присвоение показов нескольким аккаунтам

Участник торгов должен выбрать платежный идентификатор, чтобы соотнести показы своей ставки по группе интересов, используя следующие поля:

Протокол Google RTB: BidResponse.interest_group_bidding.interest_group_buyers.billing_id
OpenRTB: BidResponse.igbid.igbuyer.billing_id

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

Протокол Google RTB: BidRequest.adslot.matching_ad_data.billing_id
OpenRTB: BidRequest.imp.ext.billing_id

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

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

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

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

Во время аукциона в браузере

Генерация ставок в браузере

Используйте generateBid() для генерации ставок в браузере.

Google предоставляет следующие параметры:

auctionSignals : Пусто
perBuyerSignals : объект JavaScript тех же сигналов, предоставленных участником торгов в контекстном ответе.

Возвращаются следующие параметры:

ad : Google игнорирует это поле.
bid : числовая ставка, которая участвует в аукционе. Должна быть указана в единицах CPM (не микро).
render : URL-адрес, отображаемый для отображения креатива, если ставка выиграет аукцион. Google должен просмотреть и одобрить этот URL, иначе он будет исключен из аукциона.
allowComponentAuction : Должно быть true . В настоящее время Google поддерживает тестирование аукционов с участием нескольких продавцов.

Вот пример:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

См. раздел «Назначение ставок на устройстве» спецификации защищенной аудитории, чтобы получить объяснение функцииgenerateBid generateBid() .

Валюта ставки

Ставки на браузерном аукционе размещаются в единицах цены за тысячу показов выбранной валюты ставки.

Валюта ставки должна быть указана как в контекстном ответе на заявку, так и в возвращаемом значении generateBid и должна представлять собой действительный альфа-код ISO 4217, например «USD», «EUR» или «JPY».

В OpenRTB используйте новое поле cur в объекте InterestGroupBuyer в расширении ответа на заявку Google.

Вот пример:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

В протоколе Google RTB используйте новое поле currency в сообщении InterestGroupBuyer в ответе на заявку.

Вот пример:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

Функции generateBid ставок участников торгов должны возвращать ставки в той же валюте, которая указана в контекстном ответе на заявку. Заполните новое свойство bidCurrency в возвращаемом значении generateBid :

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

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

Проверка качества рекламы

Во время тестирования API защищенной аудитории для RTB-партнеров применение креативной политики и средств контроля издателей может быть более строгим для ставок групп интересов в браузере.

Поддержка Закона о цифровых услугах

В соответствии со статьей 26 Закона о цифровых услугах издатели могут потребовать от покупателей раскрыть информацию о прозрачности в рекламе. Когда издателем включен элемент управления «Попросить покупателей показывать объявления только с информацией о прозрачности DSA на моем сайте или в приложении в ЕЭЗ», покупатели из группы интересов могут определить, для каких возможностей им потребуется обеспечить прозрачность для покупателей, отметив следующие поля на странице полученные запросы ставок: BidRequest.dsa.dsa_support и BidRequest.dsa.publisher_rendering_support для протокола Google Authorized Buyers и BidRequest.regs.dsa.required и BidRequest.dsa.pubrender для протокола OpenRTB.

Когда участник торгов, желающий участвовать в аукционах API Protected Audience, получает в запросе ставки сигнал о том, что прозрачность DSA должна отображаться для объявлений, доставляемых через API Protected Audience, ему следует оценить, могут ли они соответствующим образом отображать необходимую информацию, и указать это, установив BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render для протокола Авторизованных покупателей Google или BidResponse.ext.igbid.igbuyer.dsaadrender для протокола OpenRTB. В противном случае покупатель не будет включен в аукцион API Protected Audience.

Дополнительную информацию о прозрачности рекламы в Законе о цифровых услугах см. в статье Справочного центра: Поддержка Закона о цифровых услугах .

Фильтрация ставок

Google применяет контроль со стороны издателей и политику в отношении рекламы во время аукциона на устройстве.

После аукциона в браузере

Сообщить о результате аукциона покупателю: reportWin()

Google не заполняет следующие аргументы:

auctionSignals
sellerSignals

Используйте reportWin() , чтобы сообщить покупателю о результате аукциона.

Дополнительную информацию см. в разделе «Отчеты покупателей о событиях рендеринга и рекламы» в пояснении API Protected Audience.

Макросы

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

`${GDPR}`	Расширяется до 0, если GDPR не применяется, или до 1, если применяется GDPR. См. документацию .
`${GDPR_CONSENT_XXXX}`	Расширяется до строки «Прозрачность и согласие» (TC), связанной с запросом. Если строка «Прозрачность и согласие (TC)» пуста или недействительна, этот макрос не раскрывается. Используйте этот макрос, чтобы передать строку TC поставщику, зарегистрированному в IAB GVL, в URL-адресе. Замените `XXXX` на идентификатор IAB GVL поставщика, зарегистрированного в IAB GVL. Если строка TC пуста или недействительна, этот макрос не раскрывается. Креативы с макросом `${GDPR_CONSENT_XXXX}` могут быть заблокированы, если зарегистрированный в IAB GVL поставщик, связанный с введенным вами идентификатором IAB GVL, не имеет согласия пользователя. Макрос `${GDPR_CONSENT_XXXX}` должен встречаться только один раз в пределах `renderUrl` .
`${ADDL_CONSENT}`	Расширяется до строки дополнительного согласия (AC), связанной с запросом.
`${AD_WIDTH}, ${AD_HEIGHT)`	Эти макросы вставляют ширину и высоту рекламного места.
`${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}`	Макрос, содержащий сигналы покупателя во время рендеринга, указанные в ответе на ставку. Замените заполнитель `buyer.origin.example` на происхождение покупателя из группы интересов, которое должно соответствовать `interest_group_buyers.origin` в ответе на заявку. Вы можете включить `_OPTIONAL_SUFFIX` чтобы предоставить до трех различных значений сигнала рендеринга.

Подсчет показов

Во время тестирования API Protected Audience с партнерами RTB Google будет подсчитывать показы, когда браузер вызывает функцию reportResult() и впоследствии получает URL-адрес отчета Google при вызове sendReportTo() .

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

Одна из целей Google при тестировании API защищенной аудитории — выявить и уменьшить эти несоответствия.

Атрибуция оплачиваемых показов

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

Ограничение дневного бюджета

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

Аккаунт может продолжать участвовать в контекстных аукционах на стороне сервера после достижения ограничения защищенной аудитории. Например, учетная запись участника торгов, достигшая ограничения Защищенной аудитории, может получить запрос ставки с auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0 ), даже если запрос ставки соответствует критериям участия в аукционе Защищенной аудитории.

Обратная связь в режиме реального времени и минимальная ставка для победы

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

Тип обратной связи объекта обратной связи будет INTEREST_GROUP_BUYER_FEEDBACK .
Происхождение покупателя группы интересов.
Минимальная ставка, которую должен выиграть покупатель из группы интересов, чтобы выиграть общий аукцион.
Минимальная ставка, которую должен выиграть покупатель из группы интересов, чтобы превзойти ставку с самым высоким рейтингом, сделанную серверным компонентом общего аукциона.
Код статуса покупателя группы интересов. Возможные коды статуса определены в файле Interest-group-buyer-status-codes.txt .

Конкретные имена полей см. в документации протокола для авторизованных покупателей RTB и расширений OpenRTB .

Уведомление об отзыве ставки

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

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

%%GOOGLE_QUERY_ID%% : этот макрос заменяется идентификатором запроса Google ( BidRequest.google_query_id в протоколе Авторизованного покупателя и BidRequest.ext.google_query_id в протоколе OpenRTB), который был отправлен в контекстном запросе ставки с включенной Защищенной аудиторией.
%%INTEREST_GROUP_OWNER%% : происхождение владельца группы интересов.
%%BID_CPM%% : цена предложения в CPM, указанная покупателем в функцииgenerateBid generateBid() .
%%RENDER_URL%% : URL-адрес отображения объявления.
%%STATUS%% : код состояния, если ставка была отклонена в рамках scoreAd() . Значения — это коды творческого статуса .

Вот пример статического URL-адреса, который участник торгов может предоставить своему менеджеру по работе с клиентами:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

Уведомление об обратной связи по ставке — это временная функция, зависящая от временного API ForDebuggingOnly Chrome.

Уровень продукта TURTLEDOVE

Объявления, состоящие из нескольких частей или TURTLEDOVE на уровне продукта (PLTD), поддерживаются для партнеров Google RTB во время тестирования API защищенной аудитории. Сообщите своему менеджеру по работе с клиентами во время интеграции, если вы планируете протестировать PLTD, поскольку потребуются дополнительные ресурсы и настройка.

Регистрация

Вот как вы можете протестировать API защищенной аудитории:

Шаги

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

Креативный обзор

Чтобы делать ставки с помощью объявлений уровня продукта ( объявлений, состоящих из нескольких частей ) на аукционах API Protected Audience, выполните следующие требования:

Включите параметр запроса &pltd=True в renderUrl для контейнера объявления компонента (также называемого renderUrl верхнего уровня), чтобы различать renderUrls верхнего уровня во время проверки объявления.
Отрисовывайте репрезентативный креатив, когда контейнер рекламного компонента извлекается для проверки креатива в Google. Чтобы понять, когда следует вернуть репрезентативную визуализацию объявления, вы можете обратиться к параметру запроса validation=True , установленному системой проверки объявлений Google.

Контрольный список интеграции

Настройте конечную точку запроса ставки, которая будет заполнять поля, связанные с Protected Audience API, в контекстном ответе на ставку, interest_group_bidding .
Внедрите тегирование на страницах рекламодателя, чтобы присоединить браузер пользователя к группе по интересам.
РеализуйтеgenerateBid generateBid() и reportWin() .
Выберите происхождение владельцев групп по интересам и добавьте их в учетную запись Авторизованного покупателя.
- Источники владельцев групп интересов должны совпадать с источниками, в которых размещены generateBid() .
- Чтобы выполнить этот шаг, обратитесь к менеджеру по работе с клиентами или отправьте заявку в Справочном центре авторизованных покупателей .
Настройте предварительный таргетинг для инвентаря, соответствующего тестированию API защищенной аудитории.
Отправляйте креативы на рассмотрение и утверждение через Creatives API .
(Необязательно) Настройте доверенные конечные точки сигналов назначения ставок.
(Необязательно) Создайте тестовую страницу рекламодателя, которая позволит инженерам Google добавлять свой браузер в группы по интересам, принадлежащие источнику покупателя вашей группы по интересам. Это позволяет нам вручную запускать аукционы защищенной аудитории.
(Необязательно) Включите обратную связь в режиме реального времени в своей учетной записи, чтобы получать отзывы от покупателей из групп интересов, которых запросили на участие в аукционе защищенной аудитории.
(Необязательно) Обратитесь к своему менеджеру по работе с клиентами, чтобы настроить статический URL-адрес для получения межсерверного уведомления, которое предоставляет обратную связь по ставкам Защищенной аудитории о статусе ставки на аукционе Защищенной аудитории на устройстве, чтобы помочь в устранении непредвиденных проблем. Подробности см. в уведомлении об отзыве ставки .

Этапы испытаний

Этап 1: Ручное тестирование

Вот как вручную запустить аукцион Защищенной аудитории, убедиться, что объявление может быть отображено, и записать показ:

Используйте Chrome 101 или более позднюю версию.
Включите API Privacy Sandbox и Fenced Frame, используя chrome://flags/#privacy-sandbox-ads-apis и chrome://flags/#enable-fenced-frames . Дополнительную информацию см. в разделе «Проверка изолированной программной среды конфиденциальности» .
Отправьте креатив на утверждение с помощью API назначения ставок в реальном времени .
Используйте страницу рекламодателя, предоставленную участником торгов, чтобы добавить браузер в группу интересов, принадлежащую претенденту.
Используйте следующую тестовую страницу издателя, предоставленную Google, чтобы запустить аукцион защищенной аудитории:
https://fledge-testing.uc.r.appspot.com/?nid=allow_all
Группа интересов в браузере должна предложить достаточно высокую цену, чтобы выиграть аукцион, поскольку она может конкурировать с обычными ставками на стороне сервера. Google также предоставляет каждому партнеру специальную тестовую страницу издателя, где только данный партнер может участвовать в аукционе. Возможно, будет проще выиграть в браузерных аукционах на странице конкретного партнера.
Проверьте следующее:
1. Ожидаемое выигрышное объявление отображается.
2. Результат аукциона отправляется на сервер — это означает, что победитель торгов получает ответный сигнал от reportWin() .
3. Консоль тестовой страницы издателя регистрирует отладочное сообщение для каждой ставки со следующей информацией:
  - renderUrl : URL-адрес отображения ставки.
  - interestGroupOwner : владелец группы интересов, участвующей в предложении.
  - accepted : это поле имеет значение true , если ставка была принята, и false если ставка отклонена функцией scoreAd() .
  - externalBidStatus : код состояния, если ставка была отклонена в рамках scoreAd() . Значения — это коды творческого статуса .

Этап 2. (Необязательно) Эксперимент без рендеринга

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

Google выделяет небольшой объем живого трафика для проведения аукционов защищенной аудитории. Тогда Google и партнеру больше не придется вручную запускать аукцион защищенной аудитории. Результат аукциона защищенной аудитории не отображается. Это позволяет нам протестировать интеграцию в масштабе.

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

Этап 3: Эксперимент по рендерингу

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

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

Дополнительные возможности

Следующими функциями являются расширения протокола ядра.

Распараллеливание

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

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

Сводка потока обслуживания

Вот краткое изложение параллельного аукционного потока: Flow diagram

Право на участие

Для параллельных аукционов вызов navigator.runAdAuction происходит до возврата контекстуального ответа на рекламу. Чтобы инициировать доверенные вызовы покупателя доверенного сервера, navigator.runAdAuction требует, чтобы параметр interestGroupBuyers должен был передаваться в качестве значения, в то время как оставшиеся параметры аукциона принимали обещания JavaScript, которые могут быть разрешены после контекстуального ответа AD. Поскольку interestGroupBuyers передается до контекстуального ответа на рекламу, контекстуальный ответ AD (включая ответы на ставку) не может быть использован для выбора того, какие покупатели участвуют в параллелизированном аукционе для данного запроса. Вместо этого Google Publisher Tag Caches, в браузере пользователя, параметр interestGroupBuyers из предыдущих выполнений navigator.runAdAuction на том же домене.

Параллелизация имеет несколько важных соображений:

Аукционные сигналы, которые не нужны для запросов на доверенные сервера покупателя, таких как perBuyerSignals , могут продолжать указывать в ответах на ставки RTB так же, как и для непараллелизированных аукционов. Как только обещания для этих сигналов будут разрешены, оставшиеся этапы аукциона на устройстве будут выполняться так же, как и для непараллельного аукционного потока.
Поскольку параллелизация зависит от кэширования покупателей группы интересов, Google не всегда проводит параллельный аукцион, поскольку кэш параллелизации может быть пустым или истек. Если кэш является пустым или истекшим, Google запускает стандартный непараллельный аукцион API аудитории, и использует намерение покупателя для участия в непараллельном аукционе, чтобы создать кэш покупателя группы.
Если по крайней мере один покупатель для любого участника участника кэшируется для текущего домена издателя, то Google будет проводиться параллельным аукционом, который будет указан по запросу ставки:
- Google RTB Protocol: BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
Каждое зарегистрированное происхождение покупателя заинтересованной группы для данного участника участника , который был включен в параллельный аукцион, будет иметь соответствующую запись ParallelAuctionBuyer :
- Google RTB Protocol: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
Если параллельный аукцион проводится, но в кэше нет конкретного происхождения покупателя, то в текущий аукцион на аукционе на аукционе нет. Это обозначено запросом с parallelized=True , в котором отсутствует запись ParallelAuctionBuyer для данной группы покупателя. Тем не менее, участники, которые указывают на процент, включая допустимые и подходящие InterestGroupBuyer , ведущие в кэш, будут добавлены соответствующие источники покупателя группы, и эти происхождения будут иметь право на будущие параллелизированные запросы из одного и того же браузера и домена. Намерение участвовать в аукционах группы интересов может быть указано в следующих областях:
- Google RTB Protocol: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
Кэшированное происхождение покупателя (которое включено в параметр Parallel Auction interestGroupBuyers ), для которого участник торгов не указывает на намерение участвовать в своем ответе на предложение, может получить вызов с доверенным сервером покупателя, но не будет участвовать на параллельном аукционе.