Es liegt im Interesse aller, dass die Protected Audience API effizient funktioniert:
- Nutzer, die im Web surfen, möchten, dass Websites schnell geladen werden. Entwickler sollten die Protected Audience API also effizient nutzen, um die begrenzten Geräteressourcen wie Rechen- oder Netzwerkressourcen, die zum Laden von Websites und den darin 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 Werbung, um ihren Umsatz zu maximieren.
- Werbetreibende und Anbieter von Anzeigentechnologien möchten, dass ihre Anzeigen schnell ausgeliefert werden, um den größtmöglichen Nutzen zu erzielen.
In diesem Dokument werden einige Best Practices für die Implementierung der Protected Audience API beschrieben, damit Ihre Website maximal effizient funktioniert.
Best Practices für Käufer (Bieter)
Wenn Sie die Effizienz von Protected Audience API-Auktionen optimieren möchten, sollten Sie die folgenden Best Practices beachten.
Weniger Inhaber von Interessengruppen
Um Protected Audience API-Bietende auf dieselbe Weise zu schützen, wie der Browser verschiedene Ursprünge im Web mit Website-Isolierung schützt, verwendet der Browser teure Ressourcen (z. B. Betriebssystemprozesse), um einzelne Inhaber von Interessengruppen zu schützen.
Um den Aufwand für diese sehr teuren Ressourcen zu minimieren, ist es entscheidend, dass es so wenige Inhaber von Interessengruppen wie möglich gibt. Vermeiden Sie, dass verschiedene Interessengruppen zu verschiedenen Subdomains gehören. Wenn adtech.example beispielsweise Interessengruppen von cats.adtech.example und dogs.adtech.example enthält, verwendet der Browser wahrscheinlich zwei separate Prozesse, um die Gebotsskripts auszuführen.
Weniger Interessengruppen bieten
Der Browser muss vor dem Aufrufen des generateBid()-Skripts eines Käufers umfangreiche Einrichtungs- und Vorbereitungsarbeiten durchfü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 nicht das aktuelle Ziel einer aktiven Werbekampagne sind, sollten die Listen mit Anzeigen-Creatives leer sein. 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. Mit deruserBiddingSignals-Property einer Interessengruppe können zusätzliche Metadaten zum Nutzer gespeichert werden. Weniger Interessengruppen bedeuten also nicht unbedingt ein weniger effektives Targeting. - Die Protected Audience API unterstützt vom Verkäufer angegebene Grenzwerte für die Anzahl der Interessengruppen und eine API für Käufer, mit der sie 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 vertrauenswürdigen Gebotssignalserver in Echtzeit feststellen kann, dass für bestimmte Interessengruppen keine Gebote abgegeben werden sollten (z.B. weil die Kampagne deaktiviert, pausiert oder das Budget überschritten ist oder für diesen bestimmten Publisher keine Gebote abgegeben werden sollten), kann er dies dem Browser mit der priorityVector-Antwort auf den Abruf der vertrauenswürdigen Gebotssignale mitteilen. Wenn das resultierende spärliche Skalarprodukt von priorityVector und prioritySignals negativ ist, ruft der Browser generateBid() für diese Interessengruppe nicht auf. Weitere Informationen zu diesem Mechanismus finden Sie im Abschnitt „Interest Groups filtering and prioritizing“ (Filterung und Priorisierung von Interessengruppen) im Explainer.
JavaScript-Ausführungsumgebung wiederverwenden
Bevor der Browser generateBid() ausführen kann, muss er eine neue JavaScript-Ausführungsumgebung initialisieren. Das kann viel Zeit in Anspruch nehmen, ähnlich wie die Ausführung eines minimalen generateBid(). Diese Zeit kann durch die Ausführungsmodi „Nach Herkunft gruppieren“ oder „Eingefrorener Kontext“ eingespart werden.
Im group-by-origin-Modus können Ausführungsumgebungen wiederverwendet werden, wenn Interessengruppen auf derselben Herkunft beigetreten werden. Wahrscheinlich sind keine Änderungen an Ihrem Gebotsscript erforderlich. Weitere Informationen finden Sie in der group-by-origin-Beschreibung in der Erläuterung. Im eingefrorenen Kontextmodus können potenziell alle Ausführungsumgebungen wiederverwendet werden. Möglicherweise sind jedoch Änderungen an Ihrem Gebotsskript erforderlich. Weitere Informationen finden Sie in der frozen-context-Beschreibung im Explainer.
Gebotsskripts wiederverwenden
Verwenden Sie nach Möglichkeit dasselbe Gebotsskript für Interessengruppen. So muss der Browser nicht mehrere Skripts herunterladen, parsen und kompilieren, was zusätzliche Netzwerkanfragen zur Folge hätte. Bieter können weiterhin Gebote basierend auf Informationen zu Interessengruppen (z.B. name oder userBiddingSignals) unterscheiden, während sie dasselbe Skript verwenden.
Ohne HTTP-Cache-Steuerungsheader wird das Gebotsscript nicht im Cache gespeichert. Geben Sie geeignete Header an, damit das Skript nicht unnötig abgerufen wird. Wenn auf der Seite mehrere Auktionen parallel laufen, wird das Gebotsskript desselben Bieters wiederverwendet, wenn es sich bereits im Arbeitsspeicher befindet. Dabei wird die Caching-Semantik ignoriert. Wenn die Auktionen sequenziell ablaufen, 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-Control-Header festgelegt sind, ruft der Browser dasselbe Script zweimal ab, einmal für jeden Zeitraum.
Wir empfehlen daher, für alle Ihre Skripts Cache-Control-Header festzulegen.
trustedBiddingSignalsUrls wiederverwenden
Netzwerklatenz und Ressourcennutzung können sehr hoch sein. Weniger Abrufe von vertrauenswürdigen Echtzeit-Gebotssignalen können dazu beitragen, diese Latenz zu 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 geeignete HTTP-Cache-Control-Header an, damit vertrauenswürdige Abrufe von Gebotssignalen für alle Anzeigen-Slots auf einer bestimmten Webseite im Cache gespeichert werden. Vermeiden Sie es, trustedBiddingSignalsSlotSizeMode auf slot-size festzulegen. Dadurch wird das Caching über Anzeigen-Slots hinweg verhindert, wenn sich die Größen der Slots unterscheiden, da sich die angeforderte URL unterscheidet.
Weniger Abrufe von vertrauenswürdigen Echtzeit-Gebotssignalen
Die Netzwerklatenz kann sehr hoch sein. Sie hängt direkt davon ab, wie viele Daten während der Abrufe von Signalen für vertrauenswürdige Gebote in Echtzeit übertragen werden.
Speichern Sie anzeigenspezifische oder interessengruppenspezifische Daten lieber in der Interessengruppe als im vertrauenswürdigen Echtzeit-Gebotssignaldienst. Reservieren Sie vertrauenswürdige Echtzeit-Gebotssignaldaten nur für Signale, die wirklich in Echtzeit benötigt werden, z. B. für 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 zu begrenzen. Wenn perBuyerCumulativeTimeouts verwendet werden, um die Zeit zu begrenzen, die Käufer zum Abrufen ihrer vertrauenswürdigen Gebotssignale und zum Ausführen ihrer Gebotsskripts haben, ist es wichtig, dass sie ihre Interessengruppen so priorisieren, dass die Gruppen, die am wahrscheinlichsten die Auktion gewinnen, zuerst ausgeführt werden. Wenn perBuyerCumulativeTimeouts beispielsweise auf 100 ms festgelegt ist, das Abrufen der vertrauenswürdigen Gebotssignale eines Bieters 50 ms dauert und jeder generateBid()-Aufruf 10 ms in Anspruch nimmt 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 nach der Wahrscheinlichkeit, dass er die Auktion gewinnt, priorisieren.
Interessengruppen können statische Prioritäten enthalten, die mit dem Feld priority definiert werden. Für Interessengruppen können auch dynamische Prioritäten verwendet werden, die in ihrem vertrauenswürdigen Dienst für Gebotssignale berechnet und mit der priorityVector-Antwort auf den Abruf der vertrauenswürdigen Gebotssignale an den Browser zurückgegeben werden.
Wenn der Browser Interessengruppen von der höchsten zur niedrigsten Priorität ausführt, können sich Interessengruppen aus verschiedenen Beitrittsquellen überschneiden, was die group-by-origin-Optimierung beeinträchtigen kann.
Best Practices für Verkäufer
Achten Sie darauf, die Effizienz von Protected Audience API-Auktionen zu beobachten und zu optimieren.
Auktionen parallelisieren
Moderne Netzwerkverbindungen und Mehrkernprozessoren können mehrere Aktivitäten gleichzeitig ausführen. 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 an. 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, kann runAdAution() im Browser aufgerufen werden, bevor sie verfügbar sind. Diese Eingaben können dann später über JavaScript-Promises bereitgestellt werden. Um die Auktionslatenz so gering wie möglich zu halten, sollte runAdAuction() aufgerufen werden, wenn der interestGroupBuyers-Eingabewert bekannt ist. Dadurch können viele Teile der Auktion sofort beginnen, einschließlich des Abrufs der Echtzeitgebotsignale des Bieters.
Auktionen im Blick behalten
Messwerte zu Ihren Auktionen erfassen Der Browser kann Latenzmesswerteper-buyer an Verkäufer senden, die viele Informationen darüber liefern, wie viel Zeit in den Auktionen eines Verkäufers verbracht wird. Verkäufer können diese Messwerte nutzen, um ihre Auktionen zu optimieren, z. B. um Timeouts effektiv festzulegen. Verkäufer können die Latenzmesswerte eines bestimmten Käufers mit diesem teilen, damit er seine Optimierungen weiter verbessern kann.
Bieter haben möglicherweise Einblicke in die Gebotsleistung ihrer eigenen Interessengruppen, können diese aber möglicherweise nicht mit anderen Bietern vergleichen. Wenn Sie die relativen Gewinnraten und Gebotsablehnungsraten für verschiedene Bieter vergleichen, können Sie Fälle ermitteln, in denen Rechenressourcen für Gebote verschwendet wurden, weil mit Interessengruppen nie brauchbare Gebote generiert wurden oder weil zu viele Gebote mit nicht genehmigten Creatives abgegeben wurden.
Schutz vor langsamen Gebotsskripts
Gebotsskripts, die zu lange dauern, können die Protected Audience API-Auktion für alle Beteiligten verlangsamen. Mit Zeitlimits können Sie langsame Auktionen vermeiden und gleichzeitig Umsatz erzielen, wenn die Auktion langsam ist.
Verkäufer sollten perBuyerCumulativeTimeouts verwenden, um langsame Auktionen zu vermeiden und Gebote auch dann anzunehmen, wenn die Auktion langsam ist und das Zeitlimit erreicht. Die Verwendung von perBuyerCumulativeTimeouts ist der Verwendung von perBuyerTimeouts und perBuyerGroupLimits vorzuziehen, da perBuyerCumulativeTimeouts keine Meinung zur Anzahl der Interessengruppen oder zur Geschwindigkeit von generateBid() hat. So können beispielsweise viele Interessengruppen, die schnell Gebote abgeben, und wenige Interessengruppen, die langsam Gebote abgeben, beide vor dem Zeitlimit abgeschlossen werden.
Es empfiehlt sich auch, mit dem Feld signal in der Auktionskonfiguration ein allgemeines Auktions-Timeout zu implementieren, um zu lange Auktionen zu verhindern, wenn das Abrufen vertrauenswürdiger Scoring-Signale und die Ausführung von scoreAd() zu viel Zeit in Anspruch nehmen.
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.