Gebots- und Auktionsdienste

bookmark_border Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Im ursprünglichen Protected Audience-Vorschlag werden Gebote und Auktionen für die Remarketing-Anzeigennachfrage lokal auf dem Gerät ausgeführt. Diese Anforderung kann hohe Rechenanforderungen mit sich bringen, die auf Geräten mit begrenzter Rechenleistung nicht praktikabel sind, oder aufgrund der Netzwerklatenz zu langsam für die Auswahl und das Rendern von Anzeigen sein.

Der Vorschlag für Bidding and Auction Services (B&A) beschreibt eine Möglichkeit, die Berechnung von geschützten Zielgruppen auf Cloud-Servern in einer Trusted Execution Environment (TEE) auszuführen, anstatt sie lokal auf dem Gerät eines Nutzers auszuführen. Der B&A-Vorschlag zielt darauf ab, einen einheitlichen Ablauf für die Berücksichtigung der Nachfrage nach kontextbezogenen und Remarketing-Anzeigen zu unterstützen. Wenn Sie die Berechnungen auf Server umstellen, können Sie die Auktion für geschützte Zielgruppen optimieren, da so Rechenzyklen und Netzwerkbandbreite für ein Gerät freigesetzt werden.

Google stellt die Komponenten von B&A zur Verfügung und diese werden als Open Source verfügbar gemacht. Interessierte Anbieter von Anzeigentechnologien können ihre eigenen Instanzen bei unterstützten Public-Cloud-Anbietern hosten. Weitere Informationen zum B&A-Vorschlag finden Sie auf GitHub. Die in diesem Dokument angegebenen Zeiträume beziehen sich auf die Implementierung in Chrome. Weitere Informationen zur Integration in Android werden wir in Zukunft veröffentlichen. Dieses Dokument dient als Einführung in B&A und die neuen APIs, die Android für die Interaktion mit B&A bereitstellen wird. In zukünftigen Updates veröffentlichen wir weitere technische Informationen zur Verwendung dieser neuen APIs.

Rolle von B&A-Diensten

B&A bietet eine zusätzliche Option zum Ausführen einer Auktion auf vertrauenswürdigen Servern von Anbietern von Anzeigentechnologien, auf denen ein von Google bereitgestelltes Open-Source-Binärprogramm ausgeführt wird. Nutzerdaten befinden sich weiterhin auf dem Gerät. Google stellt APIs bereit, mit denen diese Daten sicher in den TEE verschoben werden können. Weitere Informationen zu unserer Verschlüsselungsstrategie finden Sie unten.

Das bedeutet, dass einige Teile des Auktionsprozesses auf dem Gerät und andere in der Cloud stattfinden. Aus Sicht einer DSP werden benutzerdefinierte Zielgruppen (einschließlich infrage kommender Anzeigen für Remarketing-Kampagnen) weiterhin auf dem Gerät mit denselben APIs zur Verwaltung benutzerdefinierter Zielgruppen verwaltet wie bei der Durchführung der Auktion auf dem Gerät. Aus Sicht der SSPs werden Anfragen weiterhin auf dem Gerät ausgelöst. In diesem Dokument werden die neuen APIs beschrieben, die verwendet werden. Für alle Parteien beginnt die Meldung des Ergebnisses einer Auktion weiterhin auf dem Gerät, nachdem der B&A-Anruf beendet ist.

Der Hauptunterschied besteht darin, wo die Logik zur Gebotsabgabe, Bewertung und Berichterstellung für die URL-Generierung ausgeführt wird. Anstatt Gebote, Auktionen und Berichtslogik auf dem Gerät auszuführen, wird die Logik von generateBid(), scoreAd(), reportResult() und reportWin() in der TEE ausgeführt. Die Gebotslogik des Käufers und die Bewertungslogik des Verkäufers werden in der jeweiligen B&A-Umgebung ausgeführt, in der Mitte des Auktionsablaufs für geschützte Zielgruppen:

Datenverschlüsselung

Bei B&A werden Protected Audience-Informationen wie benutzerdefinierte Zielgruppen und Gebotsbeträge vom Gerät über die Anzeigentechnologie-Server des Verkäufers an die Anzeigentechnologie-Server des Käufers und zurück zum Gerät gesendet. Aus diesem Grund werden Daten, die an Protected Audience-Dienste gesendet werden, von der Plattform verschlüsselt und können nur von Diensten entschlüsselt werden, die attestiert wurden. Weitere Informationen zu Verschlüsselungsstrategien finden Sie auf GitHub.

Architektur und Auktionsablauf

Dieser Vorschlag umfasst die Notwendigkeit mehrerer neuer Komponenten, die auf GitHub beschrieben werden, einschließlich des Datenflusses vom Gerät zu B&A.

Der Datenfluss wird grob so beschrieben:

1. Auf dem Gerät erfassen Verkäufer Informationen aus Protected Audience mithilfe der getAdSelectionData API.
2. Das On-Device-SDK sendet eine Anfrage an den Anzeigendienst des Verkäufers. Diese Anfrage enthält eine kontextbezogene Nutzlast und eine verschlüsselte ProtectedAudienceInput.
3. Der Anzeigendienst des Verkäufers sendet eine Anfrage an den Echtzeitgebotsservice (Real Time Bidding, RTB) des Käufers, der außerhalb einer TEE ausgeführt wird, um kontextbezogene Anzeigen zu erhalten. Anschließend wird eine kontextbezogene Anzeige bewertet und ausgewählt.
4. Der Verkäufer-Anzeigendienst sendet eine Anfrage an seinen SellerFrontEnd-Dienst, der in einem TEE ausgeführt wird.
5. Der SellerFrontEnd-Dienst sendet Anfragen mit käuferspezifischen Daten an BuyerFrontEnd-Dienste.
6. Käufer verwenden ihren eigenen Schlüssel/Wert-Dienst und Gebotsservice, mit dem Gebote für Anzeigenkandidaten generiert werden, die vom Gerät stammen, für alle benutzerdefinierten Zielgruppen, die für Remarketing infrage kommen.
7. Der SellerFrontEnd-Dienst liest aus seinem Schlüssel/Wert-Dienst und bewertet die Anzeigen. Das Ergebnis wird verschlüsselt und an den Verkäufer-Werbedienst zurückgegeben.
8. Der Dienst für Verkäuferanzeigen gibt das verschlüsselte Gewinnerergebnis und optional ein kontextbezogenes Ergebnis an das On-Device-SDK zurück.
9. Auf dem Gerät rufen Verkäufer die Gewinneranzeige über die processAdSelectionResult API ab, die die Antwort vom Verkäufer-Anzeigendienst entschlüsselt.

Eine detaillierte Beschreibung der einzelnen Schritte und der Datenverschlüsselung finden Sie auf GitHub. Der Code für diese Komponenten wird als Open Source-Code verfügbar gemacht. Der bereitgestellte Code verarbeitet die Verknüpfung von Anfragen vom SellerFrontEnd-Dienst an BuyerFrontEnd-Dienste.

Cloud-Bereitstellung

Anbieter von Anzeigentechnologien stellen B&A-Dienste auf einer unterstützten öffentlichen Cloud-Plattform bereit. Diese Bereitstellungen werden von Ad Tech-Experten verwaltet, die für die Definition eines Service Level Objectives für die Verfügbarkeit verantwortlich sind.

Auktion ausführen

Der erste Schritt bei der Durchführung der B&A-Auktion besteht darin, die Daten aus benutzerdefinierten Zielgruppen auf dem Gerät zu erfassen und zu verschlüsseln, damit sie an die serverseitigen Auktionen gesendet werden können. Verwenden Sie dazu die getAdSelectionData API:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

Die getAdSelectionData-Methode generiert die erforderliche Eingabe für B&A-Komponenten wie BuyerInput und ProtectedAudienceInput und verschlüsselt die Daten, bevor das Ergebnis für den Aufrufer verfügbar gemacht wird. Um Datenlecks zwischen Apps zu verhindern, enthalten diese Daten Informationen von allen Käufern, die sich auf dem Gerät befinden. Weitere Informationen zu dieser Entscheidung finden Sie im Abschnitt Datenschutzaspekte.

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 den Verkäufer-Werbedienst senden, indem die Daten in eine POST- oder PUT-Anfrage aufgenommen werden:

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

Das On-Device-SDK ist für die Codierung dieser Daten verantwortlich. Wir empfehlen, eine platzsparende Lösung zu verwenden, z. B. das Senden der Anfrage an den Anzeigendienst des Verkäufers als multipart/form-data.

Sobald die Anfrage gestartet wurde, leitet der Seller Ad-Dienst die Anfrage an den SellerFrontEnd-Dienst weiter, der in einem TEE ausgeführt wird. Beim Konfigurieren eines SellerFrontEnd-Dienstes geben Verkäufer eine Liste von Domainadressen an, die den BuyerFrontEnd-Diensten entsprechen, die von den Käufern betrieben werden, mit denen der Verkäufer eine Partnerschaft hat. Anfragen werden an die verschiedenen vom Verkäufer bereitgestellten Buyer-Frontend-Dienste weitergeleitet, damit Käufer Gebote für die ausgewählten Anzeigenkandidaten generieren können. Für einen bestimmten Käufer sendet B&A nur Informationen zu benutzerdefinierten Zielgruppen, die dem Käufer gehören, damit keine Daten zwischen Käufern weitergegeben werden. Nach dem Generieren der Gebote wird die Liste der ausgewählten Anzeigen an den SellerFrontEnd-Dienst zurückgegeben, wo ein Gewinner ausgewählt wird. Schließlich gibt der SellerFrontEnd-Dienst die verschlüsselte Anzeige zurück, die die Auktion gewonnen hat.

Nachdem die Antwort auf die Anfrage an den Verkäufer-Werbedienst auf dem Gerät eingegangen ist, bietet die Plattform eine zweite neue API, um das Ergebnis zu entschlüsseln und ein AdSelectionOutcome zurückzugeben. Das ist dasselbe Objekt, das derzeit von einer On-Device-Auktion zurückgegeben wird.

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);

Berichte

URLs für Berichte werden in B&A-Diensten generiert. Pings an diese URLs zur Berichterstellung von Impressionen und Interaktionen für Auktionen müssen weiterhin auf dem Gerät ausgelöst werden. Das On-Device-SDK muss weiterhin die APIs reportImpression() und reportInteraction() mithilfe des während des B&A-Flows generierten AdSelectionId aufrufen. Für Interaktionsberichte generierte Beacons und die entsprechenden URLs sind in der verschlüsselten Antwort enthalten. Bei der Entschlüsselung der Antwort werden die Ereignisse und URL-Zuordnungen auf dem Gerät gespeichert.

Datenschutzaspekte

Im Vorschlag für die Browser Bidding & Auction API auf GitHub wird beschrieben, wie Datenschutzaspekte berücksichtigt wurden. In diesem Vorschlag wird die Nomenklatur von Chrome verwendet, dieselben Prinzipien gelten jedoch auch für Android.

adSelectionData wird verschlüsselt, damit nur PPAPI und die vertrauenswürdigen Server auf die Daten zugreifen können. Um das Risiko von Datenlecks aufgrund von Änderungen der adSelectionData-Größe zu minimieren, planen wir, für alle Aufrufe der getAdSelectionData API dieselbe adSelectionData zu generieren. Das bedeutet, dass alle CustomAudience auf dem Gerät zum Erstellen von adSelectionData verwendet werden. Außerdem möchten wir den Einfluss von GetAdSelectionData-Eingabeparametern auf die generierten adSelectionData einschränken.

Wenn dieselbe adSelectionData für alle Anzeigentechnologien generiert wird, wobei alle On-Device-Auktionsdaten verwendet werden, führt dies zu einer höheren Nutzlast, die bei jedem Aufruf des AdTech-Servers übertragen werden muss. Außerdem wird das System potenziell für Missbrauch durch böswillige Akteure geöffnet. Diese Punkte werden unten in den Abschnitten Größe und Maßnahmen zum Schutz vor Missbrauch behandelt.

Überlegungen zur Größe

Das Ad Tech-Client-SDK soll die verschlüsselten Bytes von adSelectionData in einen Aufruf für kontextbezogene Anzeigen verpacken, der an den Server des Verkäufers gesendet wird. Für eine optimale Leistung ist es wichtig, die Größe von adSelectionData zu optimieren, ohne die Funktionalität zu beeinträchtigen. Wir planen, Optimierungen einzuführen, wie sie in der Erläuterung zur Nutzlastoptimierung erwähnt werden, um die Größe von adSelectionData zu reduzieren. Zu diesen Optimierungen gehören:

1. ad_render_id in CustomAudience hinzufügen, damit die Anfrage mit adSelectionData statt mit dem Anzeigen-Render-URI und den Metadaten gesendet wird Anbieter von Anzeigentechnologien können dies weiter optimieren, indem sie keine Anzeigendaten in adSelectionData senden. Diese Option wird in zukünftigen Releases der CustomAudience API unterstützt.
2. Achten Sie darauf, dass user_bidding_signals nicht in adSelectionData gesendet werden. Stattdessen können Anzeigentechnologien user_bidding_signals von ihrem Schlüssel/Wert-Server abrufen.
3. Käufern erlauben, CustomAudience zu priorisieren
4. Dem Käufer erlauben, die Verkäuferpriorität anzugeben.
5. Generieren Sie adSelectionData in einigen festen Buckets, um Bitverluste zu begrenzen und gleichzeitig die Nutzlastgröße zu reduzieren.

Bei der Größenoptimierung werden die im Hinblick auf den Datenschutz geäußerten Bedenken berücksichtigt.

Maßnahmen gegen Missbrauch

Wie bereits unter „Datenschutzaspekte“ erwähnt, wird adSelectionData anhand aller Käuferdaten auf dem Gerät generiert.

Das öffnet das System für potenziell schädliche Entitäten, die betrügerische Käuferdaten hinzufügen könnten, die die Leistung beeinträchtigen, Nutzlasten vergrößern und so die Kosten erhöhen.

Um Missbrauch von adSelectionData zu bekämpfen, führen wir die folgenden Maßnahmen ein:

• CustomAudience erlauben, genehmigte Verkäufer und die Verkäuferpriorität explizit anzugeben
• SSPs erlauben, Käufer, Käuferpriorität und Kontingent pro Käufer in der generierten Nutzlast explizit anzugeben
• SSPs müssen einen Mechanismus bereitstellen, mit dem sie eine maximale Anzahl von Käufern pro Aufruf oder eine maximale Größe pro Käufer definieren können.

Mit diesen Maßnahmen können Anbieter von Anzeigentechnologien festlegen, mit welchen anderen Anbietern sie zusammenarbeiten, und akzeptable Limits für die adSelectionData-Nutzlast festlegen, die sie verarbeiten müssen. Wir schlagen vor, dem Verkäufer zu ermöglichen, diese Käuferliste und Priorität in einem separaten Aufruf anzugeben. Diese Angabe bleibt über einen bestimmten Zeitraum hinweg konstant, um zu vermeiden, dass durch wiederholte Aufrufe zusätzliche Daten über den Nutzer offengelegt werden.

Die oben genannten Maßnahmen werden derzeit diskutiert und können sich im Laufe der Zeit ändern. Wie bereits erwähnt, müssen alle Maßnahmen zur Missbrauchsprävention und Größenbeschränkung den Datenschutzanforderungen entsprechen.