Debugowanie raportów w ramach Protected Audience API

Raportowanie debugowania Protected Audience umożliwia deweloperom technologii reklamowych deklarowanie zdalnych adresów URL, aby otrzymywać żądania GET z urządzeń po wygraniu lub przegraniu aukcji. Umożliwia to następujące zastosowania:

  • otrzymywać raporty o wygrywaniu i przegrywaniu aukcji;
  • Dowiedz się, dlaczego przegrywa się aukcje. Na przykład: sprawdź, czy problem dotyczy implementacji skryptu ustalania stawek lub skryptu oceniania, czy też jest to problem z główną logiką.
  • wykrywanie problemów podczas aktualizowania logiki JavaScriptu,

Raportowanie debugowania na poziomie zdarzenia jest dostępne do testowania w wersji Piaskownicy prywatności dla programistów 9. Raportowanie debugowania jest obsługiwane na wszystkich urządzeniach, na których jest dostępny identyfikator reklamy.

Naszym długofalowym celem jest umożliwienie platformie raportowania wyników aukcji za pomocą usługi prywatnej agregacji. Dzięki temu raportowanie po fakcie nie może służyć do łączenia niestandardowych list odbiorców poszczególnych użytkowników z aplikacją wydawcy. Raportowanie na poziomie zdarzenia jest tymczasowe, dopóki nie zostanie udostępnione odpowiednie framework raportowania.

Dowiedz się więcej o [raportowaniu błędów w pierwotnym projekcie testowania origin FLEDGE w Chrome][10].

Wykorzystanie

Raportowanie debugowania jest implementowane za pomocą tych interfejsów JavaScript, które przyjmują jako argument ciąg znaków adresu URL:

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

W tym przykładzie raportowana jest aukcja reklamy, która przegrała, ze zwycięską stawką i zmienną wewnętrzną. Te dane mogą być następnie używane do debugowania.

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

Po zakończeniu aukcji szablon ${winningBid} jest zastępowany rzeczywistą wartością.

Sprzedawcy mogą opcjonalnie zwrócić rejectReason z funkcji 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'
  }
}

Jeśli sprzedawca nie poda przyczyny odrzucenia, zamiast tego zostanie wysłana wartość not-available.

Zmienne w adresach URL

Zmienne, które można dodać do adresu URL debugowania, odpowiadają zmiennym w Chrome (z wyjątkiem zmiennych ${topLevelWinningBid} i ${topLevelMadeWinningBid}, ponieważ na Androidzie nie ma koncepcji aukcji komponentów).

Nazwa zmiennej Opis
winningBid Wartość zwycięskiej stawki.
madeWinningBid Wartość logiczna wskazująca, czy kupujący z tego niestandardowego listy odbiorców złożył zwycięską stawkę za pomocą tego niestandardowego listy odbiorców lub innego niestandardowego listy odbiorców należącego do tego samego kupującego.
highestScoringOtherBid Wartość stawki, która została oceniona jako druga najwyższa przez skrypt do oceny reklamy sprzedawcy. Pamiętaj, że nie musi to być druga najwyższa wartość stawki, ponieważ wyniki i stawki mogą być niezależne.
madeHighestScoringOtherBid Wartość logiczna wskazująca, czy kupujący tej listy niestandardowych odbiorców podał stawkę ${highestScoringOtherBid} za pomocą tej listy niestandardowych odbiorców lub innej listy niestandardowych odbiorców tego samego kupującego.
rejectReason Opcjonalny ciąg znaków ustawiany przez sprzedawcę, który wyjaśnia, dlaczego oferta została odrzucona. Może być dowolną z tych wartości:

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

Ograniczenia

  • Host adresu URL musi być zgodny z zarejestrowaną domeną Privacy Sandbox.
  • Adres URL nie może zawierać więcej niż 4096 znaków, w tym domeny, prefiksu https://i zastąpionych danych aukcji.
  • W przyszłych wersjach pingi debugowania będą wysyłane tylko po połączeniu z Wi-Fi.

Działanie na urządzeniu

W środowisku mobilnym priorytetem jest ochrona pamięci i użytkowania sieci. Dlatego raporty debugowania są generowane partiami.

Te właściwości systemu kontrolują szybkość i wielkość wsadu, które można dostosować do niższych wartości na potrzeby rozwoju:

  • fledge_event_level_debug_reporting_batching_rate
  • fledge_event_level_debug_reporting_batch_size

Przewidywany czas oczekiwania na raport debugowania to 15–60 minut od zakończenia aukcji.

Nie ma żadnych gwarancji dotyczących kompletności raportów debugowania. Jeśli urządzenie się zrestartuje lub proces adservices ulegnie awarii, zanim zostaną wysłane wywołania do serwera, te zdarzenia zostaną pominięte.

Każda platforma reklamowa może mieć maksymalnie 75 zarejestrowanych adresów URL debugowania na aukcję. Adresy URL zarejestrowane po osiągnięciu tego limitu są po cichu odrzucane.

Jeśli użytkownik wyłączył AdId, wysyłane są raporty debugowania. Ta funkcja nie jest dostępna w wersji 9 wersji deweloperskiej, ale zostanie zaimplementowana w przyszłych wersjach.

Sposób działania serwera technologii reklamowych

Serwery technologii reklamowych powinny zachowywać się w ten sposób podczas raportowania debugowania:

  • Urządzenie wysyła żądania GET do serwera określonego za pomocą interfejsów API forDebuggingOnly.*.
  • Każde żądanie odpowiada jednemu raportowi debugowania na poziomie zdarzenia: wygranej lub przegranej aukcji reklam.
  • Żadne żądanie nie ma treści. Wszystkie dane znajdują się w parametrach zapytania.
  • Duże ładunki odpowiedzi mogą negatywnie wpływać na wydajność i wykorzystanie danych, dlatego są ignorowane.