Защищенная аудитория: руководство по интеграции

Внедрение функции «Защищенная аудитория» (ранее известной как FLEDGE) в Android обычно включает интеграцию между приложениями рекламодателей, издателей, продавцов и покупателей. Это руководство предназначено для партнеров, которые планируют управлять пользовательскими аудиториями и проводить аукционы, включая рекламные технологические сети, которые выступают как в роли покупателей, так и продавцов. Различные рекламные кампании могут иметь разные цели, и не все функции «Защищенной аудитории» используются во всех случаях. В этом руководстве предпринята попытка описать шаги, необходимые для поддержки более специализированных случаев, где это возможно.

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

Процесс интеграции с защищенной аудиторией состоит из 4 ключевых шагов, выполняемых различными типами партнеров в сфере рекламных технологий:

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

Следующая диаграмма иллюстрирует эти шаги:

Терминология

• Рекламодатель : компания, которая привлекает пользователей посредством покупки рекламного пространства.
• Издатель : Компания, которая продает рекламное пространство, доступное вместе с ее контентом.
• Покупатель : компания, работающая в сфере рекламных технологий, которая помогает рекламодателям приобретать рекламное пространство.
• Продавец : Компания, работающая в сфере рекламных технологий и помогающая издателям продавать рекламное пространство.
• Network : Рекламно-технологическая компания, выступающая одновременно в роли покупателя и продавца.
• В собственности и под управлением : компания, которая выступает в роли издателя, продавца и покупателя.
• Партнеры по интеграции : любые компании, с которыми вам необходимо сотрудничать для успешной интеграции с Protected Audience.

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

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

Ознакомьтесь с понятием «Защищенная аудитория».

Первым шагом является ознакомление с API и сервисами защищенной аудитории.

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

Настройте и протестируйте тестовые приложения.

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

1. Когда вы будете готовы начать интеграцию, настройте свою среду разработки, используя последнюю версию Privacy Sandbox Developer Preview .
2. Настройте необходимые серверные конечные точки. Используйте примеры макетов с вашим предпочтительным решением для тестирования API, чтобы запустить этот процесс.
3. Создайте форк и запустите код в нашем демонстрационном приложении , чтобы ознакомиться с управлением пользовательскими аудиториями, рабочим процессом выбора рекламы и отчетами о показах.

Взаимодействие с партнерами по интеграции

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

Бета-версия (доступна в 4 квартале)

Зарегистрируйте свою организацию в «Песочнице конфиденциальности» на Android. Регистрация необходима для того, чтобы разработчики рекламных технологий работали в рамках политик «Песочницы конфиденциальности», и позволяет разработчикам рекламных технологий определять свою идентичность для нескольких SDK и доменов.

Архитектурные соображения

Для покупателей и продавцов функция Protected Audience предоставляет возможность проводить рекламные аукционы на устройстве. Вам и вашим партнерам по интеграции следует учитывать несколько важных моментов при разработке:

Данные об аудиториях и ремаркетинговые объявления хранятся на устройстве.

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

Процессы торгов и аукциона происходят на самом устройстве.

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

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

Стратегия работы с данными

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

Создайте своё решение

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

Покупатели: Формирование аудитории

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

Если в приложении рекламодателя установлен собственный SDK, вы можете реализовать этот код напрямую, используя joinCustomAudience() .

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

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

Прототип ремаркетинговой кампании: создание целевой аудитории.

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

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

Настройка и прототип

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

Вопросы проектирования

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

URL логики торгов

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

Сигналы ставок пользователей

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

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

Поскольку эти сигналы доступны во время аукциона, покупатели могут выполнять индивидуальные операции по размещению ставок, в том числе:

• Повышайте или понижайте ставки в зависимости от сигналов торгов.
• Отфильтруйте конкретные объявления из аукциона.

Достоверные данные о торгах

В рамках реализации функции «Защищенная аудитория» покупатели могут получать информацию в режиме реального времени во время аукциона из сервиса «ключ-значение». В качестве временного механизма покупатель и продавец могут получать эти сигналы ставок из любого сервиса, включая тот, которым они управляют сами. Наиболее распространенный пример — это поиск оставшегося бюджета на рекламу. Во время разработки можно создать фиктивный экземпляр этого сервиса, и вы можете разрабатывать приложения, используя этот фиктивный конечный пункт. Инструкции по настройке см. в каталоге FledgeServerSpec в нашем репозитории примеров приложений на GitHub.

Поле TrustedBiddingData состоит из URL-адреса и набора ключей. Вот несколько моментов, которые следует учитывать при разработке структуры ключей:

• Один из подходов заключается в добавлении ключа, который в соотношении 1:1 соответствует создаваемой аудитории. В этом случае служба «ключ-значение» может содержать всю необходимую информацию, связанную с аудиторией.
• Бюджет и статус объявления — важные факторы, которые необходимо учитывать в режиме реального времени.
• Максимальная сумма ставки или другие сигналы, которые можно использовать для определения цены объявления на аукционе. Эту информацию можно включить в список AdData вместе с объявлением, но хранение её в формате «ключ-значение» позволяет обновлять её по мере необходимости.

Список AdData

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

Объем информации, которую следует включить в каждое объявление, решают покупатели. Вот несколько моментов, которые стоит учесть:

• Список AdData можно обновить двумя способами:
  • Когда приложение демонстрирует видимую активность на переднем плане, оно может инициировать формирование списка при добавлении пользователя в пользовательскую аудиторию.
  • Во время ежедневного обновления в фоновом режиме запускается процесс получения данных . Устройство отправляет запрос на адрес daily_update_url , указанный в вызове joinCustomAudience , и ожидает ответа, содержащего обновленный список AdData .
• Дополнительную информацию о рекламе можно запросить во время аукциона. Перед аукционом устройство отправляет запрос в службу «ключ-значение» покупателей, указанную в поле trustedBiddingData объекта joinCustomAudience . Служба «ключ-значение» — это новая служба, являющаяся частью реализации защищенной аудитории покупателями. Более подробная информация об этой службе приведена далее в этом документе .
• Включение идентификатора креатива в ваше объявление может помочь вам выполнять определенные действия с конкретными креативами. Например, рекламодатели могут приостанавливать показ определенных креативов, и вы можете получить эти идентификаторы креативов из сервиса «ключ-значение» в реальном времени, а затем сопоставить их с объявлениями в списке AdData .

AdData следует указать render_url . Для отображения объявления используется URL-адрес успешного ремаркетингового объявления. Следует учесть следующие моменты:

• URL-адрес рендеринга имеет порог k-анонимности, поэтому избегайте использования узких параметров. Более подробная информация об этом пороге k-анонимности будет опубликована позже.
• Этот URL-адрес должен содержать всю информацию, необходимую для отображения рекламы. Например, если вы хотите показать конкретные товары, вставьте идентификаторы товаров в качестве параметров в URL-адрес.

На этапе прототипирования единственным обязательным полем является renderUri , указывающее на ресурсы рендеринга объявления. Поле метаданных в AdData можно игнорировать при создании решения. По мере приближения решения к производственной среде следует определить, какие метаданные для вас актуальны, поскольку их можно использовать при генерации ставок для корректировки цены.

Время активации и время истечения срока действия

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

• Пользователь, прекративший использование приложения (например, пользователь, который не взаимодействовал с приложением рекламодателя в течение последних 7 дней).
  • Каждый раз, когда пользователь открывает приложение, покупатель может вызвать функцию joinCustomAudience и настроить activation_time как метку времени, указывающую на 7 дней вперед.
  • Участник аукциона может быть допущен к участию, если с момента последнего открытия приложения пользователем прошло 7 дней.
• Сезонная аудитория (аудитория, актуальная только в течение определенного периода времени в ближайшем будущем).
  • Покупатель может заранее определить пользовательские аудитории, которые будут участвовать в торгах только в заранее установленный период в (ближайшем) будущем.
  • Например, если у рекламодателя есть рекламная кампания в конце лета 2022 года в США, его покупатель может вызвать функцию joinCustomAudience и настроить activation_time на субботу, 20 августа 2022 года. Если кампания длится всего одну неделю, покупатель может установить дату окончания на 27 августа 2022 года, после чего пользовательская аудитория будет отфильтрована платформой при выборе объявлений и в конечном итоге удалена.

Покупатели и продавцы: выбор рекламы

Выбор объявления требует сотрудничества между покупателями и продавцами. Этот процесс можно рассматривать как четырехэтапный:

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

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

Продавцы: Определите стратегию посредничества

В разделе «Защита аудитории» планируется поддержка каскадной медиации. Этот раздел находится в стадии разработки, и дополнительная информация будет предоставлена ​​по мере её появления. На данный момент ознакомьтесь с проектом дизайна каскадной медиации в разделе «Защита аудитории».

Продавцы: Настройка аукциона

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

Настройка и прототип

• Продавец может настроить и запустить аукцион, создав объект AdSelectionConfig и используя API AdSelection . Запустить аукцион можно, вызвав метод selectAds() .
• Подробную информацию о реализации и использовании API см. в руководстве для разработчиков .

Вопросы проектирования

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

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

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

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

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

• Продавец может передавать информацию в этот процесс несколькими способами:

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

Покупатели: Торги за рекламное место.

Настройка и прототип

• Покупатель может добавить свою логику торгов в функцию JavaScript generateBid() , которая предоставляется из параметра biddingLogicUrl , заданного при создании CustomAudience . Вы можете настроить фиктивный сервис, используя предоставленную спецификацию , или реализовать эту конечную точку на реальном сервере.
• Подробную информацию о реализации и использовании API см. в руководстве для разработчиков .

Вопросы проектирования

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

Разработка логики торгов

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

Предоставьте данные для участия в тендере.

Сигналы торгов в реальном времени с использованием сервисов «ключ-значение».

В качестве покупателя вы можете получать сигналы в реальном времени во время аукциона от принадлежащего вам сервиса «ключ-значение». Начальную реализацию этого сервиса можно найти в общедоступном репозитории Privacy Sandbox , или же вы можете создать собственный сервис. URL-адрес этого сервиса указывается в качестве trustedBiddingUrl в пользовательской аудитории, и платформа пытается получить данные и сделать их доступными для вашей функции generateBid с trusted_bidding_signals parameter . Вам необходимо создать собственную структуру ключей.

Контекстные и пользовательские сигналы

Функция generateBid получает доступ к дополнительным пользовательским сигналам при проведении аукциона на устройстве. Эти сигналы передаются через поля contextual_signals и per_buyer_signals . Все эти поля представляют собой объекты JSON, формат которых должен быть определен покупателями и продавцами.

Поле contextual_signals содержит информацию о пользователе, которая может быть для него важна. Объект, содержащий эти сигналы, создается самой системой Protected Audience и передается в вашу логику назначения ставок. Он передается как пустой объект. Если вы считаете, что контекстный сигнал о пользователе может быть полезен в вашем случае, отправьте отзыв для рассмотрения.

Поле per_buyer_signals становится доступным для вашей логики торгов. Продавец устанавливает эти значения при создании конфигурации аукциона. Покупатели и продавцы должны совместно проверять наличие этих данных на устройстве и их передачу в вашу логику торгов. Примеры использования этого поля:

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

Продавцы: оцените объявление и выберите победителя.

Настройка и прототип

• Продавец может добавить свою логику оценки в функцию JavaScript scoreAd() , которая предоставляется из параметра scoringLogicUrl , заданного при создании AdSelectionConfig . Вы можете настроить фиктивный сервис, используя предоставленную спецификацию , или реализовать эту конечную точку на реальном сервере.
• Подробную информацию о реализации и использовании API см. в руководстве для разработчиков .

Логика оценки дизайна

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

данные оценки предложения

Сигналы оценки в реальном времени с использованием сервисов «ключ-значение».

В качестве продавца вы можете получать сигналы в реальном времени во время аукциона от принадлежащего вам сервиса «ключ-значение». Начальную реализацию этого сервиса можно найти в общедоступном репозитории Privacy Sandbox . URL этого сервиса указывается как trustedScoringUri в конфигурации аукциона, и платформа пытается получить данные и сделать их доступными для вашей функции scoreAd используя параметр trusted_scoring_signals . Вам следует создать собственную структуру ключей.

Контекстные и пользовательские сигналы

Функция scoreAd получает доступ к дополнительным сигналам пользователя при проведении аукциона на устройстве. Эти сигналы передаются в вашу функцию оценки с помощью поля contextual_signal . Это поле содержит JSON-объекты, формат которых определяется покупателями и продавцами.

Поле contextual_signal содержит контекстную информацию о пользователе, которая может быть для него важна. Объект, содержащий эти сигналы, создается самой системой Protected Audience и передается в вашу логику оценки. Он передается как пустой объект. Если вы считаете, что сигнал о пользователе может быть актуален для вашего варианта использования, отправьте отзыв для рассмотрения.

Продавцы: Отобразить объявление

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

Отчет о результатах просмотра

Настройка и прототип

• Покупатели и продавцы могут добавить логику формирования отчетов в функцию JavaScript reportWin() , которая предоставляется через параметры biddingLogicUrl или scoringLogicUrl соответственно. Вы можете настроить фиктивный сервис, используя предоставленную спецификацию , или реализовать эту конечную точку на реальном сервере.
• Подробную информацию о реализации и использовании API см. в руководстве для разработчиков .

Вопросы проектирования

Покупатели и продавцы должны реализовать функцию reportWin в своем JavaScript-коде, возвращаемом из настроенных ими конечных точек. Этот метод позволяет отправлять данные обратно на ваши серверы.

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