Debug-Berichte für Protected Audience

Dank der Debugging-Berichte für Protected Audience können AdTech-Entwickler URLs, an die eine GET-Anfrage von Geräten gesendet werden soll, wenn eine Auktion gewonnen oder verloren wird. Dieses ermöglicht folgende Anwendungsfälle:

  • Sie können Berichte zu gewonnenen und verlorenen Auktionsergebnissen abrufen.
  • Ermitteln, warum Auktionen verloren gehen Beispiel: Herausfinden, ob es sich um ein Problem handelt bei der Implementierung eines Gebots- oder Bewertungsskripts oder mit einem grundlegenden logischen Problem.
  • Probleme beim Aktualisieren der JavaScript-Logik erkennen

Berichte zur Fehlerbehebung auf Ereignisebene können in der Privacy Sandbox getestet werden Entwicklervorschau 9. Berichte zur Fehlerbehebung werden auf allen Geräten unterstützt, auf denen die Anzeigen-ID verfügbar.

Der langfristige Plan sieht vor, dass die Plattform Berichte zu Auktionsergebnissen mit dem Privater Aggregationsdienst. So wird sichergestellt, dass die nachträgliche Berichterstattung kann nicht verwendet werden, um die benutzerdefinierten Zielgruppen einzelner Nutzer mit der für die App des Publishers. Berichte auf Ereignisebene sind temporär, bis eine ausreichende Berichterstellung Framework veröffentlicht.

Weitere Informationen zu Debugging-Berichten im ursprünglichen FLEDGE-Ursprungstest von Chrome

Nutzung

Fehlerbehebungsberichte werden mit den folgenden JavaScript APIs implementiert, beide mit einem URL-String-Argument:

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

Im folgenden Beispiel wird ein Verlust einer Anzeigenauktion mit dem erfolgreichen Gebot gemeldet und ein interne Variable. Diese Daten können dann zur Fehlerbehebung verwendet werden.

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

Die Vorlage ${winningBid} wird durch den reellen Wert nach dem Tag abgeschlossen ist.

Verkäufer können optional über ihre scoreAds-Funktion eine rejectReason zurückgeben:

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'
  }
}

Wenn der Verkäufer keinen Ablehnungsgrund angibt, werden not-available gesendet. .

URL-Variablen

Die Variablen, die der Debug-URL hinzugefügt werden können, entsprechen ihren in Chrome (wobei ${topLevelWinningBid} und ${topLevelMadeWinningBid} sind nicht verfügbar, da noch kein Komponentenkonzept vorhanden ist Auktionen für Android).

Variablenname Beschreibung
winningBid Wert des erfolgreichen Gebots
madeWinningBid Boolescher Wert, der angibt, ob der Käufer dieser benutzerdefinierten die Zielgruppe hat das erfolgreiche Gebot abgegeben, entweder von dieser benutzerdefinierten Zielgruppe oder von einer anderen benutzerdefinierte Zielgruppe mit demselben Käufer.
highestScoringOtherBid Der Wert des Gebots, das vom mit dem Skript "scoreAd" des Verkäufers. Dies ist möglicherweise nicht das zweithöchste Gebot. verwenden, da Bewertungen und Gebote unabhängig voneinander sein können.
madeHighestScoringOtherBid Boolescher Wert, der angibt, ob der Käufer dieser benutzerdefinierten Zielgruppe hat das ${highestScoringOtherBid}-Gebot festgelegt, entweder durch diesen benutzerdefinierten oder eine andere benutzerdefinierte Zielgruppe mit demselben Käufer.
rejectReason Ein String, der optional von einem Verkäufer festgelegt wird, in dem erklärt wird, warum ein Gebot Folgende Werte sind möglich:

<ph type="x-smartling-placeholder">
    </ph>
  • not-available
  • invalid-bid
  • bid-below-auction-floor
  • pending-approval-by-exchange
  • disapproved-by-exchange
  • blocked-by-publisher
  • language-exclusions
  • category-exclusions

Einschränkungen

  • Der URL-Host muss mit Ihrer registrierten Privacy Sandbox-Domain übereinstimmen.
  • Die URL darf nicht länger als 4.096 Zeichen sein, einschließlich der Domain, ein https:// und ersetzte Auktionsdaten.
  • In zukünftigen Versionen werden Debugging-Pings nur gesendet, wenn eine WLAN-Verbindung besteht.

Verhalten auf dem Gerät

In einer mobilen Umgebung hat der Schutz von Arbeitsspeicher- und Netzwerknutzung höchste Priorität. Daher werden Debug-Berichte in Batches erstellt.

Mit den folgenden Systemeigenschaften wird die Batchrate und -größe gesteuert. für die Entwicklung auf niedrigere Werte eingestellt:

  • fledge_event_level_debug_reporting_batching_rate
  • fledge_event_level_debug_reporting_batch_size

Die erwartete Latenz eines Debug-Berichts beträgt 15 bis 60 Minuten nach einer Auktion abgeschlossen ist.

Es gibt keine feste Garantie für die Vollständigkeit der Debug-Berichte. Wenn das Gerät oder der AdServices-Prozess abstürzt, bevor Aufrufe an den Server gesendet werden, werden diese Ereignisse verworfen.

Für jede Anzeigentechnologie sind maximal 75 registrierte Debug-URLs pro Auktion zulässig. URLs registriert, nachdem dieses Limit erreicht wurde, werden ohne Meldung verworfen.

Hat der Nutzer AdId deaktiviert, werden die Fehlerbehebungsberichte gesendet. Dieses ist nicht in der Entwicklervorschau 9 implementiert, wird jedoch in Zukunft implementiert. Versionen.

Verhalten des AdTech-Servers

AdTech-Server sollten folgende Verhaltensweisen aufweisen, damit Fehlerberichte erstellt werden können:

  • Das Gerät sendet GET-Anfragen an den Server, den Sie mit der forDebuggingOnly.*-APIs.
  • Jede Anfrage stellt einen einzelnen Debug-Bericht auf Ereignisebene dar: eine einzelne Anzeigenauktion Gewinn oder Verlust bei der Auktion.
  • Jede Anfrage hat keinen Text. Alle Daten befinden sich in den Abfrageparametern.
  • Nutzlasten mit großer Antwort können sich negativ auf die Leistung und Datennutzung auswirken. werden ignoriert.