Diese Seite wurde von der Cloud Translation API übersetzt.

Protected Audience API – Übersicht

On-Device-Anzeigenauktionen für Remarketing und benutzerdefinierte Zielgruppen ohne websiteübergreifendes Tracking durch Drittanbieter.

An wen richtet sich dieses Dokument?

In diesem Dokument werden die Grundlagen der Protected Audience API und einige zugrunde liegende Konzepte erläutert, es geht jedoch nicht auf technische Details ein.

Wenn Sie in der Werbebranche oder in der Anzeigentechnologie tätig sind, erhalten Sie einen Überblick darüber, wie Protected Audience funktioniert.
Wenn Sie Entwickler oder Softwareingenieur sind, finden Sie im Entwicklerleitfaden zur Protected Audience API ausführlichere technische Details zur API. Hier finden Sie den aktuellen Status der ausstehenden Protected Audience-Funktionen.

Im Glossar finden Sie eine Liste der in der Dokumentation zu Protected Audience verwendeten Begriffe. Am Ende dieses Dokuments erfahren Sie, wie Sie Feedback einholen und geben.

Was ist die Protected Audience API?

Die Protected Audience API ist eine Privacy Sandbox-Technologie für Remarketing und benutzerdefinierte Zielgruppen, die so konzipiert ist, dass Dritte das Browserverhalten von Nutzern nicht über Websites hinweg verfolgen können.

Die Protected Audience API ermöglicht On-Device-Auktionen durch den Browser, um relevante Anzeigen von Websites auszuwählen, die der Nutzer zuvor besucht hat.

Die Protected Audience API ist der erste Test, der in Chromium im Rahmen der TURTLEDOVE-Angebotsfamilie implementiert wird. Der Unterschied zwischen Protected Audience und TURTLEDOVE besteht hauptsächlich in der Trennung der On-Device-Rolle des Anzeigenkäufers und ‑verkäufers. In den folgenden Abschnitten wird die Funktionsweise der Protected Audience API erläutert.

Protected Audience API in einer Minute

Einen ausführlicheren Überblick über die Protected Audience API finden Sie im Entwicklerleitfaden zur Protected Audience API.

Übersicht über die einzelnen Phasen des Protected Audience API-Lebenszyklus — Der Lebenszyklus der Protected Audience API.

Die Protected Audience API verwendet Interessengruppen, damit Websites Anzeigen präsentieren können, die für ihre Nutzer relevant sind.

Wenn ein Nutzer beispielsweise eine Website besucht, auf der für Produkte geworben wird, kann der Inhaber einer Interessengruppe (z. B. eine Demand-Side-Platform [DSP]) den Browser des Nutzers auffordern, die Mitgliedschaft in der Interessengruppe hinzuzufügen. Wenn die Anfrage erfolgreich ist, zeichnet der Browser Folgendes auf:

Der Name der Interessengruppe, z. B. „custom-bikes“.
Der Inhaber der Interessengruppe, z. B. „https://dsp.beispiel“.
Konfigurationsinformationen für die Interessengruppe, damit der Browser auf Gebotskode, Anzeigencode und Echtzeitdaten zugreifen kann, wenn der Inhaber der Gruppe eingeladen wird, in einer Anzeigenauktion ein Gebot abzugeben.

Wenn der Nutzer später eine Website mit verfügbarer Werbefläche besucht, kann der Verkäufer der Werbefläche (ein Sell-Side-Anbieter (SSP) oder die Website selbst) mithilfe von Protected Audience eine Anzeigenauktion durchführen, um die für den Nutzer am besten geeigneten Anzeigen auszuwählen. Der Verkäufer ruft die Funktion navigator.runAdAuction() auf, die eine Liste der Inhaber von Interessengruppen enthält, die zum Gebotsabgeben eingeladen werden.

Gebote können nur von Interessengruppen abgegeben werden, deren Mitglied der Browser ist und deren Inhaber zum Geben von Geboten eingeladen wurden.

Der Gebotscode wird aus einer URL abgerufen, die in der Konfiguration der Interessengruppe angegeben ist. Dieser Code enthält Daten zur Interessengruppe und Informationen vom Verkäufer sowie kontextbezogene Daten zur Seite und aus dem Browser.

Jede Interessengruppe, die ein Gebot abgibt, wird als Käufer bezeichnet.

Wenn der Browser die Funktion zum Ausführen der Anzeigenauktion aufruft, generiert der Code jedes Käufers ein Gebot anhand von Echtzeitdaten, die von seinem Protected Audience-Schlüssel/Wert-Dienst bereitgestellt werden. Anschließend erhält der Verkäufer diese Gebote sowie vom Verkäufer selbst erhobene Echtzeitdaten und bewertet jedes Gebot. Das Gebot mit der höchsten Punktzahl gewinnt die Auktion.

Die Gewinneranzeige wird in einem umzäunten Frame angezeigt. Die URL des Creatives wird im Gebot angegeben und die Quelle muss mit einer in der Liste übereinstimmen, die in der Konfiguration der Interessengruppe angegeben ist.

Der Verkäufer kann das Auktionsergebnis melden (reportResult()) und Käufer können ihre gewonnenen Gebote melden (reportWin()).

Weitere Informationen zu Berichten zu Protected Audience-Auktionen

Warum benötigen wir die Protected Audience API?

Wenn Sie die Interessen der Nutzer kennen, können Sie relevantere Anzeigen schalten, als wenn Sie Anzeigen nur basierend auf Websitecontent auswählen (Kontext-Targeting) oder Informationen verwenden, die ein Nutzer der Website zur Verfügung gestellt hat, auf der die Anzeige ausgeliefert wird (Targeting mit selbst erhobenen Daten).

Bisher haben Werbeplattformen die Interessen von Nutzern ermittelt, indem sie ihr plattformübergreifendes Verhalten beobachtet haben. Browser müssen es ermöglichen, dass Anzeigenplattformen relevante Anzeigen auswählen, damit Verlage und Webpublisher Werbeeinnahmen erzielen können, ohne dass websiteübergreifend getrackt wird.

Mit der Protected Audience API soll die Webplattform so weiterentwickelt werden, dass der Browser des Nutzers auf seinem Gerät – nicht die Werbetreibenden oder Werbetechnologieplattformen – Informationen darüber enthält, woran diese Person interessiert ist.

Wie kann ich die Protected Audience API testen?

Im Entwicklerleitfaden für die Protected Audience API wird beschrieben, wie Sie die API verwenden und lokal testen.
Unter protected-audience-demo.web.app finden Sie eine Schritt-für-Schritt-Anleitung für die grundlegende Bereitstellung von Protected Audience auf Websites von Werbetreibenden und Publishern. Im Demovideo zu Protected Audience wird erklärt, wie dieser Code funktioniert, und es wird eine Vorschau der Verwendung der Chrome-Entwicklertools zum Debuggen gezeigt.

Welche Browserkonfiguration ist verfügbar?

Nutzer können ihre Teilnahme an Privacy Sandbox-Tests in Chrome anpassen, indem sie die Einstellung der obersten Ebene unter chrome://settings/adPrivacy aktivieren oder deaktivieren. Während der ersten Tests können Nutzer die Protected Audience API über die Privacy Sandbox-Einstellungen deaktivieren.

In Chrome sollen Nutzer künftig die Liste der Interessengruppen einsehen und verwalten können, denen sie auf den von ihnen besuchten Websites hinzugefügt wurden. Wie bei den Privacy Sandbox-Technologien können sich die Nutzereinstellungen auch aufgrund von Feedback von Nutzern, Regulierungsbehörden und anderen entwickeln.

Wir aktualisieren die verfügbaren Einstellungen in Chrome im Laufe der Entwicklung der Protected Audience API auf Grundlage von Tests und Feedback. In Zukunft werden wir detailliertere Einstellungen zur Verwaltung von Protected Audience und zugehörigen Daten anbieten.

API-Caller können nicht auf die Gruppenmitgliedschaft zugreifen, wenn Nutzer im Inkognitomodus surfen. Die Mitgliedschaft wird entfernt, wenn Nutzer ihre Websitedaten löschen.

Kann ich die Protected Audience API deaktivieren?

Weitere Informationen zum Blockieren des Zugriffs auf die Protected Audience API

Wichtige Konzepte

Sie benötigen weitere Informationen zur Protected Audience-Terminologie? Weitere Informationen finden Sie im Glossar zur Privacy Sandbox.

Was ist eine Interessengruppe?

Eine Interessengruppe der Protected Audience API stellt eine Gruppe von Nutzern mit einem gemeinsamen Interesse dar, die einer Remarketing-Liste entspricht.

Jede Protected Audience API-Interessengruppe hat einen Inhaber. Unterschiedliche Eigentümer erstellen unterschiedliche Arten von Interessengruppen mit unterschiedlichen Anwendungsfällen.

Der Inhaber bittet den Browser des Nutzers, die Mitgliedschaft in der Interessengruppe hinzuzufügen. Dazu ruft er die JavaScript-Funktion navigator.joinAdInterestGroup() auf und gibt Informationen wie Daten zu für die Interessengruppe relevanten Anzeigen und eine URL für JavaScript an, die bei Geboten verwendet wird. Daten zu Interessengruppen (z. B. Anzeigen) können aktualisiert werden und eine Interessengruppe kann bis zu 30 Tage lang aktiviert werden.

Arten von Interessengruppen

In der folgenden Tabelle finden Sie Beispiele für verschiedene Arten von Interessengruppen und Inhabern der Protected Audience API.

Inhaber	Beispiel	Interesse	Beispiel	Anwendungsfälle
Advertiser	Fahrradhersteller	Produkte	Nutzer, die sich Produktseiten für eine bestimmte Fahrradkategorie angesehen haben.	Remarketing auf Nutzer, die bereits mit der Marke interagiert haben.
Publisher	Nachrichtenwebsite	Inhalt	Nutzer, die sich für Radfahren interessieren	Publisher können selbst erhobene Daten verwenden, um Werbetreibenden die Möglichkeit zu geben, Anzeigen zu kaufen, die für Leser auf ihrer Website relevant sind. Mit einer vom Publisher verwalteten Interessengruppe können Publisher dies auch tun, wenn diese Nutzer andere Websites besuchen. Publisher können möglicherweise Gebühren für die Möglichkeit erheben, Anzeigen für bestimmte Zielgruppensegmente zu schalten.
AdTech	DSP	Produktkategorie	Nutzer, die sich für Fahrradbekleidung interessiert haben.	Ein Anbieter von Anzeigentechnologien kann eine Interessengruppe mit Nutzern erstellen und verwalten, von denen er glaubt, dass sie an einer bestimmten Artikelkategorie interessiert sind. Diese Interessengruppe kann dann verwendet werden, um auf Websites, die Produkte in dieser Kategorie verkaufen und mit dem Anbieter von Anzeigentechnologien zusammenarbeiten, für Produkte zu werben.

In Chrome sind bis zu 1.000 Interessengruppen pro Inhaber und bis zu 1.000 Inhaber von Interessengruppen zulässig. Diese Grenzwerte sind als Sicherheitsmaßnahmen gedacht, die im normalen Betrieb nicht erreicht werden sollten.

Was ist ein Käufer?

In der Protected Audience API ist ein Käufer eine Partei, die Inhaber einer Interessengruppe ist und in einer Anzeigenauktion Gebote abgibt.

Beispiel:

Werbetreibender: handelt für sich selbst.
Demand-Side-Plattform (DSP): handelt im Auftrag von Werbetreibenden.
Inhaber einer Interessengruppe: arbeitet für mehrere Werbetreibende.

Käufer haben drei Aufgaben:

Wählen Sie aus, ob Sie an einer Auktion teilnehmen möchten.
Wählen Sie Anzeigen aus und berechnen Sie ein Gebot.
Melden Sie das Auktionsergebnis.

Diese Jobs werden programmatisch in Code ausgeführt, der vom Käufer bereitgestellt und während einer Protected Audience API-Anzeigenauktion ausgeführt wird.

Wenn ein Käufer den Browser eines Nutzers auffordert, den Gruppen, deren Mitglied er ist, eine Interessengruppe hinzuzufügen (durch Aufrufen der JavaScript-Funktion navigator.joinAdInterestGroup()), stellt er dem Browser Folgendes zur Verfügung:

Eine URL für den Gebotscode, die verwendet wird, wenn der Verkäufer eine Anzeigenauktion durchführt.
Möglicherweise URLs für Anzeigen-Creatives für die Interessengruppe. Anzeigen-URLs können später mit einem Update hinzugefügt werden.
Eine Liste der abzufragenden Datenschlüssel und die URL des Schlüssel/Wert-Dienstes des Käufers, damit der Gebotscode während einer Auktion Echtzeitdaten abrufen kann.

Der Code des Käufers kann auch eine reportWin()-Funktion enthalten, um das Auktionsergebnis zu melden.

Wer führt eine Anzeigenauktion durch?

Es gibt mehrere Parteien, die eine Auktion zum Verkauf von Werbeflächen abhalten können.

Beispiel:

Content-Publisher: Er hostet Anzeigeninhalte auf seiner Website.
Supply-Side-Plattform (SSP): arbeitet mit dem Publisher zusammen und erbringt andere Dienstleistungen.
Script eines Drittanbieters: Script, das für einen Publisher ausgeführt wird, um die Teilnahme an Anzeigenauktionen zu ermöglichen.

Mit der Protected Audience API hat ein Anzeigenflächenverkäufer drei Aufgaben:

Publisher-Regeln erzwingen: Sie legen fest, welche Käufer und Gebote zulässig sind.
Auktionslogik ausführen: JavaScript wird in Worklets ausgeführt, um für jedes Gebot einen Wert für die Attraktivität zu berechnen.
Melden Sie das Auktionsergebnis.

Diese Jobs werden programmatisch in Code ausgeführt, den der Verkäufer bereitstellt, wenn er eine Anzeigenauktion durch Aufrufen der JavaScript-Funktion navigator.runAdAuction() initiiert.

Wie funktioniert eine Protected Audience API-Anzeigenauktion?

Im folgenden Diagramm sind die einzelnen Phasen einer Protected Audience API-Anzeigenauktion dargestellt:

Sechs Phasen einer Protected Audience API-Anzeigenauktion — Phasen von Protected Audience-Anzeigenauktionen

In der Protected Audience API besteht eine Anzeigenauktion aus einer Reihe kleiner JavaScript-Programme, die der Browser auf dem Gerät des Nutzers ausführt, um eine Anzeige auszuwählen. Zum Schutz des Datenschutzes wird der gesamte Code für Anzeigenauktionen von Verkäufern und Käufern in isolierten JavaScript-Worklets ausgeführt, die nicht mit der Außenwelt kommunizieren können.

Ein Verkäufer (ein Publisher oder eine Supply-Side-Plattform) initiiert eine Protected Audience-Anzeigenauktion auf einer Website, auf der Werbeflächen verkauft werden (z. B. eine Nachrichtenwebsite). Der Verkäufer wählt die Käufer aus, die an der Auktion teilnehmen sollen, gibt an, welche Fläche zum Verkauf steht, und legt zusätzliche Kriterien für die Anzeige fest. Jeder Käufer ist Inhaber einer Interessengruppe.

Der Verkäufer stellt dem Browser Code zum Bewerten von Geboten zur Verfügung. Dieser Code enthält den Wert jedes Gebots, die URL des Anzeigen-Creatives und andere Daten, die von jedem Käufer zurückgegeben werden. Während der Auktion können Gebotskode von Käufern und Gebotspunktierungscode vom Verkäufer Daten aus ihren Schlüssel/Wert-Diensten empfangen. Sobald eine Anzeige ausgewählt und (in einem Fenced Frame zum Schutz der Privatsphäre) präsentiert wurde, können der Verkäufer und der Gewinner des Gebots das Auktionsergebnis melden.

Ein Nutzer besucht eine Website, auf der Anzeigen ausgeliefert werden.
Mit dem Code des Verkäufers wird eine Auktion gestartet. Der Verkäufer gibt an, welche Werbefläche zum Verkauf steht, wer bieten darf und wie diese Gebote bewertet werden sollen.
Der Code des eingeladenen Käufers wird ausgeführt, um ein Gebot, die URL eines relevanten Creatives und andere Daten zu generieren. Das Gebotsskript kann Echtzeitdaten wie das verbleibende Budget der Werbekampagne vom Schlüssel/Wert-Dienst des Käufers abfragen.
Der Code des Verkäufers bewertet jedes Gebot und wählt einen Gewinner aus. Bei dieser Logik wird der Gebotswert und andere Daten verwendet, um die Attraktivität eines Gebots zurückzugeben und eine Anzeige abzulehnen, die den Gewinner der kontextbezogenen Anzeige nicht übertreffen kann. Der Verkäufer kann seinen eigenen Schlüssel/Wert-Dienst für Echtzeitdaten verwenden. Bevor eine Auktion beginnt, sucht der Verkäufer die beste kontextbezogene Anzeige für die verfügbare Anzeigenfläche.
Die Gewinneranzeige wird als Objekt für die Konfiguration von eingezäunten Frames zurückgegeben, wenn das Flag resolveToConfig in der Auktionskonfiguration festgelegt ist. Anhand der Konfiguration wird der eingeblendete Frame zum Creative geleitet. Die URL des Creatives ist sowohl für den Verkäufer als auch für den Publisher ausgeblendet. Wenn das resolveToConfig-Flag auf false festgelegt oder nicht übergeben wird, wird die Gewinneranzeige als opake URN zurückgegeben, die zum Rendern der Anzeige in einem Iframe verwendet werden kann. Das Konfigurationsobjekt für eingezäunte Frames ist ab M114 verfügbar.
Die Auktion wird dem Verkäufer und den Käufern, die sie gewonnen haben, gemeldet.
Hinweis:Die reportResult() des Verkäufers und die reportWin() des Käufers können einen Aufruf von sendReportTo() enthalten. Diese Funktion ist vorübergehend verfügbar, bis zusammengefasste Berichte mit der Private Aggregation API verfügbar sind.

Ein Meldemechanismus für verlorene Käufer ist in der Diskussion.

Was ist ein Protected Audience API-Schlüssel/Wert-Dienst?

Mit dem Schlüssel/Wert-Dienst der Protected Audience API können Anbieter von Anzeigentechnologien Echtzeitdaten abfragen, wenn ein Käufer ein Gebot abgibt, und Verkäufer Anzeigen bewerten, während die Privatsphäre geschützt bleibt. Weitere Informationen zu diesem und anderen Diensten der Protected Audience API finden Sie unter Protected Audience API-Dienste.

Der Schlüssel/Wert-Dienst wird in der Cloud-Infrastruktur der AdTech-Plattform bereitgestellt und in einer vertrauenswürdigen Ausführungsumgebung ausgeführt. Eine Anfrage an einen Schlüssel/Wert-Dienst kann nicht zu Protokollierungen auf Ereignisebene führen oder andere Nebenwirkungen haben. Der Schlüssel/Wert-Dienst unterstützt auch benutzerdefinierte Funktionen (UDFs), mit denen Anbieter von Anzeigentechnologien ihre eigene benutzerdefinierte Logik im Schlüssel/Wert-Dienst ausführen können.

Ein Käufer oder Verkäufer stellt eine Liste von „Schlüsseln“ bereit, um die Daten anzugeben, die er von einem Schlüssel/Wert-Dienst der Protected Audience API benötigt. Der Schlüssel/Wert-Dienst antwortet mit einem Wert für jeden Schlüssel.

Der Schlüssel/Wert-Dienstcode der Protected Audience API ist jetzt in einem GitHub-Repository für die Privacy Sandbox verfügbar. Dieser Dienst kann von Chrome- und Android-Entwicklern verwendet werden.

Weitere Informationen zum Schlüssel/Wert-Dienst der Protected Audience API finden Sie in der API-Erläuterung und in der Erläuterung des Vertrauensmodells.

Wie werden Echtzeitdaten in Auktionen einbezogen?

Die Käufer oder Verkäufer in einer Anzeigenauktion benötigen möglicherweise Zugriff auf Echtzeitdaten. Käufer möchten beispielsweise möglicherweise das verbleibende Budget in einer Werbekampagne berechnen oder der Verkäufer muss möglicherweise prüfen, ob Anzeigen-Creatives den Richtlinien der Publisher entsprechen.

Um die Datenschutzanforderungen der Protected Audience API zu erfüllen, werden die für eine Anzeigenauktion erforderlichen Echtzeitdaten vom Schlüssel/Wert-Dienst bereitgestellt. Wenn ein Käufer navigator.joinAdInterestGroup() aufruft, gibt er eine URL für den Schlüssel/Wert-Dienst und die Schlüssel an, die während einer Auktion vom Dienst abgefragt werden sollen. Wenn der Verkäufer eine Anzeigenauktion durch Aufrufen von navigator.runAdAuction() durchführt, gibt er auch eine URL für seinen Schlüssel/Wert-Dienst an. Der Schlüssel/Wert-Dienst des Verkäufers wird mit der Render-URL des Creatives abgefragt.

Für die ersten Tests wird das Modell Bring Your Own Server (BYOS) verwendet. Langfristig müssen Anbieter von Anzeigentechnologien die Open-Source-Schlüssel/Wert-Dienste der Protected Audience API verwenden, die in vertrauenswürdigen Ausführungsumgebungen ausgeführt werden, um Echtzeitdaten abzurufen.

Damit das System ausreichend Zeit für Tests hat, gehen wir davon aus, dass die Open-Source-Schlüssel/Wert-Dienste oder vertrauenswürdigen Ausführungsumgebungen erst nach der Einstellung von Drittanbieter-Cookies erforderlich sein werden. Wir werden Entwickler rechtzeitig darüber informieren, dass sie mit den Tests und der Einführung beginnen können, bevor diese Umstellung erfolgt.

Wie werden selbst erhobene Daten in einer Protected Audience-Auktion verwendet?

Selbst erhobene Daten sind Daten, die der Website zu ihren Nutzern gehören. Wenn ein Nutzer beispielsweise auf der Website des Werbetreibenden oder Publishers seine Lieblingsfarbe angegeben hat, wird diese Farbe als selbst erhobene Daten betrachtet.

Bei einer Auktion mit geschützten Zielgruppen kann der Werbetreibende anhand seiner selbst erhobenen Daten die Zugehörigkeit zur Anzeigeninteressegruppe bestimmen und Daten als userBiddingSignals an die Interessengruppe übergeben. Die selbst erhobenen Daten des Werbetreibenden sind nur für die Käufer während der Gebotsgenerierung verfügbar und nicht für die Verkäufer.

Wenn der Werbetreibende beispielsweise die Lieblingsfarbe des Nutzers kennt, kann der Wert in der Konfiguration der Interessengruppe als userBiddingSignals festgelegt werden, wenn der Nutzer einer Interessengruppe hinzugefügt wird:

const interestGroup = {
  owner: 'https://example-buyer.com',
  name: 'running-shoes',
  userBiddingSignals: {
    favoriteColor: 'blue' // First-party data
  },
  // ...other interest group settings
};

navigator.joinAdInterestGroup(interestGroup, 3600);

Der Publisher kann seine selbst erhobenen Daten auch übergeben, indem er die Signale bei der Auktionsauslösung in der Auktionskonfiguration festlegt. Außerdem kann er festlegen, wer die selbst erhobenen Daten erhält. Wenn ein Publisher die selbst erhobenen Daten als auctionSignals übergibt, sind sie sowohl für Käufer als auch für Verkäufer verfügbar. Wenn die Daten als sellerSignals übergeben werden, sind sie nur für den Verkäufer verfügbar. Wenn sie als perBuyerSignals übergeben werden, sind sie nur für die angegebenen Käufer verfügbar. Der Publisher kann auch selbst erhobene Daten in Komponentenauktionen einreichen. Der Publisher und die Teilnehmer der Auktion sollten sich vorher darauf einigen, welche selbst erhobenen Daten weitergegeben werden müssen und wie die Daten formatiert werden müssen.

Im folgenden Beispiel wird beschrieben, wie die selbst erhobenen Daten vom Publisher an verschiedene Auktionsteilnehmer übergeben werden können:

const auctionConfig = {
  seller: 'https://example-seller.com',
  auctionSignals: {
    favoriteColor: 'blue', // Both buyer and seller will receive this signal
  },
  sellerSignals: {
    favoriteIceCreamFlavor: 'chocolate', // Only the seller will receive this signal
  },
  perBuyerSignals: {
    'https://example-buyer.com': {
      favoriteDrink: 'tea', // Only a specific buyer will receive this signal
    },
  },
  // The same pattern applies to the component auction
  componentAuctions: [{
    seller: 'https://example-component-seller.com',
    auctionSignals: { ... },
    sellerSignals: { ... },
    perBuyerSignals { ... }
  }],
  // ...other auction settings
};

navigator.runAdAuction(auctionConfig);

Weitere Informationen