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

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

В предложении служб торгов и аукционов (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 .

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

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

1. На устройстве продавцы собирают информацию из Защищенной аудитории с помощью API getAdSelectionData .
2. SDK на устройстве отправляет запрос в службу Seller Ad . Этот запрос включает контекстную полезную нагрузку и зашифрованный ProtectedAudienceInput .
3. Служба рекламы продавца отправляет запрос в службу назначения ставок в реальном времени (RTB) покупателей, работающую за пределами TEE, для получения контекстных объявлений-кандидатов, а затем оценивает и выбирает выигрышное контекстное объявление.
4. Служба Seller Ad отправляет запрос в свою службу SellerFrontEnd , работающую в TEE.
5. Служба SellerFrontEnd отправляет запросы с конкретными данными покупателя в службы BuyerFrontEnd .
6. Покупатели используют собственную службу «ключ-значение» и службу назначения ставок , которая генерирует ставки для кандидатов на рекламу, полученных с устройства, для всех особых аудиторий, рассматриваемых для ремаркетинга.
7. Служба SellerFrontEnd считывает данные из своей службы «ключ-значение» и оценивает объявления-кандидаты. Результат шифруется и возвращается в сервис Seller Ad.
8. Служба рекламы продавца возвращает зашифрованный выигрышный результат и, при необходимости, контекстный результат в SDK на устройстве.
9. На устройстве продавцы получают выигрышное объявление с помощью 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 для всех рекламных технологий с использованием всех данных аукциона на устройстве приводит к увеличению полезной нагрузки, которую необходимо передавать при каждом вызове к серверу рекламных технологий, одновременно потенциально открывая экосистему для злоупотреблений со стороны злоумышленников. Эти опасения рассматриваются в разделах «Соображения по размеру» и «Соображения по борьбе со злоупотреблениями» ниже.

Рекомендации по размеру

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

1. Добавление ad_render_id в CustomAudience , чтобы он отправлялся с использованием adSelectionData вместо использования URI рендеринга рекламы и метаданных. Рекламные специалисты могут оптимизировать это, не отправляя рекламные данные в adSelectionData . Этот параметр будет поддерживаться в CustomAudience API в будущих выпусках.
2. Убедитесь, что user_bidding_signals не отправлены в adSelectionData . Вместо этого специалисты по рекламе могут получать user_bidding_signals со своего сервера ключей/значений.
3. Позвольте покупателям расставлять приоритеты CustomAudience .
4. Разрешить покупателю указывать приоритет продавца.
5. Сгенерируйте adSelectionData в нескольких фиксированных сегментах, чтобы ограничить утечку битов и одновременно уменьшить размер полезных данных.

Оптимизация размера будет произведена с учетом соображений конфиденциальности.

Рекомендации по борьбе со злоупотреблениями

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

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

Для борьбы со злоупотреблением adSelectionData мы введем следующие меры:

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

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

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