Отчеты об отладке для защищенной аудитории

Отчеты об отладке Protected Audience позволяют разработчикам рекламных технологий объявлять удаленные URL-адреса для получения запроса GET от устройств при выигрыше или проигрыше аукциона. Это позволяет использовать следующие варианты использования:

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

Отчеты об отладке на уровне событий доступны для тестирования в Privacy Sandbox Developer Preview 9. Отчеты об отладке поддерживаются на всех устройствах, где доступен AdId.

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

Узнайте больше об [отладочных отчетах в оригинальном пробном предложении FLEDGE от Chrome][10].

Использование

Отчеты об отладке реализованы с использованием следующих API JavaScript, оба из которых принимают аргумент строки URL:

  • forDebuggingOnly.reportAdAuctionWin(String url)
  • forDebuggingOnly.reportAdAuctionLoss(String url)

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

let someDebuggableVariable = 123;
const url = "https://example.com/reportLoss?winningBid=${winningBid}&someDebuggableVariable=" + someDebuggableVariable;
forDebuggingOnly.reportAdAuctionLoss(url);

Шаблон ${winningBid} заменяется реальным значением после завершения аукциона.

Продавцы могут по желанию возвращать rejectReason из своей функции scoreAds :

function scoreAd(ad, bid, auction_config, seller_signals,
                 trusted_scoring_signals, contextual_signal,
                 custom_audience_signal) {
  let score = ...
  return {
    'status': 0,
    'score': score,
    'rejectReason': 'blocked-by-publisher'
  }
}

Если продавец не указал причину отклонения, то вместо этого отправляется сообщение not-available .

URL-переменные

Переменные, которые можно добавить в URL-адрес отладки , соответствуют своим аналогам в Chrome (хотя ${topLevelWinningBid} и ${topLevelMadeWinningBid} недоступны, поскольку в Android отсутствует концепция аукционов компонентов).

Имя переменной Описание
winningBid Стоимость победившей заявки.
madeWinningBid Логическое значение, указывающее, сделал ли покупатель этой индивидуальной аудитории выигрышную ставку либо через эту индивидуально настроенную аудиторию, либо через другую индивидуально настроенную аудиторию с тем же покупателем.
highestScoringOtherBid Значение ставки, которая была оценена как вторая по величине скриптом продавца scoreAd. Обратите внимание, что это может быть не второе по величине значение ставки, поскольку оценки и ставки могут быть независимыми.
madeHighestScoringOtherBid Логическое значение, указывающее, сделал ли покупатель этой пользовательской аудитории ставку ${highestScoringOtherBid} либо этой пользовательской аудиторией, либо другой пользовательской аудиторией с тем же покупателем.
rejectReason Строка, опционально устанавливаемая продавцом, объясняющая, почему он отклонил ставку. Может иметь любое из следующих значений:

  • not-available
  • invalid-bid
  • bid-below-auction-floor
  • pending-approval-by-exchange
  • disapproved-by-exchange
  • blocked-by-publisher
  • language-exclusions
  • category-exclusions

Ограничения

  • URL-адрес хоста должен соответствовать зарегистрированному домену Privacy Sandbox.
  • URL-адрес не должен превышать 4096 символов, включая домен, префикс https:// и замененные данные аукциона.
  • В будущих версиях отладочные пинги будут отправляться только при подключении к Wi-Fi.

Поведение на устройстве

В мобильной среде защита памяти и использования сети является основным приоритетом. Таким образом, отладочные отчеты создаются партиями.

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

  • fledge_event_level_debug_reporting_batching_rate
  • fledge_event_level_debug_reporting_batch_size

Ожидаемая задержка отладочного отчета составляет от 15 до 60 минут после завершения аукциона.

Нет никаких жестких гарантий полноты отладочных отчетов. Если устройство перезагружается или процесс adservices падает до отправки вызовов на сервер, эти события отбрасываются.

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

Наконец, если пользователь отключил AdId , то отправляются отладочные отчеты. Это не реализовано в Developer Preview 9, но будет реализовано в будущих версиях.

Поведение сервера рекламных технологий

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

  • Устройство отправляет запросы GET на указанный вами сервер с помощью API forDebuggingOnly.* .
  • Каждый запрос представляет собой отладочный отчет на уровне одного события: одна победа или поражение на аукционе рекламы.
  • Каждый запрос не имеет тела. Все данные находятся в параметрах запроса.
  • Большие объемы ответных данных могут негативно повлиять на производительность и использование данных и поэтому игнорируются.