Auktionslatenz der Protected Audience API verbessern

Es liegt im Interesse aller, dass die Protected Audience API effizient funktioniert:

  • Nutzer, die im Web surfen, möchten, dass Websites schnell geladen werden. Daher sollten Entwickler die Protected Audience API effizient verwenden, um die begrenzten Geräteressourcen wie Rechen- oder Netzwerkressourcen, die zum Laden von Websites und eingebetteten Anzeigen erforderlich sind, nicht zu überlasten.
  • Publisher möchten, dass ihre Websites schnell geladen werden, damit Nutzer sie effizient und reaktionsschnell nutzen können. Publisher möchten auch effektive Anzeigen schalten, um ihre Einnahmen zu maximieren.
  • Werbetreibende und Anbieter von Anzeigentechnologien möchten, dass ihre Anzeigen schnell ausgeliefert werden, um den größtmöglichen Nutzen zu bieten.

In diesem Dokument werden einige Best Practices für die Implementierung der Protected Audience API beschrieben, damit Ihre Website möglichst effizient funktioniert.

Best Practices für Käufer (Gebote)

Mit diesen Best Practices können Sie die Effizienz von Protected Audience API-Auktionen optimieren.

Weniger Inhaber von Interessengruppen

Um Bieter der Protected Audience API auf die gleiche Weise zu schützen wie der Browser verschiedene Ursprünge im Web mithilfe der Website-Isolation, verwendet der Browser teure Ressourcen wie Betriebssystemprozesse, um einzelne Inhaber von Interessengruppen zu schützen.

Um die Ausgaben für diese sehr teuren Ressourcen zu minimieren, ist es entscheidend, möglichst wenige Inhaber von Interessengruppen zu haben. Vermeiden Sie verschiedene Interessengruppen, die verschiedenen Subdomains zugewiesen sind. Wenn adtech.example beispielsweise Interessengruppen von cats.adtech.example und dogs.adtech.example hat, verwendet der Browser wahrscheinlich zwei separate Prozesse, um die Gebotsscripts auszuführen.

Weniger Gebote für Interessengruppen

Der Browser muss umfangreiche Einrichtungs- und Vorbereitungsschritte ausführen, bevor das generateBid()-Script eines Käufers aufgerufen wird. Dazu gehört beispielsweise die Einrichtung einer neuen sauberen JavaScript-Ausführungsumgebung und das Parsen und Laden des generateBid()-Codes.

  • Interessengruppen, die Nutzer repräsentieren, die nicht das aktuelle Ziel einer aktiven Werbekampagne sind, sollten leere Listen mit Creatives haben. So wird verhindert, dass die Protected Audience API generateBid() für Interessengruppen ohne relevante Anzeigen ausführt.
  • Wenn Sie ähnliche Interessengruppen kombinieren, muss generateBid() seltener ausgeführt werden. In der userBiddingSignals-Property einer Interessengruppe können zusätzliche Metadaten zum Nutzer gespeichert werden. Weniger Interessengruppen müssen also nicht unbedingt weniger effektives Targeting bedeuten.
  • Die Protected Audience API unterstützt vom Verkäufer festgelegte Limits für die Anzahl der Interessengruppen und eine API, mit der Käufer die relative Priorität ihrer Interessengruppen angeben können. Mit diesen Limits lässt sich die Anzahl der ausführbaren Gebotsscripts erheblich reduzieren.

Interessengruppen aus Geboten in Ihrem Schlüssel/Wert-Dienst herausfiltern

Wenn ein Käufer auf seinem Server für Echtzeitsignale für vertrauenswürdige Gebote feststellt, dass für bestimmte Interessengruppen keine Gebote abgegeben werden sollen (z.B. weil die Kampagne deaktiviert, pausiert oder das Budget aufgebraucht ist oder keine Gebote für diesen bestimmten Publisher abgegeben werden sollen), kann er dies dem Browser mit der priorityVector-Antwort auf den Abruf der vertrauenswürdigen Gebotesignale mitteilen. Wenn das resultierende spärliche Skalarprodukt von priorityVector und prioritySignals negativ ist, überspringt der Browser das Aufrufen von generateBid() für diese Interessengruppe. Weitere Informationen zu diesem Mechanismus finden Sie im Abschnitt Filtern und Priorisieren von Interessengruppen.

JavaScript-Ausführungsumgebung wiederverwenden

Bevor der Browser generateBid() ausführen kann, muss er eine neue JavaScript-Ausführungsumgebung initialisieren. Das kann einige Zeit dauern, ähnlich wie bei der Ausführung einer minimalen generateBid(). Mit den Ausführungsmodi „Nach Herkunft gruppieren“ oder „Kontext einfrieren“ lässt sich diese Zeit sparen.

Im group-by-origin-Modus können Ausführungsumgebungen wiederverwendet werden, wenn Interessengruppen auf demselben Ursprung zusammengeführt werden. In diesem Fall sind wahrscheinlich keine Änderungen am Gebotsskript erforderlich. Weitere Informationen finden Sie in der group-by-origin-Beschreibung im Hilfeartikel. Im Modus mit eingefrorenem Kontext können potenziell alle Ausführungsumgebungen wiederverwendet werden. Es sind jedoch möglicherweise Änderungen an Ihrem Gebotsskript erforderlich. Weitere Informationen finden Sie in der frozen-contextBeschreibung im Hilfeartikel.

Gebotsscripts wiederverwenden

Verwenden Sie nach Möglichkeit dasselbe Gebotsskript für Interessengruppen. So muss der Browser nicht mehrere Scripts herunterladen, parsen und kompilieren, was zusätzliche Netzwerkanfragen verursacht. Bieter können weiterhin Gebote basierend auf Informationen zu Interessengruppen (z.B. name oder userBiddingSignals) differenzieren, während sie dasselbe Script verwenden.

Ohne HTTP-Header zur Cache-Steuerung wird das Gebotsscript nicht im Cache gespeichert. Geben Sie geeignete Header an, damit das Script nicht unnötig abgerufen wird. Wenn auf der Seite mehrere Auktionen parallel ausgeführt werden, wird das Gebotsskript desselben Bieters wiederverwendet, wenn es sich bereits im Arbeitsspeicher befindet. Dabei werden die Caching-Semantiken ignoriert. Wenn die Auktionen nacheinander ausgeführt werden, hält sich der Browser an den HTTP-Caching-Mechanismus.

Der Browser lädt das Gebotsscript während der Gebotszeit (für generateBid()) und auch während der Berichtszeit (für reportWin()). Wenn keine Cache-Kontroll-Header festgelegt sind, ruft der Browser dasselbe Script zweimal ab, einmal für jeden Zeitraum.

Wir empfehlen daher, für alle Scripts Cache-Kontroll-Header festzulegen.

trustedBiddingSignalsUrls wiederverwenden

Die Netzwerklatenz und die Ressourcennutzung können sehr hoch sein. Wenn weniger Echtzeitabrufe für vertrauenswürdige Gebotssignale erfolgen, kann sich die Latenz verringern.

Die Abrufe von vertrauenswürdigen Gebotssignalen können kombiniert werden, wenn die trustedBiddingSignalsUrl für mehrere Interessengruppen wiederverwendet wird. Verwenden Sie nach Möglichkeit dieselbe trustedBiddingSignalsUrl für alle Interessengruppen.

Geben Sie die entsprechenden HTTP-Cache-Kontroll-Header an, damit Abrufe vertrauenswürdiger Gebotssignale in Anzeigenslots auf einer bestimmten Webseite im Cache gespeichert werden. Legen Sie trustedBiddingSignalsSlotSizeMode nicht auf slot-size fest, da dies das Caching in Anzeigenslots verhindert, wenn sich die Slots unterscheiden, da sich die angeforderte URL unterscheidet.

Weniger Abrufe von Echtzeitsignalen für vertrauenswürdige Gebote

Die Netzwerklatenz kann sehr hoch sein. Das hängt direkt davon ab, wie viele Daten beim Abrufen des Echtzeitsignals für vertrauenswürdige Gebote übertragen werden.

Speichern Sie datenbezogen auf Anzeigen oder Interessengruppen lieber in der Interessengruppe als im Dienst für Echtzeitsignale für vertrauenswürdige Gebote. Verwenden Sie Daten zu vertrauenswürdigen Echtzeitgeboten nur für wirkliche Echtzeitsignale wie Kampagnenbudgets oder Kill-Switches.

Alle Signale, die täglich oder in längeren Abständen aktualisiert werden können, sollten in der Interessengruppe gespeichert und mit den täglichen Updates aktualisiert werden.

Geben Sie keine vertrauenswürdigen Gebotssignale für Interessengruppen zurück, die wie im Abschnitt Interessengruppen aus Geboten in Ihrem Schlüssel/Wert-Dienst herausfiltern beschrieben herausgefiltert werden.

Interessengruppen priorisieren

Verkäufer verwenden Zeitüberschreitungen, um die Nutzung von Browserressourcen auf Publisher-Seiten einzuschränken. Wenn perBuyerCumulativeTimeouts verwendet werden, um zu begrenzen, wie lange Käufer ihre vertrauenswürdigen Gebotssignale abrufen und ihre Gebotsscripts ausführen müssen, ist es wichtig, dass Käufer ihre Interessengruppen priorisieren, damit die mit der höchsten Wahrscheinlichkeit zum Gewinn der Auktion zuerst ausgeführt werden. Wenn perBuyerCumulativeTimeouts beispielsweise auf 100 ms festgelegt ist, das Abrufen der vertrauenswürdigen Gebotssignale eines Bieters 50 ms dauert, jede generateBid()-Aufruf 10 ms in Anspruch nimmt und auf einem Gerät 10 Interessengruppen vorhanden sind, kann nur für die Hälfte der Interessengruppen ein Gebot berechnet werden. Der Käufer in diesem Beispiel sollte seine Interessengruppen nach der Wahrscheinlichkeit des Zuschlags priorisieren.

Interessengruppen können statische Prioritäten enthalten, die im Feld priority definiert sind. Für Interessengruppen können auch dynamische Prioritäten verwendet werden, die in ihrem Dienst für vertrauenswürdige Gebotssignale berechnet und mit der priorityVector-Antwort auf den Abruf der vertrauenswürdigen Gebotssignale an den Browser zurückgegeben werden.

Wenn der Browser Interessengruppen in absteigender Priorität ausführt, werden möglicherweise Interessengruppen aus verschiedenen Quellen für die Zusammenführung verwendet, was die group-by-origin-Optimierung beeinträchtigen kann.

Best Practices für Verkäufer

Beobachten und optimieren Sie die Effizienz von Protected Audience API-Auktionen.

Auktionen parallelisieren

Moderne Netzwerkverbindungen und Multi-Core-Prozessoren eignen sich hervorragend für die gleichzeitige Ausführung mehrerer Aktivitäten. Der Browser kann eine Protected Audience-Auktion parallel zu anderen Aktivitäten ausführen. Am besten rufen Sie runAdAuction() so früh wie möglich auf. Da einige Eingaben für runAdAuction() möglicherweise nicht sofort verfügbar sind, z. B. solche, die in der kontextbezogenen Antwort an den Browser zurückgesendet werden, ermöglicht der Browser den Aufruf von runAdAution(), bevor sie verfügbar sind, und die Bereitstellung dieser Eingaben zu einem späteren Zeitpunkt mithilfe von JavaScript-Versprechen. Um die niedrigste Auktionslatenz zu erreichen, sollte runAdAuction() aufgerufen werden, wenn die interestGroupBuyers-Eingabe bekannt ist. So können viele Teile der Auktion sofort beginnen, einschließlich des Abrufens der Echtzeitgebotssignale der Bieter.

Auktionen im Blick behalten

Messwerte zu Ihren Auktionen erfassen Der Browser kann Verkäufern per-buyerLatenzmesswerte melden, die Aufschluss darüber geben, wie viel Zeit in den Auktionen eines Verkäufers vergeht. Anhand dieser Messwerte können Verkäufer nach Möglichkeiten suchen, ihre Auktionen zu optimieren. So erfahren sie beispielsweise, wie sie Zeitüberschreitungen am effektivsten festlegen. Verkäufer können den Käufern die Latenzmesswerte eines bestimmten Käufers zur Verfügung stellen, damit sie diese weiter optimieren können.

Bieter können zwar Einblicke in die Gebotsleistung ihrer eigenen Interessengruppen erhalten, diese aber möglicherweise nicht mit anderen Bietern vergleichen. Wenn Sie die relativen Akzeptanzraten und Gebotsablehnungsraten für verschiedene Bieter vergleichen, können Sie Fälle erkennen, in denen Rechenressourcen für Gebote verschwendet wurden, weil Interessengruppen nie zu akzeptablen Geboten geführt haben oder übermäßig mit nicht genehmigten Creatives geboten wurde.

Schutz vor langsamen Gebotsscripts

Gebotsscripts, die zu viel Zeit in Anspruch nehmen, können die Protected Audience API-Auktion für alle Beteiligten verlangsamen. Mit Zeitüberschreitungen können Sie langsame Auktionen vermeiden und trotzdem Umsatz erzielen, wenn die Auktion langsam ist.

Verkäufer sollten perBuyerCumulativeTimeouts verwenden, um langsame Auktionen zu vermeiden und auch Gebote anzunehmen, wenn die Auktion langsam ist und die Zeitüberschreitung erreicht. Die Verwendung von perBuyerCumulativeTimeouts ist vorzuziehen, da perBuyerTimeouts und perBuyerGroupLimits die Anzahl der Interessengruppen oder die Geschwindigkeit von generateBid() nicht berücksichtigen. So können beispielsweise viele Interessengruppen, die schnell Gebote abgeben, und wenige Interessengruppen, die langsam Gebote abgeben, vor Ablauf der Zeitüberschreitung abgeschlossen werden.perBuyerCumulativeTimeouts

Sie können auch das Feld „Auktionskonfiguration“ signal verwenden, um eine allgemeine Auktions-Zeitüberschreitung zu implementieren. So lassen sich zu lange Auktionen vermeiden, wenn das Abrufen und Ausführen des vertrauenswürdigen Bewertungssignals zu viel Zeit in Anspruch nimmt.scoreAd()

Nächste Schritte

Wir möchten mit Ihnen ins Gespräch kommen, um eine API zu entwickeln, die für alle funktioniert.

Über die API diskutieren

Wie andere Privacy Sandbox APIs wird auch diese API dokumentiert und öffentlich diskutiert.

Mit der API experimentieren

Sie können Tests zur Protected Audience API durchführen und sich an Diskussionen beteiligen.