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

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

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

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

	Аукцион на устройстве		Серверный аукцион
	Предварительный просмотр для разработчиков	Бета	Предварительный просмотр для разработчиков	Бета
Отчеты о победах на уровне событий	1 квартал 23 г.	3 квартал 23 г.	Н/Д	4 квартал 23 г.
Посредничество водопада	1 квартал 23 г.	4 квартал 23 г.	Н/Д	1 квартал 24
Фильтрация ограничения частоты показов	2 кв. 23 г.	3 квартал 23 г.	Н/Д	4 квартал 23 г.
Передача контекстных объявлений в рабочий процесс выбора объявлений для фильтрации.	2 кв. 23 г.	1 квартал 24 г.	Н/Д	Н/Д
Отчеты о взаимодействии	2 кв. 23 г.	3 квартал 23 г.	Н/Д	4 квартал 23 г.
Присоединяйтесь к делегации индивидуальной аудитории	3 квартал 23 г.	4 квартал 23 г.	Н/Д	4 квартал 23 г.
выставление счетов без цены за тысячу показов	3 квартал 23 г.	4 квартал 23 г.
Отлаживать отчетность	3 квартал 23 г.	4 квартал 23 г.	3 квартал 23 г.	4 квартал 23 г.
Посредничество открытых торгов	Н/Д	Н/Д	Н/Д	1 квартал 24 г.
Фильтрация рекламы, ориентированной на установку приложения	2 кв. 23 г.	1 квартал 24 г.	Н/Д	1 квартал 24 г.
Валютный менеджмент	Н/Д	Н/Д	Н/Д	1 квартал 24 г.
К-анон интеграция	Н/Д	1 квартал 24 г.	Н/Д	1 квартал 24 г.
Интеграция частной агрегации	Н/Д	Н/Д	Н/Д	3 квартал 24 г.

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

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

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

API getAdSelectionData генерирует необходимые входные данные для компонентов Bidding и Auction, таких как 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 генерируется как результат 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 в службу SellerFrontEnd сервера ставок и аукционов, работающую в TEE.

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

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

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

API PersistAdSelectionResult

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

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

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

Персистадселектионресултекрекуест

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы серверные аукционы имели желаемый уровень полезности, нам необходимо убедиться, что API getAdSelectionData и API 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 для серверных аукционов, они не помогают идентифицировать вредоносные объекты или защитить платформу от злоупотреблений, таких как создание беспрецедентного количества индивидуализированных аудиторий со стороны покупателя.

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