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

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

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

Функция Protected Audience находится в стадии бета-тестирования и доступна для дальнейшей разработки.

С помощью функции «Защищенная аудитория» вы можете:

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

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

Хронология

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

Обзор

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

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

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

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

В общих чертах, интеграция работает следующим образом:

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

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

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

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

Получите доступ к функции «Защищенная аудитория» в Android API.

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

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

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

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

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

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

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

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

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

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

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

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

joinCustomAudience()

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

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

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

fetchAndJoinCustomAudience()

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

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

fetchAndJoinCustomAudience(fetchRequest);

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление пользователем

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

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

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

Описанные ранее решения требуют, чтобы приложение или 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)

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

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

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

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

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

Разрешения и управление приложениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Успешная визуализация рекламы

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

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

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

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

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

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

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

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 such as these:

• 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 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.

At the end of this 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 using these servers the proposal calls for the following restrictions:

• The behaviors of these servers, described later in this section, wouldn't leak user information.
• The servers wouldn't create pseudonymous profiles based on the data it sees, that is, 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.

This 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 this buy side flow, sell side may want to fetch information about creatives considered in the auction. For example, 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.

Following 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.