Hier erfahren Sie, wie Sie eine Zielgruppe durch Erstellen einer Interessengruppe mit der Protected Audience API definieren. Im Entwicklerleitfaden finden Sie Informationen zum gesamten Lebenszyklus der Protected Audience API. In der Erläuterung zur Protected Audience API finden Sie einen detaillierten Vorschlag, wie Browser Interessengruppen erfassen.
Sie sind kein Entwickler? Weitere Informationen finden Sie in der Übersicht zur Protected Audience API.
Protected Audience API-Interessengruppen
Eine Protected Audience API-Interessengruppe steht für eine Gruppe von Nutzern mit gemeinsamen Interessen und entspricht einer Remarketing-Liste. Jede Protected Audience API-Interessengruppe hat einen Inhaber.
Inhaber von Interessengruppen agieren als Käufer in der Protected Audience API-Anzeigenauktion. Die Mitgliedschaft in einer Interessengruppe wird vom Browser auf dem Gerät des Nutzers gespeichert und nicht an den Anbieter des Browsers oder andere Personen weitergegeben.
API-Funktionen
joinAdInterestGroup()
Die Demand-Side-Plattform (DSP) des Werbetreibenden oder der Werbetreibende selbst ruft navigator.joinAdInterestGroup()
auf, um den Browser aufzufordern, der Mitgliederliste des Browsers eine Interessengruppe hinzuzufügen.
Der Ursprung des Aufrufkontexts für joinAdInterestGroup()
muss mit dem Ursprung des Interessengruppeninhabers übereinstimmen. Daher muss joinAdInterestGroup()
von einem iFrame (z. B. von einer DSP) aufgerufen werden, es sei denn, der Ursprung des Interessengruppeninhabers stimmt mit dem Ursprung des aktuellen Dokuments überein (z. B. eine Website mit eigenen Interessengruppen).
joinAdInterestGroup()
benötigt die Berechtigung von:
- Die besuchte Website
- Inhaber der Interessengruppe
Das bedeutet, dass malicious.example
nur dann joinAdInterestGroup()
für eine Interessengruppe von dsp.example.com
aufrufen kann, wenn dsp.example.com
die entsprechende Berechtigung erteilt hat.
Berechtigung der besuchten Website
Die Berechtigung kann vom selben oder ursprungsübergreifend gewährt werden. Standardmäßig wird die Berechtigung für joinAdInterestGroup()
-Aufrufe gewährt, die vom selben Ursprung stammen wie die besuchte Website, also von demselben Ursprung wie der Frame auf oberster Ebene der aktuellen Seite.
Nutzungsbeispiel
Hier ist ein Beispiel dafür, wie man eine Interessengruppe definieren und den Browser bitten könnte, 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 an die Funktion übergebene interestGroup
-Objekt darf nicht größer als 50 KiB sein. Andernfalls schlägt der Aufruf fehl. Der zweite Parameter gibt die Dauer der Interessengruppe an, begrenzt auf 30 Tage. Aufeinanderfolgende Aufrufe überschreiben zuvor gespeicherte Werte.
Erforderliche Properties
Die einzigen erforderlichen Properties für Interessengruppen sind owner
und name
:
Attribut | Beispiel | Rolle |
---|---|---|
owner |
https://dsp.example |
Der Ursprung des Interessengruppeninhabers. |
name |
custom-bikes |
Name der Interessengruppe. |
Optionale Attribute
Die übrigen Eigenschaften sind optional:
biddingLogicUrl
12- Beispiel:
https://dsp.example/bid/custom-bikes/bid.js
- Rolle: URL für das Bidding-JavaScript, das im Worklet ausgeführt wird.
biddingWasmHelperUrl
12- Beispiel:
https://dsp.example/bid/custom-bikes/bid.wasm
- Rolle: URL für WebAssembly-Code von
biddingLogicUrl
. updateUrl
2- Beispiel:
https://dsp.example/bid/custom-bikes/update
- Rolle: URL, die JSON zurückgibt, um Interessengruppenattribute zu aktualisieren. Weitere Informationen finden Sie unter Zielgruppendaten und Anzeigen aktualisieren.
trustedBiddingSignalsUrl
2- Beispiel:
https://dsp.example/trusted/bidding-signals
- Rolle: Basis-URL für Anfragen mit Schlüssel/Wert-Paaren an den vertrauenswürdigen Schlüssel/Wert-Dienst des Bieters.
trustedBiddingSignalsKeys
- Beispiel:
['key1', 'key2' ...]
- Rolle: Schlüssel für Anfragen an einen vertrauenswürdigen Schlüssel/Wert-Dienst für Schlüssel/Wert-Paare.
userBiddingSignals
- Beispiel:
{...}
- Rolle: Zusätzliche Metadaten, die der Inhaber bei der Gebotsabgabe verwenden kann.
ads
1- Beispiel:
[bikeAd1, bikeAd2, bikeAd3]
- Rolle: Anzeigen, die für diese Interessengruppe gerendert werden können.
adComponents
- Beispiel:
[customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2]
- Rolle: Komponenten für Anzeigen, die aus mehreren Teilen bestehen.
1 Die Properties biddingLogicUrl
und ads
sind optional, für die Teilnahme an einer Auktion jedoch erforderlich. Es gibt verschiedene Anwendungsfälle für das Erstellen einer Interessengruppe ohne diese Eigenschaften: Beispielsweise kann ein Inhaber einer Interessengruppe einer Interessengruppe einen Browser für eine Kampagne hinzufügen, die noch nicht aktiv ist, oder für eine andere zukünftige Verwendung, oder das Werbebudget ist vorübergehend aufgebraucht.
2 In der aktuellen Implementierung der Protected Audience API müssen biddingLogicUrl
, biddingWasmHelperUrl
, updateUrl
und trustedBiddingSignalsUrl
denselben Ursprung haben wie der Inhaber. Dies ist möglicherweise keine langfristige Beschränkung und die URLs ads
und adComponents
haben keine solche Beschränkung.
Anzeigen für eine Interessengruppe festlegen
ads
- und adComponents
-Objekte enthalten eine URL für ein Anzeigen-Creative und optional beliebige Metadaten, die bei der Gebotsabgabe verwendet werden können.
Beispiel:
{
renderUrl: 'https://cdn.example/.../bikeAd1.html',
metadata: bikeAd1metadata // optional
}
leaveAdInterestGroup()
Der Inhaber einer Interessengruppe kann beantragen, dass ein Browser aus einer Interessengruppe entfernt wird. Die Interessengruppe wird aus der Mitgliederliste des Browsers entfernt.
navigator.leaveAdInterestGroup({
owner: 'https://dsp.example',
name: 'custom-bikes'
});
Wenn ein Nutzer zu der Website zurückkehrt, auf der der Browser aufgefordert wird, eine Interessengruppe hinzuzufügen, kann der Inhaber der Interessengruppe die navigator.leaveAdInterestGroup()
-Funktion aufrufen, damit der Browser die Interessengruppe entfernt.
Code für eine Anzeige kann diese Funktion auch für ihre Interessengruppe aufrufen.
Häufig gestellte Fragen
Wie viele Interessengruppen pro Gruppeninhaber sind für einen einzelnen Nutzer maximal zulässig?
In Chrome sind bis zu 1.000 Interessengruppen pro Inhaber und bis zu 1.000 Inhaber von Interessengruppen zulässig. Diese Grenzwerte sind als Schutzmaßnahmen gedacht, die im normalen Betrieb nicht erreicht werden sollen.
Wie kann ich auf einer Interessengruppe basierende Anzeigen maximieren, bei denen der K-Anon-Grenzwert erreicht wird?
Wie in der öffentlichen Erklärung angemerkt: Da eine einzelne Interessengruppe mehrere mögliche Anzeigen enthalten kann, hat die Gruppe die Möglichkeit, eine andere ihrer Anzeigen erneut als "Fallback-Anzeige" zu bieten. wann die bevorzugteste Option unter dem Grenzwert liegt. Das bedeutet, dass eine kleine spezialisierte Anzeige, die noch unter dem k-Anonymitätsschwellenwert liegt, dennoch an Auktionen teilnehmen kann. Ihre Interessengruppe kann dann auf eine allgemeinere Anzeige zurückgreifen, bis die stärker spezialisierte Anzeige eine ausreichend große Zielgruppe aufweist.
Aus taktischer Perspektive können Sie Folgendes in Betracht ziehen:
- Damit eine neue Anzeige ausgeliefert werden kann, geben Sie einfach in den gewünschten Fällen Gebote dafür ab. Sie müssen nichts weiter tun.
- Sie können eine Fallback-Anzeige verwenden, wenn neue Anzeigen nicht ausgeliefert werden. Es besteht das Risiko, dass Ihre Fallback-Anzeige selbst nicht k-anon ist. Daher kann es sinnvoll sein, erst einmal auf die Fallback-Anzeige zu bieten. Nehmen Sie dies in 1% der Fälle vor, z. B. wenn dies ein guter Wert ist, um sicherzustellen, dass Sie davon ausgehen, dass das Fallback über dem Grenzwert bleibt.
In jüngster Zeit wurden andere Möglichkeiten diskutiert, wie die API funktionieren könnte. Wenn Sie also einen Anwendungsfall haben, bei dem dieser Mechanismus ein Problem darstellen würde, beteiligen Sie sich weiterhin an der öffentlichen Diskussion über Möglichkeiten, wie die API verbessert werden könnte.
Alle Protected Audience API-Referenzen
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.