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.

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

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

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

Flow diagram

  1. Участник торгов работает со своими рекламодателями, чтобы поддерживать группы интересов для каждого рекламодателя. Зачастую рекламодатели добавляют тег участника торгов на страницу рекламодателя, чтобы добавить браузер в группы по интересам.
  2. Конечный пользователь посещает страницу рекламодателя. Страница может содержать тег участника торгов.
  3. Тег участника торгов вызывает API защищенной аудитории joinAdInterestGroup() . Этот вызов запрашивает браузер добавить пользователя в группу по интересам.
  4. Конечный пользователь посещает веб-страницу издателя. Браузер пользователя запрашивает рекламный тег издателя Google.
  5. Тег объявления издателя Google отправляет запрос контекстного объявления на сервер Google.
  6. Google отправляет контекстные запросы ставок участвующим участникам торгов. Дополнительную информацию см. в разделе «Изменения запроса ставок» .
  7. Участник торгов возвращает ответ на заявку, включающий сообщение InterestGroupBidding , необходимое для участия в аукционе группы интересов. В OpenRTB это указывается в поле BidResponse.ext.igbid , а в устаревшем протоколе Google RTB это указывается в поле BidResponse.interest_group_bidding . Если участник торгов не указывает эту информацию, Google не включает происхождение участника в interestGroupBuyers в конфигурации аукциона . InterestGroupBidding также может содержать дополнительные сигналы, специфичные для покупателя, которые будут передаваться в функцию назначения ставок участника во время аукциона в браузере. В OpenRTB это указывается в поле BidResponse.ext.igbid.igbuyer.buyerdata , а в устаревшем протоколе Google RTB это указывается в поле BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals . Дополнительную информацию см. в разделе «Изменения ответов на запросы ставок» .
  8. Google запускает аукцион на стороне сервера и возвращает ответ на запрос ставки в браузер. Аукцион на стороне сервера учитывает традиционные ставки на стороне сервера. Ответ на заявку может содержать информацию о контекстной выигрышной ставке (если таковая имеется).
  9. Ответ на заявку содержит конфигурацию аукциона в браузере. Сюда могут входить контекстные сигналы от каждого участвующего покупателя (которые ранее были отправлены через buyerdata OpenRTB или per_buyer_signals устаревшего протокола Google RTB), контекстную информацию о победителе и настройки приемлемости ставок.
  10. Тег издателя Google вызывает API защищенной аудитории runAdAuction() чтобы инициировать аукцион группы по интересам на устройстве. Google включает только тех покупателей, которые были включены в качестве InterestGroupBuyer в InterestGroupBidding во время настройки аукциона.
  11. Google передает дополнительные сигналы, специфичные для покупателя, каждого участника, имеющего право на участие в торгах, в конфигурацию аукциона Защищенной аудитории.
  12. Если группы интересов данного участника торгов trustedBiddingSignalsUrl , браузер отправляет запрос trustedBiddingSignalsUrl каждой группы для получения сигналов в реальном времени для каждой группы. Подробности см. в спецификации API Protected Audience .
  13. Браузер вызывает generateBid() участника торгов для каждой группы интересов, которая приняла участие и имеет право участвовать в аукционе в браузере. На этом этапе рассчитывается ставка и выбирается креатив. generateBid() имеет доступ к дополнительным сигналам покупателя, предоставляемым участником торгов, и доверенным сигналам торгов для данной группы интересов.
  14. Браузер вызывает scoreAd() продавца (в данном случае Google), чтобы присвоить рейтинг каждой ставке на аукционе рекламы по группам интересов. Ставки ранжируются и фильтруются на основе защиты издателей, рекламной политики и других ограничений.
  15. Браузер запускает аукцион с подходящими ставками для групп интересов. Контекстная ставка, занявшая первое место, участвует в аукционе в браузере.
  16. После аукциона, если есть победитель группы интересов, браузер вызывает reportResult() продавца и reportWin() участника торгов, чтобы уведомить каждую сторону о победителе аукциона в браузере.
  17. Если побеждает объявление группы интересов, тег издателя 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 появится в качестве нового измерения в Инструменте создания отчетов для авторизованных покупателей как измерение идентификатора отчетности покупателя .

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

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

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

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

В запросах ставок есть новые поля для указания поддержки аукционов по группам интересов:

  • ОпенРТБ:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • Протокол Google RTB (устаревший):
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

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

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

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

  • ОпенРТБ:
    • BidRequest.imp.ext.interest_group_auction . width
    • BidRequest.imp.ext.interest_group_auction . height
  • Протокол Google RTB (устаревший):
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

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

Этот размер может отличаться от размеров в контекстном запросе, например, в полях BidRequest.imp.banner.format.w и BidRequest.imp.banner.format.h OpenRTB или в полях BidRequest.adslot.width и BidRequest.adslot.height устаревшего протокола Google RTB. Поля BidRequest.adslot.height .

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

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

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

  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • Протокол Google RTB (устаревший): BidRequest.adslot.interest_group_auction.render_interest_group_ads
Минимизируйте использование идентификаторов пользователей

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

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

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

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

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

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

  • OpenRTB: BidRequest.device.ext.cdep
  • Протокол Google RTB (устаревший): BidRequest.device.cookie_deprecation_label

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

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

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

  • OpenRTB: BidResponse.ext.igbid
  • Протокол Google RTB (устаревший): BidResponse.interest_group_bidding

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

Распространяйте контекстные сигналы покупателя

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

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • Google RTB (устарело): BidResponse.interest_group_bidding.per_buyer_signals
Распространение сигналов контекстной визуализации покупателя.

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

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

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

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB (устарело): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

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

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

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

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

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

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

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

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

  • OpenRTB: BidResponse.igbid.igbuyer.billing_id
  • Протокол Google RTB (устаревший): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

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

  • OpenRTB: BidRequest.imp.ext.billing_id
  • Протокол Google RTB (устаревший): BidRequest.adslot.matching_ad_data.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 и должна представлять собой действительный альфа-код 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.regs.dsa.required и BidRequest.dsa.pubrender в запросе ставки ( BidRequest.dsa.dsa_support и BidRequest.dsa.publisher_rendering_support соответственно в устаревшем протоколе Google RTB).

Когда участник торгов, желающий участвовать в аукционах API Protected Audience, получает в запросе ставки сигнал о том, что прозрачность DSA должна отображаться для объявлений, доставляемых через API Protected Audience, ему следует оценить, могут ли они соответствующим образом отображать необходимую информацию, и указать это, установив BidResponse.ext.igbid.igbuyer.dsaadrender ( BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render в устаревшем протоколе Google RTB). В противном случае покупатель не будет включен в аукцион 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 JSON: 0 ), даже если запрос ставки соответствует критериям аукциона Защищенной аудитории.

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

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

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

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

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

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

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

  • %%GOOGLE_QUERY_ID%% : этот макрос заменяется идентификатором запроса Google, который был отправлен в контекстном запросе ставки с включенной защищенной аудиторией. В протоколе OpenRTB это указывается с помощью BidRequest.ext.google_query_id , тогда как устаревший протокол Google RTB использует BidRequest.google_query_id .
  • %%INTEREST_GROUP_OWNER%% : происхождение владельца группы интересов.
  • %%BID_CPM%% : цена предложения в CPM, указанная покупателем в 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 Protected Audience. Сообщите своему менеджеру по работе с клиентами во время интеграции, если вы планируете протестировать PLTD, поскольку потребуются дополнительные ресурсы и настройка.

Регистрация

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

Шаги

  1. Заполните форму запроса , чтобы присоединиться к эксперименту API Protected Audience.
  2. После отправки формы запроса обратитесь к своему менеджеру по работе с клиентами или отправьте заявку в Справочном центре авторизованных покупателей .
  3. После настройки учетной записи 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: Ручное тестирование

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

  1. Используйте Chrome 101 или более позднюю версию.
  2. Включите API Privacy Sandbox и Fenced Frame, используя chrome://flags/#privacy-sandbox-ads-apis и chrome://flags/#enable-fenced-frames . Дополнительную информацию см. в разделе «Проверка изолированной программной среды конфиденциальности» .
  3. Отправьте креатив на утверждение с помощью API назначения ставок в реальном времени .
  4. Используйте страницу рекламодателя, предоставленную участником торгов, чтобы добавить браузер в группу интересов, принадлежащую претенденту.

  5. Используйте следующую тестовую страницу издателя, предоставленную Google, чтобы запустить аукцион защищенной аудитории:

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

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

  6. Проверьте следующее:

    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, которые можно разрешить после ответа контекстной рекламы. Поскольку interestGroupBuyers передается до ответа на контекстное объявление, ответ на контекстное объявление (включая ответы на запросы ставок) не может использоваться для выбора покупателей, которые будут участвовать в параллельном аукционе по данному запросу. Вместо этого тег издателя Google кэширует в браузере пользователя interestGroupBuyers из предыдущих выполнений navigator.runAdAuction в том же домене.

Распараллеливание имеет несколько важных соображений:

  1. Сигналы аукциона, которые не нужны для запросов доверенного сервера покупателя, например perBuyerSignals , могут по-прежнему указываться в ответах на ставки RTB так же, как и для непараллельных аукционов. Как только обещания для этих сигналов будут решены, оставшиеся этапы аукциона на устройстве завершатся так же, как и для непараллельного аукциона.

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

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

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

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

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

  5. Если запущен параллельный аукцион, но в кеше нет конкретного источника покупателя, то данного покупателя нельзя добавить в текущий аукцион на устройстве. На это указывает запрос с параметром parallelized=True , в котором отсутствует запись ParallelAuctionBuyer для данного источника покупателей из группы интересов. Однако участники торгов, которые проявят интерес, включив в свой ответ на заявку действительных и отвечающих требованиям InterestGroupBuyer (s), будут добавлять в кэш соответствующие источники покупателей из группы интересов, и эти источники будут иметь право на будущие параллельные запросы из того же браузера и домена. Намерение участвовать в групповых аукционах по интересам может быть указано в следующих полях:

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

  6. Источники кэшированных покупателей (которые включены в параметр interestGroupBuyers параллельного аукциона), для которых участник торгов не указывает намерение участвовать в своем ответе на заявку, могут получить вызов доверенного сервера покупателя, но не будут участвовать в параллельном аукционе.