Gebots- und Auktionsdienste

Im ersten Protected Audience-Vorschlag werden Gebote und Auktionen für Remarketing-Anzeigenanfragen lokal auf dem Gerät ausgeführt. Diese Anforderung kann Rechenanforderungen stellen, die auf Geräten mit begrenzter Rechenleistung möglicherweise nicht praktikabel sind oder aufgrund von Netzwerklatenz zu langsam sind, um Anzeigen auszuwählen und zu rendern.

Im Vorschlag für Gebots- und Auktionsdienste (B&A) wird beschrieben, wie die Protected Audience-Berechnung auf Cloud-Servern in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) erfolgen kann, statt 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 von kontextbezogener und Remarketing-Anzeigennachfrage zu unterstützen. Wenn Sie die Berechnung auf Server verschieben, können Sie die Protected Audience-Auktion optimieren, da so Rechenzyklen und Netzwerkbandbreite für ein Gerät freigesetzt werden.

Google stellt die Komponenten von B&A bereit und sie werden als Open Source zur Verfügung gestellt. Interessierte Anbieter von Anzeigentechnologien können eigene Instanzen bei unterstützten öffentlichen Cloud-Anbietern hosten. Weitere Informationen zum B&A-Vorschlag finden Sie auf GitHub. Die in diesem Dokument angegebenen Daten beziehen sich auf die Implementierung für 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 bereitstellt. Wir werden in zukünftigen Updates weitere technische Informationen zur Verwendung dieser neuen APIs veröffentlichen.

Rolle von B&A-Diensten

B&A bietet eine zusätzliche Option für die Durchführung einer Auktion auf vertrauenswürdigen Servern, die von Ad-Tech-Unternehmen betrieben werden und auf denen eine von Google bereitgestellte Open-Source-Binärdatei ausgeführt wird. Nutzerdaten verbleiben auf dem Gerät und Google stellt APIs bereit, um diese Daten sicher in die TEE zu übertragen. Weitere Informationen zu unserer Verschlüsselungsstrategie

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 Kandidatenanzeigen für Remarketing-Kampagnen) weiterhin auf dem Gerät mit denselben APIs für die Verwaltung benutzerdefinierter Zielgruppen wie bei einer Auktion auf dem Gerät verwaltet. Aus Sicht einer SSP 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-Aufruf abgeschlossen ist.

Der Hauptunterschied besteht darin, wo die Logik für Gebote, Scoring und die Generierung von Berichts-URLs ausgeführt wird. Anstatt die Logik für Gebote, Auktionen und Berichte auf dem Gerät auszuführen, wird die Logik für generateBid(), scoreAd(), reportResult() und reportWin() in der TEE ausgeführt. Die Gebotslogik eines Käufers und die Scoring-Logik eines Verkäufers werden in der jeweiligen B&A-Umgebung in der Mitte des Protected Audience-Auktionsablaufs ausgeführt:

Datenverschlüsselung

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

Architektur und Auktionsablauf

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

Auf übergeordneter Ebene wird der Datenfluss so beschrieben:

1. Auf dem Gerät erheben Verkäufer Informationen aus Protected Audience mithilfe der getAdSelectionData API.
2. Das On-Device-SDK sendet eine Anfrage an den Seller Ad-Dienst. Diese Anfrage enthält eine kontextbezogene Nutzlast und verschlüsselte ProtectedAudienceInput.
3. Der Seller Ad-Dienst sendet eine Anfrage an den RTB-Dienst (Real-Time Bidding, Echtzeitgebote) der Käufer, der außerhalb einer TEE ausgeführt wird, um kontextbezogene Anzeigenkandidaten zu erhalten. Anschließend wird eine kontextbezogene Gewinneranzeige ausgewählt.
4. Der Dienst „Seller Ad“ sendet eine Anfrage an den SellerFrontEnd-Dienst, der in einer 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 Gebotsdienst, der Gebote für Anzeigenkandidaten generiert, die vom Gerät für alle benutzerdefinierten Zielgruppen stammen, die für das Remarketing infrage kommen.
7. Der SellerFrontEnd-Dienst liest Daten aus dem Schlüssel/Wert-Dienst und bewertet die infrage kommenden Anzeigen. Das Ergebnis wird verschlüsselt und an den Verkäuferanzeigendienst zurückgegeben.
8. Der Dienst „Seller Ad“ 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 mit der processAdSelectionResult API ab, die die Antwort des Seller Ad-Dienstes 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 zur Verfügung gestellt. Der bereitgestellte Code verarbeitet die Weiterleitung von Anfragen vom SellerFrontEnd-Dienst an BuyerFrontEnd-Dienste.

Cloud-Bereitstellung

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

Auktion ausführen

Der erste Schritt zum Ausführen 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 Methode getAdSelectionData 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 zu verhindern, dass Daten an andere Apps weitergegeben werden, enthält diese Datei Informationen von allen Käufern auf dem Gerät. 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 diesem AdSelectionData kann das On-Device-SDK eine Anfrage an den Seller Ad-Dienst 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. Es wird empfohlen, eine speichereffiziente Lösung zu verwenden, z. B. die Anfrage als multipart/form-data an den Seller Ad-Dienst zu senden.

Sobald die Anfrage initiiert wurde, leitet der Seller Ad-Dienst die Anfrage an den SellerFrontEnd-Dienst weiter, der in einer TEE ausgeführt wird. Beim Konfigurieren eines SellerFrontEnd-Dienstes geben Verkäufer eine Liste von Domainadressen an, die den von den Käufern betriebenen BuyerFrontEnd-Diensten entsprechen, mit denen der Verkäufer zusammenarbeitet. Anfragen werden an die verschiedenen BuyerFrontEnd-Dienste weitergeleitet, die der Verkäufer bereitgestellt hat, damit Käufer Gebote für ihre ausgewählten Anzeigenkandidaten generieren können. Für einen bestimmten Käufer sendet B&A nur Informationen zu benutzerdefinierten Zielgruppen, die dieser Käufer besitzt. So wird ein Datenabfluss zwischen Käufern verhindert. Nachdem die Gebote generiert wurden, wird die Liste der infrage kommenden Anzeigen an den SellerFrontEnd-Dienst zurückgegeben, in dem ein Gewinner ausgewählt wird. Schließlich gibt der SellerFrontEnd-Dienst die verschlüsselte Gewinneranzeige an das Gerät zurück.

Nachdem die Antwort auf die Anfrage an den Seller Ad-Dienst auf dem Gerät eingegangen ist, bietet die Plattform eine zweite neue API an, um das Ergebnis zu entschlüsseln und ein AdSelectionOutcome bereitzustellen. Das ist dasselbe Objekt, das heute bei einer Auktion auf dem Gerät 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

Berichts-URLs werden in B&A-Diensten generiert. Pings an diese URLs zum Melden 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() mit dem während des B&A-Ablaufs generierten AdSelectionId aufrufen. Für die Interaktionsberichterstellung generierte Beacons und die entsprechenden URLs sind in der verschlüsselten Antwort enthalten. Bei der Entschlüsselung der Antwort werden Ereignisse und URL-Zuweisungen auf dem Gerät gespeichert.

Datenschutz

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

adSelectionData ist verschlüsselt, damit Daten während der Übertragung nur für PPAPI und die vertrauenswürdigen Server zugänglich sind. Um das Risiko von Datenlecks aufgrund von adSelectionData-Größenänderungen 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 planen wir, den Einfluss von GetAdSelectionData-Eingabeparametern auf die generierten adSelectionData einzuschränken.

Wenn für alle Ad-Tech-Unternehmen dasselbe adSelectionData mit allen On-Device-Auktionsdaten generiert wird, führt dies zu einer höheren Nutzlast, die bei jedem Aufruf des Ad-Tech-Servers übertragen werden muss. Außerdem wird das Ökosystem dadurch möglicherweise für Missbrauch durch böswillige Akteure geöffnet. Diese Bedenken werden in den Abschnitten Größenüberlegungen und Überlegungen zum Schutz vor Missbrauch behandelt.

Überlegungen zur Größe

Das SDK des Ad-Tech-Clients 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 wie im Payload-Optimierungs-Explainer beschrieben einzuführen, um die Größe von adSelectionData zu reduzieren. Zu diesen Optimierungen gehören:

1. ad_render_id in CustomAudience hinzufügen, damit sie mit adSelectionData anstelle von Ad-Render-URI und Metadaten gesendet wird. Ad-Tech-Unternehmen können dies weiter optimieren, indem sie keine Anzeigendaten in adSelectionData senden. Diese Option wird in zukünftigen Versionen von CustomAudience API unterstützt.
2. Achten Sie darauf, dass user_bidding_signals nicht in adSelectionData gesendet werden. Stattdessen können Ad-Tech-Unternehmen 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 das Bit-Leakage zu begrenzen und gleichzeitig die Nutzlastgröße zu reduzieren.

Größenoptimierungen werden unter Berücksichtigung der in den Datenschutzhinweisen geäußerten Bedenken vorgenommen.

Überlegungen zu Maßnahmen gegen Missbrauch

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

Dadurch wird das Ökosystem für potenzielle schädliche Akteure geöffnet, die betrügerische Käuferdaten hinzufügen könnten, was die Leistung beeinträchtigen, die Nutzlasten aufblähen und die Kosten erhöhen könnte.

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

• CustomAudience kann zugelassene Verkäufer und die Priorität von Verkäufern explizit angeben.
• SSPs können Käufer, Käuferpriorität und Käuferkontingent in der generierten Nutzlast explizit angeben.
• Stellen Sie SSPs einen Mechanismus zur Verfügung, 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 Ad-Tech-Unternehmen festlegen, mit welchen anderen Ad-Tech-Unternehmen sie zusammenarbeiten, und akzeptable Grenzwerte für die adSelectionData-Nutzlast festlegen, die sie verarbeiten müssen. Wir schlagen vor, dass der Verkäufer diese Käuferliste und Priorität in einem separaten Aufruf angibt. Diese Spezifikation bleibt über einen bestimmten Zeitraum konstant, um nicht durch wiederholte Aufrufe zusätzliche Daten über den Nutzer preiszugeben.

Diese Maßnahmen werden derzeit diskutiert und können sich im Laufe der Zeit weiterentwickeln. Wie bereits erwähnt, müssen alle Maßnahmen zur Missbrauchsbekämpfung und Größenbeschränkungen den Datenschutzbestimmungen entsprechen.