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

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

Zeitachse

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

Funktion 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

Ü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. Mit diesem 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 AdTech-Plattformen und Werbetreibende, um allgemeine interaktionsbasierte Anwendungsfälle so, dass die Freigabe beider Kennungen eingeschränkt wird und Informationen zur App-Interaktion eines Nutzers mit Drittanbietern:

  1. Custom Audience API: Diese API ist auf der „Benutzerdefinierte Zielgruppe“ Abstraktion, die einen vom Werbetreibenden festgelegten Zielgruppe mit gemeinsamen Absichten. 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-Geboten, Anzeigenfilterung und -rendering.
  2. Ad Selection API: Diese API bietet ein Framework, AdTech-Plattformen orchestriert Workflows nutzen, die On-Device-Signale 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.
Flussdiagramm, das den Workflow für 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, noch Merchandise-Artikel zu kaufen. in seinem Einkaufswagen, wenn er den Kauf nicht innerhalb von zwei Tagen abgeschlossen hat. SportingGoodsApp verwendet die Custom Audience API, um den Nutzer zur „Produkte im Einkaufswagen“ Zielgruppenliste hinzu. Diese wird von der Plattform verwaltet und gespeichert. Zielgruppenliste auf dem Gerät, wodurch die Weitergabe an Dritte eingeschränkt wird. SportingGoodsApp arbeitet mit einer Anzeigentechnologieplattform zusammen, um Nutzern in seiner Zielgruppenliste Anzeigen zu präsentieren. Auf der AdTech-Plattform werden Metadaten für die Zielgruppe verwaltet. mögliche Anzeigen aufführt, die der Anzeige zur Verfügung gestellt werden, Auswahl-Workflow zu berücksichtigen. 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 aktuell und nicht mit Anfragen korreliert, 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 optimieren, 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 Berichtsfunktion ergänzt die Attribution Reporting API. Anzeigentechnologie-Plattformen können an ihre Berichtsanforderungen anzupassen.

Zugriff auf Protected Audience APIs 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 Registrieren Sie sich für ein Privacy Sandbox-Konto, um weitere Informationen zu erhalten.

Verwaltung benutzerdefinierter Zielgruppen

Benutzerdefinierte Zielgruppe

Eine benutzerdefinierte Zielgruppe ist eine vom Werbetreibenden festgelegte Gruppe von Nutzern mit gemeinsamen Absichten oder Interessen. Eine App oder ein SDK kann eine benutzerdefinierte Zielgruppe verwenden, um eine bestimmte Zielgruppe anzuzeigen, z. B. wenn jemand „Elemente links“ Warenkorb“ oder „Ich habe die Anfängerniveaus abgeschlossen“ eines Spiels. 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 Werbetreibenden-App oder das integrierte SDK kann mit lassen eine benutzerdefinierte Zielgruppe, z. B. basierend auf Interaktionen in einer App.

Benutzerdefinierte Zielgruppenmetadaten

Jede benutzerdefinierte Zielgruppe enthält die folgenden Metadaten:

  • Inhaber:Paketname der Eigentümer-App. Dies ist implizit auf den Wert Paketname der Anrufer-App.
  • Käufer:Das Werbenetzwerk des Käufers, in dem Anzeigen für diese benutzerdefinierte Zielgruppe verwaltet werden Der Käufer ist auch die Partei, die auf die benutzerdefinierte Zielgruppe zugreifen und relevante Anzeigeninformationen abrufen kann. 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 die Uhrzeit festgelegt. Fenster, in dem diese benutzerdefinierte Zielgruppe wirksam ist. Die Plattform nutzt diese um die Mitgliedschaft für eine benutzerdefinierte Zielgruppe zu widerrufen. Ablaufzeit darf das maximale Dauerfenster zur Begrenzung der Lebensdauer eines benutzerdefinierten Zielgruppe.
  • 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 erhalten Sie im Abschnitt zum Abrufen möglicher Anzeigen für benutzerdefinierte Zielgruppen.
  • Gebotssignale von Nutzern:AdTech-plattformspezifische Signale für jede Gebote für Remarketing-Anzeigen. Beispiele für Signale: etwa den ungefähren Standort des Nutzers, die bevorzugte Sprache usw.
  • Vertrauenswürdige Gebotsdaten:AdTech-Plattformen vertrauen auf Echtzeitdaten um den Abruf und die Bewertung von Anzeigen zu steuern. Beispiel: Das Budget für eine Anzeige ist aufgebraucht. und muss sofort beendet werden. Ein Anzeigentechnologie-Anbieter kann eine URL Endpunkt, von dem diese Echtzeitdaten abgerufen werden können, und der Schlüssel der die Echtzeitsuche ausführen muss. Der Server, der dies verarbeitet -Anforderung eine vertrauenswürdige Server, der vom AdTech-Plattform.
  • URL für Gebotslogik:Die URL, die die Plattform zum Abrufen von Geboten verwendet von der Demand-Side-Plattform. Die Plattform führt diesen Schritt aus, wenn 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 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 serverseitige Technologien und Integrationen durch AdTechs in Zusammenarbeit mit Agenturen und Werbetreibenden, Kunden und Partnern. 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 benutzerdefinierte Zielgruppendelegierung:

Einer benutzerdefinierten Zielgruppe beitreten

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

joinCustomAudience()

Eine App oder ein SDK kann durch folgenden Aufruf die Aufnahme in eine benutzerdefinierte Zielgruppe anfordern: joinCustomAudience() nach der Instanziierung des CustomAudience-Objekts mit der erwartete Parameter. Hier ein Beispiel für ein Code-Snippet:

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

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

fetchAndJoinCustomAudience()

Eine App oder ein SDK kann im Namen einer Anzeigentechnologie, die nicht auf dem Gerät vorhanden ist, die Aufnahme in eine benutzerdefinierte Zielgruppe beantragen. Dazu wird fetchAndJoinCustomAudience() mit den erwarteten Parametern aufgerufen, 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). Die API erzwingt auch, dass die täglichen Update-URL auch mit der eTLD+1 des Käufers übereinstimmt.

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

Die fetchAndJoinCustomAudience() API ermittelt die Identität des Käufers anhand der eTLD+1 von fetchUri. Die 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 Eigentümer von CustomAudience ist die Paketname der aufrufenden App. Es gibt keine weitere Validierung fetchUri mit Ausnahme der eTLD+1-Prüfung. Insbesondere gibt es kein k-anon. überprüfen. Die fetchAndJoinCustomAudience() API sendet eine HTTP-GET-Anfrage an fetchUri und erwartet ein JSON-Objekt, das die benutzerdefinierte Zielgruppe darstellt. Das Gleiche obligatorische, optionale Einschränkungen und Standardwerte für die benutzerdefinierte Zielgruppe -Objektfeldern auf die Antwort angewendet. Informationen zur aktuellen Anforderungen und Einschränkungen in unserem Entwicklerleitfaden.

Jede HTTP-Fehlerantwort des Käufers führt dazu, dass fetchAndJoinCustomAudience scheitern. Insbesondere eine HTTP-Statusantwort von 429-Blöcken (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 an den API-Aufrufer gemeldet, der bei vorübergehenden Fehlern (z. B. wenn der Server nicht antwortet) einen erneuten Versuch starten 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 Objekt CustomAudienceFetchRequest kann der API-Aufrufer Folgendes definieren: Informationen für die benutzerdefinierte Zielgruppe zu erstellen, indem Sie die optionalen Eigenschaften verwenden, die unter im obigen Beispiel. 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 von CustomAudience als teilweise vom API-Aufrufer definiert, ist in der GET-Anfrage an fetchUri enthalten in einer speziellen Kopfzeile X-CUSTOM-AUDIENCE-DATA. 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 fetchAndJoinCustomAudience API-Aufruf fehl.

Da 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 benutzerdefinierte Zielgruppen bestätigen, kann der Käufer eine Bestätigung Token. Das On-Device-SDK sollte dieses Token in fetchUri enthalten, damit das Endpunkt, der vom Käufer gehostet wird, den Inhalt der benutzerdefinierten Zielgruppe abrufen und Verwenden Sie das Bestätigungstoken, um zu bestätigen, dass die fetchAndJoinCustomAudience() die dem Käufer entsprechen und von einem vertrauenswürdigen On-Device-Gerät stammen. Partner. 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 für keine Zwecke verwendet API 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 die Zielgruppe über einen Anruf verlassen. leaveCustomAudience(), wie im folgenden Code-Snippet zur Veranschaulichung gezeigt:

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

Mit benutzerdefinierten Zielgruppen können Sie die Nutzung von Speicher und anderen Geräteressourcen verfallen und werden nach einem festgelegten Zeitraum . Der Standardwert muss bestimmt werden. Der Inhaber kann diesen Standardwert überschreiben.

Nutzersteuerung

  • Mit dem Vorschlag soll Nutzern die Liste der installierten Apps angezeigt werden, für die mindestens eine benutzerdefinierte Zielgruppe erstellt wurde.
  • Nutzer können Apps aus dieser Liste entfernen. Durch das Entfernen werden alle benutzerdefinierten Zielgruppen, die den Apps zugeordnet sind, und verhindern, dass die Apps neuen benutzerdefinierten Zielgruppen.
  • Nutzer können die Protected Audience API vollständig zurücksetzen. Wann? werden alle vorhandenen benutzerdefinierten Zielgruppen auf dem Gerät gelöscht.
  • Nutzer haben die Möglichkeit, die Privacy Sandbox vollständig zu deaktivieren: Android mit 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 oben beschriebenen Lösungen muss das App- oder AdTech-SDK die Methode APIs während die App im Vordergrund ausgeführt wird, und stellen die vollständigen Eigenschaften der benutzerdefinierte Zielgruppe erstellen, entweder direkt oder über die Delegierung. Es ist jedoch nicht immer Werbetreibende und Anbieter von Anzeigentechnologien können festlegen, welche Zielgruppen ein Nutzer in Echtzeit gehört, während sie die App nutzen.

Zu diesem Zweck können Anzeigentechnologie die scheduleCustomAudienceUpdate()-API. Mit dieser API kann der Aufrufer ein die Verzögerung beim Ausführen des API-Aufrufs und damit zusätzliche Zeit Verarbeitung von Ereignissen auf App-Ebene durch die reagierende Anzeigentechnologie und Geschützte Zielgruppen, denen 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. ScheduleCustomAudienceUpdateRequest kann die folgenden Informationen enthalten:

  • UpdateUri: URI-Endpunkt, an den ein GET-Aufruf zum Abrufen des Updates gesendet wird. Die Käuferidentität wird von eTLD+1 abgeleitet und muss explizit angegeben und können durch die Updateantwort nicht geändert werden. Die GET-Methode erwartet ein JSON-Objekt mit einer Liste von customAudience-Objekten in zurückgeben.
  • DelayTime: Zeit, die die Verzögerung zwischen dem scheduleCustomAudienceUpdate() API-Aufruf und der Planung der Aktualisierung angibt.

  • 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 dafür false und sind bereits angeforderte Aktualisierungen für denselben Käufer in der Dieselbe App, ein Aufruf von scheduleCustomAudienceUpdate mit diesem ScheduleCustomAudienceUpdateRequest schlägt fehl. Die Standardeinstellung ist false.

App-Berechtigungen und -Steuerung

Mit dem Vorschlag soll es Apps ermöglicht werden, 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:

  • Anbieter von Anzeigentechnologien registrieren sich in der Privacy Sandbox und geben eine eTLD+1-Domain an, die mit allen URLs für eine benutzerdefinierte Zielgruppe übereinstimmt.
  • AdTechs können mit Apps oder SDKs zusammenarbeiten, um Bestätigungstokens bereitzustellen, zur Überprüfung der Erstellung einer benutzerdefinierten Zielgruppe verwendet. Wenn dieser Prozess an einen Partner erstellen, kann beim Erstellen einer benutzerdefinierten Zielgruppe eine Bestätigung erforderlich sein. durch die Anzeigentechnologie.
  • Ein Anzeigentechnologie-Anbieter kann joinCustomAudience-Aufrufe in seinem Namen deaktivieren und nur der fetchAndJoinCustomAudience API erlauben, alle benutzerdefinierten Aufrufe zu aktivieren Zielgruppen. Die Einstellung kann während der Privacy Sandbox-Registrierung aktualisiert werden. Beachten Sie die ob alle oder gar keine Anzeigentechnologien zugelassen sind. Aufgrund von Plattformeinschränkungen Berechtigungen zur Delegierung können nicht pro Anzeigentechnologie 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 Rendering des Anzeigen-Creatives.
  • Filter:Optionale Informationen, die die Protected Audience API benötigt, um Anzeigen anhand von Gerätedaten 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. Mit diesem Angebot können benutzerdefinierte Zielgruppen und andere sensible Nutzer wie z. B. Informationen zu installierten Paketen, nur über die Ad Selection API. Für den Remarketing-Fall werden zusätzlich Anzeigenvorschläge außerhalb des Bandes abgerufen, d. h. nicht im Kontext, in dem Anzeigen ausgeliefert werden. 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. Für Anzeigentechnologie-Plattformen gilt möglicherweise Folgendes: Auswahl-Workflow:

  • Ohne Informationen zu installierten Paketen auf dem Server, AdTech mehrere kontextbezogene Anzeigen an das Gerät zurücksenden 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 außerhalb des Bandbereichs abgerufen werden, können aktuelle Gebotsmodelle aktualisiert werden müssen. 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. Dabei können sowohl serverseitige Auktionen als auch Auktionen für eine bestimmte Anzeigenbereitstellung genutzt werden.

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

Flussdiagramm, das den Start des Anzeigenauswahl-Workflows zeigt.

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 Anzeigenauswahl ohne benutzerdefinierte Zielgruppen ist unter „Aktiv“ Design.

Workflow für Anzeigenauswahl initiieren

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: Stellen Sie plattformspezifische Signale bereit.
  • 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 Demand-Side-Plattformen können diesen Parameter für folgende Aktionen verwenden: für die Auktion bereitstellen. Dieser Parameter kann beispielsweise Umfassende Kontextinformationen, die für die Gebotsbestimmung nützlich sind.

Das folgende Code-Snippet zeigt ein SDK einer Anzeigentechnologie-Plattform, Anzeigenauswahl-Workflow durch Definieren von AdSelectionConfig und selectAds aufrufen, um die erfolgreiche Anzeige zu erhalten:

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

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

Logik für Gebote auf der Buy-Side

Die Gebotslogik wird in der Regel von Plattformen auf Käuferseite bereitgestellt. Der Code dient dazu, Gebote für infrage kommende Anzeigen zu bestimmen. 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 wird Rufen Sie diese Funktion für alle Anzeigen (kontext- oder Remarketing-Anzeigen) nacheinander 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 Code für Gebote auf der Buy-Side 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, die für die Gebotsbestimmung nützlich sind.
  • Vertrauenswürdige Gebotssignale: AdTech-Plattformen nutzen Echtzeitdaten, um um das Abrufen und Bewerten von Anzeigen zu unterstützen. Einer Werbekampagne sind beispielsweise und muss sofort eingestellt 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: Dazu gehören grobe Zeitstempel oder ungefähre Standortinformationen oder der Cost-per-Click der 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 contextual_signals-Parameter für reportWin bei Impressionsberichten.

Filterlogik auf Käuferseite

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. Sobald wir die Designs der zusätzlichen Filterlogik fertiggestellt haben, folgen auch Kaufplattformen dieser Struktur, um anzuzeigen, dass die Filterung erfolgen soll.

Bewertungslogik auf Verkäuferseite

Die Bewertungslogik wird in der Regel von der Sell-Side-Plattform bereitgestellt. Zweck des Codes wird anhand der Ausgaben der Gebotslogik ermittelt, welche Anzeige erfolgreich war. 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 die „URL zur Entscheidungslogik“ Eingang der selectAds() API, um den JavaScript-Code abzurufen. Dieser sollte Fügen Sie die folgende Funktionssignatur hinzu:

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. der Funktion generateBid() ausgegeben.
  • Bid (Gebot): Der von der Funktion generateBid() ausgegebene Gebotsbetrag
  • Auktionskonfiguration: Eingabeparameter für die Methode selectAds().
  • Vertrauenswürdige Bewertungssignale: Werbetechnologie-Plattformen nutzen Echtzeitdaten, um für die Anzeigenfilterung und die Bewertung genutzt werden. Beispielsweise kann ein App-Publisher dass Anzeigen in der App ausgeliefert werden. Diese Daten werden von der vertrauenswürdigen Plattform abgerufen URL-Parameter der Auktionskonfiguration für Bewertungssignale. 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: Hierzu können Informationen wie der App-Shop gehören, die die Installation der App initiiert hat.
  • Benutzerdefiniertes Zielgruppensignal: Wenn die Anzeige, die bewertet wird, von einem Gerät stammt. benutzerdefinierte Zielgruppe enthält, enthält diese 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 einheitlich auf alle Werbenetzwerke von Käufern angewendet. Details zu dieser Begrenzung werden in einem späteren Update bekannt gegeben.
  • Der Code muss in sich geschlossen sein und 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 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 dieser wird die erfolgreiche Anzeige 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 um Informationen aus der Auktion einzubeziehen, z. B. das Gebot oder die benutzerdefinierte Zielgruppe mit dem Bericht zu den erfolgreichen Impressionen. 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 Berichtslogik in der folgenden Reihenfolge auf:

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

Das gibt Buy-Side- und Sell-Side-Plattformen die Möglichkeit, Daten an die Server zurücksenden, 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 die Unterstützung von Ereignisberichten sind zwei Schritte erforderlich: Sell-Side- und Buy-Side-JavaScript muss registrieren, für welches Ereignis Ereignisberichte empfangen werden sollen. Die Sell-Side ist für die Berichterstellung auf Ereignisebene verantwortlich.

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

registerAdBeacon(beacons)

Eingabe:

  • event_key: Ein String, der angibt, für welchen Interaktionstyp die Registrierung erfolgen soll. Wird als Schlüssel verwendet, um den Endpunkt zu ermitteln, den die Plattform anpingt, während der Auktionsergebnisse.
  • reporting_url: Die URL der Anzeigentechnologie-Plattform, auf der das Ereignis verarbeitet wird.

Ereignisschlüssel sind String-IDs, die dem SDK auf Verkäuferseite gehören die für die Berichterstellung der Auktionsergebnisse zuständig sind. 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 für die Sell-Side

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 Fehler.
  • 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 das reportWin des Käufers übergeben wird. .

Die Angebotsseite kann relevante Signale in die Berichts-URL codieren, um weitere Informationen zur Auktion und zur Gewinneranzeige zu erhalten. 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 bei Bedarf die JavaScript-Funktion reportWin() auf. Code, der aus den Metadaten der Gebotslogik-URL des 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}};
}

Eingabe:

  • auction_signals und per_buyer_signals werden abgerufen aus 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. So kann die Sell-Side-Plattform Daten zu Berichtszwecken mit der Buy-Side-Plattform teilen.
  • contextual_signals enthält Informationen wie den App-Namen und custom_audience_signals enthält die Informationen zur benutzerdefinierten Zielgruppe. Sonstiges in Zukunft hinzugefügt werden können.

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 der Impressionsbericht für die Auktion abgeschlossen. Das SDK auf Verkäuferseite ist für die Berichterstellung zu Ereignissen zuständig. Die Plattform eine API zur Verfügung stellt, die einen ReportEventRequest verwendet, der die kürzlich durchgeführte Auktion, den Ereignisschlüssel, der gemeldet wurde, und die Daten ob der Bericht an den Käufer oder den Verkäufer gesendet werden soll (oder und ein optionales Eingabeereignis für Anzeigenereignisse. 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 Daten darstellt, die mit event_key
  • reporting_destinations ist eine Bitmaske, die mit Flags des Plattform. Es kann FLAG_REPORTING_DESTINATION_SELLER oder FLAG_REPORTING_DESTINATION_BUYER oder beides sein.
  • 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 SDK auf der Sell-Side reportEvent aufgerufen hat, versucht die Plattform je nach reporting_destinations-Flag, die event_key mit den von Käufern und Verkäufern in ihren reportWin- und reportResult-JavaScript-Funktionen registrierten Schlüsseln abzugleichen. Bei einer Übereinstimmung POSTet die Plattform event_data an die verknüpfte reporting_url. Der Inhaltstyp der Anfrage ist Nur-Text, wobei der Text der event_data ist. Diese Anfrage erfolgt nach bestem Wissen und Gewissen. und scheitert bei Netzwerkfehlern, Serverfehlern oder wenn keine übereinstimmenden Schlüssel gefunden wurden.

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 AdTechs über verschiedene Remarketing-Taktiken hinweg zu messen, ermitteln, mit welchen Zielgruppentypen Sie den höchsten ROI erzielen.

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

  • Schlüssel/Wert-Zuordnung mit URIs erstellen, die für beides verwendet werden sollen 1) Berichte zu Anzeigeninteraktionen und 2) Registrierung der Quelle.
  • Auktionsdaten aus der Protected Audience-Auktion in die Quelle einbeziehen Schlüsselzuordnung für aggregierte zusammenfassende Berichte (über Attribution Reporting) (API) Weitere Informationen finden Sie im ARA-Designvorschlag.

Wenn ein Nutzer eine Anzeige sieht oder auf sie 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 einen 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. Der Anfrageheader „Attribution-Reporting-Eligible“ wird allen Anfragen für Ereignisberichte hinzugefügt, die von reportEvent() gesendet werden. 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.

Hinweis: Die eventData nach der Auktion kann vertrauliche Daten enthalten. Daher wird die eventData in Anfragen zur Registrierung von weitergeleiteten Quellen von der Plattform entfernt.

Beispiel für Berichte zu Interaktionen und Conversions

In diesem Beispiel betrachten wir das Ganze aus der Perspektive des Käufers, der Verknüpfung der Daten aus der Auktion, der gerenderten Anzeige und der Conversion-App miteinander verbinden.

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 mit den Auktionsdaten. Während des Rendering- und Conversion-Zeitraums werden die Daten der gerenderten Anzeige ebenfalls mit derselben eindeutigen ID gesendet. Später kann die eindeutige ID für Folgendes verwendet werden: können Sie diese Berichte 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, Sie werden während des Anzeigen-Renderings und bei bestimmten Interaktionsereignissen ausgelöst. (registerAdBeacon()). Um Auktionssignale für ein Anzeigenereignis zu verknüpfen, legen Sie Folgendes fest: auctionId als Abfrageparameter der Beacon-URL
  2. Während des Anzeigen-Renderings können die von Ihnen registrierten Beacons ausgelöst oder mit Daten auf Ereignisebene optimiert. 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 bei der Attribution Reporting API, indem er auf die Anzeigen-Beacon-Anfragen mit dem Attribution-Reporting-Register-Source-Header antwortet. Auktionssignale verknüpfen für ein Conversion-Ereignis: auctionId in der Quell-URL registrieren.

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

Bei der Anzeigenauswahl sind heute Echtzeitinformationen wie das Erschöpfen des Budgets erforderlich -Status, um zu ermitteln, ob Anzeigenkandidaten 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 die folgenden Einschränkungen:

  • Das später in diesem Abschnitt beschriebene Verhalten dieser Server die Daten der Nutzenden zu stehlen.
  • Die Server würden keine pseudonymisierten Profile auf der Grundlage der Daten erstellen, die sie sehen, d.h., es muss „vertrauenswürdig“ sein.

Buy-Side: Sobald die Buy-Side-Gebotslogik gestartet wurde, führt die Plattform einen HTTP-Abruf vertrauenswürdiger Gebotsdaten vom vertrauenswürdigen Server aus. URL aus dem Hinzufügen der URL und der Schlüssel aus der Spalte Signalmetadaten der benutzerdefinierten Zielgruppe verarbeitet werden. Dieser Abruf erfolgt nur bei der Verarbeitung von Anzeigen von der benutzerdefinierten Zielgruppen. In dieser Phase können Käuferseite-Nutzer Budgets erzwingen, den Status der Kampagnenunterbrechung prüfen, das Targeting vornehmen 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 vom Server sollte ein JSON-Objekt sein, dessen Schlüssel „key1“, „key2“ und wessen Werte für die Gebotsfunktionen des Käufers zur Verfügung gestellt werden.

Verkaufsseite: Ähnlich wie bei der Kaufseite oben kann die Verkaufsseite Informationen zu Creatives abrufen, die bei 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 erfolgt auch die Suche nach vertrauenswürdigen Servern auf Verkäuferseite über einen HTTP-Abruf. Die URL setzt sich aus indem Sie der URL für Trusted Scoring-Signale die Rendering-URLs der Creatives hinzufügen. für die die Daten abgerufen werden sollen.

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:

  • Es ist vertrauenswürdig, dass der Rückgabewert des Servers für jeden Schlüssel nur auf diesen 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 Signale von beliebigen Servern, auch solche, die sie selbst betreiben. 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önnen einen gemeinsamen, vertrauenswürdigen Plattformen, die mit der Privacy Sandbox für Android und im Web kompatibel sind.