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

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

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

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

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

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

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

Здесь представлен общий обзор того, как работают защищенные сигналы приложений (Protected App Signals) для поддержки релевантной рекламы установки приложений. В следующих разделах этого документа более подробно описан каждый из этих шагов.

• Курирование сигналов : По мере использования пользователями мобильных приложений, рекламные технологии курируют сигналы, сохраняя определенные ими события приложения для показа релевантной рекламы с помощью API защищенных сигналов приложений. Эти события хранятся в защищенном хранилище на устройстве, аналогично пользовательским аудиториям , и шифруются перед отправкой с устройства, так что только сервисы торгов и аукционов, работающие в доверенных средах исполнения с соответствующим контролем безопасности и конфиденциальности, могут расшифровать их для назначения ставок и оценки рекламы.
• Кодирование сигналов : Сигналы подготавливаются по расписанию с помощью пользовательской логики рекламных технологий. Фоновая задача 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 ", созданных двумя разными приложениями.

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

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

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

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

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

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

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

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

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

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

Все ключи и значения представлены в формате Base64.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для инициирования выбора рекламы продавец передает список участвующих покупателей и зашифрованные данные сигналов защищенного приложения (Protected App Signals), хранящихся на устройстве. Используя эту информацию, рекламный сервер продавца подготавливает запрос SelectAdRequest для своего доверенного сервиса SellerFrontEnd .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

prepareDataForAdRetrieval() выполняет две задачи:

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

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

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

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

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

Функция getCandidateAds() выполняется в службе получения объявлений. Она получает запрос, созданный функцией prepareDataForAdRetrieval() в службе торгов покупателя. Служба выполняет getCandidateAds() , которая получает k лучших кандидатов для торгов, преобразуя запрос в серию запросов к наборам данных, извлекает данные и выполняет пользовательскую бизнес-логику и другую пользовательскую логику получения данных.

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

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

getCandidateAds() выполняет следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отчетность

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

One common use case for reporting on the buy-side is getting the training data for models used during ad selection. In addition to existing APIs, the platform will provide a specific mechanism for egressing event-level data from the platform to ad tech servers. These egress payloads can include certain user data.

In the long term, we are investigating privacy-preserving solutions to address model training with data used in Protected Auctions without sending event-level user data outside services running on TEEs. We will provide additional details in a later update.

In the short term, we will provide a temporary way to egress noised data from generateBid() . Our initial proposal for this follows, and we will evolve it (including possible backward-incompatible changes) in response to industry feedback.

Technically, the way this works is:

1. Ad techs define a schema for the data they want to transmit.
2. In generateBid() , they build their chosen egress payload.
3. The platform validates the egress payload against the schema and enforces size limits.
4. The platform adds noise to the egress payload.
5. The egress payload is included in the win report in wire format, received on ad tech servers, decoded, and used for model training.

Defining the schema of egress payloads

For the platform to enforce evolving privacy requirements, egress payloads must be structured in a way the platform can understand. Ad techs will define the structure of their egress payloads by providing a schema JSON file. That schema will be processed by the platform, and will be kept confidential by the Bidding and Auction services using the same mechanisms as other ad tech resources like UDFs and models.

We will provide a CDDL file that defines the structure of that JSON. The CDDL file will include a set of supported feature types (for example, features that are booleans, integers, buckets, and so on). Both the CDDL file and the provided schema will be versioned.

For example, an egress payload that consists of a single boolean feature followed by a bucket feature of size two would look something like:

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

Details on the set of supported feature types are available on GitHub .

Build egress payloads in generateBid()

All Protected App Signals for a given buyer are available to their generateBid() UDF. Once these are featurized, ad techs create their payload in JSON format. This egress payload will be included in the buyer's win report for transmission to ad tech servers.

An alternative to this design is for egress vector calculation to happen in reportWin() instead of generateBid() . There are trade-offs for each approach, and we'll finalize this decision in response to industry feedback.

Validate the egress payload

The platform will validate any egress payload created by the ad tech. Validation verifies that feature values are valid for their types, size constraints are met, and that malicious actors are not attempting to defeat privacy controls by packing additional information into their egress payloads.

If an egress payload is invalid, it will be silently discarded from the inputs sent to the win report. This is because we don't want to provide debugging information to any bad actor attempting to defeat validation.

We will provide a JavaScript API for ad techs to verify the egress payload they create in generateBid() will pass platform validation:

validate(payload, schema)

This JavaScript API is entirely for callers to determine if a particular payload will pass platform validation. Actual validation must be done in the platform to guard against malicious generateBid() UDFs.

Noise the egress payload

The platform will noise egress payloads before including them in the win report. The initial noise threshold will be 1%, and this value may evolve over time. The platform will provide no indication whether or not a particular egress payload has been noised.

The noising method is:

1. The platform loads the schema definition for the egress payload.
2. 1% of egress payloads will be chosen for noising.
3. If an egress payload is not chosen, the entire original value is retained.
4. If an egress payload is chosen, each feature's value will be replaced with a random valid value for that feature type (for example, either 0 or 1 for a boolean feature).

Transmitting, receiving, and decoding the egress payload for model training

The validated, noised egress payload will be included in the arguments to reportWin() , and transmitted to buyer ad tech servers outside the privacy boundary for model training. The egress payload will be in its wire format.

Details on the wire format for all feature types and for the egress payload itself are available on GitHub .

Determine the size of the egress payload

The size of the egress payload in bits balances utility and data minimization. We will work with industry to determine the appropriate size via experimentation. While we are running those experiments, we will temporarily egress data with no bit size limitation. That additional egress data with no bit size limitation will be removed once experiments are complete.

The method for determining size is:

1. Initially, we will support two egress payloads in generateBid() :
   1. egressPayload : the size-limited egress payload we've described so far in this document. Initially, this egress payload's size will be 0 bits (meaning it will always be removed during validation).
   2. temporaryUnlimitedEgressPayload : a temporary size-unlimited egress payload for size experiments. The formatting, creation, and processing of this egress payload uses the same mechanisms as egressPayload .
2. Each of these egress payloads will have its own schema JSON file: egress_payload_schema.json and temporary_egress_payload_schema.json .
3. We provide an experiment protocol and set of metrics for determining model utility at various egress payload sizes (for example, 5, 10, ... bits).
4. Based on experiment results, we determine the egress payload size with the correct utility and privacy trade-offs.
5. We set the size of egressPayload from 0 bits to the new size.
6. After a set migration period, we remove temporaryUnlimitedEgressPayload , leaving only egressPayload with its new size.

We are investigating additional technical guardrails for managing this change (for example, encrypting egressPayload when we increase its size from 0 bits). Those details -- along with timing for the experiment and the removal of temporaryUnlimitedEgressPayload -- will be included in a later update.

Next we'll explain a possible experiment protocol for finalizing the size of egressPayload . Our goal is to work with industry to find a size that balances utility and data minimization. The artifact these experiments will produce is a graph where the x-axis is the size of the training payload in bits, and the y-axis is the percentage of revenue generated by a model at that size compared to a size-unlimited baseline.

We'll assume we're training a pInstall model, and our sources of training data are our logs and the contents of the temporaryUnlimitedegressPayload s we receive when we win auctions. The protocol for ad-techs first involves offline experiments:

1. Determine the architecture of the models they will use with Protected App Signals. For example, they will need to determine whether or not they will use model factorization .
2. Define a metric for measuring model quality. Suggested metrics are AUC loss and log loss.
3. Define the set of features they will use during model training.
4. Using that model architecture, quality metric, and set of training features, run ablation studies to determine the utility contributed per bit for each model they want to use in PAS. The suggested protocol for the ablation study is:
   1. Train the model with all features and measure utility; this is the baseline for comparison.
   2. For each feature used to produce the baseline, train the model with all features except that feature.
   3. Measure resulting utility. Divide the delta by the size of the feature in bits; this is the expected utility per bit for that feature.
5. Determine the training payload sizes of interest for experimentation. We suggest [5, 10, 15, ..., size_of_all_training_features_for_baseline ] bits. Each of these represents a possible size for egressPayload that the experiment will evaluate.
6. For each possible size, select a set of features less than or equal to that size that maximize utility per bit, using the results of the ablation study.
7. Train a model for each possible size and evaluate its utility as a percentage of the utility of the baseline model trained on all features.
8. Plot the results on a graph where the x-axis is the size of the training payload in bits, and the y-axis is the percentage of revenue generated by that model compared to baseline.

Next, ad-techs can repeat steps 5-8 in live traffic experiments, using feature data sent via temporaryUnlimitedEgressPayload . Ad-techs can choose to share the results of their offline and live traffic experiments with Privacy Sandbox to inform the decision about the size of egressPayload .

The timeline for these experiments, as well as the timeline for setting the size of egressPayload to the resulting value, is beyond the scope of this document and will come in a later update.

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

We will apply a number of protections to egressed data, including:

1. Both egressPayload and temporaryUnlimitedEgressPayload will be noised.
2. For data minimization and protection temporaryUnlimitedEgressPayload will be available only for the duration of size experiments, where we will determine the correct size for egressPayload .

Разрешения

User control

• The proposal intends to give users visibility to the list of installed apps that have stored at least one Protected App Signal or a custom audience.
• Users can block and remove apps from this list. Block and removal does the following:
  • Clears all Protected App Signals and custom audiences associated with the app.
  • Prevents the apps from storing new Protected App Signals and custom audiences
• Users have the ability to reset the Protected App Signals and Protected Audience API completely. When this happens, any existing Protected App Signals and custom audiences on the device are cleared.
• Users have the ability to opt out completely from the Privacy Sandbox on Android, which includes the Protected App Signals API and Protected Audience API. When this is the case, the Protected Audience and Protected App Signals APIs return a standard exception message: SECURITY_EXCEPTION .

App permissions and control

The proposal intends to provide apps control over its Protected App Signals:

• An app can manage its associations with Protected App Signals.
• An app can grant third party ad tech platforms permissions to manage Protected App signals on its behalf.

Ad tech platform control

This proposal outlines ways for ad techs to control their Protected App Signals:

• All ad techs must enroll with the Privacy Sandbox and provide a "site" or "origin" domain which matches all URLs for Protected App Signals.
• Ad techs can partner with apps or SDKs to provide verification tokens that are used to verify creation of Protected App Signals. When this process is delegated to a partner, Protected App Signal creation can be configured to require acknowledgement by the ad tech.