Ausrichtung auf benutzerdefinierte Zielgruppen mit der Protected Audience API unterstützen

Feedback geben

Letzte Updates

Protected Audience befindet sich in der Betaphase und ist für Tests auf öffentlichen Geräten verfügbar.

Mit der Protected Audience API haben Sie folgende Möglichkeiten:

  • Benutzerdefinierte Zielgruppen basierend auf früheren Nutzeraktionen verwalten.
  • On-Device-Auktionen mit Unterstützung für einzelne Verkäufer oder abfolgebasierte Vermittlung initiieren
  • Impressionsberichte nach Anzeigenauswahl ausführen.

Lesen Sie zuerst den Entwicklerleitfaden für Protected Audience. Wir freuen uns über Ihr Feedback für die Weiterentwicklung der Protected Audience API.

Zeitplan

In den kommenden Monaten werden wir neue Funktionen veröffentlichen. Das genaue Veröffentlichungsdatum variiert je nach Funktion. Diese Tabelle wird mit Links zur Dokumentation aktualisiert, sobald sie verfügbar ist.

Funktion In der Entwicklervorschau verfügbar In Beta verfügbar
Berichte auf Ereignisebene 1. Quartal 2023 3. Quartal 2023
Abfolgebasierte Vermittlung 1. Quartal 2023 4. Quartal 2023
Filter für App-Installationsanzeigen 2. Quartal 2023 3. Quartal 2023
Frequency Capping-Filterung 2. Quartal 2023 3. Quartal 2023
Kontextbezogene Anzeigen zum Filtern an den Workflow für die Anzeigenauswahl übergeben 2. Quartal 2023 3. Quartal 2023
Interaktionsberichte 2. Quartal 2023 3. Quartal 2023
Delegierung für benutzerdefinierte Zielgruppen einrichten 3. Quartal 2023 4. Quartal 2023
Abrechnung ohne CPM 3. Quartal 2023 4. Quartal 2023
Integration von Gebots- und Auktionsdiensten 3. Quartal 2023 4. Quartal 2023
Berichterstellung zur Fehlerbehebung 3. Quartal 2023 4. Quartal 2023
Integration von Attributionsberichten – 4. Quartal 2023
Open Bidding-Vermittlung 4. Quartal 2023 4. Quartal 2023
Währungsverwaltung 1. Quartal 2024 2. Quartal 2024
K-anon-Integration – 2. Quartal 2024
Integration aggregierter Berichte 3. Quartal 2024 4. Quartal 2024

Überblick

Bei der mobilen Werbung müssen Werbetreibende in der Regel potenziellen Nutzern Anzeigen präsentieren, die auf ihren bisherigen Interaktionen mit der App des Werbetreibenden basieren. So kann der Entwickler von SportingGoodsApp beispielsweise Werbung für Nutzer schalten, die noch Artikel im Einkaufswagen haben, indem er Nutzer mit Anzeigen daran erinnert, den Kauf abzuschließen. In der Branche wird diese allgemeine Idee mit Begriffen wie "Remarketing" und "Ausrichtung auf benutzerdefinierte Zielgruppen" beschrieben.

Heutzutage werden diese Anwendungsfälle in der Regel implementiert, indem Kontextinformationen zur Darstellung der Anzeige (z. B. der Name der App) und private Informationen wie Zielgruppenlisten an AdTech-Plattformen weitergegeben werden. Anhand dieser Informationen können Werbetreibende relevante Anzeigen auf ihren Servern auswählen.

Die Protected Audience API für Android (früher FLEDGE) umfasst die folgenden APIs für AdTech-Plattformen und Werbetreibende, um gängige interaktionsbasierte Anwendungsfälle so zu unterstützen, dass die Weitergabe von Kennungen in Apps und die Weitergabe von App-Interaktionsinformationen eines Nutzers an Dritte eingeschränkt wird:

  1. Custom Audience API: Diese API konzentriert sich auf die Abstraktion „Benutzerdefinierte Zielgruppe“, die eine vom Werbetreibenden festgelegte Zielgruppe mit gemeinsamen Absichten darstellt. Zielgruppeninformationen werden auf dem Gerät gespeichert und können relevanten Anzeigen für die Zielgruppe sowie beliebigen Metadaten wie Gebotssignalen zugeordnet werden. Anhand dieser Informationen können Werbetreibende Gebote, Anzeigenfilterung und Rendering festlegen.
  2. Ad Selection API: Diese API bietet ein Framework, das die Workflows von Anzeigentechnologie-Plattformen orchestriert, um anhand von Signalen auf dem Gerät eine „erfolgreiche“ Anzeige zu ermitteln. Dazu werden mögliche Anzeigen berücksichtigt, die lokal gespeichert werden, und mögliche weitere Verarbeitungen für mögliche Anzeigen durchzuführen, die eine AdTech-Plattform an das Gerät zurückgibt.
Flussdiagramm, das den Workflow für die benutzerdefinierte Zielgruppenverwaltung und die Anzeigenauswahl in der Privacy Sandbox für Android zeigt.

Auf übergeordneter Ebene funktioniert die Integration so:

  1. SportingGoodsApp möchte seine Nutzer daran erinnern, Merchandise-Artikel aus dem Einkaufswagen zu kaufen, wenn sie den Kauf nicht innerhalb von zwei Tagen abgeschlossen haben. SportingGoodsApp verwendet die Custom Audience API, um den Nutzer zur Zielgruppenliste "Produkte im Einkaufswagen" hinzuzufügen. Die Plattform verwaltet und speichert diese Zielgruppenliste auf dem Gerät und schränkt die Freigabe an Dritte ein. SportingGoodsApp arbeitet mit einer AdTech-Plattform zusammen, um Anzeigen für Nutzer in der Zielgruppenliste zu schalten. Auf der AdTech-Plattform werden Metadaten für Zielgruppenlisten verwaltet und mögliche Anzeigen bereitgestellt. Diese werden dann dem Workflow für die Anzeigenauswahl zur Verfügung gestellt. Die Plattform kann so konfiguriert werden, dass regelmäßig aktualisierte zielgruppenbasierte Anzeigen im Hintergrund abgerufen werden. So bleibt die Liste der zielgruppenbasierten Kandidatenanzeigen auf dem neuesten Stand und stimmt nicht mit Anfragen überein, die während der Werbechance (d.h. kontextbezogene Anzeigenanfrage) an Ad-Server von Drittanbietern gesendet werden.

  2. Wenn der Nutzer FrisbeeGame auf demselben Gerät spielt, wird ihm möglicherweise eine Anzeige präsentiert, die ihn daran erinnert, den Kauf der Artikel im Einkaufswagen von SportingGoodsApp abzuschließen. FrisbeeGame kann dies über ein integriertes Anzeigen-SDK erreichen. Dazu ruft FrisbeeGame die Ad Selection API auf, um für den Nutzer basierend auf einer Zielgruppenliste, zu der er gehört, eine erfolgreiche Anzeige auszuwählen. In diesem Beispiel ist dies die benutzerdefinierte Zielgruppe „Produkte im Einkaufswagen“, die von SportingGoodsApp erstellt wurde. Der Workflow zur Anzeigenauswahl kann so eingerichtet werden, dass zusätzlich zu den mit den benutzerdefinierten Zielgruppen verknüpften On-Device-Anzeigen und anderen On-Device-Signalen auch Anzeigen berücksichtigt werden, die von den Servern der AdTech-Plattformen abgerufen wurden. Der Workflow kann auch über die AdTech-Plattform und das Ads SDK mit benutzerdefinierter Gebots- und Bewertungslogik angepasst werden, um geeignete Werbeziele zu erreichen. So können die Daten zu Interessen oder App-Interaktionen des Nutzers die Anzeigenauswahl beeinflussen, während die Weitergabe dieser Daten an Dritte eingeschränkt wird.

  3. Die ausgewählte Anzeige wird mit dem SDK der App oder der AdTech-Plattform gerendert.

  4. Die Plattform erleichtert das Erstellen von Berichten zu Impressionen und Ergebnissen der Anzeigenauswahl. Diese Berichtsfunktion ergänzt die Attribution Reporting API. AdTech-Plattformen können Anpassungen entsprechend ihren Berichtsanforderungen vornehmen.

Zugriff auf Protected Audience on Android APIs erhalten

AdTech-Plattformen müssen sich registrieren, um auf die Protected Audience API zugreifen zu können. Weitere Informationen finden Sie unter Für Privacy Sandbox-Konto registrieren.

Benutzerdefinierte Zielgruppenverwaltung

Benutzerdefinierte Zielgruppe

Eine benutzerdefinierte Zielgruppe ist eine Gruppe von Nutzern mit gemeinsamen Absichten oder Interessen, die vom Werbetreibenden festgelegt wurde. Eine App oder ein SDK kann eine benutzerdefinierte Zielgruppe verwenden, um auf eine bestimmte Zielgruppe hinzuweisen, z. B. Nutzer, die „Artikel im Einkaufswagen gelassen“ oder „das Anfängerlevel eines Spiels abgeschlossen“ haben. Die Plattform speichert und speichert Zielgruppeninformationen lokal auf dem Gerät. Es gibt keine Informationen zu den benutzerdefinierten Zielgruppen, zu denen sich der Nutzer befindet. Benutzerdefinierte Zielgruppen unterscheiden sich von den Interessengruppen der Protected Audience in Chrome und können nicht zwischen dem Web und Apps geteilt werden. Dadurch wird das Teilen von Nutzerinformationen eingeschränkt.

Eine Werbetreibenden-App oder das integrierte SDK kann eine benutzerdefinierte Zielgruppe beispielsweise basierend auf Nutzerinteraktionen in einer App join oder verlassen.

Benutzerdefinierte Zielgruppenmetadaten

Jede benutzerdefinierte Zielgruppe enthält die folgenden Metadaten:

  • Owner:Paketname der Inhaber-App. Dieser wird implizit auf den Paketnamen der aufrufenden App festgelegt.
  • Käufer:Werbenetzwerk, das Anzeigen für diese benutzerdefinierte Zielgruppe verwaltet. Der Käufer stellt auch die Partei dar, die auf die benutzerdefinierte Zielgruppe zugreifen und relevante Anzeigeninformationen abrufen kann. Der Käufer wird im eTLD+1-Format angegeben.
  • Name:Ein beliebiger Name oder eine beliebige Kennung für die benutzerdefinierte Zielgruppe, z. B. ein Nutzer mit „Nutzer, die den Einkaufswagen ohne Kauf verlassen haben“. Dieses Attribut kann beispielsweise als eines der Targeting-Kriterien in den Werbekampagnen des Werbetreibenden oder als Abfragestring in der URL zum Abrufen des Gebotscodes verwendet werden.
  • Aktivierungs- und Ablaufzeit:Diese Felder definieren das Zeitfenster, in dem die benutzerdefinierte Zielgruppe wirksam ist. Die Plattform verwendet diese Informationen, um die Mitgliedschaft einer benutzerdefinierten Zielgruppe zu widerrufen. Die Ablaufzeit darf ein maximales Dauerfenster nicht überschreiten, um die Lebensdauer einer benutzerdefinierten Zielgruppe zu begrenzen.
  • URL für tägliche Aktualisierung:Die URL, die von der Plattform verwendet wird, um mögliche Anzeigen und andere Metadaten abzurufen, die in den Feldern „Gebotssignale für Nutzer“ und „Vertrauenswürdige Gebotssignale“ definiert sind. Weitere Informationen finden Sie im Abschnitt zum Abrufen möglicher Anzeigen für benutzerdefinierte Zielgruppen.
  • Gebotssignale für Nutzer:Plattformspezifische Signale für Anzeigentechnologie für alle Gebote von Remarketing-Anzeigen Beispiele für Signale sind der ungefähre Standort des Nutzers, die bevorzugte Sprache usw.
  • Trusted Bidding-Daten:AdTech-Plattformen stützen sich beim Abrufen und Bewerten von Anzeigen auf Echtzeitdaten. Beispielsweise kann das Budget einer Anzeige aufgebraucht werden und sie muss sofort beendet werden. AdTech kann einen URL-Endpunkt definieren, von dem aus diese Echtzeitdaten abgerufen werden können, sowie die Schlüsselsätze, für die die Echtzeitsuche ausgeführt werden soll. Der Server, der diese Anfrage verarbeitet, ist ein vertrauenswürdiger Server, der von der AdTech-Plattform verwaltet wird.
  • Gebotslogik-URL:Die URL, die die Plattform verwendet, um Gebotscode von der Demand-Side-Plattform abzurufen. Die Plattform führt diesen Schritt aus, wenn eine Anzeigenauktion initiiert wird.
  • Anzeigen:Eine Liste möglicher Anzeigen für die benutzerdefinierte Zielgruppe. Dazu gehören plattformspezifische Anzeigenmetadaten und eine URL zum Rendern der Anzeige. Wenn eine Auktion für die benutzerdefinierte Zielgruppe initiiert wird, wird diese Liste der Anzeigenmetadaten berücksichtigt. Diese Liste wird nach Möglichkeit mit dem URL-Endpunkt für die tägliche Aktualisierung aktualisiert. Aufgrund von Ressourceneinschränkungen auf Mobilgeräten ist die Anzahl der Anzeigen, die in einer benutzerdefinierten Zielgruppe gespeichert werden können, begrenzt.

Delegierung für benutzerdefinierte Zielgruppen

Die herkömmliche benutzerdefinierte Zielgruppendefinition und -konfiguration beruhen in der Regel auf serverseitigen Technologien und Integrationen, die von Anzeigentechnologien in Zusammenarbeit mit Kunden und Partnern von Agenturen und Werbetreibenden eingesetzt werden. Die Protected Audience API ermöglicht die Definition und Konfiguration benutzerdefinierter Zielgruppen, während gleichzeitig die Privatsphäre der Nutzer geschützt wird. Um eine benutzerdefinierte Zielgruppe hinzuzufügen, müssen Anzeigentechnologien für Käufer, die kein SDK in Apps haben, mit Anzeigentechnologie-Anbietern zusammenarbeiten, die auf dem Gerät präsent sind, z. B. Mobile Measurement Partner (MMPs) und Supply-Side-Plattformen (SSPs). Die Protected Audience API soll diese SDKs unterstützen, indem sie flexible Lösungen für die benutzerdefinierte Zielgruppenverwaltung bietet, indem auf Geräten im Namen von Käufern benutzerdefinierte Zielgruppen erstellt werden können. Dieser Vorgang wird als Delegierung von benutzerdefinierten Zielgruppen bezeichnet. So konfigurieren Sie die Delegierung für benutzerdefinierte Zielgruppen:

Einer benutzerdefinierten Zielgruppe beitreten

Es gibt zwei Möglichkeiten, einer benutzerdefinierten Zielgruppe beizutreten:

joinCustomAudience()

Eine App oder ein SDK kann den Beitritt zu einer benutzerdefinierten Zielgruppe anfordern, indem joinCustomAudience() aufgerufen wird, nachdem das CustomAudience-Objekt mit den erwarteten Parametern instanziiert wurde. Hier ein Beispiel für ein Code-Snippet:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

Eine App oder ein SDK kann den Beitritt zu einer benutzerdefinierten Zielgruppe im Namen eines AdTech-Teams anfordern, der nicht auf dem Gerät präsent ist. Dazu wird fetchAndJoinCustomAudience() mit den erwarteten Parametern wie im folgenden Beispiel aufgerufen:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

Der URL-Endpunkt, der dem Käufer gehört, antwortet mit dem JSON-Objekt CustomAudience im Antworttext. Die Felder „Käufer“ und „Inhaber“ der benutzerdefinierten Zielgruppe werden ignoriert und von der API automatisch ausgefüllt. Außerdem erzwingt die API, dass die URL für die tägliche Aktualisierung auch mit der eTLD+1 des Käufers übereinstimmt.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

Die fetchAndJoinCustomAudience() API ermittelt die Identität des Käufers anhand der eTLD+1 von fetchUri. Die Käuferidentität CustomAudience wird für dieselben Registrierungs- und App-Autorisierungsprüfungen verwendet wie von joinCustomAudience() und kann durch die Abrufantwort nicht geändert werden. Der Inhaber von CustomAudience ist der Paketname der aufrufenden Anwendung. Abgesehen von der eTLD+1-Prüfung und insbesondere keine k-anon-Prüfung gibt es für fetchUri keine weitere Validierung. Die fetchAndJoinCustomAudience() API sendet eine HTTP-GET-Anfrage an fetchUri und erwartet ein JSON-Objekt, das die benutzerdefinierte Zielgruppe darstellt. Dieselben obligatorischen, optionalen Einschränkungen und Standardwerte für die Felder des benutzerdefinierten Zielgruppenobjekts werden auf die Antwort angewendet. Informationen zu den aktuellen Anforderungen und Einschränkungen finden Sie in unserem Entwicklerleitfaden.

Bei jeder HTTP-Fehlerantwort des Käufers schlägt fetchAndJoinCustomAudience fehl. Insbesondere die HTTP-Statusantwort 429 (Zu viele Anfragen) blockiert Anfragen der aktuellen Anwendung für einen bestimmten Zeitraum. Der API-Aufruf schlägt auch fehl, wenn die Antwort des Käufers fehlerhaft ist. Fehler werden an den API-Aufrufer gemeldet, der für Wiederholungsversuche aufgrund von temporären Fehlern (z. B. der Server antwortet nicht) oder bei der Verarbeitung persistenter Fehler (z. B. Datenvalidierungsfehler oder andere nicht vorübergehende Fehler bei der Kommunikation mit dem Server) verantwortlich ist.

Mit dem Objekt CustomAudienceFetchRequest kann der API-Aufrufer mithilfe der optionalen Eigenschaften aus dem obigen Beispiel einige Informationen für die benutzerdefinierte Zielgruppe definieren. Wenn diese Werte in der Anfrage festgelegt sind, können sie nicht von der Käuferantwort überschrieben werden, die die Plattform erhalten hat. Die Protected Audience API ignoriert die Felder in der Antwort. Wenn sie nicht in der Anfrage festgelegt sind, müssen sie in der Antwort festgelegt werden, da diese Felder zum Erstellen einer benutzerdefinierten Zielgruppe erforderlich sind. Eine JSON-Darstellung des Inhalts von CustomAudience, wie er teilweise vom API-Aufrufer definiert wurde, ist in der GET-Anfrage an fetchUri in einem speziellen Header X-CUSTOM-AUDIENCE-DATA enthalten. Die Größe der seriellen Form der Daten, die für die benutzerdefinierte Zielgruppe angegeben wurde, ist auf 8 KB begrenzt. Wenn die Größe überschritten wird, schlägt der API-Aufruf fetchAndJoinCustomAudience fehl.

Da keine K-anon-Prüfung verfügbar ist, können Sie fetchUri zur Überprüfung des Käufers verwenden und den Informationsaustausch zwischen Käufer und SDK ermöglichen. Der Käufer kann ein Bestätigungstoken angeben, um die Überprüfung benutzerdefinierter Zielgruppen zu vereinfachen. Das SDK auf dem Gerät sollte dieses Token in fetchUri enthalten, damit der vom Käufer gehostete Endpunkt den Inhalt der benutzerdefinierten Zielgruppe abrufen und mithilfe des Bestätigungstokens prüfen kann, ob der fetchAndJoinCustomAudience()-Vorgang dem Käufer entspricht und von einem vertrauenswürdigen On-Device-Partner stammt. Um Informationen zu teilen, kann der Käufer dem Aufrufer auf dem Gerät zustimmen, dass einige der Informationen, die zum Erstellen der benutzerdefinierten Zielgruppe zu verwenden sind, als Abfrageparameter zu fetchUri hinzugefügt werden. Auf diese Weise kann der Käufer die Aufrufe prüfen und feststellen, ob ein Validierungstoken von einer schädlichen Anzeigentechnologie zum Erstellen verschiedener benutzerdefinierter Zielgruppen verwendet wurde.

Hinweis zur Definition und Speicherung von Bestätigungstokens

  • Das Bestätigungstoken wird von der Protected Audience API nicht verwendet und ist optional.

    • Mit dem Bestätigungstoken kann der Käufer verifizieren, dass die Zielgruppen in seinem Namen erstellt werden.
    • Im Protected Audience API-Angebot wird weder ein Format für das Bestätigungstoken noch angegeben, wie der Käufer das Bestätigungstoken an den Aufrufer überträgt. Das Bestätigungstoken kann beispielsweise vorab in das SDK oder Back-End des Inhabers geladen oder in Echtzeit vom SDK des Inhabers vom Server des Käufers abgerufen werden.

Benutzerdefinierte Zielgruppe verlassen

Der Inhaber einer benutzerdefinierten Zielgruppe kann leaveCustomAudience() aufrufen, um die Nutzung zu beenden, wie im folgenden Code-Snippet dargestellt:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

Benutzerdefinierte Zielgruppen laufen nach einer vorab festgelegten Zeit ab und werden aus dem On-Device-Speicher entfernt, um die Nutzung von Speicher und anderen Geräteressourcen zu schonen. Der Standardwert muss noch ermittelt werden. Der Inhaber kann diesen Standardwert überschreiben.

Nutzersteuerung

  • Das Angebot soll Nutzern Einblick in die Liste der installierten Apps geben, für die mindestens eine benutzerdefinierte Zielgruppe erstellt wurde
  • Nutzer können Apps aus dieser Liste entfernen. Dadurch werden alle mit den Apps verknüpften benutzerdefinierten Zielgruppen gelöscht und die Apps können keinen neuen benutzerdefinierten Zielgruppen mehr hinzugefügt werden.
  • Nutzer haben die Möglichkeit, die Protected Audience API vollständig zurückzusetzen. In diesem Fall werden alle vorhandenen benutzerdefinierten Zielgruppen auf dem Gerät gelöscht.
  • Nutzer haben die Möglichkeit, die Privacy Sandbox für Android, die die Protected Audience API enthält, vollständig zu deaktivieren. Wenn der Nutzer die Privacy Sandbox deaktiviert hat, schlägt die Protected Audience API im Hintergrund fehl.

Das Design dieser Funktion ist noch in der Entwicklung. Die Details werden in einer späteren Aktualisierung veröffentlicht.

App-Berechtigungen und -Steuerung

Durch das Angebot soll den Apps die Kontrolle über die benutzerdefinierten Zielgruppen ermöglicht werden:

  • Eine App kann ihre Verknüpfungen mit benutzerdefinierten Zielgruppen verwalten.
  • Eine App kann AdTech-Plattformen von Drittanbietern die Berechtigung erteilen, benutzerdefinierte Zielgruppen in ihrem Namen zu verwalten.

Das Design dieser Funktion ist noch in der Entwicklung. Die Details werden in einer späteren Aktualisierung veröffentlicht.

Steuerung der AdTech-Plattform

In diesem Vorschlag werden Möglichkeiten beschrieben, wie Anzeigentechnologie-Anbieter ihre benutzerdefinierten Zielgruppen steuern können:

  • Anzeigentechnologie-Anbieter registrieren sich für die Privacy Sandbox und stellen eine eTLD+1-Domain bereit, die mit allen URLs für eine benutzerdefinierte Zielgruppe übereinstimmt.
  • AdTechs können mit Apps oder SDKs zusammenarbeiten, um Bestätigungstokens zur Verfügung zu stellen, mit denen die Erstellung einer benutzerdefinierten Zielgruppe überprüft werden kann. Wenn dieser Prozess an einen Partner delegiert wird, kann die Erstellung benutzerdefinierter Zielgruppen so konfiguriert werden, dass eine Bestätigung durch die Anzeigentechnologie erforderlich ist.
  • Ein Anzeigentechnologie-Anbieter kann joinCustomAudience-Aufrufe für ihn deaktivieren und nur der fetchAndJoinCustomAudience API erlauben, alle benutzerdefinierten Zielgruppen für Aufrufe zu aktivieren. Die Einstellungen können während der Privacy Sandbox-Registrierung aktualisiert werden. Die Einstellung lässt entweder alle Anzeigentechnologien zu oder keine. Aufgrund von Plattformeinschränkungen können Delegierungsberechtigungen nicht auf einer einzelnen Anzeigentechnologie-Basis festgelegt werden.

Antwort auf mögliche Anzeigen und Metadaten

Mögliche Anzeigen und Metadaten, die von einer Plattform auf Käuferseite zurückgegeben werden, sollten die folgenden Felder enthalten:

  • Metadaten:Metadaten der Anzeigen auf der Käuferseite und der Anzeigentechnologie. Dazu können beispielsweise Informationen zur Werbekampagne und Targeting-Kriterien wie Standort und Sprache gehören.
  • Render-URL:Endpunkt für das Rendering des Anzeigen-Creatives.
  • Filtern:Optionale Informationen, die die Protected Audience API benötigt, um Anzeigen anhand von Gerätedaten zu filtern. Weitere Informationen finden Sie im Abschnitt zur Filterlogik auf Käuferseite.

Workflow zur Anzeigenauswahl

Mit diesem Vorschlag soll der Datenschutz verbessert werden. Dazu wird die Ad Selection API eingeführt, die die Auktionsausführung für Anzeigentechnologie-Plattformen orchestriert.

AdTech-Plattformen führen heutzutage die Gebots- und Anzeigenauswahl ausschließlich auf ihren Servern durch. Bei diesem Vorschlag sind benutzerdefinierte Zielgruppen und andere vertrauliche Nutzersignale, z. B. Informationen zu installierten Paketen, nur über die Ad Selection API verfügbar. Für den Remarketing-Anwendungsfall werden die Anzeigen außerdem außerhalb des Bereichs abgerufen, also nicht in dem Kontext, in dem die Anzeigen eingeblendet werden. AdTech-Plattformen müssen sich darauf vorbereiten, einige Teile ihrer aktuellen Logik für Auktionen und Anzeigenauswahl bereitzustellen und auf dem Gerät auszuführen. AdTech-Plattformen können die folgenden Änderungen am Workflow für die Anzeigenauswahl in Betracht ziehen:

  • Wenn keine Informationen zu installierten Paketen auf dem Server verfügbar sind, möchten Anzeigentechnologie-Plattformen mehrere kontextbezogene Anzeigen an das Gerät zurücksenden und den Workflow zur Anzeigenauswahl aufrufen, um die App-Installationsbasierte Filterung zu ermöglichen und so die Chancen zu maximieren, dass eine relevante Anzeige ausgeliefert wird.
  • Da Remarketing-Anzeigen außerhalb des Bereichs abgerufen werden, müssen aktuelle Gebotsmodelle möglicherweise aktualisiert werden. AdTech-Plattformen können Untermodelle für Gebote erstellen (die Implementierung kann auf einem sogenannten Zwei-Tower-Modell basieren), die Anzeigenfunktionen und Kontextsignale separat bearbeiten und die Ausgaben des Untermodells auf dem Gerät kombinieren können, um Gebote vorherzusagen. So profitieren Sie sowohl von serverseitigen Auktionen als auch von Auktionen für eine bestimmte Opportunity.

Bei diesem Ansatz können die App-Interaktionsdaten des Nutzers die Anzeigenauswahl beeinflussen. Gleichzeitig wird die Weitergabe dieser Daten an Dritte eingeschränkt.

Flussdiagramm, das die Initiierung des Workflows für die Anzeigenauswahl zeigt.

Dieser Workflow zur Anzeigenauswahl orchestriert die Ausführung des von der Anzeigentechnologie bereitgestellten JavaScript-Codes auf dem Gerät anhand der folgenden Reihenfolge:

  1. Gebotslogik auf Käuferseite ausführen
  2. Anzeigenfilterung und -verarbeitung auf Käuferseite
  3. Ausführung der Entscheidungslogik auf der Verkäuferseite

Bei Anzeigenauswahl mit benutzerdefinierten Zielgruppen ruft die Plattform den auf der Käuferseite bereitgestellten JavaScript-Code auf Grundlage des öffentlichen URL-Endpunkts ab, der durch die Metadaten der Gebotslogik der benutzerdefinierten Zielgruppe definiert wird. Der URL-Endpunkt für den Entscheidungscode auf der Verkäuferseite wird ebenfalls als Eingabe übergeben, um den Workflow für die Anzeigenauswahl zu starten.

Die Gestaltung von Anzeigen ohne benutzerdefinierte Zielgruppen wird derzeit aktiv entwickelt.

Workflow für die Anzeigenauswahl initiieren

Wenn in einer App eine Anzeige ausgeliefert werden muss, kann das SDK für die Anzeigentechnologie den Workflow für die Anzeigenauswahl initiieren. Dazu wird die Methode selectAds() aufgerufen, nachdem das Objekt AdSelectionConfig mit den erwarteten Parametern instanziiert wurde:

  • Verkäufer: Kennung der Sell-Side-Werbeplattform im eTLD+1-Format
  • URL der Entscheidungslogik: Beim Initiieren einer Anzeigenauktion ruft die Plattform anhand dieser URL JavaScript-Code von der Sell-Side-Plattform ab, um eine erfolgreiche Anzeige zu bewerten.
  • Benutzerdefinierte Zielgruppenkäufer: Eine Liste von Plattformen auf Käuferseite mit benutzerdefinierter zielgruppenbasierter Nachfrage für diese Auktion im eTLD+1-Format.
  • Signale zur Anzeigenauswahl: Informationen zur Auktion (Anzeigengröße, Anzeigenformat usw.)
  • Verkäufersignale: Supply-Side-Plattformspezifische Signale
  • URL für vertrauenswürdige Scoring-Signale: URL-Endpunkt des vertrauenswürdigen Signals auf der Verkäuferseite, von dem Creative-spezifische Echtzeitinformationen abgerufen werden können.
  • Signale pro Käufer: Teilnehmende Nachfrageseiten können diesen Parameter verwenden, um Eingaben für die Auktion bereitzustellen. Dieser Parameter kann umfassende Kontextinformationen enthalten, die für die Bestimmung von Geboten nützlich sind.

Das folgende Code-Snippet zur Veranschaulichung zeigt ein SDK für Anzeigentechnologie-Plattformen, das den Workflow für die Anzeigenauswahl initiiert. Dazu wird zuerst die AdSelectionConfig definiert und dann selectAds aufgerufen, um die erfolgreiche Anzeige zu erhalten:

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

Gebotslogik auf Käuferseite

Die Gebotslogik wird in der Regel von Plattformen auf Käuferseite bereitgestellt. Der Code dient dazu, Gebote für mögliche Anzeigen festzulegen. Zur Bestimmung des Ergebnisses kann zusätzliche Geschäftslogik angewendet werden.

Die Plattform ruft anhand der Metadaten der "Gebotslogik-URL" der benutzerdefinierten Zielgruppe den JavaScript-Code ab. Dieser sollte die folgende Funktionssignatur enthalten:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

Die Methode generateBid() gibt den berechneten Gebotsbetrag zurück. Die Plattform ruft diese Funktion für alle Anzeigen (Kontext oder Remarketing) nacheinander auf. Gibt es mehrere Anbieter von Gebotslogik, kann das System die Ausführungssequenz zwischen den Anbietern nicht garantieren.

Die Funktion erwartet die folgenden Parameter:

  • Anzeige: Die Anzeige, die vom Gebotscode auf Käuferseite berücksichtigt wird. Das ist eine Anzeige aus einer geeigneten benutzerdefinierten Zielgruppe
  • Auktionssignale: plattformspezifische Signale auf der Verkaufsseite
  • Signale pro Käufer: Teilnehmende Nachfrageseiten können diesen Parameter verwenden, um Eingaben für die Auktion bereitzustellen. Dieser Parameter kann umfassende Kontextinformationen enthalten, die für die Bestimmung von Geboten nützlich sind.
  • Vertrauenswürdige Gebotssignale: AdTech-Plattformen stützen sich auf Echtzeitdaten, um Anzeigen abzurufen und zu bewerten. Wenn beispielsweise das Budget einer Werbekampagne aufgebraucht ist, muss die Auslieferung sofort beendet werden. Ein AdTech-Anbieter kann einen URL-Endpunkt definieren, von dem diese Echtzeitdaten abgerufen werden können, sowie den Satz von Schlüsseln, für den die Echtzeitsuche ausgeführt werden soll. Der verwaltete Server der AdTech-Plattform, der diese Anfrage verarbeitet, ist ein vertrauenswürdiger Server, der von der AdTech-Plattform verwaltet wird.
  • Kontextsignale: Dazu können ein grober Zeitstempel, Informationen zum ungefähren Standort oder der Cost-per-Click auf der Anzeige gehören.
  • Nutzersignale: Hierzu können Informationen wie Informationen zu verfügbaren installierten Paketen gehören.

Werbekosten

Zusätzlich zum Gebot haben Plattformen auf Käuferseite die Möglichkeit, den Cost-per-Click als Teil von generateBid() zurückzugeben. Beispiel:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

Wenn diese Anzeige gewinnt, wird adCost aus Datenschutzgründen stochastisch auf 8 Bit gerundet. Der gerundete Wert von adCost wird dann während der Berichte zu Impressionen an den Parameter contextual_signals in reportWin übergeben.

Filterlogik auf Käuferseite

Buy-Side-Plattformen können Anzeigen basierend auf zusätzlichen On-Device-Signalen filtern, die während der Anzeigenauswahlphase verfügbar sind. Beispielsweise können AdTech-Plattformen hier Frequency Capping-Funktionen implementieren. Wenn es mehrere Filteranbieter gibt, kann das System die Ausführungsreihenfolge zwischen den Anbietern nicht garantieren.

Die Filterlogik auf Käuferseite kann als Teil der Gebotslogik implementiert werden, indem für eine bestimmte Anzeige ein Gebotswert von 0 zurückgegeben wird.

Außerdem können Plattformen auf Käuferseite signalisieren, dass eine bestimmte Anzeige basierend auf zusätzlichen On-Device-Signalen, die Protected Audience zur Verfügung stehen, gefiltert werden sollte und das Gerät nicht verlässt. Im Zuge der Vereinheitlichung des Designs der zusätzlichen Filterlogik folgen Plattformen auf Käuferseite derselben Struktur, um zu signalisieren, dass die Filterung erfolgen sollte.

Bewertungslogik für Verkäufer

Die Bewertungslogik wird in der Regel von der Sell-Side-Plattform bereitgestellt. Der Zweck des Codes besteht darin, anhand der Ergebnisse der Gebotslogik die erfolgreichste Anzeige zu ermitteln. Zur Bestimmung des Ergebnisses kann zusätzliche Geschäftslogik angewendet werden. Wenn es mehrere Anbieter von Entscheidungslogik gibt, kann das System die Ausführungssequenz zwischen den Anbietern nicht garantieren. Die Plattform verwendet den Eingabeparameter "Entscheidungslogik-URL" der selectAds() API, um den JavaScript-Code abzurufen, der die folgende Funktionssignatur enthalten sollte:

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

Die Funktion erwartet die folgenden Parameter:

  • Anzeige: Die auszuwertende Anzeige; Ausgabe der Funktion generateBid().
  • Gebot: Von der Funktion generateBid() ausgegebener Gebotsbetrag.
  • Auktionskonfiguration: Eingabeparameter für die Methode selectAds().
  • Vertrauenswürdige Bewertungssignale: AdTech-Plattformen stützen sich bei der Anzeigenfilterung und -bewertung auf Echtzeitdaten. Ein App-Publisher kann beispielsweise verhindern, dass Anzeigen in einer Werbekampagne in der App ausgeliefert werden. Diese Daten werden aus dem URL-Parameter für vertrauenswürdige Scoring-Signale der Auktionskonfiguration abgerufen. Der Server, der diese Anfrage sendet, sollte ein von Anzeigentechnologie verwalteter vertrauenswürdiger Server sein.
  • Kontextsignal: Dazu können ein grober Zeitstempel oder Informationen zum ungefähren Standort gehören.
  • Nutzersignal: Dazu können Informationen wie der App-Shop gehören, von dem die Installation der App initiiert wurde.
  • Benutzerdefiniertes Zielgruppensignal: Wenn die bewertete Anzeige aus einer benutzerdefinierten Zielgruppe auf dem Gerät stammt, enthält das Feld Informationen wie den Leser und den Namen der benutzerdefinierten Zielgruppe.

Codelaufzeit für Anzeigenauswahl

Im Vorschlag wird das System den von der AdTech-Plattform bereitgestellten Auktionscode von konfigurierbaren URL-Endpunkten abrufen und auf dem Gerät ausführen. Aufgrund der Ressourcenbeschränkungen auf Mobilgeräten sollte der Auktionscode den folgenden Richtlinien entsprechen:

  • Die Ausführung des Codes sollte in einem vordefinierten Zeitraum abgeschlossen sein. Diese Begrenzung gilt einheitlich für alle Käufer-Werbenetzwerke. Details zu dieser Grenze werden in einer späteren Aktualisierung veröffentlicht.
  • Der Code muss in sich geschlossen sein und darf keine externen Abhängigkeiten haben.

Da der Auktionscode, z. B. die Gebotslogik, möglicherweise Zugriff auf private Nutzerdaten wie App-Installationsquellen benötigt, bietet die Laufzeit keinen Netzwerk- oder Speicherzugriff.

Programmiersprache

Der von der AdTech-Plattform bereitgestellte Auktionscode muss in JavaScript geschrieben sein. So können AdTech-Plattformen beispielsweise Gebotscode mit Plattformen teilen, die die Privacy Sandbox unterstützen.

Erfolgreiches Anzeigen-Rendering

Die Anzeige mit der höchsten Punktzahl gilt als Gewinner der Auktion. In diesem ersten Vorschlag wird die erfolgreiche Anzeige zum Rendern an das SDK übergeben.

Die Lösung soll weiterentwickelt werden, damit Informationen über die Zugehörigkeit zu einer benutzerdefinierten Zielgruppe oder der App-Interaktionsverlauf eines Nutzers nicht von der App oder dem SDK anhand von Informationen über die erfolgreiche Anzeige ermittelt werden können (ähnlich wie beim Vorschlag von Chrome Fenced Frames).

Berichte zu Impressionen und Ereignissen

Sobald die Anzeige gerendert wurde, kann die gewonnene Impression an die teilnehmenden Buy-Side- und Sell-Side-Plattformen zurückgemeldet werden. So können Käufer und Verkäufer Informationen aus der Auktion in den Bericht zu erfolgreichen Impressionen aufnehmen, etwa das Gebot oder den Namen der benutzerdefinierten Zielgruppe. Außerdem sind für die Sell-Side- und die erfolgreiche Buy-Side-Plattform berechtigt, zusätzliche Berichte auf Ereignisebene zur erfolgreichen Anzeige zu erhalten. So haben Sie die Möglichkeit, Informationen zur Auktion (Gebot, Name der benutzerdefinierten Zielgruppe usw.) in Klicks, Aufrufe und andere Anzeigenereignisse einzubeziehen. Die Plattform ruft die Berichtslogik in dieser Reihenfolge auf:

  1. Berichte auf Verkäuferseite.
  2. Berichte auf Käuferseite.

So können auf Buy-Side- und Sell-Side-Plattformen wichtige Informationen auf dem Gerät zurück an die Server gesendet werden, um Funktionen wie Budgetplanung in Echtzeit, Aktualisierung des Gebotsmodells und genaue Abrechnungsworkflows zu ermöglichen. Diese Unterstützung für Impressionsberichte ergänzt die Attribution Reporting API.

Es sind zwei Schritte erforderlich, um Ereignisberichte zu erstellen: JavaScript auf der Verkäuferseite und auf der Käuferseite muss registrieren, für welches Ereignis Ereignisberichte gesendet werden sollen, und der Verkäufer ist für die Berichterstellung für Informationen auf Ereignisebene verantwortlich.

Protected Audience bietet einen Mechanismus, um zukünftige Ereignisse im Zusammenhang mit einer erfolgreichen Auktion zu abonnieren. Dazu werden Beacons registriert. In der JavaScript-Funktion reportResult() eines Verkäufers können Sell-Side-Plattformen Beacons mit der Funktion registerAdBeacon() der Plattform registrieren. In ähnlicher Weise können Plattformen auf Käuferseite die Methode registerAdBeacon() über ihre JavaScript-Funktion reportWin() aufrufen.

registerAdBeacon(beacons)

Eingang:

  • event_key: Ein String, der angibt, für welchen Interaktionstyp registriert werden soll. Diese Information wird verwendet, um den Endpunkt zu ermitteln, den die Plattform beim Erstellen von Berichten über die Auktionsergebnisse pingt.
  • reporting_url: URL der AdTech-Plattform für die Verarbeitung des Ereignisses.

Ereignisschlüssel sind String-IDs, die dem SDK der Verkäuferseite gehören, das für die Berichterstellung der Auktionsergebnisse zuständig ist. Für einen Callback registrieren Anzeigentechnologie-Anbieter Beacons mit Schlüsseln, die mit den Schlüsseln übereinstimmen, die von der Verkäuferseite beim Melden der Ereignisse verwendet werden. Diese müssen nicht k-anonym sein. Es gibt jedoch Limits für die Anzahl und Länge von Schlüsseln, die für eine bestimmte benutzerdefinierte Zielgruppe registriert werden können. Wenn reportEvent() aufgerufen wird, können Sell-Side-Plattformen, auf denen die Auktion ausgeführt wurde, immer diese Ereignisberichte erhalten. Nur die Käuferplattform kann diese Berichte erhalten.

Berichte auf Verkäuferseite

Die Plattform ruft die JavaScript-Funktion reportResult() im auf der Lieferseite bereitgestellten Code auf, der aus dem Parameter URL der Entscheidungslogik des Verkäufers für die selectAds() API heruntergeladen wurde:

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Ausgabe: Ein JSON-Objekt mit

  • Status: 0 für Erfolg, jeder andere Wert für „Fehlgeschlagen“.
  • Berichts-URL: Die Plattform ruft die von der Funktion zurückgegebene URL auf.
  • Signale für Käufer: Ein JSON-Objekt, das an die Funktion reportWin des Käufers übergeben wird.

Die Supply-Side-Seite kann relevante Signale in der Berichts-URL codieren, um weitere Informationen zur Auktion und gewinnenden Anzeige zu erhalten. Es kann beispielsweise folgende Signale enthalten:

  • Rendering-URL der Anzeige
  • Betrag des erfolgreichen Gebots
  • App-Name
  • Abfragekennungen
  • Signale für Käufer: Um den Datenaustausch zwischen der Angebotsseite und der Nachfrageseite zu unterstützen, übergibt die Plattform diesen Rückgabewert als Eingabeparameter an den Demand-Side-Berichtscode.

Berichte auf Käuferseite

Die Plattform ruft die JavaScript-Funktion reportWin() im Demand-Side-Code auf, der aus den Metadaten der Gebotslogik-URL der mit der Auktion verknüpften benutzerdefinierten Zielgruppe heruntergeladen wurde.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

Eingang:

  • auction_signals und per_buyer_signals werden von AuctionConfig abgerufen. Alle Informationen, die die Käuferplattform an die Berichts-URL übergeben muss, können von diesem Datum stammen.
  • signals_for_buyer ist die Ausgabe von „reportResult“ auf Verkäuferseite. Dadurch hat die Sell-Side-Plattform die Möglichkeit, Daten zu Berichtszwecken mit der Plattform auf Käuferseite zu teilen.
  • contextual_signals enthält Informationen wie den App-Namen und custom_audience_signals die Informationen zur benutzerdefinierten Zielgruppe. Weitere Informationen werden möglicherweise in Zukunft hinzugefügt.

Ausgabe:

  • Status: 0 für Erfolg, jeder andere Wert für „Fehlgeschlagen“.
  • Berichts-URL: Die Plattform ruft die von der Funktion zurückgegebene URL auf.

Ereignisse melden

Ereignisse werden erst erfasst, nachdem die Berichte zu Impressionen für die Auktion abgeschlossen sind. Das SDK der Verkaufsseite ist für die Meldung von Ereignissen verantwortlich. Die Plattform stellt eine API bereit, die eine ReportEventRequest annimmt, die die zuletzt durchgeführte Auktion, den gemeldeten Ereignisschlüssel, die mit diesem Schlüssel verknüpften Daten, ob der Bericht an den Käufer oder den Verkäufer (oder beides) gesendet werden soll, und ein optionales Eingabeereignis für Anzeigenereignisse. Der Kunde definiert den Ereignisschlüssel und die Datensammlung für den Bericht.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

Eingang:

  • ad_selection_id muss ein AdSelectionId einer kürzlich durchgeführten Auktion sein, die vom AdSelectionOutcome abgerufen wurde.
  • event_key ist ein auf Verkäuferseite definierter String, der das Interaktionsereignis beschreibt.
  • event_data ist ein String, der die Daten darstellt, die mit event_key verknüpft sind.
  • reporting_destinations ist eine Bitmaske, die mithilfe von Flags festgelegt wird, die von der Plattform bereitgestellt werden. Dies kann FLAG_REPORTING_DESTINATION_SELLER oder FLAG_REPORTING_DESTINATION_BUYER oder beides sein.
  • input_event (optional) wird für die Integration in die Attribution Reporting API verwendet. Es ist entweder ein InputEvent-Objekt (für ein Klickereignis) oder null (für ein Aufrufereignis). Weitere Informationen zu diesem Parameter finden Sie unter Integration der Attribution Reporting API.

Nachdem das Sell-Side-SDK reportEvent aufgerufen hat und je nach reporting_destinations-Flag versucht die Plattform, die event_key mit den Schlüsseln abzugleichen, die von Käufern und Verkäufern in den JavaScript-Funktionen reportWin und reportResult registriert wurden. Wenn eine Übereinstimmung vorliegt, POSTet die Plattform das event_data an das verknüpfte reporting_url. Der Inhaltstyp der Anfrage ist Nur-Text mit dem Text event_data. Diese Anfrage erfolgt im Best-Effort-Modus und schlägt automatisch fehl, wenn ein Netzwerkfehler, eine Serverfehlerantwort oder keine übereinstimmenden Schlüssel gefunden werden.

Attribution Reporting API-Integration

Zur Unterstützung von Käufern, die an einer Protected Audience-Auktion teilnehmen, bieten wir API-übergreifende Funktionen in der Protected Audience API und der Attribution Reporting API (ARA). Mit dieser Funktion können Anzeigentechnologie-Anbieter die Attributionsleistung über verschiedene Remarketing-Taktiken hinweg bewerten und so ermitteln, welche Arten von Zielgruppen den höchsten ROI erzielen.

Durch diese API-übergreifende Integration können AdTechs:

  • Erstellen Sie eine Schlüssel/Wert-Zuordnung von URIs, die sowohl für 1) Berichte zu Anzeigeninteraktionen als auch 2) für die Registrierung der Quelle verwendet werden soll.
  • Auktionsdaten aus Protected Audience-Auktionen werden in der quellseitigen Schlüsselzuordnung für aggregierte zusammenfassende Berichte berücksichtigt (mithilfe der Attribution Reporting API). Weitere Informationen finden Sie im ARA-Designvorschlag.

Wenn ein Nutzer eine Anzeige sieht oder darauf klickt,

  • Über die URL, die verwendet wird, um diese Ereignisinteraktionen über Protected Audience zu melden, werden dem Käufer die erforderlichen Daten zur Verfügung gestellt, um eine Ansicht oder einen Klick als zulässige Quelle mit der Attribution Reporting API zu registrieren.
  • Die Anzeigentechnologie kann CustomAudience (oder andere relevante Kontextinformationen zur Anzeige wie Anzeigen-Placement oder Wiedergabedauer) über diese URL weitergeben, sodass diese Metadaten in zusammenfassenden Berichten weitergegeben werden können, wenn die Anzeigentechnologie die zusammengefasste Kampagnenleistung überprüft.

Quellenregistrierung aktivieren

reportEvent() akzeptiert den neuen optionalen Parameter InputEvent. Erfolgreiche Käufer, die Anzeigen-Beacons registrieren, können auswählen, welche ReportEvent-Berichte mit den Attribution Reporting APIs als registrierte Quelle registriert werden sollen. Der Anfrageheader „Attribution-Reporting-Allowed“ wird allen von reportEvent() gesendeten Anfragen zu Ereignisberichten hinzugefügt. Alle Antworten mit entsprechenden ARA-Headern werden auf die gleiche Weise wie andere reguläre ARA-Quellenregistrierungsantworten geparst. Informationen zum Registrieren einer Quell-URL finden Sie in der Erläuterung der Attribution Reporting API.

Da ARA unter Android Aufruf- und Klickereignisse unterstützt, wird InputEvents verwendet, um zwischen den beiden Typen zu unterscheiden. Genau wie bei der Registrierung der ARA-Quelle interpretiert die reportEvent() API einen von der Plattform bestätigten InputEvent als Klickereignis. Wenn InputEvent fehlt, null oder ungültig ist, wird die Quellregistrierung als Ansicht betrachtet.

Beachten Sie, dass eventData nach der Auktion vertrauliche Informationen enthalten kann. Daher löscht die Plattform die eventData in weitergeleiteten Quellregistrierungsanfragen.

Beispiel für Berichte zu Engagement und Conversions

In diesem Beispiel sehen wir den Käufer aus der Perspektive des Käufers, der die Daten aus der Auktion, der gerenderten Anzeige und der Conversion-App miteinander verknüpfen möchte.

Bei diesem Workflow stimmt der Käufer mit dem Verkäufer ab, um eine eindeutige ID an die Auktion zu senden. Während der Auktion sendet der Käufer diese eindeutige ID zusammen mit den Auktionsdaten. Während des Renderings und der Conversion werden die Daten der gerenderten Anzeige mit derselben eindeutigen ID gesendet. Später können die Berichte anhand der eindeutigen ID zugeordnet werden.

Workflow: Vor Beginn der Auktion sendet der Käufer im Rahmen seiner programmatischen Gebotsantwort für Echtzeitgebote (Real-Time-Bidding, RTB) eine eindeutige ID an den Verkäufer. Die ID kann als Variable wie auctionId festgelegt werden. Die ID wird als perBuyerSignals im auctionConfig übergeben und steht dann in der Gebotslogik des Käufers zur Verfügung.

  1. Bei der Ausführung von reportWin kann der Käufer ein Anzeigen-Beacon registrieren, das während des Renderings der Anzeige und für bestimmte Interaktionsereignisse (registerAdBeacon()) ausgelöst wird. Um Auktionssignale für ein Anzeigenereignis zuzuordnen, legen Sie auctionId als Abfrageparameter der Beacon-URL fest.
  2. Die Beacons, die Sie während der Auktion registriert haben, können während des Renderings der Anzeige mit Daten auf Ereignisebene ausgelöst oder optimiert werden. Der Verkäufer muss reportEvent() auslösen und die Daten auf Ereignisebene übergeben. Die Plattform pingt die registrierte Beacon-URL des Käufers an, die mit der ausgelösten reportEvent() übereinstimmt.
  3. Der Käufer registriert die Anzeige mit der Attribution Reporting API, indem er auf Beacon-Anfragen für Anzeigen mit dem Header Attribution-Reporting-Register-Source antwortet. Wenn Sie Auktionssignale für ein Conversion-Ereignis verknüpfen möchten, legen Sie in der URL für die Registrierungsquelle auctionId fest.

Nach dem oben beschriebenen Vorgang erhält der Käufer einen Auktionsbericht, einen Interaktionsbericht und einen Conversion-Bericht, die mithilfe der eindeutigen ID korreliert werden können.

Ein ähnlicher Workflow gilt für Verkäufer, die Zugriff auf Attributionsdaten benötigen. Außerdem kann der Verkäufer eine eindeutige ID zum Senden mit registerAdBeacon() verwenden. Der reportEvent()-Aufruf enthält eine Ziel-Property, mit der der Bericht sowohl an den Käufer als auch an den Verkäufer gesendet werden kann.

Von der AdTech-Plattform verwalteter vertrauenswürdiger Server

Die Anzeigenauswahllogik benötigt heute Echtzeitinformationen wie den Status der Budgeterschöpfung, um zu ermitteln, ob Anzeigenkandidaten für die Auktion ausgewählt werden sollen. Sowohl Buy-Side- als auch Sell-Side-Plattformen können diese Informationen von den von ihnen betriebenen Servern abrufen. Im Angebot sind die folgenden Einschränkungen erforderlich, um die Offenlegung vertraulicher Informationen über diese Server zu minimieren:

  • Durch das weiter unten in diesem Abschnitt beschriebene Verhalten dieser Server werden keine Nutzerinformationen offengelegt.
  • Die Server erstellen auf Grundlage der angezeigten Daten keine pseudonymisierten Profile, sondern müssen als „vertrauenswürdig“ eingestuft werden.

Kaufseite: Sobald die Käuferseite die Gebotslogik auf der Käuferseite initiiert, führt die Plattform einen HTTP-Abruf von vertrauenswürdigen Gebotsdaten vom vertrauenswürdigen Server durch. Die URL besteht aus dem Anfügen der URL und der Schlüssel, die in den Metadaten für vertrauenswürdige Gebotssignale der benutzerdefinierten Zielgruppe vorhanden sind, die verarbeitet wird. Dieser Abruf erfolgt nur, wenn Anzeigen aus den benutzerdefinierten Zielgruppen auf dem Gerät verarbeitet werden. In dieser Phase kann die Käuferseite Budgets durchsetzen, den Status der Kampagnenpausierung / Pausierung überprüfen, das Targeting durchführen usw.

Mit der folgenden Beispiel-URL können Sie Daten zu vertrauenswürdigen Geboten abrufen, die auf Metadaten des vertrauenswürdigen Gebotssignals der benutzerdefinierten Zielgruppe basieren:

https://www.kv-server.example/getvalues?keys=key1,key2

Die Antwort des Servers sollte ein JSON-Objekt mit den Schlüsseln key1, key2 usw. sein. Seine Werte werden den Gebotsfunktionen des Käufers zur Verfügung gestellt.

Verkäuferseite: Ähnlich wie beim obigen Ablauf auf der Käuferseite möchte die Verkäuferseite möglicherweise Informationen zu Creatives abrufen, die für die Auktion berücksichtigt werden. Beispielsweise kann ein Publisher aufgrund von Bedenken hinsichtlich der Markensicherheit erzwingen, dass bestimmte Creatives nicht in seiner App angezeigt werden. Diese Informationen können abgerufen und der Auktionslogik auf der Verkäuferseite zur Verfügung gestellt werden. Ähnlich wie die Suche auf vertrauenswürdigen Servern auf Käuferseite erfolgt die Suche auf vertrauenswürdigen Servern auf der Verkäuferseite auch über einen HTTP-Abruf. Die URL besteht aus dem Anhängen der URL für vertrauenswürdige Bewertungssignale mit den Rendering-URLs der Creatives, für die die Daten abgerufen werden müssen.

Mit der folgenden Beispiel-URL können Sie Informationen zu Creatives abrufen, die an der Auktion teilnehmen, basierend auf den Rendering-URLs der Creatives:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

Die Antwort vom Server sollte ein JSON-Objekt sein, dessen Schlüssel Rendering-URLs sind, die in der Anfrage gesendet werden.

Diese Server würden vertrauenswürdig funktionieren, um verschiedene Sicherheits- und Datenschutzvorteile zu bieten:

  • Es kann vertraut werden, dass der Rückgabewert des Servers für jeden Schlüssel nur auf diesem Schlüssel basiert.
  • Der Server führt keine Protokollierung auf Ereignisebene durch.
  • Der Server hat aufgrund dieser Anfragen keine weiteren Nebenwirkungen.

Käufer und Verkäufer können diese Gebotssignale vorübergehend von einem beliebigen Server abrufen, auch von einem Server, von dem sie selbst betrieben werden. In der Release-Version wird die Anfrage jedoch nur an einen vertrauenswürdigen Server vom Typ Schlüssel/Wert-Paare gesendet.

Käufer und Verkäufer können einen gemeinsamen vertrauenswürdigen Schlüssel/Wert-Paar-Server für Plattformen verwenden, die mit der Privacy Sandbox auf Android und im Web kompatibel sind.