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

Letzte Updates

• Informationen zum Planen von Aktualisierungen für benutzerdefinierte Zielgruppen hinzugefügt
• Einbindung von Attributionsberichten in Protected Audience wurde hinzugefügt.
• Wir haben einen Zeitplan für die Funktionen von Protected Audience veröffentlicht.
• FLEDGE wurde in Protected Audience API umbenannt.
• Vorschlag für die Delegierung von benutzerdefinierten Zielgruppen hinzugefügt.
• Die Anforderung der k-Anonymität für die tägliche Aktualisierung wurde entfernt. URL:

Protected Audience befindet sich in der Betaphase und kann auf öffentlichen Geräten getestet werden.

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.
• Impressionsberichte nach der Anzeigenauswahl erstellen

Lesen Sie zuerst den Entwicklerleitfaden zu Protected Audience. Wir freuen uns über Ihr Feedback, damit wir Protected Audience weiter verbessern können.

Zeitachse

Wir werden in den kommenden Monaten neue Funktionen veröffentlichen. Die genauen Veröffentlichungstermine variieren je nach Funktion. Diese Tabelle wird mit Links zu Dokumentationen aktualisiert, sobald sie verfügbar sind.

Übersicht

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

Heutzutage werden diese Anwendungsfälle in der Regel durch die Freigabe kontextbezogener Daten Informationen dazu, wie die Anzeige eingeblendet wird (z. B. der Name der App) und privat wie Zielgruppenlisten mit Anzeigentechnologie-Plattformen. Anhand dieser Informationen können Werbetreibende auf ihren Servern relevante Anzeigen auswählen.

Die Protected Audience API auf Android (früher FLEDGE) umfasst die folgenden APIs für AdTech-Plattformen und Werbetreibende, um gängige interaktionsbasierte Anwendungsfälle zu unterstützen. Dabei wird die Weitergabe von IDs zwischen Apps und die Weitergabe von Informationen zu App-Interaktionen von Nutzern an Dritte eingeschränkt:

1. Custom Audience API: Diese API basiert auf der Abstraktion „benutzerdefinierte Zielgruppe“, die eine vom Werbetreibenden festgelegte Zielgruppe mit gemeinsamen Absichten darstellt. Zielgruppeninformationen werden auf dem Gerät können mit relevanten Anzeigen für die Zielgruppe und willkürlich Metadaten wie Gebotssignale. Die Informationen können verwendet werden, Werbetreibenden-Gebote, Anzeigenfilterung und -rendering.
2. Ad Selection API: Diese API bietet ein Framework, AdTech-Plattformen orchestriert Workflows nutzen, um anhand von On-Device-Signalen einen „siegenden“ Anzeige unter Berücksichtigung der lokal gespeicherten potenziellen Anzeigen und Zusätzliche Verarbeitung möglicher Anzeigen, die eine AdTech-Plattform an das Gerät zurück.

Die Integration funktioniert im Groben so:

1. SportingGoodsApp möchte seine Nutzer daran erinnern, Artikel zu kaufen, die noch in ihrem Einkaufswagen liegen, wenn sie den Kauf nicht innerhalb von zwei Tagen abgeschlossen haben. SportingGoodsApp verwendet die Custom Audience API, um den Nutzer zur „Produkte im Einkaufswagen“ Zielgruppenliste hinzu. Die Plattform verwaltet und speichert diese Zielgruppenliste auf dem Gerät und schränkt die Weitergabe an Dritte ein. SportingGoodsApp arbeitet mit einer Anzeigentechnologie-Plattform zusammen, um Nutzern Anzeigen zu präsentieren in der Zielgruppenliste. Die Anzeigentechnologie-Plattform verwaltet Metadaten für Zielgruppenlisten und stellt Anzeigenvorschläge bereit, die für den Workflow zur Anzeigenauswahl zur Verfügung gestellt werden. Die Plattform kann so konfiguriert werden, dass regelmäßig aktualisierte, auf Zielgruppen basierende Anzeigen im Hintergrund abgerufen werden. So bleibt die Liste der passenden Zielgruppen-Anzeigen immer auf dem neuesten Stand und nicht korreliert mit Anfragen, die während der Anzeigenbereitstellung an Ad-Server von Drittanbietern gesendet werden (d. h. Anfragen für kontextbezogene Anzeigen).

2. Wenn der Nutzer das FrisbeeGame auf demselben Gerät spielt, sieht er möglicherweise eine Anzeige. Erinnert sie daran, den Kauf der Artikel abzuschließen, die im Einkaufswagen. Dies ist mit FrisbeeGame (mit integrierten Anzeigen SDK), um die Ad Selection API aufzurufen, um eine erfolgreiche Anzeige auszuwählen basierend auf der Zielgruppenliste, zu der er gehört (in dieser „Produkte im Warenkorb“ von SportingGoodsApp erstellte benutzerdefinierte Zielgruppe). Der Anzeigenauswahl-Workflow kann so eingerichtet werden, dass aus der Anzeige abgerufene Anzeigen berücksichtigt werden. Technologieplattformen zusätzlich zu den mit dem benutzerdefinierte Zielgruppen und andere On-Device-Signale. Der Workflow kann auch AdTech-Plattform und Ads SDK mit benutzerdefinierten Geboten und Bewertungslogik zum Erreichen geeigneter Werbeziele Dieser Ansatz ermöglicht es, Daten zu Interessen oder App-Interaktionen, um die Anzeigenauswahl zu verbessern, während die Weitergabe dieser Daten an Dritte einzuschränken.

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

4. Die Plattform ermöglicht Berichte zu Impressionen und Anzeigenauswahl. Ergebnisse. Diese Berichtfunktion ist als Ergänzung zu den Attributionsberichten API hinzu. Anzeigentechnologie-Plattformen können an ihre Berichtsanforderungen anzupassen.

Zugriff auf Protected Audience über Android APIs erhalten

Anbieter von Anzeigentechnologien müssen sich registrieren, um auf die Protected Audience API zugreifen zu können. Weitere Informationen finden Sie unter Privacy Sandbox-Konto registrieren.

Benutzerdefinierte Zielgruppenverwaltung

Benutzerdefinierte Zielgruppe

Eine benutzerdefinierte Zielgruppe ist eine vom Werbetreibenden festgelegte Gruppe von Nutzern mit gemeinsamen Absichten oder Interessen. In einer App oder einem SDK kann eine benutzerdefinierte Zielgruppe verwendet werden, um eine bestimmte Zielgruppe anzugeben, z. B. Nutzer, die „Artikel im Einkaufswagen gelassen“ oder „die Anfängerlevel eines Spiels abgeschlossen“ haben. Die Plattform verwaltet und speichert Zielgruppeninformationen lokal auf dem Gerät und gibt nicht preis, zu welchen benutzerdefinierten Zielgruppen der Nutzer gehört. Benutzerdefinierte Zielgruppen unterscheiden sich Protected Audience-Interessengruppen von Chrome und können nicht freigegeben werden im Web und in Apps. Dadurch wird die Freigabe von Nutzerinformationen eingeschränkt.

Eine App eines Werbetreibenden oder das integrierte SDK kann eine benutzerdefinierte Zielgruppe beitreten oder verlassen, z. B. basierend auf dem Nutzer-Engagement in einer App.

Metadaten für benutzerdefinierte Zielgruppen

Jede benutzerdefinierte Zielgruppe enthält die folgenden Metadaten:

• Owner: Paketname der Eigentümer-App. Dieser wird implizit auf den Paketnamen der aufrufenden App festgelegt.
• Käufer: Käufernetzwerk, das Anzeigen für diese benutzerdefinierte Zielgruppe verwaltet. Der Käufer repräsentiert auch die Partei, die auf die benutzerdefinierte Zielgruppe zugreifen und relevante Anzeigeninformationen. Der Käufer wird im Format „eTLD+1“ 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 einen Abfragestring in der URL, um des Gebots-Codes.
• Aktivierungszeit und Ablaufzeit: In diesen Feldern wird der Zeitraum definiert, in dem diese benutzerdefinierte Zielgruppe aktiv ist. Die Plattform nutzt diese um die Mitgliedschaft für eine benutzerdefinierte Zielgruppe zu widerrufen. Die Gültigkeitsdauer darf ein maximales Zeitfenster nicht überschreiten, um die Lebensdauer einer benutzerdefinierten Zielgruppe zu begrenzen.
• URL für die tägliche Aktualisierung: Die URL, über die die Plattform fortlaufend Anzeigenvorschläge und andere Metadaten abruft, die in den Feldern „Signale für Gebote von Nutzern“ und „Signale für vertrauenswürdige Gebote“ definiert sind. Weitere Informationen finden Sie im Abschnitt zum Abrufen von Anzeigenvorschlägen für benutzerdefinierte Zielgruppen.
• Signale für Gebote von Nutzern: Plattformspezifische Signale für Anzeigentechnologien für Gebote für Remarketing-Anzeigen. Beispiele für Signale sind die ungefähre Position des Nutzers und die bevorzugte Sprache.
• Vertrauenswürdige Gebotsdaten: AdTech-Plattformen nutzen Echtzeitdaten, um die Anzeigenabruf- und -bewertung zu optimieren. Beispiel: Das Budget für eine Anzeige ist aufgebraucht. und muss sofort beendet werden. Eine Ad-Tech-Plattform kann einen URL-Endpunkt definieren, von dem diese Echtzeitdaten abgerufen werden können, und die Schlüssel, für die 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 der Gebotslogik: Die URL, über die die Plattform Gebotscode von der Demand-Side-Plattform abruft. Die Plattform führt diesen Schritt aus, wenn Anzeigenauktion initiiert wird.
• Anzeigen: Eine Liste der Anzeigen, die für die benutzerdefinierte Zielgruppe infrage kommen. Dazu gehören plattformspezifische Anzeigenmetadaten und eine URL zum Rendern der Anzeige. Wenn ein für die benutzerdefinierte Zielgruppe eingeleitet wird, wird diese Liste mit Anzeigenmetadaten berücksichtigt. Diese Anzeigenliste wird anhand der URL für die tägliche Aktualisierung aktualisiert. Endpunkt, wenn möglich. Aufgrund von Ressourcenknappheit auf Mobilgeräten gibt es Eine Beschränkung der Anzahl von Anzeigen, die in einer benutzerdefinierten Zielgruppe gespeichert werden können.

Benutzerdefinierte Zielgruppendelegierung

Die traditionelle Definition und Konfiguration benutzerdefinierter Zielgruppen basiert in der Regel auf serverseitigen Technologien und Integrationen, die von Anzeigentechnologien in Zusammenarbeit mit Agentur- und Werbetreibenden-Kunden und -Partnern bereitgestellt werden. Die Protected Audience API ermöglicht benutzerdefinierte Zielgruppen definieren und konfigurieren und gleichzeitig die Privatsphäre der Nutzer schützen. Bis einer benutzerdefinierten Zielgruppe beitreten, Anzeigentechnologie-Anbieter für Käufer, die kein SDK in Apps haben müssen mit Anzeigentechnologie-Anbietern zusammenarbeiten, die eine On-Device-Präsenz betreiben, Analysepartnern (MMPs) und Supply-Side-Plattformen (SSPs). Die Protected Audience API soll diese SDKs unterstützen, indem sie flexible Lösungen für die Verwaltung benutzerdefinierter Zielgruppen bietet. So können On-Device-Caller im Namen von Käufern benutzerdefinierte Zielgruppen erstellen. Dieses Verfahren wird als benutzerdefinierte Zielgruppe Delegierung. So konfigurieren Sie die Deaktivierung benutzerdefinierter 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 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 AdTech-Anbieters den Beitritt zu einer benutzerdefinierten Zielgruppe anfordern, nicht auf dem Gerät vorhanden ist, indem fetchAndJoinCustomAudience() aufgerufen wird mit den erwarteten Parametern, wie im folgenden Beispiel:

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 einer CustomAudience-JSON-Datei im Antworttext ein. Die Felder „Käufer“ und „Inhaber“ der benutzerdefinierten Zielgruppe sind ignoriert (und von der API automatisch ausgefüllt). Außerdem wird durch die API erzwungen, dass die URL für die tägliche Aktualisierung 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 Identität des CustomAudience-Käufers wird verwendet, um dieselben Registrierungs- und App-Autorisierungsüberprüfungen durchzuführen, die auch von joinCustomAudience() durchgeführt werden. Sie kann nicht durch die Abrufantwort geändert werden. Der Inhaber von CustomAudience ist der Paketname der aufrufenden Anwendung. Für fetchUri gibt es keine andere Validierung als die eTLD+1-Prüfung. 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 Felder des Objekts „Benutzerdefinierte Zielgruppe“ angewendet. Informationen zur aktuellen Anforderungen und Einschränkungen in unserem Entwicklerleitfaden.

Jede HTTP-Fehlerantwort des Käufers führt zu einem Fehler bei fetchAndJoinCustomAudience. Insbesondere blockiert eine HTTP-Statusantwort 429 („Zu viele Anfragen“) Anfragen von der aktuellen Anwendung für einen zu definierenden Zeitraum. Der API-Aufruf schlägt auch fehl, wenn die Antwort des Käufers fehlerhaft ist. Fehler werden an den API-Aufrufer gemeldet, der bei vorübergehenden Fehlern (z. B. wenn der Server nicht antwortet) noch einmal versuchen oder bei dauerhaften Fehlern (z. B. Fehler bei der Datenvalidierung oder andere nicht vorübergehende Fehler bei der Kommunikation mit dem Server) entsprechende Maßnahmen ergreifen muss.

Mit dem CustomAudienceFetchRequest-Objekt kann der API-Aufrufer einige Informationen für die benutzerdefinierte Zielgruppe definieren. Dazu verwendet er die optionalen Eigenschaften, die im Beispiel oben gezeigt werden. Wenn diese Werte in der Anfrage festgelegt sind, können sie nicht durch die vom Käufer empfangene Antwort überschrieben werden. 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 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 von Die für die benutzerdefinierte Zielgruppe angegebenen Daten sind auf 8 KB beschränkt. Wenn die Größe überschritten wird, schlägt der fetchAndJoinCustomAudience API-Aufruf fehl.

Wenn keine k-anon-Prüfung vorhanden ist, können Sie fetchUri für die Käuferbestätigung verwenden und den Informationsaustausch zwischen Käufer und SDK zu ermöglichen. Um die Überprüfung benutzerdefinierter Zielgruppen zu erleichtern, kann der Käufer ein Bestätigungstoken angeben. Das On-Device-SDK sollte dieses Token in fetchUri einschließen, damit der vom Käufer gehostete Endpunkt den Inhalt der benutzerdefinierten Zielgruppe abrufen und mithilfe des Bestätigungstokens prüfen kann, ob die fetchAndJoinCustomAudience()-Operation dem Käufer entspricht und von einem vertrauenswürdigen On-Device-Partner stammt. Zum Teilen von Informationen kann der Käufer mit dem Anrufer auf dem Gerät vereinbaren dass einige der Informationen, die zum Erstellen der benutzerdefinierten Zielgruppe verwendet werden, wurden als Abfrageparameter zu fetchUri hinzugefügt. So kann der Käufer die ruft ein System auf und ermittelt, ob ein Validierungs-Token von einer bösartigen Anzeigentechnologie verwendet wurde, um verschiedene benutzerdefinierte Zielgruppen erstellen.

Hinweis zur Definition und Speicherung von Bestätigungstokens

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

  • Das Bestätigungstoken kann vom Käufer verwendet werden, um zu überprüfen, ob die Zielgruppen werden in ihrem Namen vorgenommen.
  • Der Protected Audience API-Vorschlag gibt kein Format für die oder wie der Käufer das Token an das Anrufer. Das Bestätigungstoken kann beispielsweise im SDK oder Backend des Eigentümers vorab geladen oder vom SDK des Eigentümers in Echtzeit vom Server des Käufers abgerufen werden.

Benutzerdefinierte Zielgruppe verlassen

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

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

Um die Nutzung von Speicherplatz und anderen Geräteressourcen zu sparen, laufen benutzerdefinierte Zielgruppen nach einem bestimmten Zeitraum ab und werden aus dem On-Device-Speicher entfernt. Der Standardwert muss bestimmt werden. Der Eigentümer kann dies Standardwert sein.

Nutzersteuerung

• Das Angebot soll Nutzern einen Überblick über die Liste der installierten Apps geben mit mindestens einer benutzerdefinierten Zielgruppe erstellt
• 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 nicht mehr zu neuen benutzerdefinierten Zielgruppen hinzugefügt werden.
• Nutzer können die Protected Audience API vollständig zurücksetzen. Wann? werden alle vorhandenen benutzerdefinierten Zielgruppen auf dem Gerät gelöscht.
• Nutzer können die Privacy Sandbox unter Android vollständig deaktivieren, einschließlich der Protected Audience API. Wenn der Nutzer aus der Privacy Sandbox kommt, schlägt die Protected Audience API im Hintergrund fehl.

Das Design dieser Funktion befindet sich noch in der Entwicklungsphase. Die Details werden in einem späteren Update veröffentlicht.

Geplante Updates

Bei den zuvor beschriebenen Lösungen muss das App- oder Anzeigentechnologie-SDK die APIs aufrufen, während sich die App im Vordergrund befindet, und die vollständigen Eigenschaften der benutzerdefinierten Zielgruppe entweder direkt oder durch Delegierung bereitstellen. Es ist jedoch nicht immer möglich, dass Werbetreibende und Anbieter von Anzeigentechnologien in Echtzeit festlegen, zu welchen Zielgruppen ein Nutzer gehört, während er die App verwendet.

Zu diesem Zweck können Anzeigentechnologie die scheduleCustomAudienceUpdate()-API. 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 geschützten Zielgruppen der Nutzer beitreten oder aus denen er entfernt werden soll.

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

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

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

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

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest enthält die Informationen, die für Registrieren eines verzögerten Jobs zur Ausführung auf der Plattform. Nach der angegebenen Verzögerung wird in regelmäßigen Abständen ein Hintergrundjob ausgeführt und die Anfragen werden gesendet. Die ScheduleCustomAudienceUpdateRequest 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 aus der eTLD+1 abgeleitet und muss nicht explizit angegeben werden. Sie kann auch nicht durch die Antwort auf die Aktualisierung geändert werden. Die GET-Anfrage erwartet ein JSON-Objekt mit einer Liste von customAudience-Objekten als Rückgabe.
• DelayTime: Zeitpunkt, der die Verzögerung ab dem Zeitpunkt der Ausführung angibt. scheduleCustomAudienceUpdate() API-Aufruf zum Planen der Aktualisierung.

• PartialCustomAudience: Die API ermöglicht es dem On-Device-SDK auch, eine Liste von teilweise erstellten benutzerdefinierten Zielgruppen. So können die In-App-SDKs die doppelte Rolle, von der vollständigen bis zur teilweisen Kontrolle über die Verwaltung benutzerdefinierter Zielgruppen basierend auf ihrer Partnerschaft mit DSPs.

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

• ShouldReplacePendingUpdates: boolescher Wert, der angibt, ob ausstehende Updates Geplante Updates sollten storniert und durch das Update ersetzt werden, das in die aktuelle ScheduleCustomAudienceUpdateRequest. Wenn dieser Wert auf false festgelegt ist und zuvor angeforderte Updates für denselben Käufer in derselben App noch ausstehen, schlägt ein Aufruf von scheduleCustomAudienceUpdate mit dieser ScheduleCustomAudienceUpdateRequest fehl. Die Standardeinstellung ist false.

App-Berechtigungen und ‐Einstellungen

Mit dem Vorschlag soll es Apps möglich sein, ihre benutzerdefinierten Zielgruppen zu steuern:

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

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

Steuerung der Anzeigentechnologie-Plattform

In diesem Vorschlag werden Möglichkeiten beschrieben, wie Anbieter von Anzeigentechnologien ihre benutzerdefinierten Zielgruppen verwalten können:

• Anzeigentechnologie-Anbieter registrieren sich für die Privacy Sandbox und geben eine eTLD+1-Domain an, die stimmt mit allen URLs für eine benutzerdefinierte Zielgruppe überein.
• AdTechs können mit Apps oder SDKs zusammenarbeiten, um Bestätigungstokens bereitzustellen, zur Überprüfung der Erstellung einer benutzerdefinierten Zielgruppe verwendet. Wenn dieser Vorgang an einen Partner delegiert wird, kann die Erstellung benutzerdefinierter Zielgruppen so konfiguriert werden, dass eine Bestätigung durch die Anzeigentechnologie erforderlich ist.
• Anbieter von Anzeigentechnologien können joinCustomAudience-Aufrufe in ihrem Namen deaktivieren und nur der fetchAndJoinCustomAudience API erlauben, alle benutzerdefinierten Zielgruppen für Aufrufe zu aktivieren. Die Einstellung kann während der Privacy Sandbox-Registrierung aktualisiert werden. Hinweis: Mit dieser Einstellung können entweder alle oder keine Anzeigentechnologien zugelassen werden. Aufgrund von Plattformeinschränkungen können Delegierungsberechtigungen nicht pro AdTech-Anbieter festgelegt werden.

Antwort auf mögliche Anzeigen und Metadaten

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

• Metadaten: Anzeigentechnologie-spezifische Metadaten für Käufer. Dazu gehören beispielsweise Informationen zur Werbekampagne und Targeting-Kriterien wie Standort und Sprache.
• Render-URL: Endpunkt für das Rendern des Creatives.
• Filter: Optionale Informationen, die für die Protected Audience API erforderlich sind, um Anzeigen anhand von On-Device-Daten zu filtern. Weitere Informationen erhalten Sie im Abschnitt zum Kaufen von Seitenfilterlogik.

Workflow für die Anzeigenauswahl

Mit diesem Vorschlag soll der Datenschutz verbessert werden. Dazu wird die Anzeigenauswahl-API eingeführt, die die Auktionsausführung für AdTech-Plattformen koordiniert.

AdTech-Plattformen nutzen heute in der Regel ausschließlich Gebote und Anzeigenauswahl auf ihren Servern. Bei diesem Vorschlag sind benutzerdefinierte Zielgruppen und andere vertrauliche Nutzersignale wie Informationen zu verfügbaren installierten Paketen nur über die Ad Selection API zugänglich. Für den Anwendungsfall Remarketing mögliche Anzeigen werden außerhalb des Bandbereichs abgerufen, d.h. nicht in dem Kontext, in dem die Anzeigen angezeigt. Anbieter von Anzeigentechnologien müssen sich darauf vorbereiten, dass einige Teile ihrer aktuellen Auktions- und Anzeigenauswahllogik auf dem Gerät bereitgestellt und ausgeführt werden. Anbieter von Anzeigentechnologien können die folgenden Änderungen am Workflow für die Anzeigenauswahl in Betracht ziehen:

• Ohne Informationen zu installierten Paketen auf dem Server, AdTech mehrere kontextabhängige Anzeigen an das Gerät senden und Den Workflow für die Anzeigenauswahl aufrufen, um das Filtern nach App-Installation zu aktivieren um die Chancen zu maximieren, dass eine relevante Anzeige ausgeliefert wird.
• Da Remarketing-Anzeigen nicht über das Band abgerufen werden, müssen die aktuellen Gebotsmodelle möglicherweise aktualisiert werden. Anbieter von Anzeigentechnologien können Gebotsuntermodelle erstellen (die Implementierung kann auf einem Muster basieren, das als Zwei-Turm-Modell bezeichnet wird), die Anzeigenfunktionen und Kontextsignale separat verarbeiten und die Ergebnisse der Untermodelle auf dem Gerät kombinieren, um Gebote vorherzusagen. Dies kann sowohl von serverseitige Auktionen und Auktionen für eine bestimmte Anzeigenposition.

So können die Daten zu den App-Interaktionen des Nutzers bei der Anzeigenauswahl helfen. und die Weitergabe dieser Daten an Dritte wird eingeschränkt.

Dieser Workflow für die Anzeigenauswahl orchestriert die Ausführung von von Anzeigentechnologien bereitgestellter JavaScript-Code, der auf folgende Reihenfolge:

1. Ausführung der Gebotslogik auf Käuferseite
2. Filterung und Verarbeitung von Anzeigen auf Käuferseite
3. Ausführung der Entscheidungslogik auf Verkäuferseite

Bei Anzeigenauswahl mit benutzerdefinierten Zielgruppen ruft die Plattform Von Seiten bereitgestellter JavaScript-Code kaufen, der auf dem öffentlichen URL-Endpunkt basiert, der durch die „URL für die Gebotslogik“ der benutzerdefinierten Zielgruppe Metadaten. Der URL-Endpunkt für den entscheidungsseitigen Code wird ebenfalls als Eingabe übergeben, um den Workflow für die Anzeigenauswahl zu starten.

Die Entwicklung von Anzeigenausschlüssen ohne benutzerdefinierte Zielgruppen ist in vollem Gange.

Workflow für die Anzeigenauswahl starten

Wenn eine Anzeige in einer App ausgeliefert werden muss, kann die Anzeige über das SDK der Anzeigentechnologie-Plattform initiiert werden Auswahlworkflow durch Aufrufen der Methode selectAds() nach der Instanziierung Das AdSelectionConfig-Objekt mit den erwarteten Parametern:

• Verkäufer: Kennung für die Sell-Side-Werbeplattform im Format „eTLD+1“
• URL für die Entscheidungslogik: Bei der Initiierung einer Anzeigenauktion verwendet die Plattform diese URL, um JavaScript-Code von der Sell-Side-Plattform abzurufen, um einen die erfolgreiche Anzeige enthält.
• Käufer mit benutzerdefinierten Zielgruppen: Eine Liste von Buy-Side-Plattformen mit benutzerdefinierter, auf Zielgruppen basierender Nachfrage für diese Auktion im Format „eTLD+1“.
• Signale für die Anzeigenauswahl: Informationen zur Auktion (Anzeigengröße, Anzeigenformat usw.).
• Verkäufersignale: Sell-Side-Plattform-spezifische Signale.
• URL für vertrauenswürdige Scoring-Signale: URL-Endpunkt des vertrauenswürdigen Signals auf Verkäuferseite von aus denen die Creative-spezifischen 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 beispielsweise umfassende Kontextinformationen enthalten, die für die Gebotsbestimmung nützlich sind.

Im folgenden Code-Snippet wird ein SDK einer Anzeigentechnologieplattform dargestellt, das den Anzeigenauswahl-Workflow initiiert, indem zuerst AdSelectionConfig definiert und dann selectAds aufgerufen wird, um die ausgewählte 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);

Logik für Gebote auf der Buy-Side

Die Gebotslogik wird in der Regel von Plattformen auf Käuferseite bereitgestellt. Der Zweck der werden mithilfe des Codes Gebote für mögliche Anzeigen festgelegt. Es können zusätzliche Kosten anfallen um das Ergebnis zu bestimmen.

Die Plattform verwendet die „URL für die Gebotslogik“ der benutzerdefinierten Zielgruppe. Metadaten zu ruft den JavaScript-Code 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 (kontextbezogene oder Remarketing-Anzeigen) auf. Wenn Wenn es mehrere Anbieter von 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. Es muss sich um eine Anzeige aus einer geeigneten benutzerdefinierten Zielgruppe handeln.
• Auktionssignale: Sell-Side-Signale, die sich auf die Plattform beziehen.
• Signale pro Käufer: Teilnehmende Demand-Side-Plattformen können diesen Parameter für folgende Aktionen verwenden: für die Auktion bereitstellen. Dieser Parameter kann beispielsweise umfassende Kontextinformationen enthalten, die für die Gebotsbestimmung nützlich sind.
• Vertrauenswürdige Gebotsignale: AdTech-Plattformen nutzen Echtzeitdaten, um die Anzeigenabfrage und -bewertung zu optimieren. Beispielsweise kann das Budget einer Werbekampagne aufgebraucht sein und die Anzeigenbereitstellung muss sofort beendet werden. Eine Anzeigentechnologie kann URL-Endpunkt, von dem diese Echtzeitdaten abgerufen werden können, und der Schlüsselsatz für die ein Echtzeit-Lookup durchgeführt werden muss. Das der verwaltete Server, der diese Anfrage bearbeitet, ein vertrauenswürdiger Server ist, der von der AdTech-Plattform.
• Kontextsignale: Hierzu können ein vergröberter Zeitstempel oder ein ungefährer Wert gehören. Standortinformationen oder Cost-per-Click auf die Anzeige.
• Nutzersignale: Hierzu können Informationen wie etwa Paketinformationen.

Werbekosten

Neben dem Gebot können auf Buy-Side-Plattformen auch die Kosten pro Klick als Teil von generateBid(). Beispiel:

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

Wenn diese Anzeige die Gewinnerin ist, wird adCost aus Datenschutzgründen stochastisch auf 8 Bit gerundet. Der gerundete Wert von adCost wird dann in den Parameter contextual_signals in reportWin in Berichten zu Impressionen übergeben.

Buy-Side-Filterlogik

Auf Buy-Side-Plattformen können Anzeigen dann basierend auf zusätzlichen Signalen, die während der Anzeigenauswahl verfügbar sind. Beispiele: AdTech-Plattformen Frequency Capping-Funktionen hier implementieren. Wenn es mehrere Filteranbieter gibt, kann das System die Ausführungsreihenfolge der Anbieter nicht garantieren.

Die Filterlogik auf Käuferseite kann als Teil der Gebotslogik durch Rückgabe eines Gebotswerts von 0 für eine bestimmte Anzeige.

Darüber hinaus können Plattformen auf Käuferseite signalisieren, dass eine bestimmte Anzeige sollte basierend auf zusätzlichen On-Device-Signalen gefiltert werden, die für Protected verfügbar sind und die Zuschauer bleiben auf dem Gerät. Wenn wir die Designs der und zusätzliche Filterlogik verwenden, haben die Plattformen auf Käuferseite dieselbe Struktur um zu signalisieren, dass die Filterung stattfinden soll.

Bewertungslogik für die Sell-Side

Die Bewertungslogik wird in der Regel von der Sell-Side-Plattform bereitgestellt. Zweck des Codes anhand der Ausgaben der Gebotslogik eine erfolgreiche Anzeige ermitteln. Möglicherweise zusätzliche Geschäftslogik anwenden, um das Ergebnis zu bestimmen. Wenn es mehrere Entscheidungslogik-Anbieter ist, garantiert das System die Ausführungssequenz zwischen den Anbietern. Die Plattform verwendet den Eingabeparameter „URL der Entscheidungslogik“ 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:

• Anzeigen: Die zu bewertende Anzeige; Ausgabe der Funktion generateBid().
• Bid (Gebot): Der von der Funktion generateBid() ausgegebene Gebotsbetrag
• Auction config: Eingabeparameter für die selectAds()-Methode.
• Vertrauenswürdige Bewertungssignale: Werbetechnologie-Plattformen nutzen Echtzeitdaten, um für die Anzeigenfilterung und die Bewertung genutzt werden. Ein App-Publisher kann beispielsweise verhindern, dass Anzeigen einer Werbekampagne in der App ausgeliefert werden. Diese Daten werden aus dem URL-Parameter für vertrauenswürdige Bewertungssignale der Auktionskonfiguration abgerufen. Der Server, der Diese Anfrage sollte von einem von AdTech verwalteten vertrauenswürdigen Server stammen.
• Kontextsignal: Hierbei kann es sich um einen vergröberten Zeitstempel oder einen ungefähren Wert handeln. Standortinformationen.
• Nutzersignal: Dazu gehören unter anderem Informationen wie der App-Shop, über den die Installation der App gestartet wurde.
• Signal für benutzerdefinierte Zielgruppe: Wenn die benotete Anzeige aus einer benutzerdefinierten Zielgruppe auf dem Gerät stammt, enthält sie Informationen wie den Leser und den Namen der benutzerdefinierten Zielgruppe.

Laufzeit des Anzeigenauswahlcodes

Im Angebot wird vom System der Auktionscode abgerufen, der von der AdTech-Plattform bereitgestellt wird von konfigurierbaren URL-Endpunkten und Ausführung auf dem Gerät. Aufgrund der Ressourceneinschränkungen auf Mobilgeräten muss Auktionscode den folgenden Richtlinien entsprechen:

• Die Ausführung des Codes sollte in einem vordefinierten Zeitraum abgeschlossen sein. Diese Grenze gilt einheitlich für alle Werbenetzwerke von Käufern. Details zu dieser Grenze die in einer späteren Aktualisierung freigegeben werden.
• Der Code muss eigenständig sein und darf keine externen Abhängigkeiten haben.

Da der Auktionscode wie der Gebotslogik benötigt möglicherweise Zugriff auf private Nutzer etwa zu App-Installationsquellen, liefert die Laufzeit keine Netzwerk- oder Speicherzugriff.

Programmiersprache

Der von der AdTech-Plattform bereitgestellte Auktionscode muss in JavaScript geschrieben sein. So können AdTech-Plattformen beispielsweise Gebotscode 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 Gewinneranzeige zum Rendern an das SDK übergeben.

Der Plan ist die Weiterentwicklung der Lösung, um sicherzustellen, dass Informationen über die die Zugehörigkeit zu einer benutzerdefinierten Zielgruppe oder ein App-Interaktionsverlauf. die App oder das SDK anhand der Informationen zur erfolgreichen Anzeige. (ähnlich wie die Fenced Frames-Angebot).

Berichte zu Impressionen und Ereignissen

Sobald die Anzeige gerendert wurde, kann die erfolgreiche Impression an teilnehmenden Buy-Side- und Sell-Side-Plattformen. So können Käufer und Verkäufer Informationen aus der Auktion, z. B. das Gebot oder den Namen der benutzerdefinierten Zielgruppe, in den Bericht zur siegreichen Impression aufnehmen. Außerdem sind die Seiten auf Verkäuferseite und Plattform auf Käuferseite sind berechtigt, zusätzliche Ereignis- Bericht zur erfolgreichen Anzeige. So haben Sie die Möglichkeit, Informationen (Gebot, Name der benutzerdefinierten Zielgruppe usw.) mit Klicks, Aufrufen und anderen Anzeigenereignisse. Die Plattform ruft die Berichterstellungslogik in dieser Reihenfolge auf:

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

Das gibt Buy-Side- und Sell-Side-Plattformen die Möglichkeit, Informationen zurück an die Server senden, um Funktionen wie Budgetplanung in Echtzeit, Aktualisierungen des Gebotsmodells und präzise Abrechnungs-Workflows Diese Impressionsberichte wird zusätzlich zur Attribution Reporting API angeboten.

Für Ereignisberichte sind zwei Schritte erforderlich: Verkäufer und Käufer JavaScript muss registrieren, für welches Ereignis es Ereignisberichte erhalten soll, und für die Berichterstellung auf Ereignisebene zuständig.

Protected Audience bietet einen Mechanismus, um zukünftige Ereignisse zu abonnieren eine erfolgreiche Auktion durch die Registrierung von Beacons. In der reportResult()-JavaScript-Funktion eines Verkäufers können Plattformen auf Verkäuferseite Beacons mithilfe der registerAdBeacon()-Funktion der Plattform registrieren. Ebenso können Buy-Side-Plattformen die registerAdBeacon()-Methode über ihre reportWin()-JavaScript-Funktion aufrufen.

registerAdBeacon(beacons)

Eingabe:

• event_key: Ein String, der angibt, für welchen Interaktionstyp die Registrierung erfolgen soll. Dieser Wert wird als Schlüssel verwendet, um den Endpunkt abzurufen, den die Plattform anpingt, während sie die Ergebnisse der Auktion meldet.
• reporting_url: Die URL der AdTech-Plattform, über die das Ereignis verarbeitet wird.

Ereignisschlüssel sind String-IDs, die zum SDK auf der Sell-Side gehören, das für die Berichterstellung der Auktionsergebnisse verantwortlich ist. Damit ein Rückruf erfolgen kann, AdTechs registrieren Beacons mit Schlüsseln, die den von der Verkäuferseite verwendeten Schlüsseln entsprechen wenn Sie Ereignisse melden. Diese müssen nicht k-anonym sein, Limits für die Anzahl und Länge der Schlüssel, die für ein benutzerdefinierten Zielgruppe. Wenn reportEvent() aufgerufen wird, werden Sell-Side-Plattformen, die an der Auktion teilgenommen haben, sind immer für den Erhalt dieser Ereignisberichte berechtigt. Nur die erfolgreiche Plattform auf Käuferseite berechtigt ist, diese Berichte zu erhalten.

Berichte auf Verkäuferseite

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

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 diese URL auf, die von der Funktion zurückgegeben wird.
• 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, erhalten Sie weitere Informationen zur Auktion und zur erfolgreichen Anzeige. Zum Beispiel kann es Signale unten einschließen:

• Rendering-URL der Anzeige
• Betrag des erfolgreichen Gebots
• App-Name
• Abfrage-IDs
• Signale für Käufer: Um die gemeinsame Nutzung von Daten zwischen Angebotsseite und Nachfrage zu unterstützen gibt die Plattform diesen Rückgabewert als Eingabeparameter an der Demand-Side-Berichtscode.

Berichte auf Käuferseite

Die Plattform ruft die reportWin()-JavaScript-Funktion im von der Nachfrageseite bereitgestellten Code auf, der aus den Metadaten der URL der Gebotslogik 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}};
}

Eingabe:

• auction_signals und per_buyer_signals werden abgerufen von AuctionConfig Alle Informationen, die die Plattform auf Käuferseite an die Käufer kann die Berichts-URL aus diesem Bezugssystem stammen.
• signals_for_buyer ist die Ausgabe des Berichtsergebnisses auf Verkäuferseite. Damit erhalten Sie der Sell-Side-Plattform mit der Möglichkeit, Daten mit der Käuferseite zur Berichterstellung verwenden.
• contextual_signals enthält Informationen wie den App-Namen und custom_audience_signals enthält 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 diese URL auf, die von der Funktion zurückgegeben wird.

Ereignisse melden

Ereignisse können erst dann erfasst werden, wenn die Impressionsberichte für die Auktion abgeschlossen sind. Das Sell-Side-SDK ist für die Berichterstellung zu allen Ereignissen verantwortlich. Die Plattform stellt eine API bereit, die eine ReportEventRequest annimmt, in der die kürzlich durchgeführte Auktion, der gemeldete Ereignisschlüssel, die mit diesem Schlüssel verknüpften Daten, ob der Bericht an den Käufer oder den Verkäufer (oder beide) gesendet werden soll, und ein optionales Eingabeereignis für Anzeigenereignisse angegeben werden. Der Client definiert das Ereignis und die Erfassung der Berichtsdaten.

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)

Eingabe:

• ad_selection_id muss ein AdSelectionId einer kürzlich durchgeführten Auktion sein aus AdSelectionOutcome abgerufen.
• event_key ist ein auf Verkäuferseite definierter String, der die Interaktion beschreibt. .
• event_data ist ein String, der die mit event_key verknüpften Daten darstellt.
• reporting_destinations ist eine Bitmaske, die mit Flags des Plattform. Mögliche Werte sind FLAG_REPORTING_DESTINATION_SELLER oder FLAG_REPORTING_DESTINATION_BUYER oder beides.
• input_event (optional) wird für die Integration in Attribution Reporting verwendet der API erstellen. Es handelt sich entweder um ein InputEvent-Objekt (für ein Klickereignis) oder um null. (für ein Aufrufereignis). Weitere Informationen finden Sie unter Integration der Attribution Reporting API. Details zu diesem Parameter.

Nachdem das Sell-Side SDK reportEvent aufgerufen hat, und reporting_destinations-Flag verwendet, versucht die Plattform, event_key mit die von Käufern und Verkäufern registrierten Schlüsseln in reportWin und reportResult-JavaScript-Funktionen. Bei einer Übereinstimmung POSTet die Plattform event_data an die verknüpfte reporting_url. Der Inhaltstyp der Anfrage ist „text/plain“ und der Textkörper ist event_data. Diese Anfrage wird nach dem Best-Effort-Prinzip gesendet und schlägt bei einem Netzwerk- oder Serverfehler oder wenn keine übereinstimmenden Schlüssel gefunden wurden, stillschweigend fehl.

Integration der Attribution Reporting API

Um Käufer zu unterstützen, die an einer Protected Audience-Auktion teilnehmen, haben wir API-übergreifende Funktionen für Protected Audience und Attribution Reporting APIs (ARA) Mit dieser Funktion können Anbieter von Anzeigentechnologien ihre Attributionsleistung für verschiedene Remarketing-Taktiken bewerten, um zu ermitteln, mit welchen Zielgruppentypen der höchste ROI erzielt wird.

Durch diese API-übergreifende Integration haben Anbieter von Anzeigentechnologien folgende Möglichkeiten:

• Erstellen Sie eine Schlüssel/Wert-Zuordnung von URIs, die sowohl für 1) Berichte zu Anzeigeninteraktionen als auch für 2) die Quellenregistrierung verwendet werden soll.
• Fügen Sie Auktionsdaten aus der Protected Audience-Auktion in die Quellschlüsselzuordnung für zusammengefasste Zusammenfassungsberichte ein (mit der Attribution Reporting API). Weitere Informationen finden Sie im ARA-Designvorschlag.

Wenn ein Nutzer eine Anzeige sieht oder darauf klickt:

• Über die URL, über die diese Ereignisinteraktionen mit Protected Audience erfasst werden, stellt dem Käufer die erforderlichen Daten zur Verfügung, um einen Aufruf oder Klick zu registrieren als zulässige Quelle mit der Attribution Reporting API festlegen.
• Die Anzeigentechnologie kann CustomAudience (oder andere relevante kontextbezogene Informationen zur Anzeige (z. B. Anzeigen-Placement oder Wiedergabedauer) mithilfe dieser URL sodass diese Metadaten in zusammenfassenden Berichten übernommen werden können, wenn die Anzeigentechnologie Kampagnenleistung überprüfen

Quellenregistrierung aktivieren

reportEvent() akzeptiert den neuen optionalen Parameter InputEvent. Sieger Käufer, die Anzeigen-Beacons registrieren, können auswählen, welche reportEvent-Berichte die bei den Attribution Reporting APIs als registrierte Quelle registriert sind. Die Anfrage wird allen Ereignisberichten die Überschrift „Attribution-Reporting-qualifiziert“ hinzugefügt. von reportEvent() gesendete Anfragen. Alle Antworten mit entsprechenden ARA-Headern werden wie jede andere reguläre Antwort bei der ARA-Quellenregistrierung geparst. In der Erläuterung zur Attribution Reporting API erfahren Sie, wie Sie Quell-URL registrieren

Da ARA unter Android Aufruf- und Klickereignisse unterstützt, InputEvents werden verwendet, um zwischen den beiden Typen zu unterscheiden. Genau wie in der ARA-Quelle Registrierung, interpretiert die reportEvent() API eine plattformgeprüfte Plattform InputEvent als Klickereignis an. Wenn InputEvent fehlt, null oder ungültig ist, gilt die Registrierung der Quelle als Aufruf.

Die eventData nach der Auktion kann vertrauliche Daten enthalten. Das Plattform löscht eventData in weitergeleiteten Anfragen zur Quellregistrierung.

Beispiel für Berichte zu Interaktionen und Conversions

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

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

Arbeitsablauf: Vor Beginn der Auktion sendet der Käufer im Rahmen des ihre programmatische Gebotsantwort mit Echtzeitgeboten (Real-Time Bidding – RTB). Die ID kann als Variable wie auctionId festgelegt. Die ID wird als perBuyerSignals übergeben in auctionConfig und es steht in der Gebotslogik des Käufers zur Verfügung.

1. Während der Ausführung von reportWin kann der Käufer ein Anzeigen-Beacon registrieren, das beim Rendern der Anzeige und bei bestimmten Interaktionsereignissen (registerAdBeacon()) ausgelöst wird. Wenn Sie Auktionssignale mit einem Anzeigenereignis verknüpfen möchten, legen Sie auctionId als Suchparameter der Beacon-URL fest.
2. Während der Anzeigendarstellung können die Beacons, die Sie während der Auktion registriert haben, ausgelöst oder mit Daten auf Ereignisebene ergänzt werden. Der Verkäufer muss auslösen, reportEvent() und übergeben die Daten auf Ereignisebene. Die Plattform pingt registrierte Beacon-URL des Käufers für Anzeigen, reportEvent(), der ausgelöst wurde.
3. Der Käufer registriert die Anzeige in der Attribution Reporting API, indem er auf Beacon-Anfragen mit Attribution-Reporting-Register-Source-Header. Wenn Sie Auktionssignale für ein Conversion-Ereignis verknüpfen möchten, setzen Sie die auctionId in der Register source URL.

Danach steht dem Käufer ein Auktionsbericht zur Verfügung. Interaktions- und Conversion-Bericht, die mithilfe der eindeutige ID, die miteinander verknüpft werden kann.

Ein ähnlicher Workflow gilt für einen Verkäufer, wenn er Zugriff auf Attributionsdaten benötigt. Der Verkäufer kann auch eine eindeutige ID verwenden, die mit registerAdBeacon() gesendet wird. Die Der reportEvent()-Aufruf enthält eine Ziel-Property, die zum Senden an den Käufer und den Verkäufer gesendet.

Von der AdTech-Plattform verwalteter, vertrauenswürdiger Server

Für die Anzeigenauswahllogik werden derzeit Echtzeitinformationen wie der Status der Budgetausschöpfung benötigt, um zu ermitteln, ob Anzeigen für die Auktion ausgewählt werden sollen. Beide Plattformen für Käufer und Sell-Side diese Informationen Server, die sie betreiben. Um die Offenlegung vertraulicher Daten zu minimieren, Für diese Server gelten für das Angebot folgende Einschränkungen:

• Das später in diesem Abschnitt beschriebene Verhalten dieser Server die Daten der Nutzenden zu stehlen.
• Die Server erstellen keine pseudonymen Profile auf Grundlage der Daten, die sie sehen. Sie müssen also „vertraulich“ sein.

Käuferseite: Sobald die Käuferseite die Gebotslogik für Käufer initiiert, wird die Plattform einen HTTP-Abruf von Daten zu vertrauenswürdigen Geboten vom vertrauenswürdigen Server durchführt. URL aus dem Hinzufügen der URL und der Schlüssel aus der Spalte Signalmetadaten der benutzerdefinierten Zielgruppe verarbeitet werden. Diese Abfrage erfolgt nur bei der Verarbeitung von Anzeigen aus den benutzerdefinierten Zielgruppen auf dem Gerät. In dieser Phase kann die Käuferseite Budgets erzwingen. Überprüfen Sie, Pausieren / Fortsetzen der Pausierung, Targeting durchführen usw.

Unten sehen Sie eine Beispiel-URL zum Abrufen von Daten zu vertrauenswürdigen Geboten basierend auf vertrauenswürdigen Geboten. Signalmetadaten aus der benutzerdefinierten Zielgruppe:

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

Die Antwort des Servers sollte ein JSON-Objekt mit den Schlüsseln „Schlüssel1“, „Schlüssel2“ usw. sein, deren Werte den Gebotsfunktionen des Käufers zur Verfügung gestellt werden.

Sell-Side: Ähnlich wie beim oben beschriebenen Ablauf auf der Buy-Side-Seite kann die Verkäuferseite Informationen zu Creatives, die in der Auktion berücksichtigt werden. Beispiel: Ein Publisher dass bestimmte Creatives nicht in ihrer App ausgeliefert werden, weil sie Bedenken hinsichtlich der Markensicherheit haben. Diese Informationen können abgerufen und für die der Auktionslogik auf der Sell-Side-Plattform. Ähnlich wie bei der Suche nach vertrauenswürdigen Servern auf Käuferseite eine vertrauenswürdige Serversuche erfolgt ebenfalls über einen HTTP-Abruf. Die URL wird gebildet, indem an die URL für vertrauenswürdige Bewertungssignale die Render-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 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 die in der Anfrage gesendeten Rendering-URLs sind.

Diese Server arbeiten vertrauenswürdig, um verschiedene Sicherheits- und Datenschutzvorteile:

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

Vorübergehend können Käufer und Verkäufer diese Gebote abrufen von beliebigen Servern senden, auch von einem selbst betriebenen. In der Releaseversion wird die Anfrage jedoch nur an einen vertrauenswürdigen Server vom Typ „Schlüssel/Wert“ gesendet.

Käufer und Verkäufer könnten einen gemeinsamen vertrauenswürdigen Server vom Typ „Schlüssel/Wert“ für Plattformen verwenden, die mit der Privacy Sandbox für Android und das Web kompatibel sind.