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

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

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

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

Где услуги B&A уместны

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

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

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

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

С B&A информация Protected Audience, такая как пользовательские аудитории и суммы ставок, передается с устройства через серверы рекламных технологий продавца на серверы рекламных технологий покупателя и обратно на устройство. Из-за этого платформа шифрует данные, поступающие в службы Protected Audience, и может быть расшифрована только сертифицированными службами. Подробнее о стратегиях шифрования читайте на 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 считывает данные из своей службы Key/Value и оценивает объявления-кандидаты. Результат шифруется и возвращается в службу Seller Ad.
8. Служба Seller Ad возвращает зашифрованный выигрышный результат и, при необходимости, контекстный результат в SDK на устройстве.
9. На устройстве продавцы извлекают победившее объявление с помощью API processAdSelectionResult , который расшифровывает ответ от сервиса Seller Ad.

Подробное описание каждого шага и способа шифрования данных можно найти на 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 возвращает зашифрованное победившее объявление на устройство.

После того как ответ на запрос к рекламному сервису продавца возвращается на устройство, платформа предлагает второй новый 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-адресов сохраняются на устройстве.

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

Предложение Browser Bidding & Auction API на GitHub описывает, как учитывались соображения конфиденциальности. Это предложение использует номенклатуру Chrome, но те же принципы применимы и к Android.

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

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

Соображения относительно размера

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

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

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

Соображения по борьбе со злоупотреблениями

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

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

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

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

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

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