Улучшите задержку аукциона API защищенной аудитории.

В интересах всех сторон обеспечить эффективную работу API для защищенной аудитории:

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

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

Передовые методы работы покупателя (участника торгов)

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

Меньше владельцев групп интересов

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

Чтобы минимизировать затраты этих очень дорогостоящих ресурсов, крайне важно иметь как можно меньше владельцев групп интересов. Избегайте ситуации, когда разные группы интересов принадлежат разным поддоменам. Например, если у adtech.example есть группы интересов, принадлежащие cats.adtech.example и dogs.adtech.example , браузер, скорее всего, будет использовать два отдельных процесса для запуска скриптов назначения ставок.

Меньше групп интересов участвуют в торгах.

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

• Группы интересов, представляющие пользователей, которые в данный момент не являются целевой аудиторией активной рекламной кампании, должны иметь пустые списки рекламных креативов. Это предотвратит выполнение функции generateBid() API защищенной аудитории для групп интересов, не содержащих релевантных объявлений.
• Объединение групп с похожими интересами уменьшит количество запусков функции generateBid() . Свойство userBiddingSignals группы интересов можно использовать для хранения дополнительной метаинформации о пользователе, поэтому меньшее количество групп интересов не обязательно означает менее эффективный таргетинг.
• API для защищенной аудитории поддерживает установленные продавцом ограничения на количество групп интересов, а также API для покупателей, позволяющий указывать относительный приоритет групп интересов. Эти ограничения могут значительно сократить количество запускаемых скриптов для назначения ставок.

Исключите группы интересов из процесса торгов в вашем сервисе «Ключ/Значение».

Если покупатель может определить на своем сервере сигналов доверенных ставок в режиме реального времени, что определенные группы интересов не должны делать ставки (например, кампания отключена, приостановлена, вышла за рамки бюджета или не должна делать ставки на этого конкретного издателя), он может указать это браузеру с помощью ответа priorityVector на запрос сигналов доверенных ставок. Если результирующее скалярное произведение priorityVector и prioritySignals отрицательно, браузер пропустит вызов generateBid() для этой группы интересов. Подробнее об этом механизме можно прочитать в разделе «Фильтрация и приоритизация групп интересов» пояснения.

Повторное использование среды выполнения JavaScript

Прежде чем браузер сможет выполнить generateBid() , ему необходимо инициализировать новую среду выполнения JavaScript. Это может занять значительное время, сопоставимое со временем выполнения самого минимального generateBid() . Это время можно сэкономить, используя режимы выполнения group-by-origin или frozen-context.

Режим group-by-origin позволяет повторно использовать среды выполнения в случаях, когда группы интересов объединяются по одному и тому же источнику, и, вероятно, не потребует изменений в вашем скрипте торгов; чтобы узнать больше, см. описание режима group-by-origin в пояснительной статье. Режим замороженного контекста позволяет повторно использовать потенциально все среды выполнения, но может потребовать изменений в вашем скрипте торгов; чтобы узнать больше, см. описание режима frozen-context в пояснительной статье.

Повторное использование скриптов для размещения ставок

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

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

Обратите внимание, что браузер загружает скрипт для торгов во время размещения ставок (для generateBid() ) и также во время формирования отчета (для reportWin() ). Если заголовки управления кэшированием не установлены, браузер будет загружать один и тот же скрипт дважды, по одному разу для каждого временного периода.

Поэтому мы рекомендуем устанавливать заголовки управления кэшированием во всех ваших скриптах.

Повторное использование trustedBiddingSignalsUrls

Задержка в сети и потребление ресурсов могут быть очень значительными. Сокращение количества запросов на получение доверенных сигналов для торгов в режиме реального времени может помочь уменьшить эту задержку.

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

Укажите соответствующие заголовки управления HTTP-кэшированием , чтобы гарантировать кэширование достоверных сигналов торгов между рекламными местами на конкретной веб-странице. Избегайте установки параметра trustedBiddingSignalsSlotSizeMode в slot-size , так как это предотвратит кэширование между рекламными местами, если размеры мест различаются из-за различий в запрашиваемом URL-адресе.

Меньшие по размеру, но надежные сигналы для торгов в режиме реального времени.

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

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

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

Не возвращайте надежные сигналы для торгов для групп интересов, которые отфильтрованы, как описано в разделе «Отфильтровывание групп интересов из торгов в вашем сервисе Key/Value» .

Приоритизация групп интересов

Продавцы используют тайм-ауты для ограничения использования ресурсов браузера на страницах издателя. Когда perBuyerCumulativeTimeouts используется для ограничения времени, которое покупатели могут потратить на получение сигналов для участия в торгах и выполнение скриптов ставок, крайне важно, чтобы покупатели расставили приоритеты для своих групп интересов таким образом, чтобы сначала выполнялись действия для тех групп, которые с наибольшей вероятностью выиграют аукцион. Например, если perBuyerCumulativeTimeouts установлено на 100 мс, а получение сигналов для участия в торгах занимает 50 мс, каждый вызов generateBid() занимает 10 мс, и на устройстве присутствует 10 групп интересов, то только половина групп интересов сможет рассчитать ставки. В этом примере покупатель должен расставить приоритеты для своих групп интересов в порядке от наиболее вероятных к наименее вероятным победителям.

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

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

Передовые методы работы с продавцами

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

Параллельная организация аукционов

Современные сетевые соединения и многоядерные процессоры отлично справляются с одновременным выполнением множества задач. Браузер может запускать аукцион с защищенной аудиторией параллельно с другими действиями. Наилучшего результата можно добиться, вызвав runAdAuction() как можно раньше. Учитывая, что некоторые входные данные для runAdAuction() могут быть недоступны на ранних этапах, например, те, которые отправляются обратно в браузер в контекстном ответе, браузер позволяет вызывать runAdAution() до того, как они станут доступны, и предоставлять эти данные позже, используя промисы JavaScript. Для достижения минимальной задержки аукциона runAdAuction() следует вызывать, когда известны входные данные interestGroupBuyers . Это позволяет немедленно начать многие этапы аукциона, включая получение сигналов ставок участников в реальном времени.

Следите за своими аукционами

Собирайте метрики по своим аукционам. Браузер может сообщать продавцам метрики задержки per-buyer , что дает много информации о том, сколько времени тратится на аукционы продавца. Продавцы могут использовать эти метрики для поиска способов оптимизации своих аукционов, в том числе для определения наиболее эффективных способов установки тайм-аутов . Продавцы могут делиться метриками задержки конкретного покупателя с покупателем, чтобы помочь ему в дальнейшей оптимизации.

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

Защита от скриптов, медленно загружающих ставки.

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

Продавцам следует использовать perBuyerCumulativeTimeouts , чтобы предотвратить задержку аукциона, а также для того, чтобы принимать ставки, даже если аукцион идет медленно и истекает время ожидания. Использование perBuyerCumulativeTimeouts предпочтительнее, чем использование perBuyerTimeouts и perBuyerGroupLimits поскольку perBuyerCumulativeTimeouts не зависит от количества групп интересов или скорости generateBid() (например, множество групп интересов, делающих ставки быстро, и несколько групп интересов, делающих ставки медленно, могут завершиться до истечения времени ожидания).

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

Что дальше?

Мы хотим пообщаться с вами, чтобы убедиться, что мы создаем API, который будет работать для всех.

Обсудить API

Как и другие API Privacy Sandbox, этот API документирован и обсуждается публично .

Экспериментируйте с API

Вы можете экспериментировать и участвовать в обсуждении API Protected Audience.