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

Feedback geben

Letzte Updates

Protected Audience befindet sich in der Betaphase und ist zum Testen auf öffentlichen Geräten verfügbar.

Mit Protected Audience können Sie:

  • Benutzerdefinierte Zielgruppen auf Grundlage früherer Nutzeraktionen verwalten.
  • Starten Sie On-Device-Auktionen mit einem einzelnen Verkäufer oder der Unterstützung der abfolgebasierten Vermittlung.
  • Führen Sie nach der Anzeigenauswahl die Impressionsberichte durch.

Lesen Sie zuerst den Entwicklerleitfaden zu Protected Audience. Wir freuen uns über Ihr Feedback, da wir die Funktion „Protected Audience“ weiterentwickeln.

Zeitleiste

Wir werden in den kommenden Monaten neue Funktionen veröffentlichen. Die genauen Veröffentlichungsdaten variieren je nach Funktion. Diese Tabelle wird mit Links zur Dokumentation aktualisiert, sobald sie verfügbar ist.

Feature Verfügbar in der Entwicklervorschau In der Betaversion verfügbar
Berichte auf Ereignisebene 1. Quartal 2023 3. Quartal 2023
Vermittlung der Vermittlungsabfolge 1. Quartal 2023 4. Quartal 2023
Filter für App-Installationsanzeigen 2. Quartal 2023 3. Quartal 2023
Filterung nach Frequency Capping 2. Quartal 2023 3. Quartal 2023
Kontextbezogene Anzeigen zur Filterung an den Anzeigenauswahl-Workflow übergeben 2. Quartal 2023 3. Quartal 2023
Interaktionsberichte 2. Quartal 2023 3. Quartal 2023
An der benutzerdefinierten Zielgruppendelegierung teilnehmen 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
Fehlerbehebungsberichte 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 von aggregierten Berichten 3. Quartal 2024 4. Quartal 2024

Überblick

Bei mobiler Werbung müssen Werbetreibende häufig Anzeigen für potenziell interessierte Nutzer basierend auf ihren bisherigen Interaktionen mit der App des Werbetreibenden schalten. Zum Beispiel möchte der Entwickler von SportingGoodsApp möglicherweise Nutzer ansprechen, die Artikel im Einkaufswagen haben, indem er Anzeigen schaltet, um Nutzer daran zu erinnern, den Kauf abzuschließen. In der Branche wird diese allgemeine Idee häufig mit Begriffen wie „Remarketing“ oder „Ausrichtung auf benutzerdefinierte Zielgruppen“ beschrieben.

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

Die Protected Audience API unter Android (früher FLEDGE) umfasst die folgenden APIs für Anzeigentechnologie-Plattformen und Werbetreibende, um gängige interaktionsbasierte Anwendungsfälle auf eine Weise zu unterstützen, bei der die Weitergabe von Kennungen zwischen Apps und App-Interaktionsdaten eines Nutzers an Dritte eingeschränkt wird:

  1. Custom Audience API: Diese API ist auf die Abstraktion „benutzerdefinierte Zielgruppe“ ausgerichtet, d. h. eine vom Werbetreibenden festgelegte Zielgruppe mit gemeinsamen Absichten. Zielgruppeninformationen werden auf dem Gerät gespeichert und können mit relevanten, für die Zielgruppe relevanten Anzeigen sowie mit beliebigen Metadaten, z. B. Gebotssignalen, verknüpft werden. Anhand dieser Informationen lassen sich Gebote für Werbetreibende optimieren sowie Anzeigen filtern und rendern.
  2. Ad Selection API: Diese API bietet ein Framework, das die Workflows von Anzeigentechnologie-Plattformen orchestriert, die On-Device-Signale nutzen, um eine "Erfolgreiche" Anzeige zu ermitteln. Dabei werden mögliche Anzeigen berücksichtigt, die lokal gespeichert sind. Außerdem werden mögliche Anzeigen, die von einer AdTech-Plattform an das Gerät zurückgegeben werden, zusätzlich verarbeitet.
Flussdiagramm, das die Verwaltung von benutzerdefinierten Zielgruppen 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 in ihrem 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. Diese Zielgruppenliste wird von der Plattform verwaltet und auf dem Gerät gespeichert, wodurch die Freigabe für Dritte eingeschränkt wird. SportingGoodsApp arbeitet mit einer Anzeigentechnologie-Plattform zusammen, um seine Anzeigen Nutzern in der entsprechenden Zielgruppenliste zu präsentieren. Auf der AdTech-Plattform werden Metadaten für Zielgruppenlisten verwaltet und mögliche Anzeigen bereitgestellt, die dem Workflow für die Anzeigenauswahl zur Verfügung gestellt werden. Die Plattform kann so konfiguriert werden, dass regelmäßig aktualisierte zielgruppenbasierte Anzeigen im Hintergrund abgerufen werden. So bleibt die Liste der zielgruppenbasierten Kandidatenanzeigen aktuell und steht nicht im Zusammenhang mit Anfragen, die während der Werbechance an Ad-Server von Drittanbietern gesendet werden (d.h. kontextbezogene Anzeigenanfrage).

  2. Wenn der Nutzer das FrisbeeGame auf demselben Gerät spielt, sieht er möglicherweise eine Anzeige, die ihn daran erinnert, den Kauf der Artikel im Einkaufswagen von SportingGoodsApp abzuschließen. Dazu muss FrisbeeGame (mit einem integrierten Anzeigen-SDK) die Ad Selection API aufrufen, um basierend auf der Zielgruppenliste, zu der der Nutzer gehört, eine erfolgreiche Anzeige für den Nutzer auszuwählen (in diesem Beispiel die von SportingGoodsApp erstellte benutzerdefinierte Zielgruppe „Produkte im Einkaufswagen“). Der Workflow für die Anzeigenauswahl kann so eingerichtet werden, dass neben Anzeigen auf dem Gerät, die den benutzerdefinierten Zielgruppen zugeordnet sind, auch andere Gerätesignale berücksichtigt werden, die von den Servern der Anzeigentechnologie-Plattformen abgerufen wurden. Der Workflow kann auch über die AdTech-Plattform und das Ads SDK mit benutzerdefinierter Gebotseinstellung und Bewertungslogik angepasst werden, um geeignete Werbeziele zu erreichen. So können die Daten zu Interessen oder App-Interaktionen des Nutzers als Grundlage für die Anzeigenauswahl dienen und die Weitergabe dieser Daten an Dritte wird eingeschränkt.

  3. Die ausgewählte Anzeige wird über das SDK der Ad Serving-App oder der AdTech-Plattform gerendert.

  4. Die Plattform ermöglicht die Berichterstellung zu Impressionen und Ergebnissen der Anzeigenauswahl. Diese Berichtsfunktion ist Ergänzung zur Attribution Reporting API. Anzeigentechnologie-Plattformen können je nach Berichtsanforderungen angepasst werden.

Zugriff auf Protected Audience API für Android-APIs erhalten

AdTech-Plattformen müssen sich für den Zugriff auf die Protected Audience API registrieren. Weitere Informationen finden Sie unter Für ein Privacy Sandbox-Konto registrieren.

Benutzerdefinierte Zielgruppenverwaltung

Benutzerdefinierte Zielgruppe

Eine benutzerdefinierte Zielgruppe ist eine Gruppe von Nutzern, die vom Werbetreibenden mit gemeinsamen Absichten oder Interessen festgelegt wurden. Eine App oder ein SDK kann eine benutzerdefinierte Zielgruppe verwenden, um eine bestimmte Zielgruppe anzugeben, z. B. Nutzer, die Artikel im Einkaufswagen haben oder die Anfängerlevels eines Spiels abgeschlossen haben. Die Plattform speichert und speichert Zielgruppeninformationen lokal auf dem Gerät. Dabei ist nicht offengelegt, zu welchen benutzerdefinierten Zielgruppen der Nutzer gehört. Benutzerdefinierte Zielgruppen unterscheiden sich von den Interessengruppen von Protected Audience in Chrome und können nicht im Web und in Apps geteilt werden. Dadurch wird die Freigabe von Nutzerinformationen eingeschränkt.

Eine Werbetreibenden-App oder das integrierte SDK kann einer benutzerdefinierten Zielgruppe join oder verlassen, z. B. basierend auf Nutzerinteraktionen in einer App.

Benutzerdefinierte Zielgruppenmetadaten

Jede benutzerdefinierte Zielgruppe enthält die folgenden Metadaten:

  • Owner (Inhaber): Paketname der Inhaber-App. Dies ist implizit auf den Paketnamen der aufrufenden App festgelegt.
  • Käufer:Das Werbenetzwerk des Käufers, in dem Anzeigen für diese benutzerdefinierte Zielgruppe verwaltet werden Außerdem repräsentiert der Käufer die Partei, die auf die benutzerdefinierte Zielgruppe zugreifen und relevante Anzeigeninformationen abrufen darf. Der Käufer wird im Format eTLD+1 angegeben.
  • Name:Beliebiger Name oder 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 Ausrichtungskriterien in den Werbekampagnen des Werbetreibenden oder als Abfragestring in der URL zum Abrufen von Gebotscode verwendet werden.
  • Aktivierungszeit und Ablaufzeit:Diese Felder definieren das Zeitfenster, in dem diese benutzerdefinierte Zielgruppe wirksam ist. Die Plattform nutzt diese Informationen, um einer benutzerdefinierten Zielgruppe die Mitgliedschaft zu entziehen. Die Ablaufzeit darf ein maximales Dauerfenster nicht überschreiten, um die Lebensdauer einer benutzerdefinierten Zielgruppe zu begrenzen.
  • URL für tägliche Aktualisierung:Die URL, über die die Plattform mögliche Anzeigen und andere Metadaten regelmäßig abruft, die in den Feldern „Gebotssignale des Nutzers“ und „Vertrauenswürdige Gebotssignale“ definiert sind. Weitere Informationen finden Sie im Abschnitt Kandidaten für benutzerdefinierte Zielgruppen abrufen.
  • Gebotssignale von Nutzern:Plattformspezifische Signale der Anzeigentechnologie für alle Gebote für Remarketing-Anzeigen Beispiele für Signale sind der ungefähre Standort des Nutzers, seine bevorzugte Sprache usw.
  • Vertrauenswürdige Gebotsdaten:AdTech-Plattformen vertrauen beim Abrufen und Bewerten von Anzeigen auf Echtzeitdaten. Dies ist beispielsweise der Fall, wenn das Budget für eine Anzeige aufgebraucht ist und die Auslieferung sofort beendet werden muss. Eine Anzeigentechnologie kann einen URL-Endpunkt definieren, von dem aus die Echtzeitdaten abgerufen werden können, sowie den Schlüsselsatz, für den die Echtzeitsuche durchgeführt werden muss. Der Server, der diese Anfrage verarbeitet, ist ein vertrauenswürdiger Server, der von der AdTech-Plattform verwaltet wird.
  • URL für die Gebotslogik:Die URL, die die Plattform verwendet, um Gebotscode von der Demand-Side-Plattform abzurufen. Dieser Schritt wird von der Plattform ausgeführt, wenn eine Anzeigenauktion initiiert wird.
  • Anzeigen:Eine Liste möglicher Anzeigen für die benutzerdefinierte Zielgruppe. Dazu gehören plattformspezifische Anzeigenmetadaten der Anzeigentechnologie und eine URL zum Rendern der Anzeige. Wenn eine Auktion für die benutzerdefinierte Zielgruppe eingeleitet wird, wird diese Liste von Anzeigenmetadaten berücksichtigt. Diese Anzeigenliste wird nach Möglichkeit mit dem URL-Endpunkt für die tägliche Aktualisierung aktualisiert. Aufgrund von Ressourceneinschränkungen auf Mobilgeräten gibt es ein Limit für die Anzahl der Anzeigen, die in einer benutzerdefinierten Zielgruppe gespeichert werden können.

Benutzerdefinierte Zielgruppendelegierung

Die traditionelle Definition und Konfiguration von benutzerdefinierten Zielgruppen basiert in der Regel auf serverseitigen Technologien und Integrationen, die von AdTechs in Zusammenarbeit mit Agentur- und Werbetreibendenkunden und -partnern durchgeführt werden. Mit der Protected Audience API können Sie benutzerdefinierte Zielgruppen definieren und konfigurieren und gleichzeitig die Privatsphäre der Nutzer schützen. Um einer benutzerdefinierten Zielgruppe beizutreten, müssen Anzeigentechnologie-Anbieter ohne SDK in Apps mit Anzeigentechnologie-Anbietern zusammenarbeiten, die auf dem Gerät präsent sind, z. B. Mobile Measurement Partners (MMPs) und Supply-Side-Plattformen (SSP). Die Protected Audience API unterstützt diese SDKs. Sie bietet flexible Lösungen für die Verwaltung benutzerdefinierter Zielgruppen. Sie ermöglicht es Nutzern auf dem Gerät, im Namen von Käufern benutzerdefinierte Zielgruppen zu erstellen. Dieser Vorgang wird als Delegierung von benutzerdefinierten Zielgruppen bezeichnet. So konfigurieren Sie die benutzerdefinierte Zielgruppendelegierung:

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 sie joinCustomAudience() aufruft, nachdem das CustomAudience-Objekt mit den erwarteten Parametern instanziiert wurde. Hier ist 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 im Namen eines Anzeigentechnologie-Anbieters, der keine Präsenz auf dem Gerät hat, den Beitritt zu einer benutzerdefinierten Zielgruppe anfordern, indem er fetchAndJoinCustomAudience() mit den erwarteten Parametern wie im folgenden Beispiel aufruft:

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 des Käufers antwortet mit einem CustomAudience-JSON-Objekt im Antworttext. Die Felder für Käufer und Inhaber der benutzerdefinierten Zielgruppe werden ignoriert und von der API automatisch ausgefüllt. Die API erzwingt außerdem, 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 über die eTLD+1 von fetchUri. Die Identität des Käufers CustomAudience wird verwendet, um dieselben Registrierungs- und Anwendungsautorisierungsprüfungen durchzuführen, die auch von joinCustomAudience() durchgeführt werden, und kann durch die Abrufantwort nicht geändert werden. Der CustomAudience-Inhaber ist der Paketname der aufrufenden Anwendung. Außer der eTLD+1-Prüfung findet keine weitere Validierung von fetchUri statt. Insbesondere gibt es keine k-anon-Prüfung. Die fetchAndJoinCustomAudience() API sendet eine HTTP-GET-Anfrage an fetchUri und erwartet ein JSON-Objekt, das die benutzerdefinierte Zielgruppe darstellt. Auf die Antwort werden dieselben obligatorischen optionalen Einschränkungen und Standardwerte für die benutzerdefinierten Zielgruppenobjektfelder angewendet. Informationen zu den aktuellen Anforderungen und Einschränkungen finden Sie in unserem Entwicklerleitfaden.

Jede HTTP-Fehlerantwort des Käufers führt zum Fehlschlagen von fetchAndJoinCustomAudience. Insbesondere blockiert eine HTTP-Statusantwort von 429 (Zu viele Anfragen) Anfragen von der aktuellen Anwendung für einen noch zu definierenden Zeitraum. Der API-Aufruf schlägt auch fehl, wenn die Antwort des Käufers fehlerhaft ist. Fehler werden dem API-Aufrufer gemeldet, der für Wiederholungsversuche aufgrund temporärer Fehler (z. B. wenn der Server nicht antwortet) oder dauerhafte Fehler (z. B. Fehler bei der Datenvalidierung oder andere dauerhafte Fehler bei der Kommunikation mit dem Server) verantwortlich ist.

Mit dem Objekt CustomAudienceFetchRequest kann der API-Aufrufer mithilfe der optionalen Attribute, die im obigen Beispiel gezeigt werden, 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 von der Plattform empfangen wird. Die Protected Audience API ignoriert die Felder in der Antwort. Wenn sie nicht in der Anfrage festgelegt werden, müssen sie in der Antwort festgelegt werden, da diese Felder zum Erstellen einer benutzerdefinierten Zielgruppe erforderlich sind. Eine JSON-Darstellung des Inhalts der CustomAudience, wie sie 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 serialisierten Form der für die benutzerdefinierte Zielgruppe angegebenen Daten ist auf 8 KB begrenzt. Wenn die Größe überschritten wird, schlägt der API-Aufruf fetchAndJoinCustomAudience fehl.

Da keine k-anon-Prüfung vorhanden ist, kannst du fetchUri für die Käuferüberprüfung verwenden und den Informationsaustausch zwischen Käufer und SDK ermöglichen. Der Käufer kann ein Bestätigungstoken angeben, um die benutzerdefinierte Zielgruppenüberprüfung zu vereinfachen. Das On-Device-SDK sollte dieses Token in fetchUri aufnehmen, damit der vom Käufer gehostete Endpunkt den Inhalt der benutzerdefinierten Zielgruppe abrufen und mithilfe des Bestätigungstokens überprüfen kann, ob der fetchAndJoinCustomAudience()-Vorgang dem Käufer entspricht und von einem vertrauenswürdigen On-Device-Partner stammt. Zum Teilen von Informationen kann der Käufer mit dem Aufrufer auf dem Gerät vereinbaren, dass einige der Informationen, die zum Erstellen der benutzerdefinierten Zielgruppe verwendet werden sollen, als Abfrageparameter in die fetchUri eingefügt werden. So kann der Käufer die Aufrufe prüfen und feststellen, ob ein Validierungstoken von einer schädlichen Anzeigentechnologie verwendet wurde, um mehrere verschiedene benutzerdefinierte Zielgruppen zu erstellen.

Hinweis zur Definition und Speicherung von Bestätigungstokens

  • Das Bestätigungstoken wird von der Protected Audience API für keine Zwecke verwendet und ist optional.

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

Benutzerdefinierte Zielgruppe verlassen

Der Inhaber einer benutzerdefinierten Zielgruppe kann die Zielgruppe verlassen, indem er leaveCustomAudience() aufruft, wie im folgenden Code-Snippet gezeigt:

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

Um die Nutzung von Speicher und anderen Geräteressourcen zu schonen, laufen benutzerdefinierte Zielgruppen ab und werden nach einem festgelegten Zeitraum aus dem Gerätespeicher entfernt. Der Standardwert muss bestimmt werden. Der Inhaber kann diesen Standardwert überschreiben.

Nutzersteuerung

  • Das Angebot soll Nutzern einen Einblick in die Liste der installierten Apps geben, die mindestens eine benutzerdefinierte Zielgruppe erstellt haben.
  • Nutzer können Apps aus dieser Liste entfernen. Dadurch werden alle mit den Apps verknüpften benutzerdefinierten Zielgruppen gelöscht und die Anwendungen können keinen neuen benutzerdefinierten Zielgruppen hinzugefügt werden.
  • Nutzer können die Protected Audience API vollständig zurücksetzen. In diesem Fall werden alle vorhandenen benutzerdefinierten Zielgruppen auf dem Gerät gelöscht.
  • Nutzer können die Privacy Sandbox für Android, die die Protected Audience API enthält, vollständig 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 enthalten sein.

Geplante Updates

Bei den oben beschriebenen Lösungen muss die App oder das AdTech SDK die APIs aufrufen, während die App im Vordergrund ausgeführt wird. Außerdem müssen die vollständigen Eigenschaften der benutzerdefinierten Zielgruppe entweder direkt oder per Delegierung bereitgestellt werden. Werbetreibende und Anbieter von Anzeigentechnologien können jedoch nicht immer in Echtzeit definieren, zu welchen Zielgruppen ein Nutzer gehört, während er die App verwendet.

Zu diesem Zweck kann die Anzeigentechnologie die scheduleCustomAudienceUpdate() API aufrufen. Mit dieser API kann der Aufrufer eine Verzögerung für den API-Aufruf angeben. Dadurch hat die antwortende Anzeigentechnologie mehr Zeit, Ereignisse auf App-Ebene zu verarbeiten und zu bestimmen, welchen Protected Audience-Zielgruppen der Nutzer beitreten oder aus welchen entfernt werden soll.

/**
* API To schedule delayed update events for Custom Audience
*
* @param delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/

public void scheduleCustomAudienceUpdates(
    @NonNull DelayedCustomUpdate delayedCustomAudienceUpdate,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

DelayedCustomAudienceUpdate

public final class DelayedCustomAudienceUpdate {
    // Required Field
    @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

    // Required Field
    @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

    //  Required Field
    @NonNull public List<PartialCustomAudience> getPartialCustomAudiences() {
    return mPartialCustomAudiences;
  }
}

DelayedCustomAudienceUpdate enthält die Informationen, die für die Registrierung eines verzögerten Jobs zur Ausführung auf der Plattform erforderlich sind. Nach der angegebenen Verzögerung wird ein Hintergrundjob regelmäßig ausgeführt und die Anfragen werden gesendet. Das DelayedCustomAudienceUpdate kann die folgenden Informationen enthalten:

  • UpdateUri: URI-Endpunkt, an den ein GET-Aufruf zum Abrufen des Updates gesendet wird. Die Identität des Käufers wird von eTLD+1 abgeleitet und muss nicht explizit angegeben werden. Sie kann nicht durch die Updateantwort geändert werden. Die GET-Anfrage erwartet ein JSON-Objekt, das eine Liste von customAudience-Objekten enthält.
  • DelayTime: Zeit, die die Verzögerung ab dem Zeitpunkt des scheduleCustomAudienceUpdate() API-Aufrufs zum Planen der Aktualisierung angibt.

  • PartialCustomAudience: Mit der API kann das On-Device-SDK auch eine Liste unvollständiger benutzerdefinierter Zielgruppen senden. Dadurch können die In-App-SDKs die doppelte Rolle übernehmen, von der vollständigen bis hin zur teilweisen Kontrolle über die Verwaltung benutzerdefinierter Zielgruppen, die auf ihrer Partnerschaft mit DSPs basieren.

    • Dadurch bleibt die API auch mit der fetchAndJoinCustomAudience() API kompatibel, die einen ähnlichen Informationsaustausch ermöglicht.

App-Berechtigungen und ‐Einstellungen

Das Angebot soll Apps mehr Kontrolle über die benutzerdefinierten Zielgruppen geben:

  • Eine App kann ihre Verknüpfungen mit benutzerdefinierten Zielgruppen verwalten.
  • Über eine App können Anzeigentechnologie-Plattformen von Drittanbietern Berechtigungen zum Verwalten benutzerdefinierter Zielgruppen erteilt werden.

Das Design dieser Funktion ist noch in der Entwicklung. Die Details werden in einer späteren Aktualisierung enthalten sein.

Steuerung der Anzeigentechnologie-Plattform

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

  • Sie 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 verifiziert wird. 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 in seinem Namen deaktivieren und nur der fetchAndJoinCustomAudience API erlauben, alle benutzerdefinierten Aufrufzielgruppen zu aktivieren. Die Einstellung kann während der Registrierung für die Privacy Sandbox aktualisiert werden. Mit dem Steuerelement können Sie entweder alle oder keine Anzeigentechnologien zulassen. Aufgrund von Plattformeinschränkungen können Berechtigungen zur Delegierung nicht auf Anzeigentechnologiebasis gewährt werden.

Antwort auf mögliche Anzeigen und Metadaten

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

  • Metadaten: Anzeigentechnologie-spezifische Metadaten für Käufer. Dazu können beispielsweise Informationen zur Werbekampagne und Ausrichtungskriterien wie Standort und Sprache gehören.
  • Render-URL:Endpunkt für das Rendering des Anzeigen-Creatives.
  • Filter:Optionale Informationen, die erforderlich sind, damit die Protected Audience API Anzeigen anhand von Gerätedaten filtern kann. Weitere Informationen finden Sie im Abschnitt zur Filterlogik für Käufer.

Workflow für die Anzeigenauswahl

Ziel dieses Vorschlags ist es, den Datenschutz zu verbessern. Dazu wird die Ad Selection API eingeführt, die die Auktionsausführung für AdTech-Plattformen koordiniert.

AdTech-Plattformen führen Gebote und Anzeigenauswahl heute in der Regel ausschließlich auf ihren Servern aus. Bei diesem Angebot kann auf benutzerdefinierte Zielgruppen und andere vertrauliche Nutzersignale (z. B. Informationen zu installierten Paketen) nur über die Ad Selection API zugegriffen werden. Außerdem werden im Remarketing-Anwendungsfall die Anzeigenkandidaten außerhalb des zulässigen Bereichs abgerufen, d.h. nicht in dem Kontext, in dem die Anzeigen zu sehen sind. AdTech-Plattformen müssen sich darauf vorbereiten, einige Teile ihrer aktuellen Auktions- und Anzeigenauswahllogik auf dem Gerät bereitzustellen und auszuführen. Anzeigentechnologie-Plattformen können folgende Änderungen an ihrem Workflow für die Anzeigenauswahl in Betracht ziehen:

  • Wenn keine Informationen zu installierten Paketen auf dem Server verfügbar sind, möchten Anzeigentechnologie-Plattformen unter Umständen mehrere kontextbezogene Anzeigen an das Gerät zurücksenden und den Workflow für die Anzeigenauswahl aufrufen, um die Filterung auf der Grundlage von App-Installationen zu aktivieren und so die Chancen für die Auslieferung einer relevanten Anzeige zu maximieren.
  • Da Remarketing-Anzeigen außerhalb des Bereichs abgerufen werden, müssen aktuelle Gebotsmodelle möglicherweise aktualisiert werden. Anzeigentechnologie-Plattformen möchten eventuell Untermodelle für Gebote erstellen. Die Implementierung basiert dabei möglicherweise auf einem sogenannten Zwei-Turm-Modell. Diese können Anzeigenfunktionen und Kontextsignale separat verarbeiten und die Ausgaben des Untermodells auf dem Gerät kombinieren, um Gebote vorherzusagen. Dies kann sowohl von serverseitigen Auktionen als auch von Auktionen für eine bestimmte Werbechance profitieren.

So können die Daten zu den App-Interaktionen des Nutzers als Grundlage für die Anzeigenauswahl dienen und gleichzeitig die Weitergabe dieser Daten an Dritte eingeschränkt werden.

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

Bei diesem Workflow für die Anzeigenauswahl wird die Ausführung von JavaScript-Code, der von der Anzeigentechnologie bereitgestellt wird, auf dem Gerät anhand der folgenden Reihenfolge orchestriert:

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

Bei Anzeigenauswahl, die benutzerdefinierte Zielgruppen umfassen, ruft die Plattform von Käufern bereitgestellter JavaScript-Code anhand des öffentlichen URL-Endpunkts ab, der in den Metadaten der benutzerdefinierten Zielgruppe für die Gebotslogik definiert ist. Der URL-Endpunkt für den verkäuferseitigen Entscheidungscode wird ebenfalls als Eingabe zum Initiieren des Anzeigenauswahl-Workflows übergeben.

Die Anzeigenauswahl, die keine benutzerdefinierten Zielgruppen umfasst, befindet sich noch im aktiven Design.

Workflow für Anzeigenauswahl initiieren

Wenn eine Anzeige in einer App ausgeliefert werden muss, kann das SDK der Anzeigentechnologie-Plattform den Workflow für die Anzeigenauswahl initiieren, indem es die selectAds()-Methode aufruft, nachdem das AdSelectionConfig-Objekt mit den erwarteten Parametern instanziiert wurde:

  • Verkäufer: Kennung für die verkäuferseitige Werbeplattform im Format eTLD+1
  • URL der Entscheidungslogik: Wenn eine Anzeigenauktion initiiert wird, ruft die Plattform über diese URL JavaScript-Code von der Sell-Side-Plattform ab, um eine erfolgreiche Anzeige zu bewerten.
  • Käufer von benutzerdefinierten Zielgruppen: Eine Liste von Plattformen auf Käuferseite mit benutzerdefinierter zielgruppenbasierter Nachfrage für diese Auktion im Format eTLD+1.
  • Signale für die Anzeigenauswahl: Informationen zur Auktion (Anzeigengröße, Anzeigenformat usw.).
  • Verkäufersignale: Stellen Sie plattformspezifische Signale bereit.
  • URL für vertrauenswürdige Scoring-Signale: URL-Endpunkt des vertrauenswürdigen Signals auf Verkäuferseite, von dem Creative-spezifische Echtzeitinformationen abgerufen werden können.
  • Signale pro Käufer: Teilnehmende Demand-Side-Plattformen können diesen Parameter verwenden, um Eingaben für die Auktion bereitzustellen. Dieser Parameter kann beispielsweise umfassende Kontextinformationen enthalten, die für die Bestimmung von Geboten hilfreich sind.

Das folgende Code-Snippet zur Veranschaulichung zeigt ein SDK der Anzeigentechnologie-Plattform, das den Workflow für die Anzeigenauswahl initiiert, indem zuerst AdSelectionConfig definiert und dann selectAds aufgerufen wird, um die erfolgreiche Anzeige abzurufen:

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. Mit dem Code werden Gebote für mögliche Anzeigen festgelegt. Es kann zusätzliche Geschäftslogik angewendet werden, um das Ergebnis zu bestimmen.

Die Plattform ruft den JavaScript-Code mit den Metadaten der benutzerdefinierten Zielgruppe für die Gebotslogik ab, der die folgende Funktionssignatur enthalten sollte:

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 nacheinander für alle Anzeigen (kontext- oder Remarketing-Anzeigen) auf. Wenn es mehrere Anbieter für die Gebotslogik gibt, garantiert das System nicht die Ausführungssequenz unter den Anbietern.

Die Funktion erwartet die folgenden Parameter:

  • Anzeige: Die Anzeige, die vom Gebotscode auf Käuferseite berücksichtigt wird. Dies ist eine Anzeige einer geeigneten benutzerdefinierten Zielgruppe
  • Auktionssignale: Plattformspezifische Signale auf Verkäuferseite.
  • Signale pro Käufer: Teilnehmende Demand-Side-Plattformen können diesen Parameter verwenden, um Eingaben für die Auktion bereitzustellen. Dieser Parameter kann beispielsweise umfassende Kontextinformationen enthalten, die für die Bestimmung von Geboten hilfreich sind.
  • Vertrauenswürdige Gebotssignale: AdTech-Plattformen nutzen Echtzeitdaten, um Anzeigen abzurufen und zu bewerten. Das ist beispielsweise der Fall, wenn das Budget einer Werbekampagne aufgebraucht ist und die Auslieferung sofort beendet werden muss. Eine Anzeigentechnologie kann einen URL-Endpunkt definieren, von dem aus diese Echtzeitdaten abgerufen werden können, sowie den Schlüsselsatz, für den die Echtzeitsuche durchgeführt werden muss. Der verwaltete Server der AdTech-Plattform, der diese Anfrage verarbeitet, ist ein vertrauenswürdiger Server, der von der AdTech-Plattform verwaltet wird.
  • Kontextsignale: Hierzu gehören ein vergröberter Zeitstempel, Informationen zum ungefähren Standort oder der Cost-per-Click auf die Anzeige.
  • Nutzersignale: Dazu können Informationen wie verfügbare Informationen zu installierten Paketen gehören.

Werbekosten

Neben dem 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 im Impressionsbericht in reportWin an den Parameter contextual_signals übergeben.

Filterlogik auf Käuferseite

Plattformen auf Käuferseite können Anzeigen dann anhand der während der Anzeigenauswahl verfügbaren zusätzlichen On-Device-Signale filtern. Beispielsweise können AdTech-Plattformen hier Frequency Capping-Funktionen implementieren. Wenn es mehrere Filteranbieter gibt, garantiert das System nicht, dass die Ausführungsreihenfolge zwischen den Anbietern erfolgt.

Die käuferseitige Filterlogik kann als Teil der Gebotslogik implementiert werden, indem der Gebotswert 0 für eine bestimmte Anzeige zurückgegeben wird.

Darüber hinaus können Plattformen auf Käuferseite signalisieren, dass eine bestimmte Anzeige basierend auf zusätzlichen On-Device-Signalen gefiltert werden sollte, die der Protected Audience API zur Verfügung stehen und die das Gerät nicht verlassen. Wenn wir das Design einer zusätzlichen Filterlogik vereinheitlicht haben, folgen Buy-Side-Plattformen dieser Struktur, um zu signalisieren, dass die Filterung ausgeführt werden soll.

Bewertungslogik auf Verkäuferseite

Die Bewertungslogik wird in der Regel von der Sell-Side-Plattform bereitgestellt. Der Code dient dazu, anhand der Ausgaben der Gebotslogik eine erfolgreiche Anzeige zu ermitteln. Es kann zusätzliche Geschäftslogik anwenden, um das Ergebnis zu bestimmen. Wenn es mehrere Anbieter von Entscheidungslogik gibt, garantiert das System nicht die Ausführungsreihenfolge zwischen den Anbietern. Die Plattform verwendet den Eingabeparameter „URL für die Entscheidungslogik“ der selectAds() API, um den JavaScript-Code abzurufen. Dieser sollte die folgende Funktionssignatur enthalten:

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 Anzeige, die ausgewertet wird; Ausgabe der Funktion generateBid().
  • Bid (Gebot): Der von der Funktion generateBid() ausgegebene Gebotsbetrag
  • Auktionskonfiguration: Eingabeparameter für die Methode selectAds().
  • Vertrauenswürdige Bewertungssignale: Anzeigentechnologie-Plattformen nutzen Echtzeitdaten für die Anzeigenfilterung und -bewertung. Beispielsweise kann ein App-Publisher eine Werbekampagne blockieren, sodass keine Anzeigen in der App ausgeliefert werden. Diese Daten werden aus dem URL-Parameter „Vertrauenswürdige Bewertungssignale“ der Auktionskonfiguration abgerufen. Der Server, auf dem diese Anfrage verarbeitet wird, sollte ein von AdTech verwalteten vertrauenswürdigen Server sein.
  • Kontextsignal: Dabei kann es sich um einen vergröberten Zeitstempel oder ungefähre Standortinformationen handeln.
  • Nutzersignal: Dazu können Informationen wie der App-Shop gehören, über den die Installation der App initiiert wurde.
  • Benutzerdefiniertes Zielgruppensignal: Wenn die bewertete Anzeige von einer benutzerdefinierten Zielgruppe auf dem Gerät stammt, enthält diese Informationen wie den Leser und den Namen der benutzerdefinierten Zielgruppe.

Laufzeit des Anzeigenauswahlcodes

Im Rahmen des Vorschlags ruft das System den vom Anzeigentechnologie-Plattform bereitgestellten Auktionscode von konfigurierbaren URL-Endpunkten ab und wird auf dem Gerät ausgeführt. Angesichts 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 Bindung gilt einheitlich für alle Werbenetzwerke von Käufern. Details zu dieser Grenze erhalten Sie in einer späteren Aktualisierung.
  • Der Code muss eigenständig 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 Plattform bereitgestellte Auktionscode muss in JavaScript geschrieben sein. So können Anzeigentechnologie-Plattformen beispielsweise Gebotscode mit Plattformen teilen, die die Privacy Sandbox unterstützen.

Rendering der erfolgreichen Anzeige

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

Die Lösung soll weiterentwickelt werden, damit Informationen zur benutzerdefinierten Zielgruppenzugehörigkeit oder zum Verlauf der App-Interaktionen von der App oder dem SDK nicht anhand der Informationen zur erfolgreichen Anzeige ermittelt werden können (ähnlich wie beim Fencing-Frame-Angebot von Chrome).

Berichte zu Impressionen und Ereignissen

Sobald die Anzeige gerendert wurde, kann die erfolgreiche Impression den teilnehmenden Buy-Side- und Sell-Side-Plattformen gemeldet werden. So können Käufer und Verkäufer Informationen aus der Auktion in den Bericht zu den erfolgreichen Impressionen aufnehmen, etwa das Gebot oder den Namen der benutzerdefinierten Zielgruppe. Darüber hinaus können sowohl die Sell-Side- als auch die erfolgreiche Buy-Side-Plattform zusätzliche Berichte auf Ereignisebene zur erfolgreichen Anzeige erhalten. So können Sie Informationen zur Auktion (Gebot, Name der benutzerdefinierten Zielgruppe usw.) mit Klicks, Aufrufen und anderen Anzeigenereignissen hinzufügen. Die Plattform ruft die Berichterstellungslogik in dieser Reihenfolge auf:

  1. Sell-Side-Berichte.
  2. Berichte auf Käuferseite

Dadurch können Plattformen für Käufer und Verkäufer wichtige Geräteinformationen an die Server zurücksenden, um Funktionen wie die Budgetplanung in Echtzeit, Aktualisierungen des Gebotsmodells und genaue Abrechnungs-Workflows zu ermöglichen. Diese Unterstützung für Berichte zu Impressionen ist eine Ergänzung der Attribution Reporting API.

Für die Unterstützung von Ereignisberichten sind zwei Schritte erforderlich: Beim JavaScript auf Verkäuferseite und auf Käuferseite muss registriert werden, für welches Ereignis Ereignisberichte gesendet werden sollen. Die Seite auf Verkäuferseite ist für die Berichterstellung zu Informationen auf Ereignisebene zuständig.

Protected Audience bietet einen Mechanismus, um zukünftige Ereignisse im Zusammenhang mit einer erfolgreichen Auktion zu abonnieren, indem Beacons registriert werden. In der reportResult()-JavaScript-Funktion eines Verkäufers können Sell-Side-Plattformen Beacons über die registerAdBeacon()-Funktion der Plattform registrieren. Ebenso 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 die Registrierung erfolgen soll. Er wird als Schlüssel verwendet, um den Endpunkt zu ermitteln, den die Plattform anpingt, während die Ergebnisse der Auktion gemeldet werden.
  • reporting_url: Die URL der Anzeigentechnologie-Plattform, auf der das Ereignis verarbeitet wird.

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

Berichte auf Verkäuferseite

Die Plattform ruft die JavaScript-Funktion reportResult() im 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 reportWin-Funktion des Käufers übergeben wird.

Die Supply-Seite kann relevante Signale in der Berichts-URL codieren, um weitere Einblicke in die Auktion und die erfolgreiche Anzeige zu gewinnen. Sie kann beispielsweise folgende Signale enthalten:

  • Rendering-URL der Anzeige
  • Betrag des erfolgreichen Gebots
  • App-Name
  • Abfrage-IDs
  • Signale für Käufer: Um die Datenfreigabe zwischen Angebotsseite und 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 von der Nachfrage bereitgestellten Code auf, der aus den Metadaten der Gebotslogik-URL der benutzerdefinierten Zielgruppe heruntergeladen wird, die mit der Auktion verknüpft ist.

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 Plattform auf Käuferseite an die Berichts-URL übergeben muss, können aus diesem Bezugssystem stammen.
  • signals_for_buyer ist die Ausgabe des Berichtsergebnisses auf Verkäuferseite. Dadurch hat die Sell-Side-Plattform die Möglichkeit, Daten zu Berichtszwecken mit der Buy-Side-Plattform 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 können erst erfasst werden, nachdem die Impressionsberichte für die Auktion abgeschlossen wurden. Das SDK auf Verkäuferseite ist für die Berichterstellung zu Ereignissen zuständig. Die Plattform stellt eine API zur Verfügung, die eine ReportEventRequest verwendet, die die kürzlich 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, sowie ein optionales Eingabeereignis für Anzeigenereignisse angibt. Der Client definiert den Ereignisschlüssel und die Sammlung der zu meldenden Daten.

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 ausgeführten Auktion sein, die aus der AdSelectionOutcome abgerufen wurde.
  • event_key ist ein auf Verkäuferseite definierter String, der das Interaktionsereignis beschreibt.
  • event_data ist ein String, der die mit event_key verknüpften Daten darstellt.
  • reporting_destinations ist eine Bitmaske, die mit Flags der Plattform festgelegt wird. Er kann FLAG_REPORTING_DESTINATION_SELLER, FLAG_REPORTING_DESTINATION_BUYER oder beides sein.
  • input_event (optional) wird für die Einbindung in die Attribution Reporting API verwendet. Es handelt sich entweder um ein InputEvent-Objekt (für ein Klickereignis) oder um null (für ein Ansichtsereignis). Weitere Informationen zu diesem Parameter finden Sie unter Integration der Attribution Reporting API.

Nachdem das Sell-Side-SDK reportEvent aufgerufen hat und abhängig vom Flag reporting_destinations versucht die Plattform, event_key mit den Schlüsseln abzugleichen, die von Käufern und Verkäufern in den JavaScript-Funktionen reportWin und reportResult registriert wurden. Wenn es eine Übereinstimmung gibt, sendet die Plattform die event_data an die verknüpfte reporting_url. Der Inhaltstyp der Anfrage ist Nur-Text, wobei der Text der event_data ist. Diese Anfrage wird so gut wie möglich ausgeführt und schlägt im Fall eines Netzwerkfehlers, einer Serverfehlerantwort oder wenn keine passenden Schlüssel gefunden wurden, ohne Meldung fehl.

Integration der Attribution Reporting API

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

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

  • Erstellen Sie eine Schlüssel/Wert-Zuordnung mit URIs, die für Berichte zu Anzeigeninteraktionen und 2) zur Registrierung der Quelle verwendet werden soll.
  • Auktionsdaten aus der Protected Audience-Auktion in die quellseitige Schlüsselzuordnung für aggregierte zusammenfassende Berichte über die Attribution Reporting API einbeziehen. Weitere Informationen finden Sie im Vorschlag für das ARA-Design.

Wenn ein Nutzer eine Anzeige sieht oder darauf klickt:

  • Die URL, über die diese Ereignisinteraktionen mit Protected Audience gemeldet werden, stellt dem Käufer die erforderlichen Daten zur Verfügung, um eine Datenansicht oder einen Klick als zulässige Quelle mit der Attribution Reporting API zu registrieren.
  • Der Anzeigentechnologie-Anbieter kann CustomAudience oder andere relevante Kontextinformationen zur Anzeige (z. B. das Anzeigen-Placement oder die Wiedergabedauer) über diese URL übergeben, sodass diese Metadaten in zusammenfassenden Berichten weitergegeben werden können, wenn er 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 über die Attribution Reporting APIs als registrierte Quelle registriert werden. Der Anfrageheader „Attribution-Reporting-berechtigte“ wird allen Anfragen zu Ereignisberichten hinzugefügt, die über reportEvent() gesendet werden. Alle Antworten mit entsprechenden ARA-Headern werden auf dieselbe Weise geparst wie jede andere reguläre ARA-Quellenregistrierungsantwort. Informationen zum Registrieren einer Quell-URL finden Sie in der Erläuterung zur Attribution Reporting API.

Da ARA unter Android View- und Click-Events unterstützt, wird InputEvents verwendet, um zwischen den beiden Typen zu unterscheiden. Genau wie bei der ARA-Quellenregistrierung interpretiert die reportEvent() API ein von der Plattform bestätigtes InputEvent als Klickereignis. Wenn InputEvent fehlt, null oder ungültig ist, wird die Quellenregistrierung als Ansicht betrachtet.

Beachten Sie, dass das eventData nach der Auktion möglicherweise vertrauliche Informationen enthält. Daher entfernt die Plattform die eventData in weitergeleiteten Quellregistrierungsanfragen.

Beispiel für Berichte zu Interaktionen und Conversions

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

Dabei sendet der Käufer in Absprache mit dem Verkäufer eine eindeutige ID an die Auktion. Während der Auktion sendet der Käufer diese eindeutige ID zusammen mit den Auktionsdaten. Während des Rendering- und Conversion-Zeitraums werden die Daten der gerenderten Anzeige ebenfalls mit derselben eindeutigen ID gesendet. Später können diese Berichte mithilfe der eindeutigen ID verknüpft werden.

Workflow: Vor Beginn der Auktion sendet der Käufer im Rahmen seiner programmatischen Gebotsantwort für Echtzeitgebote eine eindeutige ID an den Verkäufer. Die ID kann als Variable wie auctionId festgelegt werden. Die ID wird als perBuyerSignals in die auctionConfig übergeben und ist in der Gebotslogik des Käufers verfügbar.

  1. Während 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. Wenn Sie Auktionssignale für ein Anzeigenereignis zuordnen möchten, legen Sie den auctionId als Abfrageparameter der Beacon-URL fest.
  2. Während des Anzeigen-Renderings können die Beacons, die Sie während der Auktion registriert haben, ausgelöst oder mit Daten auf Ereignisebene 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 für Anzeigen an, die der ausgelösten reportEvent() entspricht.
  3. Der Käufer registriert die Anzeige bei der Attribution Reporting API, indem er auf die 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 zum Registrieren der Quell-URL den auctionId fest.

Nach dem oben beschriebenen Vorgang hat der Käufer einen Auktionsbericht, einen Interaktions- und einen Conversion-Bericht, die mithilfe der eindeutigen ID, die miteinander verknüpft werden kann, 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 Aufruf reportEvent() 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

Bei der Anzeigenauswahl sind derzeit Echtzeitinformationen wie der Status des aufgebrauchten Budgets erforderlich, um zu ermitteln, ob Anzeigenkandidaten für die Auktion ausgewählt werden sollen. Sowohl Plattformen für Käufer als auch für Sell-Side-Plattformen können diese Informationen von den Servern abrufen, die sie betreiben. Um den Datenleck über diese Server zu minimieren, sieht das Angebot folgende Einschränkungen vor:

  • Beim Verhalten dieser Server, das weiter unten in diesem Abschnitt beschrieben wird, werden keine Nutzerinformationen verloren.
  • Die Server würden keine pseudonymisierten Profile auf der Grundlage der angezeigten Daten erstellen, d.h., sie müssen als „vertrauenswürdig“ eingestuft werden.

Käufer: Sobald die Käuferseite die Gebotslogik auf der Käuferseite initiiert, führt die Plattform einen HTTP-Abruf der Daten zu vertrauenswürdigen Geboten vom vertrauenswürdigen Server durch. Dazu werden die URL und die Schlüssel in den Metadaten der Trusted Bidding-Signale der verarbeiteten benutzerdefinierten Zielgruppe angehängt. Dieser Abruf erfolgt nur bei der Verarbeitung von Anzeigen aus den benutzerdefinierten Zielgruppen auf dem Gerät. In dieser Phase kann die Käuferseite Budgets erzwingen, den Status der Kampagne zum Pausieren / Fortsetzen der Kampagne prüfen, Ausrichtungen vornehmen usw.

Mit der folgenden Beispiel-URL können Sie vertrauenswürdige Gebotsdaten abrufen, die auf den Metadaten von Trusted Bidding-Signalen aus der benutzerdefinierten Zielgruppe basieren:

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

Die Antwort vom Server sollte ein JSON-Objekt sein, dessen Schlüssel z. B. key1 oder key2 sind und dessen Werte den Gebotsfunktionen des Käufers zur Verfügung gestellt werden.

Sell-Side: Ähnlich wie beim oben beschriebenen Ablauf auf der Käuferseite möchte die Verkäuferseite möglicherweise Informationen zu Creatives abrufen, die in der Auktion berücksichtigt werden. Beispielsweise kann ein Publisher aus Gründen der Markensicherheit erzwingen, dass bestimmte Creatives nicht in seiner App ausgeliefert werden. Diese Informationen können abgerufen und der Auktionslogik auf Verkäuferseite zur Verfügung gestellt werden. Ähnlich wie bei der Suche auf Käuferseite über einen vertrauenswürdigen Server erfolgt die Suche auf Verkäuferseite auch über einen HTTP-Abruf. Die URL setzt sich zusammen, indem der URL für Trusted-Scoring-Signale die Rendering-URLs der Creatives angehängt werden, für die die Daten abgerufen werden müssen.

Mit der folgenden Beispiel-URL können Sie Informationen zu Creatives abrufen, die in der Auktion berücksichtigt werden. Diese Informationen basieren 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 arbeiten vertrauenswürdig und bieten mehrere Vorteile in Bezug auf Sicherheit und Datenschutz:

  • Es ist vertrauenswürdig, dass der Rückgabewert des Servers für jeden Schlüssel nur auf diesem Schlüssel basiert.
  • Der Server führt kein Logging auf Ereignisebene durch.
  • Der Server hat keine weiteren Nebenwirkungen, die auf diesen Anfragen basieren.

Käufer und Verkäufer können diese Gebotssignale vorübergehend von jedem Server abrufen, auch von einem selbst betriebenen Server. In der Release-Version wird die Anfrage jedoch nur an einen vertrauenswürdigen Server mit Schlüssel/Wert-Paar-Typ 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 für Android und im Web kompatibel sind.