Debugowanie raportów w ramach Protected Audience API

Raporty dotyczące debugowania w ramach Protected Audience API umożliwiają deweloperom deklarowanie funkcji zdalnych Adresy URL, które mają otrzymać żądanie GET z urządzeń w przypadku wygranej lub przegranej aukcji. Ten umożliwia te przypadki użycia:

  • Otrzymuj raporty o wygranych i przegranych aukcjach.
  • Dowiedz się, dlaczego aukcje przegrywają Na przykład: sprawdź, czy to problem z implementacją skryptu określania stawek lub punktacji albo z głównym problemem logicznym.
  • Wykrywanie problemów z aktualizacją logiki JavaScriptu

Raportowanie debugowania na poziomie zdarzenia jest dostępne do testowania w Piaskownicy prywatności Podgląd dla programistów 9. Raportowanie debugowania jest obsługiwane na wszystkich urządzeniach, na których identyfikator AdId ma wartość i dostępności informacji.

Planem długoterminowym jest umożliwienie platformie raportowania wyników aukcji za pomocą Usługa agregacji prywatnej. Dzięki temu raportowanie po wystąpieniu nie można za jego pomocą łączyć niestandardowych list odbiorców poszczególnych użytkowników z w aplikacji wydawcy. Raporty na poziomie zdarzenia są tymczasowe, do momentu uzyskania odpowiedniego raportowania platformy.

Dowiedz się więcej o raportowaniu debugowania w ramach testowania origin FLEDGE w Chrome ofertę pakietową.

Wykorzystanie

Raportowanie debugowania jest wdrażane za pomocą poniższych interfejsów API JavaScript. Oba które przyjmują argument ciągu adresu URL:

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

W przykładzie poniżej podano przegraną w aukcji ze zwycięską stawką, a dodatkowo zmienną wewnętrzną. Dane te mogą być później używane do debugowania.

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

Szablon ${winningBid} jest zastępowany rzeczywistą wartością po elemencie aukcja została zakończona.

Sprzedawcy mogą opcjonalnie zwrócić rejectReason ze swojej 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 ustawi przyczyny odrzucenia, zostanie wysłana wiadomość not-available .

Zmienne adresów URL

Zmienne, które można dodać do adresu URL debugowania odpowiadają parametrom w Chrome (chociaż ${topLevelWinningBid} i Wartości ${topLevelMadeWinningBid} są niedostępne, ponieważ nie ma pojęcia komponentu. aukcji na Androidzie).

Nazwa zmiennej Opis
winningBid Wartość zwycięskiej stawki.
madeWinningBid Wartość logiczna wskazująca, czy kupujący tego niestandardowego zamówienia grupa odbiorców, która wybrała zwycięską stawkę, za pomocą tej niestandardowej grupy odbiorców lub innego niestandardowe listy odbiorców z tym samym kupującym.
highestScoringOtherBid Wartość stawki, która została oznaczona jako druga w kolejności przez skrypt ScoreAd sprzedawcy. Pamiętaj, że nie może to być druga najwyższa stawka. ponieważ wyniki i stawki mogą być niezależne od siebie.
madeHighestScoringOtherBid Wartość logiczna wskazująca, czy kupujący w przypadku danej niestandardowej listy odbiorców ${highestScoringOtherBid}, za pomocą tego niestandardowej stawki, lub inną niestandardową listę odbiorców z tym samym kupującym.
rejectReason opcjonalnie ustawiony przez sprzedawcę ciąg tekstowy wyjaśniający, dlaczego odrzucił stawkę. Może mieć 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 pasować do zarejestrowanej domeny Piaskownicy prywatności.
  • Długość adresu URL nie może przekraczać 4096 znaków łącznie z domeną i atrybutem https:// i podstawione dane aukcji.
  • W kolejnych wersjach pingi debugowania będą wysyłane tylko po połączeniu z siecią Wi-Fi.

Działanie na urządzeniu

W środowisku mobilnym ochrona pamięci i wykorzystania sieci jest głównym priorytetem. Z tego powodu raporty na temat debugowania są generowane zbiorczo.

Poniższe właściwości systemu kontrolują szybkość wsadu i rozmiar, które można dostosowane do niższych wartości na potrzeby programowania:

  • fledge_event_level_debug_reporting_batching_rate
  • fledge_event_level_debug_reporting_batch_size

Spodziewany czas oczekiwania na raport debugowania wynosi 15–60 minut od zakończenia aukcji została zakończona.

Nie ma sztywnych gwarancji co do kompletności raportów debugowania. Jeśli urządzenie uruchamia się ponownie lub ulega awarii przed wysłaniem wywołań serwera, są pomijane.

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

I na koniec, jeśli użytkownik wyłączył AdId, raporty na temat debugowania są wysyłane. Ten nie została zaimplementowana w wersji przedpremierowej dla programistów w wersji 9, ale zostanie wprowadzona w przyszłości. wersji.

Działanie serwera technologii reklamowych

Na potrzeby raportowania debugowania serwery technologii reklamowych powinny działać w ten sposób:

  • Urządzenie wysyła żądania GET do wskazanego przez Ciebie serwera za pomocą metody forDebuggingOnly.* interfejsów API.
  • Każde żądanie reprezentuje 1 raport debugowania na poziomie zdarzenia: jedną aukcję reklam. wygranej lub przegranej w aukcji.
  • Żadne żądanie nie ma treści. Wszystkie dane znajdują się w parametrach zapytania.
  • duże ładunki odpowiedzi mogą negatywnie wpłynąć na wydajność i użycie danych; są ignorowane.