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

Услуги по проведению торгов и аукционов

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

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

Google предоставит компоненты B&A, и они будут доступны с открытым исходным кодом. Заинтересованные рекламные специалисты могут размещать свои собственные экземпляры у поддерживаемых поставщиков общедоступных облаков. Подробнее о предложении B&A можно прочитать на GitHub . Обратите внимание, что даты, представленные в этом документе, отражают реализацию Chrome, и в будущем мы опубликуем дополнительную информацию об интеграции с Android. Этот документ представляет собой введение в B&A и новые API-интерфейсы Android, которые будут предоставлены для взаимодействия с B&A. Мы опубликуем дополнительную техническую информацию о том, как использовать эти новые API в будущих обновлениях.

Где подходят услуги B&A

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

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

Основное различие заключается в том, где выполняется логика создания URL-адресов для ставок, оценки и отчетности. Вместо запуска логики торгов, аукциона и отчетности на устройстве, generateBid() , scoreAd() , reportResult() и reportWin() выполняется в TEE. Логика назначения ставок покупателя и логика оценки продавца выполняются в их собственной среде B&A, в середине аукциона Защищенной аудитории:

Иллюстрация, показывающая ход аукциона Защищенной аудитории и соотношение ставок и аукциона. — Ход аукциона «Защищенная аудитория»

Шифрование данных

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

Архитектура и аукционный поток

Это предложение включает в себя необходимость нескольких новых компонентов, подробно описанных на GitHub , включая поток данных от устройства к B&A .

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

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

На устройстве продавцы собирают информацию из Защищенной аудитории с помощью API getAdSelectionData .
SDK на устройстве отправляет запрос в службу Seller Ad . Этот запрос включает контекстную полезную нагрузку и зашифрованный ProtectedAudienceInput .
Служба рекламы продавца отправляет запрос в службу назначения ставок в реальном времени (RTB) покупателей, работающую за пределами TEE, для получения контекстных объявлений-кандидатов, а затем оценивает и выбирает выигрышное контекстное объявление.
Служба Seller Ad отправляет запрос в свою службу SellerFrontEnd , работающую в TEE.
Служба SellerFrontEnd отправляет запросы с конкретными данными покупателя в службы BuyerFrontEnd .
Покупатели используют собственную службу «ключ-значение» и службу назначения ставок , которая генерирует ставки для кандидатов на рекламу, полученных с устройства, для всех особых аудиторий, рассматриваемых для ремаркетинга.
Служба SellerFrontEnd считывает данные из своей службы «ключ-значение» и оценивает объявления-кандидаты. Результат шифруется и возвращается в сервис Seller Ad.
Служба рекламы продавца возвращает зашифрованный выигрышный результат и, при необходимости, контекстный результат в SDK на устройстве.
На устройстве продавцы получают выигрышное объявление с помощью API- processAdSelectionResult , который расшифровывает ответ от службы объявлений продавца.

Подробное описание каждого шага и способа шифрования данных можно найти на GitHub . Код этих компонентов будет доступен через открытый исходный код. Предоставленный код будет обрабатывать объединение запросов от службы SellerFrontEnd к службам BuyerFrontEnd.

Облачное развертывание

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

Запустить аукцион

Первым шагом к проведению аукциона B&A является сбор данных из индивидуально настроенных аудиторий на устройствах и их шифрование для отправки на аукционы на стороне сервера. Для этого используйте API getAdSelectionData :

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

Метод getAdSelectionData генерирует необходимые входные данные для компонентов B&A, таких как BuyerInput и ProtectedAudienceInput , и шифрует данные, прежде чем сделать результат доступным вызывающей стороне. Чтобы предотвратить утечку данных из приложений, эти данные содержат информацию обо всех покупателях, присутствующих на устройстве. Подробнее об этом решении читайте в разделе «Соображения конфиденциальности» .

Этот API возвращает объект AdSelectionData :

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Используя этот AdSelectionData , SDK на устройстве может отправить запрос в свою службу Seller Ad, включив данные в запрос POST или PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

За кодирование этих данных отвечает встроенный в устройство SDK. Рекомендуется использовать решение, позволяющее эффективно использовать пространство, например отправку запроса в службу Seller Ad в виде multipart/form-data .

После инициирования запроса служба Seller Ad перенаправляет запрос службе SellerFrontEnd, работающей в TEE. При настройке службы SellerFrontEnd продавцы предоставляют список доменных адресов, соответствующих службам BuyerFrontEnd, управляемым покупателями, с которыми продавец является партнером. Запросы будут объединены с различными службами BuyerFrontEnd, предоставленными продавцом, чтобы покупатели могли формировать ставки для выбранных ими рекламных кандидатов. Для конкретного покупателя B&A будет отправлять информацию только о индивидуализированных аудиториях, принадлежащих покупателю, чтобы не было перекрестной утечки данных между покупателями. После формирования ставок список объявлений-кандидатов возвращается в сервис SellerFrontEnd, где выбирается победитель. Наконец, служба SellerFrontEnd возвращает зашифрованное выигрышное объявление на устройство.

Получив ответ на запрос к сервису Seller Ad на устройстве, платформа предлагает второй новый API для расшифровки результата и предоставления AdSelectionOutcome — того же объекта, который сегодня возвращается с аукциона на устройстве.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Отчетность

URL-адреса отчетов будут созданы в сервисах B&A. Пинги на эти URL-адреса для отчетности о показах и взаимодействиях на аукционах по-прежнему необходимо будет запускать на устройстве. SDK на устройстве по-прежнему потребуется вызывать API reportImpression() и reportInteraction() используя AdSelectionId , сгенерированный во время потока B&A. Маяки, созданные для отчетов о взаимодействии, и соответствующие URL-адреса содержатся в зашифрованном ответе, поэтому во время расшифровки ответа события и сопоставления URL-адресов сохраняются на устройстве.

Вопросы конфиденциальности

Предложение API для ставок и аукционов в браузере на GitHub описывает, как учитываются вопросы конфиденциальности. В этом предложении используется номенклатура Chrome, но те же принципы применимы и к Android.

adSelectionData шифруется, чтобы обеспечить доступность передаваемых данных только для PPAPI и доверенных серверов. Чтобы снизить риск утечки данных из-за изменения размера adSelectionData , мы планируем генерировать одни и те же adSelectionData для всех вызовов API getAdSelectionData . Это означает, что все CustomAudience на устройстве используются для создания adSelectionData . Мы также планируем ограничить влияние входных параметров GetAdSelectionData на генерируемые adSelectionData .

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