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

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

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

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

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

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

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

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

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

Flow diagram

Участник торгов работает со своими рекламодателями, поддерживая группы интересов для каждого из них. Зачастую рекламодатели добавляют тег участника торгов на свою страницу, чтобы добавить браузер в группы интересов.
Конечный пользователь посещает страницу рекламодателя. На странице может быть указан тег участника торгов.
Тег участника торгов вызывает API защищенной аудитории joinAdInterestGroup() . Этот вызов запрашивает у браузера добавление пользователя в группу интересов.
Конечный пользователь посещает веб-страницу издателя. Браузер пользователя запрашивает тег объявления издателя Google.
Тег объявления издателя Google отправляет запрос контекстной рекламы на сервер Google.
Google отправляет контекстные запросы ставок участвующим претендентам. Подробнее см. в разделе «Изменение запросов ставок» .
Участник торгов возвращает ответ на заявку, включающий сообщение 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 . Подробнее см. в разделе «Изменения в ответе на заявку» .
Google запускает аукцион на стороне сервера и возвращает ответ на заявку браузеру. В этом аукционе учитываются традиционные серверные заявки. Ответ на заявку может содержать информацию о контекстной победившей ставке (если таковая имеется).
Ответ на заявку содержит конфигурацию аукциона для аукциона в браузере. Она может включать контекстные сигналы от каждого участвующего покупателя (отправленные через buyerdata OpenRTB или через устаревший протокол Google RTB per_buyer_signals ), контекстную информацию о победителе и настройки соответствия требованиям для ставок.
Тег издателя Google вызывает API защищенной аудитории runAdAuction() для инициирования аукциона по интересам на устройстве. Google включает только покупателей, которые были включены в InterestGroupBuyer в InterestGroupBidding при настройке аукциона.
Google передает необязательные сигналы, специфичные для покупателя, каждого подходящего претендента в конфигурацию аукциона защищенной аудитории.
Если группы интересов конкретного участника торгов указали trustedBiddingSignalsUrl , браузер отправляет запрос на trustedBiddingSignalsUrl каждой группы для получения сигналов в режиме реального времени для каждой группы. Подробности см. в спецификации Protected Audience API .
Браузер вызывает generateBid() участника аукциона для каждой группы интересов, которая согласилась участвовать в аукционе в браузере. На этом этапе вычисляется ставка и выбирается креатив. generateBid() имеет доступ к дополнительным сигналам покупателя, предоставленным участником аукциона, и к доверенным сигналам ставок для данной группы интересов.
Браузер вызывает 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 дней. Если вы отправляете креативы через Real-time Bidding API, вам потребуется повторно отправить их через 15 дней. Если вы используете автоматическое сканирование креативов, процесс сканирования автоматически пересканирует их.

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

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

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

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

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

Аукцион на стороне сервера

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

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

OpenRTB ранняя ссылка
Протокол Google RTB (устарел), ранняя ссылка

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

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

OpenRTB:
- BidRequest.imp.ext.ae
- BidRequest.imp.ext.igbid
Протокол Google RTB (устарел):
- BidRequest.adslot.supported_auction_environment
- BidRequest.adslot.interest_group_bidding_allowed

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

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

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

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

OpenRTB:
- 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

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

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

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

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

Реклама защищенной аудитории может отображаться или не отображаться в зависимости от текущего этапа интеграции (см. эксперимент без отображения ). Поле 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 защищенной аудитории, могут по-прежнему содержать традиционные идентификаторы на основе файлов cookie, если они доступны в браузере, например, поля BidRequest.user.id и BidRequest.user.buyerid или BidRequest.google_user_id и BidRequest.hosted_match_data в устаревшем протоколе Google RTB. Наличие таких идентификаторов в запросах ставок регулируется действующими политиками конфиденциальности. Мы рекомендуем не использовать идентификаторы на основе файлов cookie для таргетинга и назначения ставок во время тестирования, чтобы лучше подготовиться к эффективным покупкам в условиях отсутствия сторонних файлов cookie.

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

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

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

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

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-безопасными, макросуффиксы не являются уникальными или предоставлено более 3 наборов сигналов.

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

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

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

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

OpenRTB: BidResponse.igbid.igbuyer.maxbid (выражено в единицах валюты CPM)
Протокол Google RTB (устарел): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (выражено в microCPM)

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

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

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() см. в разделе «Торги на устройстве» спецификации Protected Audience.

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

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

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

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

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

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

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

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

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

auctionSignals
sellerSignals

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

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

Макросы

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 защищенной аудитории с партнерами RTB Google будет подсчитывать показы, когда браузер вызывает функцию reportResult() и затем извлекает URL-адрес отчетов Google в вызове sendReportTo() .

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

Одной из целей Google при тестировании API защищенной аудитории является выявление и устранение подобных несоответствий.

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

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

Дневной лимит бюджета

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

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

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

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

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

Конкретные имена полей см. в документации по протоколу для расширений Authorized Buyers 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 Chrome ForDebuggingOnly .

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

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

Адаптация

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

Шаги

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

Творческий обзор

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

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

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

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

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

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

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

Используйте Chrome 101 или более позднюю версию.
Включите Privacy Sandbox API и Fenced Frame с помощью chrome://flags/#privacy-sandbox-ads-apis и chrome://flags/#enable-fenced-frames . Подробнее см. в статье «Тестирование Privacy Sandbox» .
Отправьте креатив на утверждение с помощью 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 : A status code if the bid was rejected within scoreAd() . Values are creative status codes .

Stage 2: (Optional) Non-rendering experiment

After Google and the partner have manually verified that the partner can participate in the Protected Audience auction, Google enables the partner for the next stage of testing.

Google allocates a small amount of live traffic to run Protected Audience auctions. Then, Google and the partner no longer need to manually trigger a Protected Audience auction. The result of the Protected Audience auction isn't rendered. This allows us to test the integration at scale.

Reach out to your account manager or file a ticket through the Authorized Buyer Help Center when you're ready. Google will enable the account for this stage.

Stage 3: Rendering Experiment

Once Google and the partner have verified Protected Audience auctions at scale without rendering, Google can enable the partner to render the Protected Audience winning ad. Google has a small amount of traffic where Protected Audience auctions are eligible to run, and winning interest group ads are rendered. Participating bidders' in-browser bids compete with the traditional bids.

Reach out to your account manager or file a ticket through the Authorized Buyer Help Center when you're ready. Google will enable the account for this stage.

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

The following features are extensions of the core protocol.

Parallelization

Parallelization is an optimization that decreases end-to-end auction latency by initiating the contextual ad request in parallel with the requests to the buyer trusted servers specified in trustedBiddingSignalsUrl .

Parallelization reduces latency but affects interest group buyer eligibility and support for coordinated experiments . Parallelization applies to all bidders who participate in the on-device interest group auction. Bidders don't need to take action to participate in parallel auctions but should familiarize themselves with how parallelization may affect their eligibility in on-device auctions. Experiment group IDs for coordinated experiments are not yet supported within parallel auctions.

Serving flow summary

Here's a summary of the parallel auction flow: Flow diagram

On-device interest group buyer eligibility

For parallel auctions, navigator.runAdAuction 's call happens before the contextual ad response is returned. In order to initiate buyer trusted server calls, navigator.runAdAuction requires that the interestGroupBuyers parameter must be passed as a value, while the remaining auction parameters accept Javascript Promises that can be resolved after the contextual ad response. Since interestGroupBuyers is passed before the contextual ad response, the contextual ad response (including bid responses) cannot be used to choose which buyers participate in the parallelized auction for the given request. Instead Google's publisher tag caches, in the user's browser, the interestGroupBuyers parameter from previous navigator.runAdAuction executions on the same domain.

Parallelization has several important considerations:

Auction signals that aren't needed for buyer trusted server requests, such as perBuyerSignals , can continue to be specified in RTB bid responses in the same way as for non-parallelized auctions. Once the Promises for these signals are resolved, the remaining steps of the on-device auction will complete in the same manner as for the non-parallel auction flow.
Since parallelization relies on caching the list of interest group buyers, Google does not always run a parallel auction, as the parallelization cache may be empty or expired. If the cache is empty or expired, Google runs a standard non-parallel Protected Audience API auction and uses buyer intent to participate in the non-parallel auction to build the interest group buyer cache.
If at least one buyer for any bidder is cached for the current publisher domain, then Google will run a parallel auction, which will be indicated on the bid request:
- Google RTB Protocol: BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
Each registered interest group buyer origin for a given bidder that was included in the parallel auction will have a corresponding ParallelAuctionBuyer entry:
- Google RTB Protocol: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
If a parallel auction is run, but a specific buyer origin is not present in the cache, then that given buyer cannot be added to the current on-device auction. This is indicated by a request with parallelized=True that lacks a ParallelAuctionBuyer entry for a given interest group buyer origin. However, bidders that indicate interest by including valid and eligible InterestGroupBuyer (s) on their bid response will have the corresponding interest group buyer origins added to the cache, and those origins will be eligible for future parallelized requests from the same browser and domain. Intent to participate in interest group auctions can be indicated in the following fields:
- Google RTB Protocol: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
Cached buyer origins (which are included in the parallel auction's interestGroupBuyers parameter) for which a bidder doesn't indicate intent to participate on their bid response may receive a buyer trusted server call but won't participate in the parallel auction.

API защищенной аудитории (ранее FLEDGE) Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

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

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

Творческий обзор

API торгов в реальном времени

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

Истечение срока действия креатива

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

Аукцион на стороне сервера

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

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

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

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

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

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

Изменения в ответе на заявку

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

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

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

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

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

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

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

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

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

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

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

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

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

Макросы

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

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

Дневной лимит бюджета

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

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

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

Адаптация

Шаги

Творческий обзор

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

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

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

Stage 2: (Optional) Non-rendering experiment

Stage 3: Rendering Experiment

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

Parallelization

Serving flow summary

On-device interest group buyer eligibility

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