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

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

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

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

Развертывание в облаке

Специалисты по рекламным технологиям будут развертывать сервисы 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 . Это означает, что для создания adSelectionData будут использоваться все CustomAudience на устройстве. Мы также планируем ограничить влияние входных параметров 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 со своего сервера Key/Value.
3. Предоставьте покупателям возможность отдавать приоритет CustomAudience .
4. Предоставьте покупателю возможность указать приоритет продавца.
5. Генерируйте adSelectionData в нескольких фиксированных сегментах, чтобы ограничить утечку данных и уменьшить размер полезной нагрузки.

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

Соображения по предотвращению злоупотреблений

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

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

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

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

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

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