Защищенные сигналы приложений для поддержки релевантных объявлений об установке приложений

Это предложение подлежит процессу регистрации и аттестации Privacy Sandbox. Для получения дополнительной информации об аттестациях обратитесь к предоставленной ссылке на аттестацию . Будущие обновления этого предложения будут описывать требования для получения доступа к этой системе.

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

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

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

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

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

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

• Курирование сигналов : поскольку пользователи используют мобильные приложения, специалисты по рекламе курируют сигналы, сохраняя определенные специалистами по рекламе события приложений для показа релевантной рекламы с использованием API защищенных сигналов приложений. Эти события хранятся в защищенном хранилище на устройстве, аналогичном Custom Audiences , и шифруются перед отправкой с устройства, так что только службы торгов и аукционов, работающие в средах Trusted Execution с соответствующим контролем безопасности и конфиденциальности, могут расшифровать их для торгов и оценки рекламы.
• Кодирование сигнала : сигналы подготавливаются по расписанию с помощью пользовательской технологической логики рекламы. Фоновое задание Android выполняет эту логику для выполнения кодирования на устройстве с целью создания полезной нагрузки защищенных сигналов приложений, которые впоследствии могут использоваться в режиме реального времени для выбора рекламы во время защищенного аукциона. Полезная нагрузка надежно хранится на устройстве до отправки на аукцион.
• Выбор рекламы : чтобы выбрать релевантную рекламу для пользователя, SDK продавца отправляет зашифрованную полезную нагрузку защищенных сигналов приложений и настраивает защищенный аукцион. На аукционе пользовательская логика покупателя подготавливает защищенные сигналы приложений вместе с предоставленными издателем контекстными данными (данные, которые обычно передаются в запросе рекламы Open-RTB ) для разработки функций, предназначенных для выбора рекламы (поиск рекламы, вывод и генерация ставок). Подобно защищенной аудитории , покупатели отправляют рекламу продавцу для окончательной оценки на защищенном аукционе.
  • Поиск рекламы : покупатели используют защищенные сигналы приложений и предоставленные издателем контекстные данные для разработки функций, соответствующих интересам пользователя. Эти функции используются для сопоставления объявлений, соответствующих критериям таргетинга. Объявления, не входящие в бюджет, отфильтровываются. Затем для торгов выбираются k лучших объявлений.
  • Торги : Логика индивидуальных торгов покупателей подготавливает предоставленные издателем контекстные данные и сигналы защищенных приложений для разработки функций, которые используются в качестве входных данных для моделей машинного обучения покупателей для вывода и торгов по рекламным объявлениям-кандидатам в рамках доверенных границ сохранения конфиденциальности. Затем покупатель возвращает выбранное им объявление продавцу.
  • Оценка продавцов : индивидуальная логика оценки продавцов оценивает объявления, представленные участвующими покупателями, и выбирает победившее объявление, которое отправляется обратно в приложение для рендеринга.
• Отчетность : Участники аукциона получают соответствующие отчеты о выигрышах и отчеты о проигрышах. Мы изучаем механизмы сохранения конфиденциальности для включения данных для обучения модели в отчет о выигрышах.

Хронология

Отслеживайте сигналы защищенных приложений

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

API защищенных сигналов приложений

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

В этом примере демонстрируется скалярный сигнал и сигнал временного ряда, связанный с adtech1.com :

• Скалярный сигнал с ключом значения base64 " A1c " и значением " c12Z ". Хранилище сигналов было запущено com.google.android.game_app 1 июня 2023 года .
• Список сигналов с ключом « dDE », созданных двумя разными приложениями.

Ad techs выделяется определенное количество места для хранения сигналов на устройстве. Сигналы будут иметь максимальный TTL, который должен быть определен.

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

API защищенных сигналов приложений состоит из следующих частей:

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

Добавить, обновить или удалить сигналы

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

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

Поддерживаемые команды JSON:

• put: вставляет или переопределяет скалярное значение для указанного ключа.
• put_if_not_present: вставляет скалярное значение для заданного ключа, если значение еще не сохранено. Эта опция может быть полезна, например, для установки идентификатора эксперимента для заданного пользователя и избежания его переопределения, если он уже установлен другим приложением.
• append: добавляет элемент к временному ряду, связанному с заданным ключом. Параметр maxSignals указывает максимальное количество сигналов во временном ряду. Если размер превышен, более ранние элементы удаляются. Если ключ содержит скалярное значение, он автоматически преобразуется во временной ряд.
• удалить: удаляет содержимое, связанное с указанным ключом.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Все ключи и значения выражены в Base64.

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

Сохраненные сигналы автоматически связываются с приложением, выполняющим запрос на выборку, и ответчиком запроса («сайт» или «источник» зарегистрированной рекламной технологии), а также временем создания запроса. Все сигналы подлежат хранению от имени зарегистрированной рекламной технологии Privacy Sandbox , URI «сайт»/«источник» должен соответствовать данным зарегистрированной рекламной технологии. Если запрашивающая рекламная технология не зарегистрирована, запрос отклоняется.

Квота хранения и выселение

У каждой рекламной технологии есть ограниченное количество места на пользовательском устройстве для хранения сигналов. Эта квота определяется для каждой рекламной технологии, поэтому сигналы, отобранные из разных приложений, делят квоту. Если квота превышена, система очищает пространство, удаляя более ранние значения сигналов по принципу «первым пришел — первым ушел». Чтобы предотвратить слишком частое выполнение вытеснения, система реализует логику пакетирования, чтобы разрешить ограниченное количество превышения квоты и очистить некоторое дополнительное пространство после срабатывания логики вытеснения.

Кодирование данных на устройстве для передачи

Для подготовки сигналов для выбора рекламы настраиваемая логика per buyer имеет защищенный доступ к сохраненным сигналам и событиям per app. Фоновое задание системы Android запускается ежечасно для выполнения настраиваемой логики кодирования per buyer, которая загружается на устройство. Настраиваемая логика кодирования per buyer кодирует сигналы per app, а затем сжимает сигналы per app в полезную нагрузку, которая соответствует квоте per buyer. Затем полезная нагрузка шифруется в пределах защищенного хранилища устройства, а затем передается в службы торгов и аукционов.

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

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

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

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

С этим предложением пользовательский код ad tech может получить доступ только к защищенным сигналам приложений в защищенном аукционе (API выбора рекламы), запущенном в TEE. Для дальнейшей поддержки потребностей в сценарии использования установки приложения, объявления-кандидаты извлекаются во время защищенного аукциона в режиме реального времени. Это контрастирует со сценарием использования ремаркетинга, где объявления-кандидаты известны до аукциона.

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

Рабочий процесс выбора объявлений выглядит следующим образом:

1. SDK продавца отправляет на устройство зашифрованные данные сигналов защищенного приложения.
2. Сервер продавца создает конфигурацию аукциона и отправляет ее в службу доверенных торгов и аукционов продавца вместе с зашифрованной полезной нагрузкой для инициирования рабочего процесса выбора объявлений .
3. Служба торгов и аукционов продавца передает полезную нагрузку на серверы доверенных покупателей, участвующих в торгах.
4. Служба торгов покупателя выполняет логику выбора рекламы на стороне покупателя
   1. Реализация логики поиска рекламы на стороне покупателя .
   2. Реализация логики торгов на стороне покупателя .
5. Выполняется логика оценки на стороне продавца .
6. Реклама отображается и инициируется отчет .

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

Когда приложение готово к показу рекламы, SDK рекламных технологий (обычно SSP) инициирует рабочий процесс выбора рекламы, отправляя любые соответствующие контекстные данные от издателя и зашифрованные полезные данные для каждого покупателя, которые должны быть включены в запрос, отправляемый на защищенный аукцион с помощью вызова getAdSelectionData . Это тот же API, который используется для рабочего процесса ремаркетинга и описан в предложении Bidding And Auction Integration for Android .

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

Продавец устанавливает следующее:

• Полезная нагрузка, полученная от getAdSelectionData , которая содержит защищенные сигналы приложения.

• Контекстные сигналы с использованием:

  • auction_config.auction_signals (для информации об аукционе )

  • auction_config.seller_signals (для сигналов продавца)

  • auction_config.per_buyer_config["buyer"].buyer_signals (для сигналов покупателей )

• Список покупателей, включенных в аукционы с использованием поля buyer_list .

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

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

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

1. Служба BuyerFrontEnd получает запрос на рекламу.
2. Служба BuyerFrontEnd отправляет запрос в службу торгов покупателя. Служба торгов покупателя запускает UDF, называемую prepareDataForAdRetrieval() , которая создает запрос для получения k лучших кандидатов из службы поиска рекламы. Служба торгов отправляет этот запрос в настроенную конечную точку сервера поиска.
3. Служба поиска объявлений запускает пользовательскую функцию getCandidateAds() , которая фильтрует набор из k лучших объявлений-кандидатов, которые отправляются в службу торгов покупателя.
4. Служба торгов покупателя запускает пользовательскую функцию generateBid() , которая выбирает лучшего кандидата, вычисляет его ставку, а затем возвращает ее службе BuyerFrontEnd.
5. Сервис BuyerFrontEnd возвращает объявления и ставки продавцу.

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

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

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

Служба поиска рекламы внутренне включает службу «ключ-значение». Специалисты по рекламе могут материализовать пары «ключ-значение» в эту службу со своих собственных серверов, за пределами границ конфиденциальности. Мы предоставим JavaScript API для специалистов по рекламе, чтобы они могли читать из этой службы «ключ-значение» из UDF, работающих в службе поиска рекламы. В отличие от службы торгов покупателя, служба поиска рекламы не содержит службу вывода.

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

Факторизация модели

Факторизация модели — это метод, который позволяет разбить одну модель на несколько частей, а затем объединить эти части в прогноз. В случае использования App Install модели часто используют три вида данных: пользовательские данные, контекстные данные и рекламные данные.

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

Это делает возможным следующую конструкцию:

1. Разбейте модель на частную часть (данные пользователя) и одну или несколько общедоступных частей (контекстные и рекламные данные).
2. При желании можно передать некоторые или все нечастные части в качестве аргументов в UDF, которая должна делать прогнозы. Например, контекстные вложения передаются в UDF в per_buyer_signals .
3. При желании специалисты по рекламе могут создавать модели для нечастных частей, а затем материализовать вложения из этих моделей в хранилище ключей и значений Ad Retrieval Service. UDF в Ad Retrieval Service могут извлекать эти вложения во время выполнения.
4. Чтобы сделать прогноз во время UDF, объедините приватные вложения из службы вывода с не приватными вложениями из аргументов функции UDF или хранилища ключей и значений с помощью операции типа скалярного произведения. Это окончательное предсказание.

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

Пользовательская функция prepareDataForAdRetrieval()

Функция prepareDataForAdRetrieval() запущенная в службе торгов покупателя, отвечает за создание полезной нагрузки запроса, которая будет отправлена ​​в службу поиска объявлений для извлечения k лучших объявлений-кандидатов.

prepareDataForAdRetrieval() принимает следующую информацию:

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

prepareDataForAdRetrieval() выполняет две функции:

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

prepareDataForAdRetrieval() возвращает:

• Защищенные сигналы приложений : полезная нагрузка сигналов, подобранных с помощью рекламных технологий.
• Сигналы, специфичные для аукциона : сигналы со стороны продавца, специфичные для платформы, и контекстная информация, такая как auction_signals и per_buyer_signals (включая контекстные вставки) из SelectAdRequest . Это похоже на Protected Audiences .
• Дополнительные сигналы : дополнительная информация, например, частные вложения, полученные из службы вывода.

Этот запрос отправляется в службу поиска рекламы, которая выполняет сопоставление кандидатов, а затем запускает пользовательскую функцию getCandidateAds() .

Пользовательская функция getCandidateAds()

getCandidateAds() запускается в Ad Retrieval Service. Он получает запрос, созданный prepareDataForAdRetrieval() в службе торгов покупателя. Служба выполняет getCandidateAds() , который извлекает top-k кандидатов для торгов, преобразуя запрос в серию заданных запросов, выборок данных и выполняя пользовательскую бизнес-логику и другую пользовательскую логику поиска.

getCandidateAds() принимает следующую информацию:

• Защищенные сигналы приложений : полезная нагрузка сигналов, подобранных с помощью рекламных технологий.
• Сигналы, специфичные для аукциона : сигналы со стороны продавца, специфичные для платформы, и контекстная информация, такая как auction_signals и per_buyer_signals (включая контекстные вставки) из SelectAdRequest . Это похоже на Protected Audiences .
• Дополнительные сигналы : дополнительная информация, например, частные вложения, полученные из службы вывода.

getCandidateAds() делает следующее:

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

Обратите внимание, что оценка для рекламы может быть результатом предиктивной модели, которая, например, предсказывает вероятность установки пользователем приложения. Этот тип генерации оценок включает своего рода факторизацию модели : поскольку getCandidateAds() работает на Ad Retrieval Service, а у Ad Retrieval Service нет службы вывода, прогнозы могут быть сгенерированы путем комбинирования:

• Контекстные вложения передаются с использованием входных сигналов, специфичных для аукциона .
• Частные вложения передаются с использованием дополнительных входных сигналов .
• Любые неконфиденциальные вставки, которые рекламные технологии материализовали со своих серверов в сервис «ключ-значение» Службы поиска рекламы.

Обратите внимание, что функция generateBid() UDF, которая работает на сервисе торгов покупателя, может также применять свой собственный тип факторизации модели для прогнозирования торгов. Если для этого требуются какие-либо вложения из сервиса «ключ-значение», их необходимо извлечь сейчас.

getCandidateAds() возвращает:

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

Мы изучаем другие методы предоставления рекламы для оценки, включая предоставление ее в качестве части вызова SelectAdRequest . Эти объявления могут быть получены с помощью запроса RTB-ставки. Обратите внимание, что в таких случаях объявления должны быть получены без защищенных сигналов приложений. Мы ожидаем, что специалисты по рекламе оценят компромиссы, прежде чем выбрать лучший вариант, включая размер полезной нагрузки ответа, задержку, стоимость и доступность сигналов.

Пользовательская функция generateBid()

После того, как вы извлекли набор объявлений-кандидатов и вложений во время извлечения, вы готовы перейти к торгам, которые выполняются в службе торгов покупателя. Эта служба запускает предоставленную покупателем UDF generateBid() для выбора объявления для ставки из первых k, а затем возвращает его с его ставкой.

generateBid() принимает следующую информацию:

• Кандидатные объявления : первые k объявлений, возвращенных службой поиска объявлений.
• Сигналы, специфичные для аукциона : сигналы со стороны продавца, специфичные для платформы, и контекстная информация, такая как auction_signals и per_buyer_signals (включая контекстные вставки) из SelectAdRequest .
• Дополнительные сигналы : дополнительная информация, которая будет использоваться во время торгов.

Реализация generateBid() покупателя выполняет три действия:

• Признакизация : преобразует сигналы в признаки для использования при выводе.
• Вывод : генерирует прогнозы с использованием моделей машинного обучения для расчета таких значений, как прогнозируемые показатели кликов и конверсии.
• Торги : объединение предполагаемых значений с другими входными данными для расчета ставки за рекламный ролик-кандидат.

generateBid() возвращает:

• Объявление кандидата.
• Его расчетная сумма ставки.

Обратите внимание, что generateBid() используемый для рекламы установки приложений, и generateBid(), используемый для рекламы ремаркетинга, различаются.

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

Осуществление функций

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

Вывод

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

Клиенты могут предоставить ряд моделей машинного обучения вместе с их реализацией generateBid() . Мы также предоставим JavaScript API в generateBid() чтобы клиенты могли выполнять вывод во время выполнения.

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

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

Реализовать факторизацию модели

Ранее мы объясняли факторизацию модели . Во время торгов конкретный подход таков:

1. Разбейте единую модель на частную часть (пользовательские данные) и одну или несколько общедоступных частей (контекстные и рекламные данные).
2. Передайте нечастные части в generateBid() . Они могут поступать либо из per_buyer_signals , либо из вложений, которые рекламные специалисты вычисляют извне, материализуются в хранилище ключей и значений службы поиска, извлекаются во время поиска и возвращаются как часть дополнительных сигналов. Это не включает частные вложения, поскольку они не могут быть получены из-за пределов конфиденциальности.
3. В generateBid() :
   1. Выполняйте выводы на основе моделей, чтобы получить частные пользовательские вложения.
   2. Объедините частные пользовательские вложения с контекстными вложениями из per_buyer_signals или нечастной рекламой и контекстными вложениями из службы поиска, используя операцию типа скалярного произведения. Это окончательное предсказание, которое можно использовать для расчета ставок.

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

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

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

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

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

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

Отчетность

В этом предложении используются те же API-интерфейсы отчетов, что и в предложении отчетов Protected Audience (например, reportImpression() , который запускает отправку платформой отчетов о продавцах и покупателях).

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

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

В краткосрочной перспективе мы предоставим временный способ выхода в уход нученных данных из generateBid() . Наше первоначальное предложение для этого следует, и мы развиваем его (включая возможные обратно-несогласные изменения) в ответ на обратную связь с отрасли.

Технически, как это работает:

1. AD Techs определяют схему для данных, которые они хотят передать.
2. В generateBid() они создают выбранную ими выходную полезную нагрузку.
3. Платформа подтверждает выходную нагрузку против схемы и обеспечивает соблюдение пределов размера.
4. Платформа добавляет шум к полезной нагрузке.
5. Выходная полезная нагрузка включена в отчет о WIN в формате WIRE, полученный на технических серверах AD, декодировал и используется для модельной подготовки.

Определение схемы выходных нагрузок

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

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

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

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Подробная информация о наборе поддерживаемых типов функций доступна на GitHub .

Построить выходные полезные нагрузки в generateBid()

Все защищенные сигналы приложения для данного покупателя доступны для их generateBid() UDF. После того, как они станут вклад, рекламные технологии создают свою полезную нагрузку в формате JSON. Эта выходная полезная нагрузка будет включена в отчет о победе покупателя для передачи на AD Tech Servers.

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

Проверить выходную полезную нагрузку

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

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

Мы предоставим API JavaScript API для AD Techs, чтобы проверить выходную полезную нагрузку, которую они создают в generateBid() пройдет проверка платформы:

validate(payload, schema)

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

Шум выходная полезная нагрузка

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

Метод ноуминга:

1. Платформа загружает определение схемы для выходной полезной нагрузки.
2. 1% выходных нагрузок будут выбраны для затруднения.
3. Если выходная нагрузка не выбрана, все исходное значение сохраняется.
4. Если выбранная полезная нагрузка, значение каждой функции будет заменено на случайное допустимое значение для этого типа функции (например, либо 0 , либо 1 для логической функции).

Передача, получение и декодирование выходной нагрузки для обучения модели

Уверенная, нученная выходная полезная нагрузка будет включена в аргументы в отношении reportWin() и передана на технические серверы покупателя AD за пределами границы конфиденциальности для обучения модели. Выходная полезная нагрузка будет в его формате провода.

Подробная информация о формате провода для всех типов функций и самой полезной нагрузки доступна на GitHub .

Определите размер выходной нагрузки

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

Метод определения размера:

1. Первоначально мы будем поддерживать две выходные нагрузки в generateBid() :
   1. egressPayload : выходная полезная нагрузка, ограниченная размером, мы описали до сих пор в этом документе. Первоначально, размер этой выходной полезной нагрузки будет 0 бит (то есть он всегда будет удален во время проверки).
   2. temporaryUnlimitedEgressPayload : временная выплата по выходу, не имеющая размера, для экспериментов по размеру. Форматирование, создание и обработка этой выходной полезной нагрузки используют те же механизмы, что и egressPayload .
2. Каждая из этих выходных нагрузок будет иметь свою собственную схему файла json: egress_payload_schema.json и temporary_egress_payload_schema.json .
3. Мы предоставляем протокол эксперимента и набор метрик для определения утилиты модели при различных размерах полевой нагрузки (например, 5, 10, ... биты).
4. На основе результатов эксперимента мы определяем размер полезной нагрузки с правильными компромиссами и конфиденциальностью.
5. Мы устанавливаем размер egressPayload от 0 битов до нового размера.
6. После установленного периода миграции мы удаляем temporaryUnlimitedEgressPayload , оставляя только egressPayload с его новым размером.

Мы исследуем дополнительные технические ограждения за управление этим изменением (например, шифруем egressPayload , когда увеличиваем его размер от 0 битов). Эти детали - наряду с временем для эксперимента и удалением temporaryUnlimitedEgressPayload разгрузки загрузки - будут включены в более позднее обновление.

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

Мы предполагаем, что мы обучаем модель Pinstall, и наши источники учебных данных являются наши журналы и содержимое temporaryUnlimitedegressPayload выгрузки, которое мы получаем, когда выигрываем аукционы. Протокол для AD-технологий сначала включает в себя эксперименты в автономном режиме:

1. Определите архитектуру моделей, которые они будут использовать с защищенными сигналами приложения. Например, им нужно будет определить, будут ли они использовать факторизацию модели .
2. Определите метрику для измерения качества модели. Предлагаемыми показателями являются потеря AUC и потеря лог.
3. Определите набор функций, которые они будут использовать во время обучения модели.
4. Используя эту модельную архитектуру, показатель качества и набор обучающих функций, запустите исследования абляции, чтобы определить утилиту, внесенную за бит для каждой модели, которую они хотят использовать в PAS. Предлагаемый протокол для исследования абляции:
   1. Обучить модель со всеми функциями и измерить утилиту; Это базовая линия для сравнения.
   2. Для каждой функции, используемой для производства базовой линии, тренируйте модель со всеми функциями, кроме этой функции.
   3. Мера, полученная в результате полезности. Разделите дельту на размер функции в битах; Это ожидаемая утилита за бит для этой функции.
5. Определите учебные размеры полезной нагрузки процентов для экспериментов. Мы предлагаем [5, 10, 15, ..., size_of_all_training_features_for_baseline ] биты. Каждый из них представляет собой возможный размер для egressPayload , который будет оценивать эксперимент.
6. Для каждого возможного размера выберите набор функций, менее или равных такому размеру, которые максимизируют утилиту за бит, используя результаты исследования абляции.
7. Обурите модель для каждого возможного размера и оцените ее полезность в процентах от утилиты базовой модели, обученной на всех функциях.
8. Постройте результаты на графике, где ось X-это размер обучающей полезной нагрузки в битах, а ось Y-это процент дохода, полученной этой моделью по сравнению с базовой линией.

Затем, AD-Techs могут повторять шаги 5-8 в экспериментах по живым трафикам, используя данные о функциях, отправленные через temporaryUnlimitedEgressPayload . AD-Techs могут поделиться результатами своих автономных и живых экспериментов с трафиком с песочницей конфиденциальности, чтобы проинформировать решение о размере egressPayload .

Сроки для этих экспериментов, а также временная шкала для установки размера egressPayload для полученного значения, выходит за рамки этого документа и будет в более позднем обновлении.

Меры защиты данных

Мы применим ряд защитных данных для перемещенных данных, в том числе:

1. Как egressPayload , так и temporaryUnlimitedEgressPayload будут чувакой.
2. Для минимизации данных и защиты temporaryUnlimitedEgressPayload будет доступна только на время экспериментов по размеру, где мы определим правильный размер для egressPayload .

Разрешения

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

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

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

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

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

Управление платформой AD Tech

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

• Все рекламные технологии должны зарегистрироваться в песочнице конфиденциальности и предоставить домен «сайт» или «Origin», который соответствует всем URL -адресам для сигналов защищенных приложений.
• AD Techs могут сотрудничать с приложениями или SDK для предоставления токенов проверки, которые используются для проверки создания сигналов защищенных приложений. Когда этот процесс делегирован партнеру, может быть настроено создание сигнала защищенного приложения, чтобы требовать подтверждения технологией AD.