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

<ph type="x-smartling-placeholder">

Feedback geben

Letzte Updates

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

Mit Protected Audience können Sie:

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

Lesen Sie zuerst den Entwicklerleitfaden zu Protected Audience. 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-Gebote, 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.
<ph type="x-smartling-placeholder">
</ph>
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 Anzeigentechnologie-Plattform zusammen, um Nutzern Anzeigen zu präsentieren in der Zielgruppenliste. 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, werden regelmäßig aktualisierte zielgruppenbasierte Anzeigen im Hintergrund abgerufen. Dieses Die Liste der zielgruppenbasierten Kandidatenanzeigen bleibt aktuell und nicht korreliert. mit Anfragen, die während der Werbechance an den Ad-Server eines Drittanbieters gesendet werden (d.h. kontextbezogene Anzeigenanfrage).

  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 Berichtfunktion ist als Ergänzung zu den Attributionsberichten API hinzu. 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.

Benutzerdefinierte Zielgruppenverwaltung

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. 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 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 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 tägliche Updates:URL, unter der die Plattform zum Abrufen möglicher Anzeigen und anderer Metadaten verwendet, die in der Spalte "Gebote durch Nutzer Signalen“ und „Vertrauenswürdige Gebotssignale“ in regelmäßigen Abständen. 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). The Protected Die Audience API unterstützt diese SDKs durch flexible Lösungen für die benutzerdefinierte Zielgruppenverwaltung, indem Sie auf dem Gerät die Berechtigung zum Aufrufen benutzerdefinierter Zielgruppen im Auftrag von Käufern 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 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 du fetchAndJoinCustomAudience() aufrufst 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). 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 Käufers von CustomAudience wird für folgende Aufgaben verwendet: dieselben Registrierungs- und App-Autorisierungsprüfungen wie joinCustomAudience() und kann durch die Fetch-Antwort nicht 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 gemeldet an den API-Aufrufer, der für den erneuten Versuch aufgrund temporärer Fehler (z. B. Server antwortet nicht) oder behebt dauerhafte Fehler (z. B. Datenvalidierung). Ausfälle oder andere dauerhafte Fehler bei der Kommunikation mit dem Server).

Mit dem Objekt CustomAudienceFetchRequest kann der API-Aufrufer Folgendes definieren: Informationen für die benutzerdefinierte Zielgruppe angeben, 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 Antwort des Käufers, die die Plattform erhalten hat, werden von der Protected Audience API die Felder in der Antwort. Sind sie nicht in der Anfrage festgelegt, müssen sie in der Antwort festgelegt werden, da diese Felder zum Erstellen eines benutzerdefinierten Zielgruppe. 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 von Die für die benutzerdefinierte Zielgruppe angegebenen Daten sind auf 8 KB beschränkt. Wenn die Größe fetchAndJoinCustomAudience-API-Aufruf schlägt 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. Beispiel: Das Bestätigungstoken kann im Voraus in den das SDK oder Back-End des Eigentümers verwendet, oder es könnte in Echtzeit vom SDK vom Server des Käufers.

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 dies Standardwert sein.

Nutzersteuerung

  • Das Angebot soll Nutzern Einblick in die Liste der installierten Apps geben mit mindestens einer benutzerdefinierten Zielgruppe erstellt
  • 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 ist noch in der Entwicklung und die Details werden in einer späteren Aktualisierung enthalten sein.

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 delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/

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

DelayedCustomAudienceUpdate

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

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

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

DelayedCustomAudienceUpdate enthält die Informationen, die für 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 DelayedCustomAudienceUpdate 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: 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.

App-Berechtigungen und ‐Einstellungen

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

  • Eine App kann ihre Verknüpfungen mit benutzerdefinierten Zielgruppen verwalten.
  • Über eine App können 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 Anzeigentechnologie-Anbieter ihre benutzerdefinierten Zielgruppen steuern 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 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 Registrierung für die Privacy Sandbox 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. Zum Beispiel könnte dies Informationen über die Werbekampagne und Ausrichtungskriterien 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

Ziel dieses Vorschlags ist es, den Datenschutz durch die Einführung der Anzeigenauswahl API zur Orchestrierung der Auktionsausführung für AdTech-Plattformen

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 Anwendungsfall Remarketing mögliche Anzeigen werden außerhalb des Bandbereichs abgerufen, d.h. nicht in dem Kontext, in dem die Anzeigen angezeigt. AdTech-Plattformen müssen sich darauf vorbereiten, die aktuelle Auktions- und Anzeigenauswahllogik . 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. AdTech-Plattformen könnten Gebotsuntermodelle erstellen, Die Implementierung basiert möglicherweise auf einem Muster namens Zwei-Türme-Modell) die Anzeigenfunktionen und Kontextsignale separat bearbeiten und die Ausgaben des untergeordneten Modells an das Gerät, 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 als Grundlage für die Anzeigenauswahl dienen. und die Weitergabe dieser Daten an Dritte wird eingeschränkt.

<ph type="x-smartling-placeholder">
</ph>
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. Anzeigenfilterung und -verarbeitung 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 wird auch der Code für die Sell-Side-Entscheidung den Workflow zur Anzeigenauswahl.

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 der Werbeplattform auf Verkäuferseite (eTLD+1) Format
  • 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 von benutzerdefinierten Zielgruppen: Eine Liste von Plattformen auf Käuferseite mit benutzerdefinierten für diese Auktion im Format eTLD+1 festlegen.
  • 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);

Gebotslogik auf Käuferseite

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 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 Gebotscode auf Käuferseite berücksichtigt wird. Dies ist ein Anzeige aus einer geeigneten benutzerdefinierten Zielgruppe
  • Auktionssignale: Plattformspezifische Signale auf Verkäuferseite.
  • 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: 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 gewinnt, wird adCost stochastisch gerundet auf 8 Bit Datenschutz. 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 Anbietern filtern, garantiert das System die Ausführungsreihenfolge unter die Anbieter.

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 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. Anhand der Ressource Einschränkungen für Mobilgeräte gilt, sollte der Auktionscode Richtlinien:

  • 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 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 Plattform bereitgestellte Auktionscode muss in JavaScript geschrieben sein. So können AdTech-Plattformen beispielsweise Gebotscode die die Privacy Sandbox unterstützen.

Rendering der erfolgreichen Anzeige

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 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, 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 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() 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 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 die von der Funktion zurückgegebene URL auf.
  • Signale für Käufer: Ein JSON-Objekt, das an das reportWin 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 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. 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. 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. 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 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 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 wird genauso geparst wie jede andere reguläre ARA-Quellenregistrierung. die Antwort wäre. 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 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 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 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 in der Attribution Reporting API, indem er auf Beacon-Anfragen mit Attribution-Reporting-Register-Source-Header. 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 Verkäufer, die Zugriff auf Attributionsdaten benötigen. Der Verkäufer kann auch eine eindeutige ID zum Senden mit registerAdBeacon() verwenden. 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 folgende 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.

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. Dieser Abruf erfolgt nur bei der Verarbeitung von Anzeigen von der benutzerdefinierten Zielgruppen. 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 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.

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 möchte möglicherweise erreichen, dass bestimmte Creatives nicht in ihrer App erscheinen, 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 Die Suche auf einem vertrauenswürdigen Server erfolgt auch ü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 Rendering-URLs sind. die in der Anfrage gesendet wurde.

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. Im Bereich Release-Version verwenden, wird die Anfrage nur an einen vertrauenswürdigen Schlüssel/Wert-Paar-Typ Server.

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.