В интересах каждого обеспечить эффективную работу API защищенной аудитории:
- Люди, просматривающие Интернет, хотят, чтобы сайты загружались быстро. Это означает, что разработчикам следует эффективно использовать API Protected Audience, чтобы не перегружать ограниченные ресурсы устройства, такие как вычислительные или сетевые ресурсы, которые необходимы для загрузки сайтов и встроенной рекламы.
- Издатели хотят, чтобы их сайты загружались быстро, предоставляя пользователям эффективный и отзывчивый интерфейс. Издатели также хотят, чтобы эффективная реклама максимизировала их доход.
- Рекламодатели и рекламные специалисты хотят, чтобы их реклама отображалась быстро и приносила максимальную пользу.
В этом документе описываются некоторые рекомендации по реализации API защищенной аудитории, позволяющие обеспечить максимальную эффективность работы вашего сайта.
Рекомендации для покупателей (участников торгов)
Чтобы обеспечить эффективность аукциона API Protected Audience API, следуйте этим рекомендациям.
Меньше владельцев групп по интересам
Чтобы защитить участников торгов API Protected Audience так же, как браузер защищает различные источники в Интернете с помощью изоляции сайтов , браузер использует дорогостоящие ресурсы (например, процессы операционной системы) для защиты владельцев отдельных групп интересов.
Чтобы свести к минимуму расходование этих очень дорогих ресурсов, решающее значение имеет наименьшее количество владельцев групп интересов. Избегайте того, чтобы разные группы по интересам принадлежали разным субдоменам. Например, если бы у adtech.example были группы по интересам, принадлежащие cats.adtech.example и dogs.adtech.example , браузер, скорее всего, использовал бы два отдельных процесса для запуска своих сценариев назначения ставок.
Меньше заявок от групп интересов
Браузер должен выполнить значительную настройку и подготовку перед вызовом generateBid() покупателя, например, настроить новую чистую среду выполнения JavaScript, а также проанализировать и загрузить generateBid() .
- Группы по интересам, представляющие пользователей, которые не являются текущей целью активной рекламной кампании, должны иметь пустые списки рекламных объявлений. Это не позволяет API защищенной аудитории выполнять
generateBid()для групп по интересам без релевантной рекламы. - Объединение схожих групп по интересам уменьшит количество запусков
generateBid(). СвойствоuserBiddingSignalsгруппы интересов можно использовать для хранения дополнительных метаданных о пользователе, поэтому меньшее количество групп интересов не обязательно означает менее эффективный таргетинг. - API Protected Audience поддерживает установленные продавцом ограничения на количество групп интересов, а также API, позволяющий покупателям указывать относительный приоритет своих групп интересов. Эти ограничения можно использовать, чтобы значительно сократить количество запускаемых скриптов назначения ставок.
Отфильтруйте группы интересов от ставок в сервисе «ключ-значение».
Если покупатель может определить на своем доверенном сервере сигналов назначения ставок в режиме реального времени, что определенные группы интересов не должны делать ставки (например, кампания отключена, приостановлена или выходит за рамки бюджета или не следует делать ставки для этого конкретного издателя), он может указать это в браузер с ответом priorityVector на получение доверенных сигналов назначения ставок. Если результирующее разреженное скалярное произведение priorityVector и prioritySignals отрицательное, то браузер пропустит вызов generateBid() для этой группы интересов. Подробнее об этом механизме можно прочитать в разделе объяснителя «Фильтрация и приоритезация групп по интересам» .
Повторное использование среды выполнения JavaScript
Прежде чем браузер сможет generateBid() , он должен инициализировать новую среду выполнения JavaScript. Это может занять значительное количество времени, равное количеству времени, которое может потребоваться для выполнения самой минимальной generateBid() . Это время можно сэкономить, используя режимы выполнения «группа по источнику» или «замороженный контекст».
Режим group-by-origin позволяет повторно использовать среду выполнения в тех случаях, когда группы интересов объединены в одном источнике, и, скорее всего, не потребует внесения изменений в сценарий назначения ставок; Чтобы узнать больше, см. описание group-by-origin в объяснителе. Режим замороженного контекста потенциально может повторно использовать все среды выполнения, но может потребовать внесения изменений в сценарий назначения ставок; Чтобы узнать больше, см. описание frozen-context в объяснителе.
Повторное использование сценариев назначения ставок
Если возможно, используйте один и тот же сценарий торгов для групп интересов. Это избавляет браузер от необходимости загружать, анализировать и компилировать несколько сценариев (что влечет за собой дополнительные сетевые запросы). Участники торгов по-прежнему могут различать ставки на основе информации о группе интересов (например, name или userBiddingSignals ), используя один и тот же скрипт.
Без заголовков управления кэшем HTTP скрипт назначения ставок не кэшируется. Укажите соответствующие заголовки, чтобы гарантировать, что сценарий не будет загружен без необходимости. Если на странице одновременно проводятся несколько аукционов, сценарий торгов одного и того же участника будет использоваться повторно, если он уже находится в памяти, игнорируя семантику кэширования. Если аукционы проводятся последовательно, браузер будет использовать механизм HTTP-кэширования.
Обратите внимание, что браузер загружает скрипт назначения ставок во время ставки ( generateBid() ), а также во время отчета (для reportWin() ). Если заголовки управления кэшем не установлены, браузер будет получать один и тот же сценарий дважды, по одному разу для каждого периода времени.
Поэтому мы рекомендуем устанавливать заголовки управления кэшем во всех ваших скриптах.
Повторное использование trustedBiddingSignalsUrls
Задержка сети и использование ресурсов могут быть очень значительными. Меньшее количество доверенных сигналов назначения ставок в реальном времени может помочь сократить эту задержку.
Доверенные выборки сигналов назначения ставок можно комбинировать, если trustedBiddingSignalsUrl повторно используется несколькими группами интересов. По возможности используйте один и тот же trustedBiddingSignalsUrl для всех групп интересов.
Укажите соответствующие заголовки управления кэшем HTTP , чтобы обеспечить кэширование доверенных сигналов назначения ставок в рекламных местах на определенной веб-странице. Не устанавливайте для trustedBiddingSignalsSlotSizeMode значение slot-size , так как это предотвратит кэширование между рекламными местами, когда размеры рекламных мест различаются, поскольку запрошенный URL-адрес будет отличаться.
Получается меньше надежных сигналов для ставок в режиме реального времени.
Задержка в сети может быть очень значительной, и на нее напрямую влияет объем данных, передаваемых во время получения сигнала доверенного назначения ставок в реальном времени.
Предпочитайте хранить данные, относящиеся к конкретному объявлению или группе интересов, в группе интересов, а не в службе доверенных сигналов назначения ставок в режиме реального времени. Зарезервируйте данные надежных сигналов назначения ставок в реальном времени только для тех сигналов, которые действительно работают в реальном времени, таких как составление бюджета кампании или аварийные переключатели.
Любой сигнал, который может обновляться ежедневно или дольше, должен храниться в группе по интересам и обновляться с использованием ежедневных обновлений.
Не возвращайте надежные сигналы назначения ставок для групп интересов, которые отфильтрованы, как описано в разделе «Отфильтровать группы интересов от назначения ставок в вашей службе «ключ-значение»» .
Расставьте приоритеты по интересам
Продавцы будут использовать тайм-ауты, чтобы ограничить использование ресурсов браузера на страницах издателя. Когда perBuyerCumulativeTimeouts используется для ограничения времени, в течение которого покупатели должны получать доверенные сигналы торгов и выполнять свои сценарии торгов, покупателям крайне важно убедиться, что они расставляют приоритеты для своих групп интересов, чтобы те, кто с наибольшей вероятностью выиграет аукцион, выполнили свои обязательства первыми. Например, если для perBuyerCumulativeTimeouts установлено значение 100 мс, а получение доверенных сигналов назначения ставок участником аукциона занимает 50 мс, а каждый вызов generateBid() занимает 10 мс, а на устройстве присутствует 10 групп интересов, то только половина групп интересов будет иметь возможность рассчитать ставки. Покупатель в этом примере должен расставить приоритеты своих групп интересов в порядке от наиболее вероятных к выигрышу к наименее вероятным.
Группы интересов могут содержать статические приоритеты, определенные в их поле priority . Группы по интересам также могут использовать динамические приоритеты, которые можно рассчитать в их службе доверенных сигналов назначения ставок и вернуть в браузер с ответом priorityVector на выборку доверенных сигналов назначения ставок.
Обратите внимание, что когда браузер выполняет группы интересов от самого высокого приоритета до самого низкого, это может чередовать группы интересов из разных источников присоединения, что может привести к сбою оптимизации group-by-origin .
Лучшие практики продавца
Обязательно отслеживайте и оптимизируйте эффективность аукциона API Protected Audience.
Распараллелить аукционы
Современные сетевые соединения и многоядерные процессоры прекрасно справляются с выполнением нескольких действий одновременно. Браузер может проводить аукцион Защищенной аудитории параллельно с другими действиями. Лучше всего это можно сделать, вызвав runAdAuction() как можно раньше. Понимая, что некоторые входные данные для runAdAuction() могут быть недоступны на раннем этапе, например те, которые отправляются обратно в браузер в контекстном ответе, браузер позволяет вызывать runAdAution() до того, как они станут доступны, и предоставлять эти входные данные позже. время с использованием обещаний JavaScript. Чтобы добиться минимально возможной задержки аукциона, runAdAuction() следует вызывать, когда известны входные данные interestGroupBuyers . Это позволяет немедленно начать многие этапы аукциона, включая получение сигналов торгов в режиме реального времени.
Следите за своими аукционами
Собирайте показатели своих аукционов. Браузер может сообщать продавцам показатели задержки per-buyer , что дает подробную информацию о том, как тратится время на аукционах продавца. Продавцы могут использовать эти показатели для поиска способов оптимизации своих аукционов, включая информацию о том, как наиболее эффективно устанавливать тайм-ауты . Продавцы могут поделиться с покупателем показателями задержки конкретного покупателя, чтобы помочь им в дальнейшей оптимизации.
Участники торгов могут иметь представление о результатах торгов своих групп интересов, но они не смогут сравнить их с результатами других участников торгов. Сравнение относительных показателей выигрышей и показателей отклонения ставок для разных участников торгов может помочь выявить случаи, когда вычислительные ресурсы для ставок были потрачены впустую из-за того, что группы интересов никогда не предлагали жизнеспособные ставки или из-за чрезмерной ставки за неутвержденные креативы.
Защита от сценариев медленных ставок
Скрипты назначения ставок, которые занимают слишком много времени, могут замедлить аукцион Protected Audience API для всех участников. Использование тайм-аутов может предотвратить медленные аукционы, сохраняя при этом доход, даже если аукцион идет медленно.
Продавцам следует использовать perBuyerCumulativeTimeouts чтобы предотвратить медленные аукционы, а также продолжать принимать ставки, когда аукцион медленный и достигает тайм-аута. Использование perBuyerCumulativeTimeouts предпочтительнее использования perBuyerTimeouts и perBuyerGroupLimits , поскольку perBuyerCumulativeTimeouts не зависит от количества групп по интересам или скорости generateBid() (например, многие группы по интересам, которые делают ставки быстро, и несколько групп по интересам, которые делают ставки медленно, могут завершиться до истечения времени ожидания).
Использование поля signal конфигурации аукциона для реализации общего тайм-аута аукциона также является хорошей идеей для предотвращения слишком длительных аукционов в тех случаях, когда получение доверенного сигнала оценки и выполнение scoreAd() занимают слишком много времени.
Что дальше?
Мы хотим пообщаться с вами, чтобы убедиться, что мы создаем API, который будет работать для всех.
Обсудить API
Как и другие API Privacy Sandbox, этот API документирован и обсуждается публично .
Экспериментируйте с API
Вы можете экспериментировать и участвовать в обсуждении API Protected Audience.