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

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

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

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

Компания 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 защищенной аудитории.

В рамках предварительной версии для разработчиков 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 Web Services	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 генерируется как результат выполнения API-запроса getAdSelectionData . Он содержит следующее:

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 в сервис SellerFrontEnt сервера торгов и аукционов, работающий в среде TEE.

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

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

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

API PersistAdSelectionResult

Для расшифровки результата анализа защищенной аудитории рекламодатель может вызвать второй API анализа защищенной аудитории 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 возвращает URI рендеринга выигрышного объявления. После расшифровки adSelectionResult данные отчета сохраняются внутри системы. Функция обратного вызова OutcomeReceiver.onResult() возвращает AdSelectionOutcome , содержащий:

• URI : Если есть победившее объявление в рамках защищенной аудитории, возвращается URL-адрес рендеринга этого объявления. Если победителя в рамках защищенной аудитории нет, возвращается `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 . В начальных версиях для создания adSelectionData будут использоваться все CustomAudiences на устройстве, а зашифрованная полезная нагрузка будет дополнена для маскировки различий в размере. Мы также ограничим влияние входных параметров GetAdSelectionData на генерируемые adSelectionData .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   1. Укажите приоритет пользовательской аудитории : позвольте покупателям указать значение приоритета в пользовательской аудитории. Поле priority будет использоваться для определения пользовательских аудиторий, которые должны быть включены в аукцион, если набор пользовательских аудиторий покупателей превышает лимиты на одного продавца или одного покупателя. Неуказанное значение приоритета в пользовательской аудитории по умолчанию будет равно 0.0 .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Смягчение последствий

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

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

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

Идентификация вредоносных объектов

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

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