Эта страница переведена с помощью Cloud Translation API.

Защищенные сигналы приложений для поддержки релевантной рекламы, ориентированной на установку приложения.

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

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

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

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

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

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

Схема, показывающая процесс установки приложения с защищенными сигналами — Блок-схема, показывающая сигналы защищенных приложений и рабочий процесс выбора рекламы в Privacy Sandbox на Android.

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

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

Хронология

	Предварительный просмотр для разработчиков			Бета
Особенность	4 квартал 23 г.	1 квартал 24 г.	2 квартал 24 г.	3 квартал 2024 г.
API курирования сигналов	API-интерфейсы хранилища на устройстве	Логика квотирования хранилища на устройстве Ежедневные обновления пользовательской логики на устройстве	Н/Д	Доступно для устройств 1% T+
Сервер поиска рекламы в TEE	MVP	Доступно в GCP Поддержка Топ К производство UDF	Доступно на AWS Согласованная отладка, метрики и мониторинг
Служба вывода в TEE Поддержка запуска моделей ML и их использования для ставок в TEE.	В разработке	Доступно в GCP Возможность развертывания и прототипирования статических моделей ML с использованием Tensorflow и PyTorch.	Доступно на AWS Развертывание промышленной модели для моделей Tensorflow и PyTorch. Телеметрия, согласованная отладка и мониторинг
Поддержка торгов и аукционов в TEE	Доступно в GCP	Интеграция получения рекламы PAS-B&A и TEE (с шифрованием gRPC и TEE<>TEE) Поддержка поиска рекламы через контекстный путь (включая поддержку B&A<>K/V в TEE)	Доступно на AWS Отчеты об отладке Согласованная отладка, метрики и мониторинг

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

Сигнал – это представление различных действий пользователя в приложении, которые рекламные технологии определяют как полезные для показа релевантной рекламы. Приложение или интегрированный 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 поддерживает делегирование, аналогичное делегированию пользовательской аудитории Protected Audience.

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

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

put: вставляет или переопределяет скалярное значение для данного ключа.
put_if_not_present: вставляет скалярное значение для данного ключа, если уже не сохранено значение. Эта опция может быть полезна, например, для установки идентификатора эксперимента для данного пользователя и предотвращения его переопределения, если он уже был установлен другим приложением.
добавление: добавляет элемент во временной ряд, связанный с данным ключом. Параметр 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 «сайт»/«источник» должен совпадать с данными зарегистрированной рекламной технологии. Если запрашивающая рекламная технология не зарегистрирована, запрос отклоняется.

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

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

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

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

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

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

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

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

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

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

Иллюстрация рабочего процесса выбора объявлений. — Рабочий процесс выбора объявлений в Privacy Sandbox на Android.

Порядок отбора объявлений следующий:

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

Запустить рабочий процесс выбора объявлений

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

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

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

Полезная нагрузка, полученная от getAdSelectionData , которая содержит сигналы защищенного приложения.
Контекстуальные сигналы с использованием:
- auction_config.auction_signals (для получения информации об аукционе )
- auction_config.seller_signals (для сигналов продавца
- auction_config.per_buyer_config["buyer"].buyer_signals (для сигналов покупателей )
Список покупателей , участвующих в аукционах, с использованием поля buyer_list .

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

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

Иллюстрация логики выполнения выбора рекламы со стороны покупателя. — Логика выполнения выбора рекламы со стороны покупателя в Privacy Sandbox на Android.

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

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

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

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

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

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

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

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

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

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

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

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

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

`prepareDataForAdRetrieval()`

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

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

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

prepareDataForAdRetrieval() делает две вещи:

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

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

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

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

Пользовательская `getCandidateAds()`

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

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

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

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

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

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

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

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

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

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

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

Пользовательская `generateBid()`

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

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

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

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

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

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

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

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

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

Характеристики

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

Вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

Отчетность

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

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

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

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

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

AD Techs определяют схему для данных, которые они хотят передать.
В generateBid() они строят свою желаемую выходную полевую нагрузку.
Платформа подтверждает выходную нагрузку против схемы и обеспечивает соблюдение пределов размера.
Платформа добавляет шум к полезной нагрузке.
Выходная полезная нагрузка включена в отчет о 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% выходных нагрузок будут выбраны для затруднения.
Если выходная нагрузка не выбрана, все исходное значение сохраняется.
Если выбранная полезная нагрузка, значение каждой функции будет заменено на случайное допустимое значение для этого типа функции (например, либо 0 , либо 1 для логической функции).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разрешения

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

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

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

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

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

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

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

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