Auktionslatenz der Protected Audience API verbessern

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

  • Nutzer möchten, dass Websites schnell geladen werden. Entwickler sollten also effizient Anwendungen mit der Protected Audience API erstellen, um eine übermäßige Auslastung von begrenzten Geräteressourcen wie Rechen- oder Netzwerkressourcen, die zum Laden von Websites und ihren eingebetteten Anzeigen erforderlich sind, zu vermeiden.
  • Publisher möchten, dass ihre Websites schnell geladen werden, was den Nutzern eine effiziente und reaktionsschnelle Erfahrung bietet. Publisher wünschen sich zudem effektive Werbung, um ihren Umsatz zu maximieren.
  • Werbetreibende und Anzeigentechnologie-Anbieter möchten, dass ihre Anzeigen schnell eingeblendet werden, um maximalen Nutzen zu bieten.

In diesem Dokument werden einige Best Practices für eine Protected Audience API-Implementierung beschrieben, mit der Sie Ihre Website mit maximaler Effizienz betreiben können.

Best Practices für Käufer (Bieter)

Beachten Sie die folgenden Best Practices, um die Effizienz von Protected Audience API-Auktionen zu optimieren.

Weniger Inhaber von Interessengruppen

Um Protected Audience API-Bieter auf dieselbe Weise zu schützen wie der Browser verschiedene Ursprünge im Web mithilfe der Website-Isolierung, verwendet der Browser teure Ressourcen (z. B. Betriebssystemprozesse), um einzelne Inhaber von Interessengruppen zu schützen.

Um die Ausgaben dieser sehr teuren Ressourcen zu minimieren, ist es entscheidend, nur wenige Inhaber von Interessengruppen zu haben. Vermeiden Sie verschiedene Interessengruppen, die verschiedenen Subdomains zugeordnet sind. Wenn adtech.example beispielsweise Interessengruppen hätte, die zu cats.adtech.example und dogs.adtech.example gehören, würde der Browser wahrscheinlich zwei separate Prozesse zum Ausführen der Gebotsskripts verwenden.

Gebote mit weniger Interessengruppen

Der Browser muss vor dem Aufrufen des generateBid()-Skripts eines Käufers umfangreiche Einrichtungs- und Vorbereitungsschritte ausführen, z. B. eine neue saubere JavaScript-Ausführungsumgebung einrichten sowie den generateBid()-Code parsen und laden.

  • Für Interessengruppen, die Nutzer repräsentieren, die derzeit nicht das aktuelle Ziel einer aktiven Werbekampagne sind, sollten leere Anzeigen-Creative-Listen vorhanden sein. Dadurch 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. Mit der Property userBiddingSignals einer Interessengruppe können zusätzliche Metadaten zum Nutzer gespeichert werden. Weniger Interessengruppen bedeuten also nicht weniger effektives Targeting.
  • Die Protected Audience API unterstützt von Verkäufern angegebene 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 auszuführenden Gebotsskripts erheblich reduzieren.

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

Wenn ein Käufer auf seinem Echtzeit-Signalserver für vertrauenswürdige Gebote feststellen kann, dass bestimmte Interessengruppen keine Gebote abgeben sollten, weil z.B. die Kampagne deaktiviert oder pausiert ist, das Budget erschöpft ist oder für diesen Publisher kein Gebot abgegeben werden sollte, kann er dem Browser mit der priorityVector-Antwort auf den Abruf der vertrauenswürdigen Gebotssignale mitteilen. Wenn das resultierende dünnbesetzte 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 in der Erläuterung im Abschnitt Interessengruppen filtern und priorisieren.

JavaScript-Ausführungsumgebung wiederverwenden

Bevor der Browser generateBid() ausführen kann, muss er eine neue JavaScript-Ausführungsumgebung initialisieren. Das kann ziemlich viel Zeit in Anspruch nehmen, ähnlich wie die Zeit, die ein minimaler generateBid()-Vorgang selbst für die Ausführung dauern kann. Diese Zeit kann mit den Ausführungsmodi „Gruppieren nach Ursprung“ oder „Eingefrorener Kontext“ eingespart werden.

Im Modus „group-by-origin“ können Ausführungsumgebungen wiederverwendet werden, wenn Interessengruppen am selben Ursprung zusammengeführt sind und wahrscheinlich keine Änderungen an Ihrem Gebotsskript erforderlich sind. Weitere Informationen finden Sie in der Erläuterung zu group-by-origin. In diesem Modus können potenziell alle Ausführungsumgebungen wiederverwendet werden, allerdings sind unter Umständen Änderungen an Ihrem Gebotsskript erforderlich. Weitere Informationen finden Sie in der Erläuterung zu frozen-context.

Gebotsskripts wiederverwenden

Verwenden Sie nach Möglichkeit dasselbe Gebotsskript für Interessengruppen. Dadurch wird verhindert, dass der Browser mehrere Skripts herunterladen, parsen und kompilieren muss (was zusätzliche Netzwerkanfragen verursacht). Bieter können mit demselben Script weiterhin Gebote anhand von Informationen zu Interessengruppen differenzieren (z.B. name oder userBiddingSignals).

trustedBiddingSignalsUrls wiederverwenden

Die Netzwerklatenz und die Ressourcennutzung können sehr stark sein. Diese Latenz kann durch weniger Echtzeitabrufe von vertrauenswürdigen Signalen verringert werden.

Die Abrufe von Signalen für vertrauenswürdige Gebote können kombiniert werden, wenn das trustedBiddingSignalsUrl für mehrere Interessengruppen wiederverwendet wird. Verwenden Sie nach Möglichkeit für alle Interessengruppen dieselbe trustedBiddingSignalsUrl.

Geben Sie geeignete HTTP-Cache-Steuerungsheader an, damit vertrauenswürdige Gebotssignale auf allen Anzeigenflächen einer bestimmten Webseite im Cache gespeichert werden. Legen Sie trustedBiddingSignalsSlotSizeMode nicht auf slot-size fest, da sonst das Caching über Anzeigenflächen hinweg verhindert wird, wenn sich die Größe der Anzeigenflächen unterscheidet, weil die angeforderte URL davon abweicht.

Kleinere Abrufe von vertrauenswürdigen Gebotssignalen in Echtzeit

Die Netzwerklatenz kann sehr hoch sein und hängt direkt davon ab, wie viele Daten beim Abrufen von Trusted Bidding-Signalen in Echtzeit übertragen werden.

Sie sollten werbe- oder interessengruppenspezifische Daten lieber in der Interessengruppe speichern als im Echtzeitsignaldienst für vertrauenswürdige Gebote. Reservieren Sie Echtzeitdaten zu vertrauenswürdigen Gebotssignalen nur für solche, die tatsächlich in Echtzeit sind, z. B. für das Kampagnenbudget oder für Kill-Switches.

Alle Signale, die täglich oder länger aktualisiert werden können, sollten in der Interessengruppe gespeichert und mithilfe der täglichen Aktualisierungen aktualisiert werden.

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

Interessengruppen priorisieren

Verkäufer begrenzen mithilfe von Zeitüberschreitungen die Nutzung von Browserressourcen auf Publisher-Seiten. Wenn perBuyerCumulativeTimeouts verwendet wird, um einzuschränken, wie lange Käufer ihre vertrauenswürdigen Gebotssignale abrufen und ihre Gebotsskripts ausführen müssen, ist es wichtig, dass sie ihre Interessengruppen priorisieren, damit diejenigen, die die Auktion am ehesten gewinnen, zuerst ausgeführt werden. Beispiel: Wenn „perBuyerCumulativeTimeouts“ auf 100 ms festgelegt ist und das Abrufen der vertrauenswürdigen Gebotssignale eines Bieters 50 ms dauert, jeder generateBid()-Aufruf 10 ms dauert und auf einem Gerät 10 Interessengruppen vorhanden sind, hat nur die Hälfte der Interessengruppen die Möglichkeit, Gebote zu berechnen. Der Käufer in diesem Beispiel sollte seine Interessengruppen in absteigender Reihenfolge priorisieren.

Interessengruppen können statische Prioritäten enthalten, die im Feld priority definiert sind. Interessengruppen können auch dynamische Prioritäten verwenden, die für den 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 die Interessengruppen von der höchsten zur niedrigsten Priorität ausführt, können dadurch Interessengruppen mit unterschiedlichen Ursprungsquellen ineinandergreifen, wodurch die group-by-origin-Optimierung unter Umständen nicht berücksichtigt wird.

Best Practices für Verkäufer

Achten Sie darauf, die Auktionseffizienz der Protected Audience API zu überwachen und zu optimieren.

Auktionen parallelisieren

Moderne Netzwerkverbindungen und Multi-Core-Prozessoren sind hervorragend dafür geeignet, mehrere Aktivitäten gleichzeitig auszuführen. Der Browser kann parallel zu anderen Aktivitäten eine Protected Audience-Auktion ausführen. Rufen Sie dazu so früh wie möglich runAdAuction() an. Da einige Eingaben an runAdAuction() möglicherweise nicht zu Beginn verfügbar sind, z. B. solche, die in der kontextbezogenen Antwort an den Browser zurückgesendet werden, lässt der Browser den Aufruf von runAdAution() zu, bevor sie verfügbar sind, und die Eingabe dieser Eingaben zu einem späteren Zeitpunkt mithilfe von JavaScript Promises. Zum Erreichen der geringstmöglichen Auktionslatenz 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

Erfassen Sie Messwerte für Ihre Auktionen. Der Browser kann per-buyer-Latenzmesswerte an Verkäufer melden, die einen umfassenden Überblick darüber bieten, wie viel Zeit in Auktionen eines Verkäufers bleibt. Anhand dieser Messwerte können Verkäufer ihre Auktionen optimieren und beispielsweise Zeitüberschreitungen einrichten. Verkäufer können die Latenzmesswerte eines bestimmten Käufers mit dem Käufer teilen, um weitere Optimierungen vornehmen zu können.

Bieter können die Gebotsleistung ihrer eigenen Interessengruppen zwar einsehen, jedoch nicht mit anderen Bietern vergleichen. Durch den Vergleich der relativen Gewinn- und Gebotsablehnungsraten für verschiedene Bieter lassen sich Fälle ermitteln, in denen Rechenressourcen für Gebote verschwendet wurden, weil Interessengruppen nie praktikable Gebote erstellen oder zu hohe Gebote mit nicht genehmigten Creatives abgeben.

Vor langsamen Gebotsskripts schützen

Die Verwendung von Gebotsskripts, die zu lange dauern, kann die Protected Audience API-Auktion für alle Beteiligten verlangsamen. Zeitüberschreitungen können langsame Auktionen verhindern und trotzdem Umsatz erzielen, wenn die Auktion langsam ist.

Verkäufer sollten perBuyerCumulativeTimeouts verwenden, um langsame Auktionen zu verhindern und weiterhin Gebote anzunehmen, wenn die Auktion langsam ist und das Zeitlimit erreicht wird. Die Verwendung von perBuyerCumulativeTimeouts ist besser als perBuyerTimeouts und perBuyerGroupLimits, da für perBuyerCumulativeTimeouts die Anzahl der Interessengruppen oder die Geschwindigkeit von generateBid() nicht berücksichtigt wird. So können beispielsweise viele Interessengruppen, die schnell bieten, und wenige Interessengruppen, die langsam bieten, beide vor dem Zeitlimit abgeschlossen werden.

Wenn Sie ein allgemeines Zeitlimit für Auktionen über das Feld signal für die Auktionskonfiguration implementieren, sollten Sie außerdem zu lange Auktionen vermeiden, wenn das Abrufen und Ausführen von scoreAd() zu lange dauert.

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.