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:
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
<ph type="x-smartling-placeholder">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 inCustomAudience
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 inadSelectionData
senden. Diese Option wird in zukünftigen Releases inCustomAudience API
unterstützt.- Achten Sie darauf, dass
user_bidding_signals
nicht inadSelectionData
gesendet werden. Stattdessen können Sie Techniker könnenuser_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.