Diese Seite wurde von der Cloud Translation API übersetzt.

Gebots- und Auktionsdienste

Im ursprünglichen Protected Audience-Angebot werden Gebote und Auktionen für Remarketing-Anzeigennachfrage wird lokal auf dem Gerät ausgeführt. Diese Anforderung kann Berechnungsanforderungen, die sich auf Geräten mit bestimmten eingeschränkte Prozessorleistung oder ist möglicherweise zu langsam, um Anzeigen auszuwählen und zu rendern. Netzwerklatenz.

Im Angebot „Gebots- und Auktionsdienste“ wird beschrieben, wie Sie Berechnung von Protected Audience auf Cloud-Servern an einem Ausführungsumgebung (Execution Environment, TEE), anstatt sie lokal auf dem Gerät eines Nutzers auszuführen. Die Das B&A-Angebot zielt darauf ab, einen einheitlichen Ablauf bei der Berücksichtigung von Kontext- und Remarketing-Anzeigennachfrage. Durch die Verlagerung von Berechnungen auf Server kann Protected Audience-Auktionen durch weniger Rechenzyklen und Netzwerk Bandbreite für ein Gerät.

Google stellt die Komponenten von B&A zur Verfügung und wird als Open Source. Interessierte AdTechs können ihre eigenen Instanzen mit unterstützten Anbieter öffentlicher Clouds. Weitere Informationen zum B&A-Vorschlag finden Sie unter GitHub Beachten Sie, dass die in diesem Dokument angegebenen Daten den Implementierung für Chrome. Wir werden weitere Informationen in Android integriert werden. Dieses Dokument dient als Einführung und die neuen APIs, die Android für die Interaktion mit B&A bereitstellen wird. Wir posten erhalten Sie weitere technische Informationen zur Verwendung dieser neuen APIs in zukünftigen Updates.

Vorteile von B&A-Dienstleistungen

B&A bietet eine zusätzliche Option für die Durchführung einer Auktion innerhalb von Anzeigentechnologie-Anbietern. vertrauenswürdigen Servern mit einem von Google bereitgestellten Open-Source-Binärprogramm Nutzerdaten weiterhin auf dem Gerät verbleiben, und Google stellt APIs bereit, um diese Daten an das TEE senden. Weitere Informationen zu unserer Verschlüsselungsstrategie finden Sie unten.

Das bedeutet, dass einige Teile des Auktionsprozesses auf dem Gerät stattfinden, andere in der Cloud. Aus Sicht einer DSP wurden benutzerdefinierte Zielgruppen (beinhaltet Kandidatenanzeigen für Remarketing-Kampagnen), werden weiterhin auf dem Gerät mit den gleichen benutzerdefinierten APIs zur Zielgruppenverwaltung wie bei der Auktion auf dem Gerät Von einem aus der Perspektive der SSPs, Anfragen werden weiterhin auf dem Gerät ausgelöst und dieses Dokument beschreibt die neuen APIs, die verwendet werden. Für alle Parteien sollten die das Resultat einer Auktion auf dem Gerät beginnt, nachdem das B&A-Gespräch beendet wurde.

Der Hauptunterschied besteht darin, wo die Gebots-, Bewertungs- und Berichts-URL Generierungslogik ausgeführt wird. Anstatt Gebote, Auktionen und Berichte auszuführen, Logik auf dem Gerät, generateBid(), scoreAd(), reportResult() und Die reportWin()-Logik wird im TEE ausgeführt. Die Gebotslogik eines Käufers und die des Verkäufers Die Bewertungslogik wird in der eigenen B&A-Umgebung ausgeführt, in der Mitte der Protected Audience-Auktionsablauf:

Die Abbildung zeigt den Auktionsablauf von Protected Audience und zeigt, wo Gebote und Auktionen passen. — Der Auktionsablauf von Protected Audience

Datenverschlüsselung

Bei B&A, Protected Audience-Informationen wie benutzerdefinierten Zielgruppen und Geboten Beträge fließen vom Gerät über die AdTech-Server von Verkäufern zur Anzeigentechnologie des Käufers. Server und zurück zum Gerät übertragen. Daher verschlüsselt die Plattform Daten, die an Protected Audience-Dienste gesendet werden, und können nur von die attestiert wurden. Weitere Informationen zu Verschlüsselungsstrategien finden Sie unter GitHub

Architektur und Auktionsablauf

Bei diesem Vorschlag sind mehrere neue Komponenten erforderlich, die im GitHub, einschließlich des Datenflusses vom Gerät zum B&A

Abbildung, die den als Nächstes beschriebenen Auktionsfluss für einheitliche kontextbezogene und geschützte Zielgruppen zeigt — Einheitliche kontext- und Protected Audience-Auktionsablauf mit Bidding- und Auktionsdiensten

Auf übergeordneter Ebene wird der Datenfluss wie folgt beschrieben:

Verkäufer erheben auf dem Gerät Daten von Protected Audience mithilfe der getAdSelectionData-API.
Über das SDK auf dem Gerät wird eine Anfrage an die Verkäuferanzeige Diese Anfrage enthält kontextbezogene Nutzlast und ProtectedAudienceInput verschlüsselt.
Der Verkäuferanzeigendienst sendet eine Anfrage an die Echtzeitgebote (Real-Time-Bidding, RTB) Dienst, der außerhalb eines TEE ausgeführt wird, um mögliche kontextbezogene Anzeigen zu erhalten, und dann den Faktor und wählen Sie die erfolgreiche kontextbezogene Anzeige aus.
Der Verkäuferanzeigendienst sendet eine Anfrage an sein SellerFrontEnd- Dienst, der in einem TEE läuft.
Der SellerFrontEnd-Dienst sendet Anfragen mit käuferspezifischen Daten an BuyerFrontEnd-Dienste.
Käufer verwenden ihren eigenen Schlüssel/Wert-Dienst und ihre eigenen Gebote , der Gebote für Anzeigenkandidaten generiert, die aus Gerät für alle benutzerdefinierten Zielgruppen, die für das Remarketing in Betracht gezogen werden.
Der SellerFrontEnd-Dienst liest aus seinem Schlüssel/Wert Dienst und bewertet die möglichen Anzeigen. Das Ergebnis wird verschlüsselt und an den Anzeigendienst für Verkäufer zurückgesendet.
Der Verkäuferanzeigendienst gibt das verschlüsselte Ergebnis der erfolgreichen Auktion zurück. Optional kann ein an das SDK auf dem Gerät übergeben.
Auf dem Gerät wird die erfolgreiche Anzeige über die processAdSelectionResult API, die die Antwort der Verkäuferanzeige entschlüsselt .

Eine detaillierte Beschreibung der einzelnen Schritte und die Verschlüsselung von Daten finden Sie auf der GitHub Der Code für diese Komponenten wird über Open Source. Der bereitgestellte Code steuert die Föderation von Anfragen aus SellerFrontEnd-Dienst zu BuyerFrontEnd-Diensten.

Cloud-Bereitstellung

AdTechs stellen B&A-Dienste in einer unterstützten öffentlichen Cloud bereit. Plattform. Diese Bereitstellungen werden von AdTech-Teams verwaltet, ist für die Definition eines Verfügbarkeits-Service Level Objective verantwortlich.

Eine Auktion durchführen

Der erste Schritt zur Durchführung der B&A-Auktion besteht darin, die Daten auf dem Gerät zu erfassen. und verschlüsseln Sie diese, damit sie an die serverseitigen Auktionen gesendet werden. Aufgabe verwenden Sie die getAdSelectionData API:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

Die Methode getAdSelectionData generiert die erforderliche Eingabe für B&A-Komponenten. wie BuyerInput und ProtectedAudienceInput und verschlüsselt die Daten, bevor sie das Ergebnis, das dem Aufrufer zur Verfügung steht. Um Datenlecks in Apps zu vermeiden, Die Daten enthalten Informationen von allen auf dem Gerät vorhandenen Käufern. Weitere Informationen zu finden Sie im Abschnitt Überlegungen zum Datenschutz.

Diese API gibt ein AdSelectionData-Objekt zurück:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Mit dieser AdSelectionData kann das On-Device-SDK eine Anfrage an Anzeigendienst des Verkäufers durch Einfügen der Daten in eine POST- oder PUT-Anfrage:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

Für die Codierung dieser Daten ist das On-Device-SDK verantwortlich. Es wird empfohlen, Eine platzsparende Lösung wie das Senden der Anfrage an die Verkäuferanzeige Dienst als multipart/form-data.

Nach der Initiierung der Anfrage leitet der Verkäufer-Anzeigendienst sie an den SellerFrontEnd-Dienst, der in einem TEE ausgeführt wird. Beim Konfigurieren eines SellerFrontEnd , stellen die Verkäufer eine Liste mit Domainadressen bereit, den BuyerFrontEnd-Diensten entsprechen, die von den Käufern betrieben werden und der mit denen Sie eine Partnerschaft eingegangen sind. Anfragen werden mit den verschiedenen BuyerFrontEnd verknüpft Dienste, die der Verkäufer bereitgestellt hat, damit Käufer für die ausgewählten Anzeigenkandidaten. Bei einem bestimmten Käufer sendet B&A zu benutzerdefinierten Zielgruppen des Käufers, Datenlecks zwischen Käufern. Nachdem die Gebote erstellt wurden, Mögliche Anzeigen werden an den SellerFrontEnd-Dienst zurückgesendet, wenn der Gewinner ausgewählt. Schließlich gibt der SellerFrontEnd-Dienst die verschlüsselte erfolgreiche Anzeige zurück. auf das Gerät übertragen.

Mit der Antwort auf die Anfrage an den Verkäufer-Anzeigendienst auf dem Gerät bietet die Plattform eine zweite neue API, um das Ergebnis zu entschlüsseln und eine AdSelectionOutcome, dasselbe Objekt, das von einer On-Device-Auktion zurückgegeben wird heute.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Berichterstellung

Berichts-URLs werden in B&A-Diensten generiert. Pings an diese URLs für müssen die Berichterstellung für Impressionen und Interaktionen für Auktionen auf dem Gerät ausgelöst. Das On-Device-SDK muss trotzdem reportImpression() und reportInteraction() APIs mit AdSelectionId, die während des B&A-Vorgangs generiert wurden. Beacons generiert für Interaktionsberichte und die entsprechenden URLs sind im verschlüsselte Antwort, sodass während der Entschlüsselung der Antwort Ereignisse und URL Zuordnungen auf dem Gerät gespeichert.

Überlegungen zum Datenschutz

Die Seite Browser-Gebote und Auktions-API-Angebot auf GitHub beschreibt wie Datenschutzaspekte berücksichtigt wurden. Für dieses Angebot wird die Nomenklatur, aber die gleichen Prinzipien gelten auch für Android.

adSelectionData ist verschlüsselt, damit nur Daten bei der Übertragung zugänglich sind zu PPAPI und den vertrauenswürdigen Servern. Um das Risiko von Datenlecks aufgrund adSelectionData Größenänderungen, wir planen, die gleichen adSelectionData zu generieren für alle Aufrufe der getAdSelectionData API. Dies impliziert, dass alle CustomAudience auf dem Gerät werden zum Erstellen von adSelectionData verwendet. Außerdem den Einfluss von GetAdSelectionData-Eingabeparametern auf die adSelectionData generiert.

Dieselbe adSelectionData für alle Anzeigentechnologie-Anbieter generieren, die alle führt zu einer höheren Nutzlast, die in jedem einen Aufruf an den AdTech-Server, wodurch das Werbesystem missbraucht werden kann. vor schädlichen Entitäten zu schützen. Diese Probleme werden in der Spalte Größe Überlegungen und Überlegungen vor Missbrauch weiter unten.

Überlegungen zur Größe

Das AdTech-Client-SDK soll die verschlüsselten Byte der adSelectionData in einen Aufruf von kontextbezogenen Anzeigen an den Server des Verkäufers. Für eine optimale Leistung ist es wichtig, die Größe der adSelectionData ohne Abstriche bei der Funktionalität. Wir planen, wie oben im Abschnitt Nutzlastoptimierung erklären, um die Größe adSelectionData zu verringern. Diese Optimierungen umfasst Folgendes:

ad_render_id wird in CustomAudience hinzugefügt, damit die Nachricht gesendet wird: adSelectionData statt den URI und Metadaten des Anzeigen-Renderings zu verwenden. Anzeigentechnologie-Anbieter können können Sie diese weiter optimieren, indem Sie keine Anzeigendaten in adSelectionData senden. Diese Option wird in zukünftigen Releases in CustomAudience API unterstützt.
Achten Sie darauf, dass user_bidding_signals nicht in adSelectionData gesendet werden. Stattdessen können Sie Techniker können user_bidding_signals von ihrem Schlüssel/Wert-Server abrufen.
Erlauben Sie Käufern, CustomAudience zu priorisieren.
Ermöglicht dem Käufer, die Verkäuferpriorität festzulegen.
Generieren Sie adSelectionData in einigen korrigierten Buckets, um Bitlecks zu begrenzen, während die die Nutzlastgröße reduzieren.

Die Größe wird unter Berücksichtigung der Datenschutzbedenken optimiert zu berücksichtigen.

Überlegungen zum Schutz vor Missbrauch

Wie unter datenschutzrechtlichen Bestimmungen erwähnt, wird adSelectionData mithilfe von alle Käuferdaten auf dem Gerät.

Dadurch wird das System für potenziell bösartige Entitäten geöffnet, betrügerische Käuferdaten, die die Leistung beeinträchtigen könnten, Nutzlasten aufblähen, um Kosten usw.

Um den Missbrauch von adSelectionData zu bekämpfen, werden folgende Maßnahmen ergriffen

CustomAudience erlauben, genehmigte Verkäufer und Verkäufer explizit anzugeben Priorität
SSPs erlauben, den Käufer, die Käuferpriorität und das Kontingent pro Käufer ausdrücklich in der Nutzlast generiert
Sie stellen einen Mechanismus für SSPs bereit, mit dem eine maximale Anzahl von Käufern pro Aufruf oder maximale Größe pro Käufer.

AdTechs können so festlegen, welche anderen Anzeigentechnologien mit denen sie zusammenarbeiten, und akzeptable Grenzen für die adSelectionData festzulegen Nutzlast, die sie verarbeiten müssten. Wir schlagen vor, dass der Verkäufer diese Käuferliste und deren Priorität in einem separaten Anruf an. Diese Spezifikation wird über einen bestimmten Zeitraum konstant bleiben, um zu vermeiden, dass zusätzliche Daten preisgegeben werden. wiederholte Anrufe erhalten.

Die oben erwähnten Maßnahmen werden noch diskutiert und werden im Laufe der Zeit . Wie bereits erwähnt, wurden alle Maßnahmen zur Bekämpfung von Missbrauch und zur Größenordnung müssen Datenschutzaspekte berücksichtigt werden.