Gebots- und Auktionsdienste

Im ersten Protected Audience-Angebot werden Gebote und Auktionen für die Nachfrage nach Remarketing-Anzeigen lokal auf dem Gerät ausgeführt. Diese Anforderung kann Rechenanforderungen erfordern, die auf Geräten mit begrenzter Prozessorleistung möglicherweise nicht ausgeführt werden können oder aufgrund der Netzwerklatenz möglicherweise zu langsam sind, um Anzeigen auszuwählen und zu rendern.

Das Angebot für Gebots- und Auktionsdienste beschreibt eine Möglichkeit, die Berechnung durch Protected Audience auf Cloud-Servern in einer vertrauenswürdigen Ausführungsumgebung (TEE) zu ermöglichen, anstatt sie lokal auf dem Gerät eines Nutzers auszuführen. Das B&A-Angebot zielt darauf ab, einen einheitlichen Ablauf zur Berücksichtigung der Nachfrage nach kontextbezogenen Anzeigen und Remarketing-Anzeigen zu unterstützen. Durch das Verschieben von Berechnungen auf Server können Sie die Protected Audience-Auktion optimieren, da Rechenzyklen und Netzwerkbandbreite für ein Gerät freigegeben werden.

Google stellt die Komponenten von B&A bereit und sie werden als Open Source zur Verfügung gestellt. Interessierte Anzeigentechnologie-Anbieter können ihre eigenen Instanzen mit unterstützten Anbietern öffentlicher Clouds hosten. Weitere Informationen zum B&A-Angebot finden Sie auf GitHub. Hinweis: Die Angaben in diesem Dokument beziehen sich auf die Implementierung von Chrome. Wir werden in Zukunft weitere Informationen zur Integration von Android veröffentlichen. Dieses Dokument dient als Einführung in B&A und die neuen APIs, die Android für die Interaktion mit B&A zur Verfügung stellt. Wir werden in zukünftigen Updates weitere technische Informationen zur Verwendung dieser neuen APIs veröffentlichen.

B&A-Dienstleistungen

B&A bietet eine zusätzliche Option für die Durchführung einer Auktion innerhalb von vertrauenswürdigen Servern von AdTech, auf der ein von Google bereitgestelltes Open-Source-Binärprogramm ausgeführt wird. Nutzerdaten sind weiterhin auf dem Gerät gespeichert und Google stellt APIs zur sicheren Übertragung dieser Daten auf das TEE bereit. 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 möglicher Anzeigen für Remarketing-Kampagnen) weiterhin auf dem Gerät mit denselben APIs für die benutzerdefinierte Zielgruppenverwaltung verwaltet wie bei der Auktion auf dem Gerät. Aus Sicht von SSPs werden Anfragen weiterhin auf dem Gerät ausgelöst. In diesem Dokument werden die neuen APIs beschrieben, die verwendet werden. Das Ergebnis einer Auktion wird nach Abschluss des B&A-Aufrufs immer noch auf dem Gerät gemeldet.

Der Hauptunterschied besteht darin, wo die Logik zum Generieren von Gebots-, Bewertungs- und Berichts-URLs ausgeführt wird. Anstatt die Gebots-, Auktions- und Berichtslogik auf dem Gerät auszuführen, wird generateBid()-, scoreAd()-, reportResult()- und reportWin()-Logik im TEE ausgeführt. Die Gebotslogik und Bewertungslogik eines Käufers wird in seiner eigenen B&A-Umgebung in der Mitte des Protected Audience-Auktionsablaufs ausgeführt:

Der Auktionsprozess für Protected Audience

Datenverschlüsselung

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

Architektur und Auktionsablauf

Für dieses Angebot sind mehrere neue Komponenten erforderlich, die auf GitHub beschrieben werden, einschließlich des Datenflusses vom Gerät zu B&A.

Einheitlicher Auktionsablauf für kontextbezogene und Protected Audience-Auktionen mit Gebots- und Auktionsdiensten

Auf übergeordneter Ebene wird der Datenfluss so beschrieben:

1. Auf dem Gerät erheben Verkäufer über die getAdSelectionData API Informationen von Protected Audience.
2. Das SDK auf dem Gerät sendet eine Anfrage an den Verkäuferanzeigendienst. Diese Anfrage enthält kontextbezogene Nutzlast und verschlüsselte ProtectedAudienceInput.
3. Der Verkäuferanzeigendienst sendet eine Anfrage an den RTB-Dienst (Real-Time-Bidding, Echtzeitgebote) des Käufers, der außerhalb eines TEE ausgeführt wird, um mögliche kontextbezogene Anzeigen zu erhalten. Anschließend bewerten Sie die kontextbezogene Anzeige und wählen diese aus.
4. Der Verkäuferanzeigendienst sendet eine Anfrage an seinen SellerFrontEnd-Dienst, der in einem TEE ausgeführt wird.
5. Über den SellerFrontEnd-Dienst werden Anfragen mit käuferspezifischen Daten an die BuyerFrontEnd-Dienste gesendet.
6. Käufer verwenden ihren eigenen Schlüssel/Wert-Dienst und Bidding-Dienst, mit dem Gebote für Anzeigenkandidaten vom Gerät für alle benutzerdefinierten Zielgruppen generiert werden, die für das Remarketing infrage kommen.
7. Der SellerFrontEnd-Dienst liest den Schlüssel/Wert-Dienst und bewertet die möglichen Anzeigen. Das Ergebnis wird verschlüsselt und an den Verkäuferanzeigendienst zurückgegeben.
8. Der Verkäuferanzeigendienst gibt das verschlüsselte erfolgreiche Ergebnis und optional ein kontextbezogenes Ergebnis an das SDK auf dem Gerät zurück.
9. Auf dem Gerät rufen Verkäufer die erfolgreiche Anzeige mithilfe der processAdSelectionResult API ab, die die Antwort des Verkäuferanzeigendienstes entschlüsselt.

Eine ausführliche Beschreibung der einzelnen Schritte und wie Daten verschlüsselt werden, finden Sie auf GitHub. Der Code für diese Komponenten wird über Open Source zur Verfügung gestellt. Der bereitgestellte Code verarbeitet die Föderation von Anfragen vom SellerFrontEnd-Dienst an den BuyerFrontEnd-Dienst.

Cloud-Bereitstellung

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

Auktion durchführen

Der erste Schritt für die B&A-Auktion besteht darin, die Daten aus benutzerdefinierten Zielgruppen auf dem Gerät zu erfassen und zu verschlüsseln, um sie an serverseitige Auktionen zu senden. 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 dem Aufrufer zur Verfügung gestellt wird. Um Datenlecks in den 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 diesem AdSelectionData kann das SDK auf dem Gerät eine Anfrage an den Anzeigendienst des Verkäufers senden, indem die Daten in eine POST- oder PUT-Anfrage aufgenommen werden:

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

Das SDK auf dem Gerät ist für die Codierung dieser Daten verantwortlich. Wir empfehlen, eine platzsparende Lösung zu verwenden, z. B. die Anfrage als multipart/form-data an den Anzeigendienst für Verkäufer senden.

Sobald die Anfrage initiiert wurde, leitet der Anzeigendienst für Verkäufer sie an den in einem TEE ausgeführten SellerFrontEnd-Dienst weiter. Bei der Konfiguration eines SellerFrontEnd-Dienstes stellen Verkäufer eine Liste mit Domainadressen zur Verfügung, die den BuyerFrontEnd-Diensten entsprechen, die von den Käufern betrieben werden, mit denen der Verkäufer eine Partnerschaft hat. Anfragen werden mit den verschiedenen BuyerFrontEnd-Diensten des Verkäufers föderiert, damit die 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 ihm gehören, damit keine Datenlecks unter den Käufern entstehen. Nachdem die Gebote generiert wurden, wird die Liste der Kandidatenanzeigen an den SellerFrontEnd-Dienst zurückgesendet, um den Gewinner auszuwählen. Schließlich gibt der SellerFrontEnd-Dienst die verschlüsselte erfolgreiche Anzeige an das Gerät zurück.

Nachdem die Antwort auf die Anfrage an den Anzeigendienst des Verkäufers auf dem Gerät zurückgegeben wird, bietet die Plattform eine zweite neue API, um das Ergebnis zu entschlüsseln und ein AdSelectionOutcome bereitzustellen. Dabei handelt es sich um dasselbe Objekt, das heute bei 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);

Berichterstellung

Berichts-URLs werden in B&A-Diensten generiert. Pings an diese URLs, um Impressionen und Interaktionen für Auktionen zu erfassen, müssen weiterhin auf dem Gerät ausgelöst werden. Das SDK auf dem Gerät muss weiterhin die APIs reportImpression() und reportInteraction() mit AdSelectionId aufrufen, die während des B&A-Vorgangs generiert wurden. Beacons, die für Berichte zu Interaktionen generiert werden, und die entsprechenden URLs sind in der verschlüsselten Antwort enthalten. So werden beim Entschlüsseln der Antwort Ereignisse und URL-Zuordnungen auf dem Gerät gespeichert.

Überlegungen zum Datenschutz

Im Vorschlag für die Browser-Gebote und Auktions-API auf GitHub wird beschrieben, wie Datenschutzaspekte berücksichtigt wurden. Dieser Vorschlag nutzt die Nomenklatur von Chrome, aber die Prinzipien gelten auch für Android.

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

Wenn dieselbe adSelectionData für alle Anzeigentechnologien generiert wird, die alle Auktionsdaten auf dem Gerät verwenden, führt dies zu einer höheren Nutzlast, die bei jedem Aufruf an den AdTech-Server übertragen werden muss. Gleichzeitig kann das System vor Missbrauch durch schädliche Entitäten geschützt werden. Diese Bedenken werden in den folgenden Abschnitten Überlegungen zur Größe und Überlegungen zum Schutz vor Missbrauch behandelt.

Hinweise zur Größe

Das Ad Tech Client SDK muss die verschlüsselten Byte von adSelectionData in einen Aufruf für kontextbezogene Anzeigen verpacken, die an den Server des Verkäufers gesendet werden. 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 in der Erläuterung zur Nutzlastoptimierung erwähnt, um die Größe von adSelectionData zu reduzieren. Zu diesen Optimierungen gehören:

1. ad_render_id wird in CustomAudience hinzugefügt, damit die Anfrage über adSelectionData gesendet wird, anstatt den URI und die Metadaten für das Anzeigenrendering zu verwenden. AdTech-Unternehmen können dies weiter optimieren, indem sie keine Anzeigendaten in adSelectionData senden. Diese Option wird in zukünftigen Releases in CustomAudience API unterstützt.
2. Achten Sie darauf, dass user_bidding_signals nicht in adSelectionData gesendet werden. Stattdessen können AdTech-Unternehmen user_bidding_signals von ihrem Schlüssel/Wert-Server abrufen.
3. Käufern erlauben, CustomAudience zu priorisieren.
4. Der Käufer kann die Verkäuferpriorität angeben.
5. Generieren Sie adSelectionData in einigen festen Buckets, um das Austreten von Bits zu begrenzen und gleichzeitig die Nutzlastgröße zu reduzieren.

Größenoptimierungen werden unter Berücksichtigung der Bedenken in Bezug auf den Datenschutz vorgenommen.

Überlegungen zum Schutz vor Missbrauch

Wie im Abschnitt zum Datenschutz erwähnt, wird adSelectionData mithilfe aller Käuferdaten auf dem Gerät generiert.

Dadurch wird das Ökosystem für potenziell schädliche Entitäten geöffnet, die betrügerische Käuferdaten hinzufügen, die die Leistung beeinträchtigen könnten, oder aufgeblähten Schadcodes, um die Kosten zu erhöhen.

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

• CustomAudience erlauben, die Priorität von genehmigten Verkäufern und Verkäufern explizit anzugeben
• SSPs erlauben, den Käufer, die Käuferpriorität und das Kontingent pro Käufer in der generierten Nutzlast explizit anzugeben
• Stellen Sie einen Mechanismus für Sell-Side-Plattformen zur Verfügung, um eine maximale Anzahl von Käufern pro Anruf oder eine maximale Größe pro Käufer zu definieren.

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

Die oben genannten Risikominderungen werden derzeit diskutiert und werden im Laufe der Zeit weiterentwickelt. Wie bereits erwähnt, müssen bei allen Maßnahmen gegen Missbrauch und Größenbeschränkungen Datenschutzaspekte berücksichtigt werden.