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

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

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

Защищенная аудитория находится в стадии бета-тестирования и доступна для тестирования на общедоступных устройствах!

С помощью Защищенной аудитории вы можете:

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

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

Хронология

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Традиционное определение и настройка индивидуальной аудитории обычно опирается на серверные технологии и интеграцию, реализуемые рекламными технологиями в партнерстве с клиентами и партнерами агентств и рекламодателей. API Protected Audience позволяет определять и настраивать пользовательскую аудиторию, одновременно защищая конфиденциальность пользователей. Чтобы присоединиться к индивидуальной аудитории, специалистам по рекламе для покупателей, у которых нет SDK в приложениях, необходимо сотрудничать с рекламными специалистами, которые присутствуют на устройствах, например с партнерами по мобильным измерениям (MMP) и платформами предложения (SSP). API Protected Audience предназначен для поддержки этих 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-адреса, принадлежащая покупателю, отправляет в ответ объект CustomAudience JSON в тексте ответа. Поля «Покупатель» и «Владелец» пользовательской аудитории игнорируются (и заполняются 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() , и не может быть изменена ответом на выборку. Владельцем CustomAudience является имя пакета вызывающего приложения. Никакой другой проверки fetchUri , кроме проверки eTLD+1, и, в частности, проверки k-anon, не существует. API fetchAndJoinCustomAudience() выдает HTTP-запрос GET для fetchUri и ожидает объект JSON, представляющий пользовательскую аудиторию. К ответу применяются те же обязательные и необязательные ограничения и значения по умолчанию для полей объекта пользовательской аудитории. Узнайте о текущих требованиях и ограничениях в нашем Руководстве для разработчиков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы облегчить это, специалисты по рекламе могут вызвать API scheduleCustomAudienceUpdate() . Этот 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 на устройстве отправлять список частично созданных индивидуально настроенных аудиторий. Это позволяет встроенным в приложение SDK выполнять двойную роль: от полного до частичного контроля над управлением индивидуальной аудиторией на основе партнерства с DSP.

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

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

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

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

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

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

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

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

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

Объявления кандидатов и ответ на метаданные

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

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

Рабочий процесс выбора объявлений

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

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

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

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

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

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

Для выбранных объявлений, включающих пользовательскую аудиторию, платформа будет получать код JavaScript, предоставленный покупателем, на основе конечной точки общедоступного URL-адреса, определенной метаданными «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() возвращает рассчитанную сумму ставки. Платформа будет последовательно вызывать эту функцию для всех объявлений (контекстных или ремаркетинговых). При наличии нескольких поставщиков логики назначения ставок система не гарантирует последовательность выполнения между поставщиками.

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

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

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

В дополнение к ставке, платформы покупателя имеют возможность возвращать стоимость клика как часть 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 во время отчета о показах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код аукциона, предоставляемый платформой рекламных технологий, должен быть написан на JavaScript. Это позволит платформам рекламных технологий, например, обмениваться кодом ставок между платформами, поддерживающими 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 . Тип контента запроса - это простой текст, и корпус - это 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 рассматривает агрегатную эффективность кампании.

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

reportEvent() примет новый InputEvent параметр. Победители покупателей, которые регистрируют рекламные маяки, могут выбрать, какие отчеты 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 и для Интернета.