Интеграция и оптимизация сервисов торгов и аукционов

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

Чтобы провести аукцион, как описано ранее, продавец должен выполнить на устройстве следующие действия:

1. Собирайте и шифруйте данные для аукциона сервера
2. Отправить запрос в службу недоверенного продавца
3. Получите ответ от службы недоверенных продавцов
4. Расшифруйте ответ аукциона Protected Audience и получите результат аукциона

Protected Audience представляет два новых API для поддержки проведения аукционов на сервере:

1. API getAdSelectionData собирает данные для аукциона сервера и генерирует зашифрованную полезную нагрузку, содержащую данные аукциона. Сервер торгов и аукционов использует эту полезную нагрузку для запуска аукциона, генерации результата аукциона и возврата результата аукциона.
2. Клиенты рекламных технологий на устройствах могут вызвать API persistAdSelectionResult , чтобы расшифровать результат, сгенерированный аукционом сервера, и получить URL-адрес победившей рекламы.

Для проведения аукциона рекламная технология продавца на устройстве должна интегрировать и создать следующее:

1. Соберите и зашифруйте данные для аукциона сервера Продавец : рекламный техник должен вызвать API getAdSelectionData , чтобы получить зашифрованную полезную нагрузку.
2. Отправить запрос в службу недоверенного продавца Отправить : HTTP POST или PUT , содержащий зашифрованную полезную нагрузку, сгенерированную API getAdSelectionData , в службу недоверенного продавца и данные, необходимые службе недоверенного продавца для генерации контекстных результатов.
3. Получение ответа от службы ненадежных продавцов : Ответ от службы ненадежных продавцов будет содержать зашифрованный результат аукциона защищенной аудитории и результат контекстного аукциона.
4. Расшифруйте ответ аукциона защищенной аудитории и получите результат аукциона: Чтобы расшифровать результат аукциона защищенной аудитории, рекламный техник продавца должен вызвать API persistAdSelectionResult . Результат, сгенерированный persistAdSelectionResult , поможет рекламным техник определить, выиграла ли аукцион контекстная реклама или реклама защищенной аудитории, а также URI победившей защищенной рекламы аудитории, если применимо.

Функции, поддерживаемые для аукциона сервера

Мы стремимся поддерживать все функции, доступные для аукциона на устройстве. График поддержки этих функций на аукционе сервера следующий:

Запуск аукционов сервера с использованием API защищенной аудитории

В версии Developer Preview AdSelectionManager представляет два новых API: getAdSelectionData и persistAdSelectionResult . Эти API позволяют интегрировать SDK рекламных технологий с серверами торгов и аукционов.

Собирайте и шифруйте данные для аукциона сервера

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

Для доступа к API необходимо включить доступ к API защищенной аудитории и определить разрешение ACCESS_ADSERVICES_CUSTOM_AUDIENCE в манифесте вызывающей стороны.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. Вызывающая сторона должна указать поле seller в запросе, так как оно используется для выполнения проверок регистрации перед обслуживанием запроса.
2. Поле coordinatorOriginUri является необязательным.
   1. Если задано, оно должно соответствовать схеме, имени хоста и порту URL-адреса координатора, настроенного при развертывании сервера B&A продавца .
   2. Координатор должен входить в список утвержденных координаторов:

      Провайдер	URI	URI-источник	По умолчанию
      Google Облако	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	Да
      Веб-сервисы Amazon	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	Нет

   3. Если источник координатора не указан, используется координатор по умолчанию.
   4. Хотя маловероятно, что URL-адрес координатора изменится, настоятельно рекомендуется реализовать механизм динамического управления этим URL-адресом. Это гарантирует, что любые будущие изменения URL-адреса могут быть учтены без необходимости выпуска нового SDK.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

После проверки запроса данные покупателя на устройстве объединяются в BuyerInput и ProtectedAudienceInput . Затем окончательный объект полезной нагрузки шифруется с использованием двунаправленного гибридного шифрования с открытым ключом .

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome генерируется как результат getAdSelectionData API. Он содержит следующее:

1. adSelectionId : непрозрачное целое число для идентификации этого вызова getAdSelectionData . Клиент рекламной технологии должен сохранить это значение adSelectionId , поскольку оно действует как указатель на вызов getAdSelectionData . Этот идентификатор требуется API persistAdSelectionResult для расшифровки результата аукциона с сервера торгов и аукционов, а также требуется API reportImpression и reportEvent .
2. adSelectionData : Это зашифрованные данные аукциона, которые потребуются серверу торгов и аукционов для проведения аукционов. Этот метод содержит:
   1. Отфильтрованные данные индивидуальной аудитории на основе ограничения частоты показов, фильтров установки приложений и требований аукциона сервера для индивидуальной аудитории.
   2. В будущей версии он будет содержать данные об установке приложений.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Обработка ошибок, исключений и сбоев

Если генерация данных выбора объявлений не может быть успешно завершена по таким причинам, как недопустимые аргументы, тайм-ауты или чрезмерное потребление ресурсов, обратный вызов OutcomeReceiver.onError() предоставляет исключение AdServicesException со следующим поведением:

1. Если getAdSelectionData инициируется с недопустимыми аргументами, исключение AdServicesException ` указывает на исключение IllegalArgumentException в качестве причины.
2. Все остальные ошибки получают исключение AdServicesException с причиной IllegalStateException .

Отправить запрос в службу недоверенного продавца

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

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

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

Получите ответ от ненадежного продавца

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

Недоверенная служба продавца пересылает зашифрованные adSelectionData и AuctionConfig в службу SellerFrontEnd сервера торгов и аукционов, работающую в TEE.

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

Недоверенный сервис продавца отправляет на устройство ответ, содержащий контекстную рекламу и/или зашифрованный результат аукциона Protected Audience.

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

API PersistAdSelectionResult

Чтобы расшифровать результат Protected Audience, продавец рекламных технологий может вызвать второй API Protected Audience persistAdSelectionResult . API расшифровывает результат и возвращает AdSelectionOutcome , тот же объект, который возвращается с аукциона на устройстве сегодня.

Чтобы получить доступ к API, вызывающая сторона должна включить доступ к API защищенной аудитории и определить разрешение ACCESS_ADSERVICES_CUSTOM_AUDIENCE в своем манифесте.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

Вызывающий должен указать в запросе следующее:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId : непрозрачный идентификатор, сгенерированный вызовом getAdSelectionData , результат которого вызывающий хочет расшифровать.
2. seller : в запросе должен быть указан идентификатор рекламной технологии продавца для запуска проверок регистрации перед обслуживанием запроса.
3. adSelectionResult : зашифрованный результат аукциона, сгенерированный сервером торгов и аукционов, который вызывающий абонент хочет расшифровать.

Ответ AdSelectionOutcome

Если есть победитель защищенной аудитории, то AdSelectionOutcome возвращает URI отображения победившей рекламы. После того, как adSelectionResult расшифрован, данные отчета сохраняются внутри. Обратный вызов OutcomeReceiver.onResult() возвращает AdSelectionOutcome , который содержит:

• URI : Если есть победившая реклама Protected Audience, то возвращается URL-адрес рендеринга рекламы для победившей рекламы. Если победителя Protected Audience нет, то возвращается `Uri.EMPTY.
• adSelectionId : adSelectionId , связанный с этим аукционом сервера.

Обработка ошибок, исключений и сбоев

Если генерация данных выбора объявлений не может быть успешно завершена по таким причинам, как недопустимые аргументы, тайм-ауты или чрезмерное потребление ресурсов, обратный вызов OutcomeReceiver.onError() предоставляет исключение AdServicesException со следующим поведением:

1. Если getAdSelectionData инициируется с недопустимыми аргументами, AdServicesException указывает на IllegalArgumentException в качестве причины.
2. Все остальные ошибки получают исключение AdServicesException с причиной IllegalStateException .

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

adSelectionData зашифрован, чтобы гарантировать, что передаваемые данные доступны только PPAPI и доверенным серверам.

Несмотря на шифрование, утечка данных может произойти из-за размера adSelectionData . Размер adSelectionData может меняться из-за:

1. Изменения в данных CustomAudience , присутствующих на устройстве.
2. Изменения в логике фильтрации CustomAudience .
3. Изменения во входных данных для вызова getAdSelectionData .

Изменение размера adSelectionData может быть использовано для генерации идентификатора кросс-приложения, как упоминалось в обсуждении 1-битной утечки . Многие смягчения, применимые к 1-битной утечке, применимы и здесь.

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

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

Оптимизация размера

Ожидается, что SDK клиента ad tech упакует зашифрованные байты adSelectionData в контекстный вызов HTTP PUT/POST направленный на сервер ad tech. Для снижения задержки и стоимости кругового пути необходимо максимально уменьшить размер adSelectionData , не влияя на полезность.

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

1. Полезная нагрузка, сгенерированная в фиксированном наборе размеров ведра с заполнением : чтобы минимизировать утечку из-за изменений размера, при этом все еще допуская более низкие полезные нагрузки, мы предлагаем использовать фиксированный размер ведра для сгенерированной полезной нагрузки. Сохранение небольшого количества ведер, например, 7, приведет к менее чем 3 битам утечки энтропии на вызов getAdSelectionData .

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

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

   Затем эта конфигурация будет использоваться для оценки вклада покупателя в adSelectionData , генерируемый для каждого запроса getAdSelectionData .

   Конфигурация полезной нагрузки покупателя позволит покупателям указать:

   1. Список разрешенных продавцов : CustomAudiences покупателя будут добавлены в полезную нагрузку только в том случае, если вызов getAdSelectionData инициирован продавцом из разрешенного списка. Мы будем извлекать конфигурацию полезной нагрузки ежедневно, чтобы поддерживать список разрешенных в актуальном состоянии.
   2. Ограничение размера для каждого продавца : покупатель может указать ограничение размера для каждого продавца, чтобы определить размер данных, отправляемых в полезной нагрузке, когда аукцион инициируется определенным продавцом. Это может быть полезно, если покупатель хочет выделить больше ресурсов на обработку данных аукциона от определенных продавцов. SellerFrontendService пересылает только данные, специфичные для покупателя, в каждую службу BuyerFrontendService. Таким образом, определяя ограничение размера для каждого продавца, покупатель может явно контролировать объем данных, принимаемых и обрабатываемых службой BuyerFrontendService своего сервера торгов и аукционов для аукционов, проводимых продавцом.

3. Конфигурация продавца : мы оцениваем осуществимость конфигурации аукциона для каждого продавца, которая позволит продавцам определять параметры аукциона для управления размером полезной нагрузки и участниками аукциона. Если это осуществимо, во время регистрации рекламный технический специалист продавца сможет указать конечную точку, из которой Protected Audience сможет получать конфигурацию аукциона для каждого продавца с регулярной частотой. Затем эта конфигурация будет использоваться для определения состава и ограничений adSelectionData , генерируемых для каждого запроса getAdSelectionData .

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

   Конфигурация аукциона продавца позволит продавцам указывать:

   1. Список разрешенных покупателей : для аукционов, инициированных данным продавцом, только покупатели из разрешенного списка смогут вносить CustomAudiences для аукциона. Конфигурацию аукциона необходимо будет обновлять ежедневно, чтобы поддерживать список разрешенных покупателей в актуальном состоянии с помощью списка разрешенных покупателей на стороне сервера.
   2. Ограничение размера для покупателя : продавцы могут указать ограничение для покупателя, чтобы регулировать размер данных, загружаемых каждым покупателем в полезную нагрузку, отправляемую в SellerFrontendService. Если покупатель превышает ограничение размера для покупателя, приоритет CustomAudience, установленный в конфигурации полезной нагрузки покупателя, будет использоваться для получения данных в ожидаемых пределах.
   3. Приоритет покупателя : разрешить продавцам устанавливать приоритет покупателя. Приоритет покупателя будет использоваться для определения того, какие данные покупателя следует хранить в полезной нагрузке, если размер полезной нагрузки превышает ограничение размера полезной нагрузки.
   4. Максимальный размер нагрузки : разные продавцы могут иметь разное распределение ресурсов и могут захотеть установить максимальный размер нагрузки для аукциона по запросу. Максимальный размер нагрузки будет соответствовать фиксированным размерам сегментов, установленным API защищенной аудитории.

4. Изменения пользовательской аудитории

   1. Укажите приоритет Custom Audience : Разрешите покупателям указывать значение приоритета в Custom Audience. Поле priority будет использоваться для определения Custom Audience, которые должны быть включены в аукцион, если набор Custom Audiences покупателя превысит ограничения по размеру per-seller или per-buyer. Неуказанное значение приоритета в Custom Audience будет по умолчанию 0.0 .

5. Изменения данных полезной нагрузки

   1. Уменьшение данных, отправляемых в полезной нагрузке : Как подробно описано в разделе Оптимизация полезной нагрузки служб торгов и аукционов , более высокая полезная нагрузка обусловлена ​​данными ads пользовательской аудитории, сигналами ставок пользователя, сигналами Android. Более высокие полезные нагрузки могут быть снижены за счет:
      1. Клиент отправляет идентификаторы рендеринга рекламы (вместо объектов рекламы) в полезной нагрузке.
      2. Клиент не должен отправлять рекламные данные в полезной нагрузке.
      3. Не отправляются сигналы ставок пользователя в полезной нагрузке клиента.

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

Оптимизация задержки

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

Мы изучаем следующие стратегии, чтобы удержать задержку в приемлемых пределах:

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

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

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

   Предварительная генерация данных защищенной аудитории будет основана на

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

2. Активное применение отрицательной фильтрации : если это предпочтет продавец, платформа может предварительно вычислить adSelectionData , предварительно сгенерировав данные Protected Audience и применив отрицательную фильтрацию к критическому вызову getAdSelectionData . Это позволит продавцам сбалансировать снижение задержки, принимая застой в отрицательной фильтрации.

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

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

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

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

Выявление и смягчение последствий злоупотреблений

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

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

Смягчение

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

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

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

Выявление вредоносных объектов

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

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