Поддержка индивидуального таргетинга аудитории с помощью API Protected Audience.

Последние обновления

• Добавлена ​​информация о планировании обновлений пользовательской аудитории.
• Добавлена ​​интеграция отчетов об атрибуции с защищенными аудиториями
• Опубликована хронология функций защищенной аудитории.
• FLEDGE был переименован в Protected Audience API .
• Добавлено предложение по делегированию индивидуальной аудитории .
• Удалено требование k-анонимности для URL-адреса ежедневного обновления .

Защищенная аудитория находится на стадии бета-тестирования и доступна для разработки.

С помощью Protected Audience вы можете:

• Управляйте индивидуальными аудиториями на основе предыдущих действий пользователей.
• Инициируйте аукционы на устройстве с поддержкой одного продавца или каскадной медиации.
• Осуществление отчетов о показах после выбора рекламы.

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

Хронология

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

Обзор

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

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

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

1. API пользовательской аудитории : это основано на абстракции «пользовательской аудитории», которая представляет собой аудиторию, назначенную рекламодателем, с общими намерениями. Информация об аудитории хранится на устройстве и может быть связана с соответствующими рекламными объявлениями-кандидатами для аудитории и произвольными метаданными, такими как сигналы ставок. Информацию можно использовать для информирования о ставках рекламодателя, фильтрации рекламы и рендеринга.
2. API выбора рекламы : предоставляет структуру, которая организует рабочие процессы рекламных технологических платформ, использующих сигналы на устройстве для определения «выигрышной» рекламы путем рассмотрения рекламных объявлений, хранящихся локально, и выполнения дополнительной обработки рекламных объявлений, которые рекламная технологическая платформа возвращает на устройство.

На высоком уровне интеграция работает следующим образом:

1. SportingGoodsApp хочет напомнить своим пользователям о необходимости покупки товаров, оставшихся в корзине, если они не завершили покупку в течение 2 дней. SportingGoodsApp использует API Custom Audience для добавления пользователя в список аудитории «продукты в корзине». Платформа управляет и хранит этот список аудитории на устройстве, ограничивая совместное использование с третьими лицами. SportingGoodsApp сотрудничает с платформой рекламных технологий для показа своей рекламы пользователям из своего списка аудитории. Платформа рекламных технологий управляет метаданными для списков аудитории и предоставляет объявления-кандидаты, которые предоставляются рабочему процессу выбора рекламы для рассмотрения. Платформу можно настроить на периодическую загрузку обновленных объявлений на основе аудитории в фоновом режиме. Это помогает поддерживать список объявлений-кандидатов на основе аудитории в актуальном состоянии и не коррелировать с запросами, отправляемыми на сторонние серверы рекламы во время возможности показа рекламы (т. е. запрос контекстной рекламы).

2. Когда пользователь играет в FrisbeeGame на том же устройстве, он может увидеть рекламу, напоминающую ему о необходимости завершить покупку товаров, оставшихся в корзине покупок SportingGoodsApp. Это может быть достигнуто с помощью FrisbeeGame (с интегрированным рекламным SDK), вызывающего API выбора рекламы , чтобы выбрать выигрышную рекламу для пользователя на основе любого списка аудитории, частью которого он может быть (в этом примере это пользовательская аудитория «продукты в корзине», созданная SportingGoodsApp). Рабочий процесс выбора рекламы можно настроить так, чтобы учитывать рекламу, полученную с серверов платформ рекламных технологий, в дополнение к рекламе на устройстве, связанной с пользовательскими аудиториями, а также другие сигналы на устройстве. Рабочий процесс также можно настроить с помощью платформ рекламных технологий и рекламного SDK с помощью пользовательской логики ставок и подсчета очков для достижения соответствующих рекламных целей. Такой подход позволяет использовать данные об интересах пользователя или взаимодействиях с приложением для информирования о выборе рекламы, ограничивая при этом передачу этих данных третьим лицам.

3. Приложение для показа рекламы или SDK рекламной технологической платформы отображает выбранное объявление.

4. Платформа облегчает отчетность о показах и результатах выбора рекламы . Эта возможность отчетности является дополнением к API отчетов об атрибуции . Платформы рекламных технологий могут настраиваться в зависимости от своих потребностей в отчетности.

Получите доступ к защищенной аудитории на API Android

Платформам Ad Tech необходимо зарегистрироваться для доступа к API Protected Audience. Для получения дополнительной информации см. раздел Регистрация для учетной записи Privacy Sandbox .

Индивидуальное управление аудиторией

Индивидуальная аудитория

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

Приложение рекламодателя или интегрированный SDK могут присоединяться к пользовательской аудитории или выходить из нее , например, на основе активности пользователя в приложении.

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

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

• Владелец: Имя пакета приложения-владельца. Это неявно установлено на имя пакета вызывающего приложения.
• Покупатель: Рекламная сеть покупателя, которая управляет рекламой для этой пользовательской аудитории. Покупатель также представляет сторону, которая может получить доступ к пользовательской аудитории и получить релевантную рекламную информацию. Покупатель указывается в соответствии с форматом eTLD+1.
• Имя: Произвольное имя или идентификатор для пользовательской аудитории, например, пользователь, у которого есть «покупатели, оставившие корзину». Этот атрибут может использоваться, например, как один из критериев таргетинга в рекламных кампаниях рекламодателя или строка запроса в URL для получения кода ставок.
• Время активации и время истечения срока действия: эти поля определяют временное окно, в течение которого эта пользовательская аудитория будет эффективна. Платформа использует эту информацию для отзыва членства из пользовательской аудитории. Время истечения срока действия не может превышать максимальное окно продолжительности, чтобы ограничить срок действия пользовательской аудитории.
• URL ежедневного обновления: URL, который платформа использует для получения объявлений-кандидатов и других метаданных, определенных в полях «Сигналы ставок пользователя» и «Доверенные сигналы ставок» на регулярной основе. Для получения дополнительных сведений см. раздел о том, как получить объявления-кандидаты для пользовательских аудиторий .
• Сигналы ставок пользователя: Сигналы, специфичные для рекламной платформы, для любых ставок ремаркетинговых объявлений. Примеры сигналов включают: грубое местоположение пользователя или предпочтительную локацию.
• Доверенные данные о ставках: платформы рекламных технологий полагаются на данные в реальном времени для информирования о поиске и оценке рекламы. Например, реклама может исчерпать бюджет и ее необходимо немедленно прекратить. Специалист по рекламе может определить конечную точку URL, откуда можно получить эти данные в реальном времени, и набор ключей, для которых необходимо выполнить поиск в реальном времени. Сервер, обрабатывающий этот запрос, будет доверенным сервером, управляемым платформой рекламных технологий.
• URL логики торгов: URL, который платформа использует для получения кода торгов с платформы спроса. Платформа выполняет этот шаг, когда инициируется аукцион объявлений .
• Реклама: список объявлений-кандидатов для пользовательской аудитории. Сюда входят метаданные рекламы, специфичные для платформы рекламных технологий, и URL-адрес для отображения рекламы. Когда для пользовательской аудитории инициируется аукцион, этот список метаданных рекламы будет рассмотрен. Этот список объявлений будет обновляться с использованием конечной точки URL ежедневного обновления, когда это возможно. Из-за ограничений ресурсов на мобильных устройствах существует ограничение на количество объявлений, которые можно сохранить в пользовательской аудитории.

Делегирование индивидуальной аудитории

Установленный подход к определению и настройке индивидуальной аудитории обычно опирается на серверные технологии и интеграции, управляемые рекламными технологиями в партнерстве с клиентами и партнерами агентств и рекламодателей. API защищенной аудитории позволяет определять и настраивать индивидуальную аудиторию, защищая конфиденциальность пользователей. Чтобы присоединиться к индивидуальной аудитории, рекламным технологиям покупателя, у которых нет SDK в приложениях, необходимо сотрудничать с рекламными технологиями, у которых есть присутствие на устройстве, например, с партнерами по мобильным измерениям (MMP) и платформами на стороне предложения (SSP). API защищенной аудитории направлено на поддержку этих SDK, предоставляя гибкие решения для управления индивидуальной аудиторией, позволяя вызывающим на устройстве пользователям вызывать создание индивидуальной аудитории от имени покупателей. Этот процесс называется делегированием индивидуальной аудитории . Настройте делегирование индивидуальной аудитории, выполнив следующие действия:

Присоединяйтесь к индивидуальной аудитории

Присоединиться к индивидуальной аудитории можно двумя способами:

joinCustomAudience()

Приложение или SDK может запросить присоединение к пользовательской аудитории, вызвав joinCustomAudience() после создания экземпляра объекта CustomAudience с ожидаемыми параметрами. Вот иллюстративный пример фрагмента кода:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

Приложение или SDK могут запросить присоединение к пользовательской аудитории от имени рекламного специалиста, у которого нет присутствия на устройстве, вызвав fetchAndJoinCustomAudience() с ожидаемыми параметрами, как в следующем примере:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

Конечная точка URL, принадлежащая покупателю, отвечает объектом JSON CustomAudience в теле ответа. Поля покупателя и владельца пользовательской аудитории игнорируются (и автоматически заполняются API). API также обеспечивает, чтобы URL ежедневного обновления также соответствовал eTLD+1 покупателя.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

API fetchAndJoinCustomAudience() определяет личность покупателя из eTLD+1 fetchUri . Личность покупателя CustomAudience используется для выполнения тех же проверок регистрации и авторизации приложения, которые выполняет joinCustomAudience() , и не может быть изменена ответом fetch. Владелец CustomAudience — это имя пакета вызывающего приложения. Нет никакой другой проверки fetchUri , кроме проверки eTLD+1, и, в частности, нет проверки k-anon. API fetchAndJoinCustomAudience() отправляет запрос HTTP GET к fetchUri и ожидает объект JSON, представляющий пользовательскую аудиторию. К ответу применяются те же обязательные, необязательные ограничения и значения по умолчанию для полей объекта пользовательской аудитории. Узнайте о текущих требованиях и ограничениях в нашем Руководстве разработчика.

Любой ответ об ошибке HTTP от покупателя приводит к сбою fetchAndJoinCustomAudience . В частности, ответ о состоянии HTTP 429 (слишком много запросов) блокирует запросы от текущего приложения на определенный период. Вызов API также завершается сбоем, если ответ от покупателя имеет неправильный формат. О сбоях сообщается вызывающей стороне API, ответственной за повторные попытки из-за временных сбоев (например, если сервер не отвечает) или обработку постоянных сбоев (например, сбоев проверки данных или других невременных ошибок при связи с сервером).

Объект CustomAudienceFetchRequest позволяет вызывающему API определять некоторую информацию для Custom Audience с помощью необязательных свойств, показанных в примере. Если они установлены в запросе, эти значения не могут быть перезаписаны ответом покупателя, полученным платформой; API Protected Audience игнорирует поля в ответе. Если они не установлены в запросе, то они должны быть установлены в ответе, так как эти поля необходимы для создания Custom Audience. JSON-представление содержимого CustomAudience , частично определенного вызывающим API, включено в запрос GET для fetchUri в специальном заголовке X-CUSTOM-AUDIENCE-DATA . Размер сериализованной формы данных, указанных для Custom Audience, ограничен 8 КБ. Если размер превышен, вызов API fetchAndJoinCustomAudience завершается ошибкой.

Отсутствие проверки k-anon позволяет использовать fetchUri для проверки покупателя и для включения обмена информацией между покупателем и SDK. Для упрощения проверки настраиваемой аудитории покупатель может предоставить токен проверки. SDK на устройстве должен включать этот токен в fetchUri , чтобы конечная точка, размещенная покупателем, могла извлекать содержимое настраиваемой аудитории и использовать токен проверки для проверки того, что операция fetchAndJoinCustomAudience() соответствует покупателю и исходит от доверенного партнера на устройстве. Для обмена информацией покупатель может договориться с вызывающей стороной на устройстве о том, что часть информации, которая будет использоваться для создания настраиваемой аудитории, будет добавлена ​​в качестве параметров запроса в fetchUri . Это позволяет покупателю проверять вызовы и определять, использовался ли токен проверки вредоносной рекламной технологией для создания нескольких различных настраиваемых аудиторий.

Примечание об определении и хранении проверочного токена

• Токен верификации не используется API защищенной аудитории ни для каких целей и является необязательным.

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

Оставьте пользовательскую аудиторию

Владелец индивидуальной аудитории может решить покинуть ее, вызвав метод leaveCustomAudience() , как показано в этом наглядном фрагменте кода:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

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

Пользовательский контроль

• Целью предложения является предоставление пользователям возможности просматривать список установленных приложений, которые создали хотя бы одну пользовательскую аудиторию.
• Пользователи могут удалять приложения из этого списка. Удаление очищает все пользовательские аудитории, связанные с приложениями, и не позволяет приложениям присоединяться к новым пользовательским аудиториям.
• Пользователи имеют возможность полностью сбросить API защищенной аудитории. Когда это происходит, все существующие пользовательские аудитории на устройстве очищаются.
• Пользователи имеют возможность полностью отказаться от Privacy Sandbox на Android, который включает в себя API Protected Audience. Если пользователь отказался от Privacy Sandbox, API Protected Audience автоматически откажет.

Разработка этой возможности находится в стадии разработки, подробности будут включены в более позднее обновление.

Запланированные обновления

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

Чтобы облегчить это, рекламный техник может вызвать scheduleCustomAudienceUpdate() API. Этот API позволяет вызывающему указать задержку, когда должен быть сделан вызов API, тем самым предоставляя дополнительное время для отвечающего рекламного техник для обработки событий на уровне приложения и определения того, к каким защищенным аудиториям пользователь должен присоединиться или из каких должен быть удален.

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

РасписаниеПользовательскаяАудиторияОбновлениеЗапрос

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

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

• UpdateUri : конечная точка URI, которая будет отправлена ​​вызовом GET для получения обновления. Идентификация покупателя по сути выводится из eTLD+1 и не должна быть явно указана и не может быть изменена ответом на обновление. Запрос GET ожидает объект JSON, содержащий список объектов customAudience в ответе.
• DelayTime : время, обозначающее задержку с момента выполнения вызова API scheduleCustomAudienceUpdate() для планирования обновления.

• PartialCustomAudience : API также позволяет SDK на устройстве отправлять список частично сконструированных Custom Audiences. Это позволяет SDK в приложении выполнять двойную роль: от полного до частичного контроля над управлением Custom Audience на основе их партнерства с DSP.

  • Это также обеспечивает совместимость данного API с API fetchAndJoinCustomAudience() , который позволяет осуществлять аналогичный обмен информацией.

• ShouldReplacePendingUpdates : Boolean, который определяет, следует ли отменить какие-либо запланированные обновления и заменить их обновлением, подробно описанным в текущем ScheduleCustomAudienceUpdateRequest . Если установлено значение false и есть ранее запрошенные обновления, все еще ожидающие выполнения для того же покупателя в том же приложении, вызов scheduleCustomAudienceUpdate с этим ScheduleCustomAudienceUpdateRequest завершится ошибкой. По умолчанию false .

Разрешения и контроль приложений

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

• Приложение может управлять своими связями с пользовательскими аудиториями.
• Приложение может предоставлять сторонним рекламным платформам разрешения на управление пользовательскими аудиториями от своего имени.

Разработка этой возможности находится в стадии разработки, подробности будут включены в более позднее обновление.

Управление платформой рекламных технологий

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

• Специалисты по рекламе регистрируются в Privacy Sandbox и предоставляют домен eTLD+1, который соответствует всем URL-адресам для индивидуальной аудитории.
• Технические специалисты по рекламе могут сотрудничать с приложениями или SDK для предоставления токенов проверки, которые используются для проверки создания пользовательской аудитории. Когда этот процесс делегируется партнеру, создание пользовательской аудитории можно настроить так, чтобы оно требовало подтверждения со стороны технического специалиста по рекламе.
• Специалист по рекламе может отключить вызовы joinCustomAudience от своего имени и разрешить API fetchAndJoinCustomAudience включать все вызовы пользовательских аудиторий. Элемент управления можно обновить во время регистрации в Privacy Sandbox. Обратите внимание, что элемент управления разрешает либо всех специалистов по рекламе, либо ни одного. Из-за ограничений платформы делегирование разрешений не может осуществляться на основе каждого специалиста по рекламе.

Кандидаты на рекламу и ответ на метаданные

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

• Метаданные: метаданные рекламных объявлений, специфичные для рекламных технологий, на стороне покупателя. Например, сюда может входить информация о рекламной кампании и критерии таргетинга, такие как местоположение и язык.
• URL-адрес рендеринга: конечная точка для рендеринга рекламного объявления.
• Фильтр: Необязательная информация, необходимая для API защищенной аудитории для фильтрации рекламы на основе данных на устройстве. Для получения более подробной информации прочитайте раздел о логике фильтрации на стороне покупки .

Рабочий процесс выбора рекламы

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

Сегодня рекламные технологические платформы обычно выполняют торги и выбор рекламы исключительно на своих серверах. С этим предложением пользовательские аудитории и другие чувствительные пользовательские сигналы, такие как информация о доступных установленных пакетах, будут доступны только через API выбора рекламы. Кроме того, для варианта использования ремаркетинга рекламные объявления-кандидаты будут извлекаться из полосы пропускания (т. е. не в контексте, в котором будет показываться реклама). Рекламным технологическим платформам необходимо будет подготовиться к развертыванию и выполнению некоторых частей их текущей логики аукциона и выбора рекламы на устройстве. Рекламные технологические платформы могут рассмотреть следующие изменения в своем рабочем процессе выбора рекламы:

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

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

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

1. Реализация логики торгов на стороне покупателя
2. Фильтрация и обработка рекламы на стороне покупателя
3. Реализация логики принятия решений на стороне продавца

Для выбора рекламы, включающей пользовательские аудитории, платформа будет извлекать JavaScript-код, предоставленный покупателем, на основе общедоступной конечной точки URL, определенной метаданными пользовательской аудитории "Bidding logic URL". Конечная точка URL для кода решения продавца также будет передана в качестве входных данных для инициирования рабочего процесса выбора рекламы.

Дизайн подборок объявлений, не предполагающих индивидуально настроенную аудиторию, находится в стадии активной разработки.

Инициировать рабочий процесс выбора рекламы

Когда приложению необходимо показать рекламу, SDK платформы рекламных технологий может инициировать рабочий процесс выбора рекламы, вызвав метод selectAds() после создания экземпляра объекта AdSelectionConfig с ожидаемыми параметрами:

• Продавец : идентификатор рекламной платформы на стороне продавца в формате eTLD+1.
• URL-адрес логики принятия решения : при запуске аукциона объявлений платформа будет использовать этот URL-адрес для извлечения кода JavaScript с платформы продавца, чтобы оценить выигрышное объявление.
• Покупатели с индивидуальной аудиторией : список платформ со стороны покупателя с индивидуальным спросом на основе аудитории для этого аукциона в формате eTLD+1.
• Сигналы выбора рекламы : Информация об аукционе (размер рекламы, формат рекламы и т. д.).
• Сигналы продавца : сигналы, специфичные для платформы предложения.
• URL-адрес доверенных сигналов оценки : конечная точка URL-адреса доверенного сигнала на стороне продавца, из которого можно получить конкретную информацию о креативе в режиме реального времени.
• Сигналы покупателя : участвующие стороны спроса могут использовать этот параметр для предоставления входных данных для аукциона. Например, этот параметр может включать в себя исчерпывающую контекстную информацию, полезную для определения ставок.

В следующем иллюстративном фрагменте кода показан SDK рекламной технологической платформы, который инициирует рабочий процесс выбора рекламы, сначала определяя AdSelectionConfig , а затем вызывая selectAds для получения победившей рекламы:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

Логика торгов на стороне покупателя

Логика ставок обычно предоставляется платформами на стороне покупателя. Цель кода — определить ставки для объявлений-кандидатов. Он может применять дополнительную бизнес-логику для определения результата.

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

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

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

Функция ожидает следующие параметры:

• Ad : Реклама, рассматриваемая кодом ставки покупателя. Это будет реклама из подходящей пользовательской аудитории
• Сигналы аукциона : сигналы со стороны продавца, специфические для платформы.
• Сигналы покупателя : участвующие стороны спроса могут использовать этот параметр для предоставления входных данных для аукциона. Например, этот параметр может включать в себя исчерпывающую контекстную информацию, полезную для определения ставок.
• Доверенные сигналы ставок : платформы рекламных технологий полагаются на данные в реальном времени для информирования о поиске и оценке рекламы. Например, рекламная кампания может исчерпать бюджет и ее необходимо немедленно остановить. Специалист по рекламе может определить конечную точку URL, из которой можно получить эти данные в реальном времени, и набор ключей, для которых необходимо выполнить поиск в реальном времени. Управляемый сервер платформы рекламных технологий, который обслуживает этот запрос, будет доверенным сервером, управляемым платформой рекламных технологий.
• Контекстные сигналы : это может быть укрупненная временная метка или приблизительная информация о местоположении, а также стоимость клика по объявлению.
• Пользовательские сигналы : сюда может входить такая информация, как информация о доступных установленных пакетах.

Стоимость рекламы

В дополнение к ставке, платформы buy-side имеют возможность возвращать стоимость за клик как часть generateBid() . Например:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

Если эта реклама победитель, adCost стохастически округляется до 8 бит для конфиденциальности. Округленное значение adCost затем передается в параметр contextual_signals в reportWin во время отчета о показах.

Логика фильтрации на стороне покупателя

Платформы Buy-side смогут фильтровать рекламу на основе дополнительных сигналов на устройстве, доступных на этапе выбора рекламы. Например, платформы ad tech могут реализовать здесь возможности ограничения частоты. Если есть несколько поставщиков фильтрации, система не гарантирует последовательность выполнения среди поставщиков.

Логику фильтрации на стороне покупателя можно реализовать как часть логики торгов , возвращая значение ставки 0 для данного объявления.

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

Логика оценки на стороне продавца

Логика оценки обычно предоставляется платформой на стороне продавца. Цель кода — определить выигрышное объявление на основе выходных данных логики торгов. Он может применять дополнительную бизнес-логику для определения результата. Если есть несколько поставщиков логики принятия решений, система не гарантирует последовательность выполнения среди поставщиков. Платформа будет использовать входной параметр «URL логики принятия решений» API selectAds() для извлечения кода JavaScript, который должен включать следующую сигнатуру функции:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

Функция ожидает следующие параметры:

• Ad : оцениваемое объявление; вывод функции generateBid() .
• Ставка : сумма ставки, выведенная функцией generateBid() .
• Конфигурация аукциона : Входной параметр для метода selectAds() .
• Сигналы доверенной оценки : платформы рекламных технологий используют данные в реальном времени для информирования о фильтрации и оценке рекламы. Например, издатель приложения может заблокировать показ рекламы в приложении рекламной кампанией. Эти данные извлекаются из параметра URL доверенных сигналов оценки конфигурации аукциона. Сервер, обслуживающий этот запрос, должен быть доверенным сервером, управляемым рекламными технологиями.
• Контекстный сигнал : может включать грубую временную метку или приблизительную информацию о местоположении.
• Пользовательский сигнал : может включать в себя такую ​​информацию, как магазин приложений, инициировавший установку приложения.
• Сигнал индивидуальной аудитории : если оцениваемое объявление исходит от индивидуальной аудитории на устройстве, он будет содержать такую ​​информацию, как читатель и название индивидуальной аудитории.

Время выполнения кода выбора объявления

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

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

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

Язык программирования

Код аукциона, предоставляемый платформой Ad Tech, должен быть написан на JavaScript. Это позволило бы платформам Ad Tech, например, совместно использовать код торгов на платформах, поддерживающих Privacy Sandbox.

Выигрышная визуализация рекламы

Реклама с наивысшим рейтингом считается победителем аукциона. В этом первоначальном предложении победившая реклама передается в SDK для рендеринга.

План состоит в том, чтобы усовершенствовать решение таким образом, чтобы информация о членстве пользователя в индивидуальной аудитории или истории взаимодействия с приложением не могла быть определена приложением или SDK на основе информации о победившем объявлении (аналогично предложению Chrome по закрытым рамкам) .

Отчеты о впечатлениях и событиях

После того, как реклама будет отрисована, выигрышный показ может быть передан обратно участвующим платформам покупателя и продавца. Это позволяет покупателям и продавцам включать информацию с аукциона, такую ​​как ставка или имя пользовательской аудитории, в отчет о выигрышном показе. Кроме того, платформа продавца и победившей платформы покупателя имеют право получать дополнительные отчеты на уровне событий о победившем объявлении. Это дает возможность включать информацию об аукционе (ставка, имя пользовательской аудитории и т. д.) с кликами, просмотрами и другими событиями рекламы. Платформа вызывает логику отчетности в следующем порядке:

1. Отчетность со стороны продавца.
2. Отчетность со стороны покупателя.

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

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

Защищенная аудитория обеспечивает механизм подписки на будущие события, связанные с победным аукционом, зарегистрировав маяки. В функции JavaScript Function Solder's reportResult() платформы на стороне продажи могут регистрировать маяки, используя функцию Platform's registerAdBeacon() . Аналогичным образом, платформы на стороне покупки могут вызвать метод registerAdBeacon() reportWin() их функции JavaScript.

registerAdBeacon(beacons)

Вход:

• event_key : строка, обозначающая тип взаимодействия для регистрации. Это используется в качестве ключа для поиска конечной точки, когда платформа пингает при сообщении о результатах аукциона.
• reporting_url : URL -адрес, принадлежащий Ad Tech Platform для обработки мероприятия.

Ключи событий-это идентификаторы строк, которые принадлежат SDK на стороне продажи, ответственной за сообщения о результатах аукциона. Для получения обратного вызова рекламных технологий регистрируют маяки с ключами, которые соответствуют ключам, используемым на стороне продажи при сообщении о событиях. Они не должны быть K-аноними, хотя существуют ограничения на количество и длину ключей, которые могут быть зарегистрированы для данной пользовательской аудитории. Если называется reportEvent() , платформы на стороне продажи, которые проводили аукцион, всегда имеют право на получение этих отчетов о событиях. Только выигрышная платформа для покупки имеет право на получение этих отчетов.

Отчеты о продаже

Платформа вызывает функцию javaScript функции reportResult() в коде, предоставленном на стороне снабжения, загруженной из параметра URL-адреса логики решений продавца для API selectAds() :

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Вывод: объект JSON, содержащий

• Статус: 0 для успеха, любое другое значение для неудачи.
• Отчетность URL: платформа вызывает этот URL -адрес, возвращаемый с функции.
• Сигналы для покупателя: объект JSON, который будет передан функции reportWin покупателя.

Сторона поставок может кодировать соответствующие сигналы в URL -адресах отчетности, чтобы помочь им получить дополнительную информацию об аукционе и победе. Например, это может включать сигналы, подобные этим:

• Ad revender url
• Выигрышная сумма ставки
• Имя приложения
• Идентификаторы запросов
• Сигналы для покупателя: Для поддержки обмена данными между стороной предложения и спросом платформы передают это возвратное значение в качестве входного параметра для кода отчетности по боковой отчетности.

Отчетность о покупке

Платформа вызывает функцию javaScript reportWin() в коде с спросом, загруженным с помощью метаданных URL-адресов логики ставок на пользовательскую аудиторию, связанную с аукционом.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

Вход:

• auction_signals и per_buyer_signals извлекаются из AuctionConfig . Любая информация, которую платформа на стороне покупки должна перейти в URL-адрес отчетности, может быть получена из этой даты.
• signals_for_buyer -это выходной репортаж на стороне продажи. Это предоставляет платформе на стороне продажи возможность поделиться данными с платформой на стороне покупки в целях отчетности.
• contextual_signals содержит такую информацию, как имя приложения и custom_audience_signals , содержит пользовательскую информацию о аудитории. Другая информация может быть добавлена в будущем.

Выход:

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

Сообщение о событиях

Отчетность о событиях возможна только после того, как отчет о впечатлениях на аукцион завершится. SDK на стороне продажи отвечает за сообщения о любых мероприятиях. Платформа раскрывает API, который принимает ReportEventRequest , который указывает недавно проведенный аукцион, представленное ключ события, данные, связанные с этим ключом, независимо от того, следует ли отправлять отчет покупателю или продавцу (или оба), и дополнительное входное событие для событий рекламы. Клиент определяет ключ события и сбор данных для отчета.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

Вход:

• ad_selection_id должен быть AdSelectionId недавно пробега аукциона, извлеченного из AdSelectionOutcome .
• event_key -это строка, определенная на стороне продажи, описывающую событие взаимодействия.
• event_data - это строка, представляющая данные, связанные с event_key
• reporting_destinations - это немного маски, установленная с использованием флагов, предоставленных платформой. Это может быть один из FLAG_REPORTING_DESTINATION_SELLER или FLAG_REPORTING_DESTINATION_BUYER , или оба.
• input_event (необязательно) используется для интеграции с API отчета о атрибуции. Это либо объект, InputEvent для того, что для клики), либо NULL (для события просмотра). См. Интеграция API отчета о атрибуции для получения более подробной информации об этом параметре.

После того, как SDK SDK вызывает reportEvent , и, в зависимости от флага reporting_destinations , платформа пытается сопоставить event_key с ключами, зарегистрированными покупателями и продавцами в их reportWin и reportResult JavaScript. Если есть совпадение, платформа публикует event_data в соответствующую reporting_url . content type запроса - это простой текст, и корпус - это event_data . Этот запрос предпринимается как наилучшее усилие и молча не сбои в случае сетевой ошибки, ответа на ошибку сервера или, если не было найдено подходящих клавиш.

Интеграция API отчета о атрибуции API

Чтобы поддержать покупателей, которые участвуют в аукционе защищенной аудитории, мы предоставляем функциональность Cross-API в области API-интерфейсов охраняемой аудитории и отчетов о атрибуции (ARA). Эта функциональность позволяет AD -технологиям оценивать свои характеристики атрибуции по различной тактике ремаркетинга, чтобы они могли понять, какие типы аудитории обеспечивают самый высокий ROI.

Благодаря этой кросс-афийской интеграции Adtechs Can:

• Создайте ключевую карту URI, которая будет использоваться как для 1) отчетности об взаимодействии AD, так и для регистрации источника.
• Включите данные аукциона из аукциона «Защищенная аудитория» в их картирование ключей на стороне исходной стороны для совокупных сводных отчетов (с использованием API отчета о атрибуции) См. Предложение ARA Design для получения дополнительной информации.

Когда пользователь видит или нажимает на объявление:

• URL -адрес, используемый для сообщений об этих взаимодействиях событий с использованием защищенной аудитории, предоставит необходимые данные покупателю, которые будут использоваться для регистрации представления или нажатия в качестве подходящего источника с API отчетности по атрибуции.
• AD Tech может выбрать передачу CustomAudience (или другую соответствующую контекстную информацию о рекламе, такой как размещение рекламы или продолжительность просмотра), используя этот URL -адрес, чтобы эти метаданные могли распространяться на сводные отчеты, когда AD Tech рассматривает агрегатную эффективность кампании.

Включение регистрации источника

InputEvent reportEvent() примет новый необязательный параметр. Победители покупателей, которые регистрируют рекламные маяки, могут выбрать, какие отчеты ReportEvent зарегистрированы в API -интерфейсах отчетов о атрибуции в качестве зарегистрированного источника. Во всех запросах, подходящих для атрибуции, будет добавлено во всех запросах отчетности о событиях, отправленных из reportEvent() . Любые ответы с соответствующими заголовками ARA будут анализироваться так же, как и любой другой обычный ответ на регистрацию источника ARA. См. Объяснитель API отчета о атрибуции для регистрации URL -адреса .

Поскольку ARA на Android поддерживает просмотр и щелчок события, InputEvents используются для различения двух типов. Как и в регистрации источника ARA, API reportEvent() будет интерпретировать, InputEvent платформу, в качестве события Click. Если InputEvent отсутствует, нулевой или недействительный, регистрация источника будет считаться представлением.

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

Пример отчетности о взаимодействии и конверсии

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

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

Рабочий процесс: Перед началом аукциона покупатель отправляет уникальному идентификатору продавцу в рамках своего ответа на программную заявку в реальном времени («RTB») . Идентификатор может быть установлен как переменная, такая как auctionId . Идентификатор передается в качестве perBuyerSignals в auctionConfig , и он становится доступным в логике торгов покупателя.

1. Во время выполнения reportWin покупатель может зарегистрировать рекламный маяк, который будет вызван во время AD рендеринга и для конкретных событий взаимодействия ( registerAdBeacon() ). Чтобы ассоциировать сигналы аукциона для рекламного события, установите auctionId в качестве параметра запроса URL.
2. Во время рендеринга рекламных маяков, которые вы зарегистрировали во время аукциона, могут быть вызваны или улучшены с помощью данных на уровне событий. Продавец должен запустить reportEvent() и передать данные на уровне событий. Платформа прописывает URL -адрес -маяк зарегистрированного рекламного маяка покупателя, который коррелирует с reportEvent() , который был запущен.
3. Покупатель зарегистрирует объявление с помощью API отчетности по атрибуции, ответив на запросы AD Meacon с помощью заголовка Attribution-Reporting-Register-Source . Чтобы ассоциировать сигналы аукциона для события конверсии, установите auctionId в URL -адресу источника регистра.

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

Аналогичный рабочий процесс применяется к продавцу, если он нуждается в доступе к данным атрибуции, и продавец также может использовать уникальный идентификатор для отправки с registerAdBeacon() . Вызов reportEvent() содержит свойство назначения, которое можно использовать для отправки отчета как покупателю, так и продавцу.

Ad Tech Platform управляется доверенным сервером

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

• Поведение этих серверов, описанных позже в этом разделе, не вытекало бы с информации пользователя.
• Серверы не будут создавать псевдонимные профили на основе данных, которые он видит, то есть их необходимо будет «доверять».

Сторона покупки : после того, как купить сторона инициирует логику торгов на стороне покупки, платформа выполняет HTTP -образные данные о доверенных данных о торгах с доверенного сервера. URL -адрес состоит из добавления URL и ключей, присутствующих в доверенных сигналах, которые обрабатывают пользовательскую аудиторию. Эта выборка выполняется только при обработке рекламы из пользовательской аудитории на устройстве. На данном этапе, купить сторона может обеспечить соблюдение бюджетов, проверить паузу для кампании / состояние, выполнять таргетинг и т. Д.

Это пример URL -адреса для получения доверенных данных, основанных на доверенных метаданных сигналах сигнала от пользовательской аудитории:

https://www.kv-server.example/getvalues?keys=key1,key2

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

Сторона продажи : аналогично этому потоку покупки, продавая сторона может захотеть получить информацию о креативщиках, рассматриваемой на аукционе. Например, издатель может захотеть обеспечить соблюдение того, что определенные креативщики не показаны в их приложении на основе проблем безопасности бренда. Эта информация может быть извлечена и предоставлена для логики аукциона Sell Side. Подобно поиску доверенного сервера, продавая, Sell Side Trusted Server также происходит с использованием HTTP. URL -адрес состоит из добавления URL -адреса доверенных сигналов оценки с помощью URL -адресов рендеринга креативщиков, для которых необходимо извлечь данные.

Ниже приведен пример URL для получения информации о креативщиках, рассматриваемых на аукционе, на основе творческих resend urls:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

Ответ с сервера должен быть объектом JSON, ключи которых являются рендеринговыми URL -адресами, отправленными в запросе.

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

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

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

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