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

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

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

• Добавлена ​​информация о планировании обновлений индивидуальной аудитории.
• Добавлена ​​интеграция отчетов по атрибуции с защищенными аудиториями.
• Опубликован график работы функций защищенной аудитории.
• 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() , который позволяет обмениваться аналогичной информацией.

• ShodleReplacePendingUpdates : логическое значение, которое определяет, следует ли отменить любые ожидающие запланированные обновления и заменить их обновлением, подробно описанным в текущем 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 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 generateBid() .
• Bid : сумма ставки, выводимая из функцииgenerateBid 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() .

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 и для Интернета.

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

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

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

С защищенной аудиторией вы можете:

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

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

Хронология

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

Обзор

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

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

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

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

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

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

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

3. SDK SDK от Ad-Serving или Ad Tech Platform производит выбранное объявление.

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

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

AD Tech Plateries должны зарегистрироваться для доступа к API защищенной аудитории. См. Зарегистрируется для учетной записи песочницы конфиденциальности для получения дополнительной информации.

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

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

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

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

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

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

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

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

Традиционное определение и конфигурацию аудитории обычно опираются на технологии и интеграции на стороне сервера, обусловленные рекламными технологиями в партнерстве с клиентами и партнерами и партнерами по рекламе. Защищенная аудитория API обеспечивает пользовательское определение аудитории и конфигурацию при защите конфиденциальности пользователей. Чтобы присоединиться к пользовательской аудитории, покупателя AD Techs, которые не имеют присутствия 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, принадлежащая покупателю, отвечает объектом CustomAudience JSON в органе ответа. Поля покупателей и владельца пользовательской аудитории игнорируются (и автозаполнены API). API также обеспечивает соблюдение того, что URL -адрес Daily Update также будет соответствовать 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 Status 429 (слишком много запросов) блокирует запросы из текущей приложения на определенный период. Вызов API также терпит неудачу, если ответ от покупателя узоренен. Отказы сообщаются об API-абоненту, ответственному за повторение, из-за временных сбоев (например, сервер не отвечают) или обработку постоянных сбоев (например, сбои проверки данных или другие не трансляционные ошибки с общением с сервером).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/**
* 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)

ScheduleCustomaUdienceUpdateRequest

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 может содержать следующую информацию:

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

• PartialCustomaUdience : API также позволяет SDK на устройстве отправлять список частично построенной пользовательской аудитории. Это позволяет SDK в приложении выполнять двойную роль, от полного до частичного контроля над пользовательским управлением аудиторией на основе их партнерства с DSPS.

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

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

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

The proposal intends to provide apps control over its custom audiences:

• An app can manage its associations with custom audiences.
• An app can grant third-party ad tech platforms permissions to manage custom audiences on its behalf.

The design of this capability is a work in progress, and the details will be included in a later update.

Ad tech platform control

This proposal outlines ways for ad techs to control their custom audiences:

• Ad techs enroll with the Privacy Sandbox and provide an eTLD+1 domain which matches all URLs for a custom audience.
• Ad techs can partner with apps or SDKs to provide verification tokens that are used to verify a custom audience creation. When this process is delegated to a partner, custom audience creation can be configured to require acknowledgement by the ad tech.
• An ad tech can choose to deactivate joinCustomAudience calls on their behalf and only allow the fetchAndJoinCustomAudience API to enable all call custom audiences. Control can be updated during Privacy Sandbox enrollment. Note the control allows either all ad techs or none. Due to platform limitations, delegation permissions can't be on a per ad tech basis.

Candidate ads and metadata response

Candidate ads and metadata returned from a buy-side platform should include the following fields:

• Metadata: Buy-side, ad tech-specific ads metadata. For example, this may include information about the ad campaign, and targeting criteria such as location and language.
• Render URL: Endpoint for rendering the ad creative.
• Filter: Optional information necessary for the Protected Audience API to filter ads based on on-device data. For more details, read the section on buy side filtering logic .

Ad selection workflow

This proposal aims to improve privacy by introducing the Ad Selection API, which orchestrates auction execution for ad tech platforms.

Ad tech platforms today typically perform bidding and ad selection exclusively on their servers. With this proposal, custom audiences and other sensitive user signals, such as available installed package information, will be accessible only through the Ad Selection API. Additionally for the remarketing use case candidate ads will be fetched out of band (ie not in the context in which ads will be shown). Ad tech platforms will need to prepare to have some parts of their current auction and ad selection logic deployed and executed on the device. Ad tech platforms may consider the following changes to their ad selection workflow:

• Without installed package information available on the server, ad tech platforms may want to send multiple contextual ads back to the device and invoke the ad selection workflow to enable app install-based filtering in order to maximize chances to show a relevant ad.
• Because remarketing ads are fetched out of band, current bidding models may need to be updated. Ad tech platforms may want to create bidding sub-models (the implementation may be based on a pattern called two-tower model) that can work on ads features and contextual signals separately and combine the sub-model outputs on the device to predict bids. This can benefit from both server-side auctions and auctions for any given ad opportunity.

This approach enables the user's app interactions data to inform ads selection, while limiting the sharing of this data with third-parties.

This ad selection workflow orchestrates the on-device execution of ad tech-provided JavaScript code based on the following sequence:

1. Buy-side bidding logic execution
2. Buy-side ad filtering and processing
3. Sell-side decision logic execution

For ad selections that involve custom audiences, the platform will fetch buy side-provided JavaScript code based on the public URL endpoint defined by the custom audience's "Bidding logic URL" metadata. The URL endpoint for sell-side decision code will also be passed as an input to initiate the ad selection workflow.

The design of ad selections that don't involve custom audiences is under active design.

Initiate ad selection workflow

When an app needs to show an ad, the ad tech platform SDK may initiate the ad selection workflow by calling the selectAds() method after instantiating the AdSelectionConfig object with the expected parameters:

• Seller : Identifier for the sell-side ad platform, following the eTLD+1 format
• Decision logic URL : When an ad auction is initiated, the platform will use this URL to fetch JavaScript code from the sell-side platform to score a winning ad.
• Custom audience buyers : A list of buy-side platforms with custom audience-based demand for this auction, following the eTLD+1 format.
• Ad selection signals : Information about the auction (ad size, ad format etc.).
• Seller signals : Supply side platform specific signals.
• Trusted Scoring Signals URL : URL endpoint of sell-side trusted signal from which creative specific realtime information can be fetched from.
• Per buyer signals : Participating demand sides may use this parameter to provide inputs for the auction. For example, this parameter may include comprehensive contextual information useful for determining bids.

The following illustrative code snippet shows an ad tech platform SDK initiating the ad selection workflow by first defining the AdSelectionConfig and then invoking selectAds to get the winning Ad:

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);

Buy-side bidding logic

The bidding logic is typically provided by buy-side platforms. The purpose of the code is to determine bids for candidate ads. It may apply additional business logic to determine the result.

The platform will use the custom audience's "Bidding logic URL" metadata to fetch the JavaScript code which should include the function signature below:

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

The generateBid() method returns the calculated bid amount. The platform will invoke this function for all ads (contextual or remarketing) sequentially. If there are multiple bidding logic providers, the system does not guarantee the execution sequence among the providers.

The function expects the following parameters:

• Ad : The ad being considered by the buy-side bidding code. This will be an Ad from an eligible custom audience
• Auction signals : Sell-side, platform-specific signals.
• Per buyer signals : Participating demand sides may use this parameter to provide inputs for the auction. For example, this parameter may include comprehensive contextual information useful for determining bids.
• Trusted bidding signals : Ad tech platforms rely on real-time data to inform ad retrieval and scoring. For instance, an ad campaign may run out of budget and needs to be stopped serving immediately. An Ad-tech can define a URL endpoint from where this real-time data can be fetched and the set of keys for which the real-time lookup needs to be performed. The ad tech platform's managed server that serves this request will be a trusted server managed by the ad tech platform.
• Contextual signals : This may include coarsened timestamp or approximate location information, or cost per click on the ad.
• User signals : This may include information such as available installed package information.

Ad cost

In addition to the bid, buy-side platforms have the option to return the cost per click as part of generateBid() . Например:

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

If this ad is the winner, adCost is stochastically rounded to 8 bits for privacy. The rounded value of adCost is then passed into the contextual_signals parameter in reportWin during impression reporting.

Buy-side filtering logic

Buy-side platforms will be able to filter ads based on additional on-device signals available during the ad selection phase. For example, ad tech platforms can implement frequency capping capabilities here. If there are multiple filtering providers, the system does not guarantee the execution sequence among the providers.

The buy-side filtering logic can be implemented as part of the bidding logic by returning a bid value of 0 for a given ad.

In addition to that, buy-side platforms will be able to signal that a given ad should be filtered based on additional on-device signals available to Protected Audience and that won't leave the device. As we solidify the designs of additional filtering logic, buy-side platforms will follow this same structure to signal that the filtering should happen.

Sell-side scoring logic

The scoring logic is typically provided by the sell-side platform. The purpose of the code is to determine a winning ad based on bidding logic outputs. It may apply additional business logic to determine the result. If there are multiple decision logic providers, the system does not guarantee the execution sequence among the providers. The platform will use the "Decision logic URL" input parameter of the selectAds() API to fetch the JavaScript code which should include the function signature below:

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

The function expects the following parameters:

• Ad : The Ad being evaluated; output from the generateBid() function.
• Bid : Bid amount output from the generateBid() function.
• Auction config : Input parameter to selectAds() method.
• Trusted Scoring Signals : Ad tech platforms rely on real-time data to inform ad filtering and scoring. For instance, an app publisher may block an ad campaign from showing ads in the app. This data is fetched from trusted scoring signals url parameter of the auction configuration. The server serving this request should be an ad tech-managed trusted server.
• Contextual signal : This may include coarsened timestamp or approximate location information.
• User signal : This may include information such as the app store that initiated the installation of the app.
• Custom audience signal : If the Ad being scored is coming from an on-device custom audience, this will contain information such as the reader and name of the custom audience.

Ad selection code runtime

In the proposal, the system will fetch ad tech platform-provided auction code from configurable URL endpoints and execute on the device. Given the resource constraints on mobile devices, auction code should adhere to the following guidelines:

• The code should finish executing in a predefined amount of time. This bound will apply uniformly to all buyer ad networks. Details of this bound will be shared in a later update.
• The code must be self-contained and not have any external dependencies.

Since the auction code, such as the bidding logic may need access to private user data such as app install sources, the runtime will not provide network or storage access.

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

Ad tech platform-provided auction code should be written in JavaScript. This would allow ad tech platforms to, for example, share bidding code across platforms that support Privacy Sandbox.

Winning ad rendering

The ad with the highest score is considered the winner of the auction. In this initial proposal, the winning ad is passed into the SDK for rendering.

The plan is to evolve the solution to ensure that information about a user's custom audience membership, or app engagement history, cannot be determined by the app or SDK through information about the winning ad (similar to Chrome's fenced frames proposal) .

Impression and event reporting

Once the ad has been rendered, the winning impression can be reported back to participating buy-side and sell-side platforms. This allows buyers and sellers to include information from the auction, such as the bid or custom audience name, with the winning impression report. Additionally, the sell-side and winning buy-side platform are eligible to receive additional event-level reporting about the winning ad. This provides the ability to include information about the auction (bid, custom audience name etc.) with clicks, views and other ad events. The platform invokes reporting logic in this order:

1. Sell-side reporting.
2. Buy-side reporting.

This gives buy-side and sell-side platforms a way to send important on-device information back to the servers to enable capabilities like real time budgeting, bidding model updates, and accurate billing workflows. This impression reporting support is complementary to the Attribution Reporting API .

There are two steps required to support event reporting: Sell-side and buy-side JavaScript needs to register what event it should receive event reports for, and the sell-side is responsible for reporting event-level information.

Protected Audience provides a mechanism to subscribe to future events related to a winning auction by registering beacons. In a seller's reportResult() JavaScript function, sell-side platforms can register beacons using the platform's registerAdBeacon() function. Similarly, buy-side platforms can call the registerAdBeacon() method from their reportWin() JavaScript function.

registerAdBeacon(beacons)

Вход:

• event_key : A string denoting which interaction type to register for. This is used as a key to look up the endpoint the platform pings while reporting the results of the auction.
• reporting_url : The URL owned by the ad tech platform for handling the event.

Event keys are string identifiers that are owned by the sell-side SDK responsible for reporting the results of the auction. For a callback to be made, ad techs register beacons with keys that match the keys used by the sell-side when reporting the events. These don't need to be k-anonymous, though there are limits to the quantity and length of keys that can be registered for a given custom audience. If reportEvent() is called, sell-side platforms that ran the auction are always eligible to receive these event reports. Only the winning buy-side platform is eligible to receive these reports.

Sell-side reporting

The platform invokes the reportResult() JavaScript function in the supply side-provided code downloaded from the seller's Decision logic URL parameter for the selectAds() API:

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}};
}

Output: A JSON object containing

• Status: 0 for success, any other value for failure.
• Reporting URL: The platform invokes this URL returned from the function.
• Signals for Buyer: A JSON object to be passed to the buyer's reportWin function.

The supply side may encode relevant signals in the reporting URL to help them gain further insights into the auction and winning ad. For example, it may include signals below:

• Ad render URL
• Winning bid amount
• Название приложения
• Query identifiers
• Signals for buyer: To support data sharing between supply side and demand side, the platform passes this return value as an input parameter to demand side reporting code.

Buy-side reporting

The platform invokes the reportWin() JavaScript function in the demand side-provided code downloaded from the Bidding logic URL metadata of the custom audience associated with the auction.

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 and per_buyer_signals are fetched from AuctionConfig . Any information that the buy-side platform needs to pass into the reporting URL may come from this datum.
• signals_for_buyer is the output of the sell-side reportResult. This provides the sell-side platform with an opportunity to share data with the buy-side platform for reporting purposes.
• contextual_signals contains information such as app name and custom_audience_signals contains the custom audience information. Other information may be added in the future.

Выход:

• Status: 0 for success, any other value for failure.
• Reporting URL: The platform invokes this URL returned from the function.

Reporting Events

Reporting events is only possible after impression reporting for the auction has completed. The sell-side SDK is responsible for reporting any events. The platform exposes an API that takes a ReportEventRequest that specifies the recently run auction, the event key that is reported, the data associated with that key, whether the report should be sent to the buyer or the seller (or both), and an optional input event for ad events. The client defines the event key and collection of data to report.

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 needs to be an AdSelectionId of a recently run auction retrieved from the AdSelectionOutcome .
• event_key is a sell-side defined string describing the interaction event.
• event_data is a string representing the data associated with the event_key
• reporting_destinations is a bit mask set using flags provided by the platform. It can be one of FLAG_REPORTING_DESTINATION_SELLER or FLAG_REPORTING_DESTINATION_BUYER , or both.
• input_event (optional) is used for integration with Attribution Reporting API. It is either an InputEvent object (for a click event) or null (for a view event). See Attribution Reporting API Integration for more details on this parameter.

After the sell-side SDK invokes reportEvent and, depending on the reporting_destinations flag, the platform attempts to match the event_key to the keys registered by buyers and sellers in their reportWin and reportResult JavaScript functions. If there is a match, the platform POSTs the event_data to the associated reporting_url . The content type of the request is plain text with the body being the event_data . This request is made as best effort and fails silently in the event of a network error, server error response, or if no matching keys were found.

Attribution Reporting API integration

To support buyers who participate in a Protected Audience auction, we are providing cross-API functionality across the Protected Audience and Attribution Reporting APIs (ARA). This functionality enables ad techs to evaluate their attribution performance across various remarketing tactics, so that they can understand which types of audiences deliver the highest ROI.

Through this cross-API integration, adtechs can:

• Create a key-value map of URIs to be used for both 1) ad interaction reporting and 2) source registration.
• Include auction data from the Protected Audience auction in their source-side key mapping for aggregate summary reporting (using the Attribution Reporting API) See the ARA design proposal for more information.

When a user sees or clicks on an ad:

• The URL used to report those events interactions using Protected Audience will provide the necessary data to the buyer to be used to register a view or click as an eligible source with the Attribution Reporting API.
• The ad tech may choose to pass CustomAudience (or other relevant contextual information about the ad such as ad placement or view duration) using that URL so this metadata can propagate down to summary reports when the ad tech is reviewing aggregate campaign performance.

Enabling source registration

reportEvent() will accept a new optional parameter InputEvent . Winning buyers who register ad beacons can choose which reportEvent reports get registered with Attribution Reporting APIs as a registered source. The request header Attribution-Reporting-Eligible will be added to all event reporting requests sent from reportEvent() . Any responses with appropriate ARA headers will be parsed in the same way any other regular ARA source registration response would be. See Attribution Reporting API explainer for how to register a source URL .

Because ARA on Android supports view and click events, InputEvents are used to distinguish between the two types. Just as in ARA source registration, the reportEvent() API will interpret a platform-verified InputEvent as a click event. If the InputEvent is missing, null, or invalid, the source registration will be considered a view.

Note the post-auction eventData may contain sensitive information, so the platform drops the eventData in redirected source registration requests.

Engagement and conversion reporting example

In this example, we'll look at it from the buyer perspective who is interested in associating the data from the auction, rendered ad, and conversion app together.

In this workflow, the buyer coordinates with the seller to send a unique ID into the auction. During the auction, the buyer sends this unique ID with the auction data. During render and conversion time, the data from the rendered ad is also sent out with the same unique ID. Later, the unique ID can be used to associate these reports together.

Workflow: Before the auction starts, the buyer sends a unique ID to the seller as part of their programmatic real-time bidding ("RTB") bid response . The ID can be set as a variable like auctionId . The ID is passed in as perBuyerSignals in the auctionConfig and it becomes available in buyer's bidding logic.

1. During the execution of reportWin , the buyer can register an ad beacon to be triggered during ad render time and for specific interaction events ( registerAdBeacon() ). To associate auction signals for an ad event, set the auctionId as a query param of the beacon URL.
2. During ad render time, the beacons you registered during auction time can be triggered or enhanced with event-level data. The seller must trigger reportEvent() and pass in the event-level data. The platform will ping the buyer's registered ad beacon URL that correlates with the reportEvent() that was triggered.
3. The buyer will register the ad with the Attribution Reporting API by responding to the ad beacon requests with the Attribution-Reporting-Register-Source header. To associate auction signals for a conversion event, set the auctionId in the Register source URL.

After the above process, the buyer will have an auction report, interaction report, and conversion report, that can be correlated using the unique ID that can be used to associate with each other.

Similar workflow applies to a seller if it needs access to attribution data, and the seller can also use a unique ID to send with registerAdBeacon() . The reportEvent() call contains a destination property that can be used to send the report to both the buyer and the seller.

Ad tech platform managed trusted server

Ad selection logic today requires real-time information such as budget depletion status to determine if ad candidates should be selected for auction. Both buy-side and sell-side platforms will be able to get this information from servers they operate. In order to minimize leak of any sensitive information via these servers the proposal calls for the following restrictions:

• The behaviors of these servers, described later in this section, would not leak user information.
• The servers would not create pseudonymous profiles based on the data it sees, ie it will need to be 'trusted'.

Buy side : Once buy side initiates the buy side bidding logic, the platform performs an HTTP fetch of trusted bidding data from the trusted server. The URL is composed by appending the URL and keys present in the Trusted Bidding Signals metadata of the custom audience being processed. This fetch is done only when processing ads from the on device custom audiences. At this stage, buy side can enforce budgets, check for campaign pause / unpause state, perform targeting, etc.

Below is a sample URL to fetch trusted bidding data, based on trusted bidding signal metadata from the custom audience:

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

The response from the server should be a JSON object whose keys are key1, key2, etc., and whose values will be made available to the buyer's bidding functions.

Sell side : Similar to the buy side flow above, sell side may want to fetch information about creatives considered in the auction. For instance, a publisher may want to enforce that certain creatives are not shown in their app based on brand safety concerns. This information can be fetched and made available to the sell side auction logic. Similar to the buy side trusted server lookup, sell side trusted server lookup also happens using an HTTP fetch. The URL is composed by appending the Trusted Scoring Signals URL with render URLs of the creatives for which the data needs to be fetched.

Below is a sample URL to fetch information about creatives considered in the auction, based on creative render URLs:

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

Response from the server should be a JSON object whose keys are render URLs sent in the request.

These servers would operate in a trusted way to offer several security and privacy benefits:

• The server's return value for each key can be trusted to be based only on that key.
• The server does not perform event-level logging.
• The server has no other side effects based on these requests.

As a temporary mechanism, the buyer and seller can fetch these bidding signals from any server, including one they operate themselves. However, in the release version, the request will only be sent to a trusted key-value-type server.

Buyers and sellers could use a common trusted key-value-type server for platforms compatible with Privacy Sandbox on Android and for the Web.