Hier erfahren Sie, wie Sie eine Zielgruppe definieren, indem Sie mit der Protected Audience API eine Interessengruppe erstellen. Im Entwicklerleitfaden finden Sie Informationen zum gesamten Lebenszyklus der Protected Audience API. Im Protected Audience API-Explainer wird ausführlich beschrieben, wie Browser Interessengruppen aufzeichnen.
Sie sind kein Entwickler? Weitere Informationen finden Sie in der Übersicht zur Protected Audience API.
Protected Audience API-Interessengruppen
Eine Protected Audience API-Interessengruppe stellt eine Gruppe von Personen mit einem gemeinsamen Interesse dar, was einer Remarketing-Liste entspricht. Jede Interessengruppe der Protected Audience API hat einen Inhaber.
Interessengruppeninhaber fungieren als Käufer in der Anzeigenauktion der Protected Audience API. Die Zugehörigkeit zu Interessengruppen wird vom Browser auf dem Gerät des Nutzers gespeichert und nicht an den Browseranbieter oder andere weitergegeben.
API-Funktionen
joinAdInterestGroup()
Die Demand-Side-Platform (DSP) des Werbetreibenden oder der Werbetreibende selbst ruft navigator.joinAdInterestGroup() auf, um den Browser aufzufordern, der Mitgliedschaftsliste des Browsers eine Interessengruppe hinzuzufügen.
Der Ursprung des aufrufenden Kontexts für joinAdInterestGroup() muss mit dem Ursprung des Inhabers der Interessengruppe übereinstimmen. joinAdInterestGroup() muss also über ein iFrame aufgerufen werden (z. B. von einer DSP), es sei denn, der Ursprung des Inhabers der Interessengruppe stimmt mit dem Ursprung des aktuellen Dokuments überein (z. B. eine Website mit eigenen Interessengruppen).
Für joinAdInterestGroup() ist eine Berechtigung von folgenden Personen erforderlich:
- Die besuchte Website
- Der Inhaber der Interessengruppe
Das bedeutet, dass malicious.example joinAdInterestGroup() nicht für eine Interessengruppe aufrufen kann, die dsp.example.com gehört, ohne dass dsp.example.com die Berechtigung erteilt.
Berechtigung von der besuchten Website
Berechtigungen können vom selben oder von einem anderen Ursprung erteilt werden. Standardmäßig wird die Berechtigung für joinAdInterestGroup()-Aufrufe vom selben Ursprung wie die besuchte Website gewährt, d. h. vom selben Ursprung wie der Frame der obersten Ebene der aktuellen Seite.
Nutzungsbeispiel
Hier sehen Sie ein Beispiel dafür, wie eine Interessengruppe definiert und der Browser aufgefordert werden kann, der Gruppe beizutreten.
const interestGroup = {
owner: 'https://dsp.example',
name: 'custom-bikes',
biddingLogicUrl: ...,
biddingWasmHelperUrl: ...,
updateUrl: ...,
trustedBiddingSignalsUrl: ...,
trustedBiddingSignalsKeys: ['key1', 'key2'],
userBiddingSignals: {...},
ads: [bikeAd1, bikeAd2, bikeAd3],
adComponents: [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2],
};
navigator.joinAdInterestGroup(interestGroup, 7 * kSecsPerDay);
Das interestGroup-Objekt, das an die Funktion übergeben wird, darf nicht größer als 50 KiB sein. Andernfalls schlägt der Aufruf fehl. Der zweite Parameter gibt die Dauer der Interessengruppe an, die auf 30 Tage begrenzt ist. Bei aufeinanderfolgenden Aufrufen werden zuvor gespeicherte Werte überschrieben.
Erforderliche Properties
Die einzigen erforderlichen Eigenschaften für Interessengruppen sind owner und name:
| Attribut | Beispiel | Rolle |
|---|---|---|
owner |
https://dsp.example |
Ursprung des Inhabers der Interessengruppe. |
name |
custom-bikes |
Name der Interessengruppe. |
Optionale Attribute
Die verbleibenden Attribute sind optional:
biddingLogicUrl1, 2- Beispiel:
https://dsp.example/bid/custom-bikes/bid.js - Rolle: URL für das Gebots-JavaScript, das im Worklet ausgeführt wird.
biddingWasmHelperUrl1, 2- Beispiel:
https://dsp.example/bid/custom-bikes/bid.wasm - Rolle: URL für WebAssembly-Code, der von
biddingLogicUrlgesteuert wird. updateUrl2- Beispiel:
https://dsp.example/bid/custom-bikes/update - Rolle: URL, die JSON zurückgibt, um Attribute von Interessengruppen zu aktualisieren. Zielgruppendaten aktualisieren und Anzeigen neu laden
trustedBiddingSignalsUrl2- Beispiel:
https://dsp.example/trusted/bidding-signals - Rolle: Basis-URL für Schlüssel/Wert-Anfragen an den vertrauenswürdigen Schlüssel/Wert-Dienst des Bieters.
trustedBiddingSignalsKeys- Beispiel:
['key1', 'key2' ...] - Rolle: Schlüssel für Anfragen an den vertrauenswürdigen Schlüssel/Wert-Dienst.
userBiddingSignals- Beispiel:
{...} - Rolle: Zusätzliche Metadaten, die der Inhaber bei Geboten verwenden kann.
ads1- Beispiel:
[bikeAd1, bikeAd2, bikeAd3] - Rolle
[bikeAd1, bikeAd2, bikeAd3]: Anzeigen, die für diese Interessengruppe gerendert werden könnten. adComponents- Beispiel:
[customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2] - Rolle: Komponenten für Anzeigen, die aus mehreren Teilen bestehen.
1 Die Attribute biddingLogicUrl und ads sind optional, aber für die Teilnahme an einer Auktion erforderlich. Es kann Anwendungsfälle geben, in denen eine Interessengruppe ohne diese Eigenschaften erstellt wird. Ein Interessengruppeninhaber möchte beispielsweise einer Interessengruppe einen Browser für eine Kampagne hinzufügen, die noch nicht läuft oder für eine andere zukünftige Verwendung. Möglicherweise ist auch das Werbebudget vorübergehend aufgebraucht.
2 In der aktuellen Implementierung der Protected Audience API müssen biddingLogicUrl, biddingWasmHelperUrl, updateUrl und trustedBiddingSignalsUrl denselben Ursprung wie der Eigentümer haben. Das muss keine langfristige Einschränkung sein. Für die URLs ads und adComponents gilt diese Einschränkung nicht.
Anzeigen für eine Interessengruppe angeben
ads- und adComponents-Objekte enthalten eine URL für ein Anzeigen-Creative und optional beliebige Metadaten, die bei Gebotsabgabe verwendet werden können.
Beispiel:
{
renderUrl: 'https://cdn.example/.../bikeAd1.html',
metadata: bikeAd1metadata // optional
}
leaveAdInterestGroup()
Der Inhaber der Interessengruppe kann beantragen, dass ein Browser aus einer Interessengruppe entfernt wird. Der Browser entfernt die Interessengruppe aus seiner Mitgliedschaftsliste.
navigator.leaveAdInterestGroup({
owner: 'https://dsp.example',
name: 'custom-bikes'
});
Wenn ein Nutzer die Website wieder besucht, auf der der Browser aufgefordert wurde, eine Interessengruppe hinzuzufügen, kann der Inhaber der Interessengruppe die Funktion navigator.leaveAdInterestGroup() aufrufen, um den Browser aufzufordern, die Interessengruppe zu entfernen.
Der Code für eine Anzeige kann diese Funktion auch für die zugehörige Interessengruppe aufrufen.
Häufig gestellte Fragen
Wie viele Interessengruppen kann ein einzelner Nutzer maximal pro Gruppeninhaber haben?
In Chrome sind bis zu 1.000 Interessengruppen pro Inhaber und bis zu 1.000 Inhaber von Interessengruppen zulässig. Diese Grenzwerte sind als Leitlinien gedacht und sollten im normalen Betrieb nicht erreicht werden.
Wie kann ich Anzeigen für Interessengruppen maximieren, die die 𝑘-Anonymitätsschwellenwerte erfüllen?
Wie im öffentlichen Explainer beschrieben, kann eine einzelne Interessengruppe mehrere mögliche Anzeigen enthalten, die ausgeliefert werden können. Wenn die bevorzugte Anzeige unter dem Schwellenwert liegt, kann die Gruppe jederzeit ein neues Gebot für eine ihrer Anzeigen abgeben, die als „Fallback-Anzeige“ fungiert. Das bedeutet, dass eine kleine, spezialisierte Anzeige, die noch unter dem 𝑘-Anonymitätsschwellenwert liegt, trotzdem an Auktionen teilnehmen kann. Die Interessengruppe kann auf eine allgemeinere Anzeige zurückgreifen, bis die spezialisierte Anzeige eine ausreichend große Zielgruppe hat.
Aus taktischer Sicht sollten Sie Folgendes in Betracht ziehen:
- Damit eine neue Anzeige ausgeliefert wird, müssen Sie einfach Gebote dafür abgeben. Sie müssen nichts weiter tun.
- Sie können eine Fallback-Anzeige verwenden, wenn neue Anzeigen nicht 𝑘-anonym sind. Es besteht ein gewisses Risiko, dass Ihre Fallback-Anzeige selbst nicht 𝑘-anonym ist. Sie könnten daher in Erwägung ziehen, von vornherein nur mit der Fallback-Anzeige zu bieten. Vielleicht sollten Sie das in 1% der Fälle tun, wenn das ein guter Wert ist, um sicherzustellen, dass der Fallback über dem Schwellenwert bleibt.
Es gab in letzter Zeit einige Diskussionen über andere Möglichkeiten, wie die API funktionieren könnte. Wenn Sie also einen Anwendungsfall haben, bei dem dieser Mechanismus ein Problem darstellen würde, beteiligen Sie sich bitte weiterhin an der öffentlichen Diskussion darüber, wie die API verbessert werden könnte.
Alle Verweise auf die Protected Audience API
API-Referenzleitfäden sind verfügbar:
- Entwicklerleitfaden für die Protected Audience API
- Käuferleitfaden für Protected Audience zu Interessengruppen und Gebotserstellung.
- Leitfaden für Anzeigenverkäufer zu Protected Audience-Anzeigenauktionen
- Leitfaden zur Berichterstellung für Auktionsergebnisse
- Best Practices für die Latenz bei der Anzeigenauktion von Protected Audience
- Fehlerbehebung bei Protected Audience
In der Erläuterung der Protected Audience API finden Sie auch Details zur Funktionsunterstützung und zu den Einschränkungen.