Diese Seite wurde von der Cloud Translation API übersetzt.

Geschützte App-Signale zur Unterstützung relevanter App-Installationsanzeigen

Dieses Angebot unterliegt dem Anmeldeprozess und den Attestierungen für die Privacy Sandbox. Weitere Informationen zu den Attestierungen findest du unter dem bereitgestellten Bestätigungslink. In zukünftigen Aktualisierungen dieses Angebots werden die Anforderungen für den Zugriff auf dieses System beschrieben.

App-Installationsanzeigen werden auch als Anzeigen zur Nutzergewinnung bezeichnet. Sie sind eine Art von mobiler Werbung, mit der Nutzer zum Herunterladen einer App angeregt werden sollen. Diese Anzeigen werden Nutzern auf Grundlage ihrer Interessen und demografischen Merkmale präsentiert und erscheinen häufig in anderen mobilen Apps wie Spielen, sozialen Medien und Nachrichten-Apps. Wenn ein Nutzer auf eine App-Installationsanzeige klickt, wird er direkt zum App-Shop weitergeleitet, wo er die App herunterladen kann.

Wenn ein Werbetreibender beispielsweise in den USA die Anzahl der Installationen für eine neue mobile Lieferdienst-App steigern möchte, kann er seine Anzeigen auf Nutzer ausrichten, die sich in den USA befinden und die bereits mit anderen Lieferdienst-Apps interagiert haben.

Dazu werden in der Regel Kontext-, Erstanbieter- und Drittanbietersignale zwischen Anzeigentechnologien eingebunden, um Nutzerprofile auf Grundlage der Werbe-IDs zu erstellen. Die Modelle für maschinelles Lernen von AdTech-Modellen verwenden diese Informationen als Eingaben, um Anzeigen auszuwählen, die für den Nutzer relevant sind und mit der höchsten Wahrscheinlichkeit zu einer Conversion führen.

Die folgenden APIs werden zur Unterstützung effektiver App-Installationsanzeigen vorgeschlagen, die den Datenschutz für Nutzer verbessern, indem die Abhängigkeit von parteiübergreifenden Nutzerkennungen beseitigt wird:

Protected App Signals API: In dieser API werden Funktionen für Anzeigentechnologien gespeichert und erstellt, die potenzielle Interessen der Nutzer darstellen. Anzeigentechnologien speichern selbstdefinierte Ereignissignale pro App, z. B. App-Installationen, erstes Öffnen, Nutzeraktionen (In-Game-Level, Erfolge), Kaufaktivitäten oder Zeit in der App. Signale werden zum Schutz vor Datenlecks geschrieben und auf dem Gerät gespeichert. Sie stehen nur der AdTech-Logik zur Verfügung, die das entsprechende Signal während einer geschützten Auktion in einer sicheren Umgebung speichert.
Ad Selection API: Diese API bietet eine API zum Konfigurieren und Ausführen einer geschützten Auktion, die in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) ausgeführt wird, in der Anzeigentechnologie-Anbieter Anzeigenkandidaten abrufen, Inferenzen ausführen, Gebote berechnen und sowohl die kontextabhängigen vom Publisher bereitgestellten Signale als auch die von Publishern bereitgestellten Echtzeitinformationen auswählen.

Diagramm, das den Ablauf der App-Installation mit geschützten Signalen zeigt — Flussdiagramm, das den Workflow für geschützte App-Signale und die Anzeigenauswahl in der Privacy Sandbox für Android zeigt.

Im Folgenden finden Sie eine allgemeine Übersicht darüber, wie geschützte App-Signale relevante App-Installationsanzeigen unterstützen. In den folgenden Abschnitten dieses Dokuments finden Sie weitere Informationen zu den einzelnen Schritten.

Signalauswahl: Wenn Nutzer mobile Apps verwenden, wählen Anzeigentechnologien Signale aus, indem AdTech-definierte App-Ereignisse gespeichert werden, um mithilfe der Protected App Signals API relevante Anzeigen auszuliefern. Diese Ereignisse werden ähnlich wie bei benutzerdefinierten Zielgruppen in einem geschützten Speicher auf dem Gerät gespeichert und verschlüsselt, bevor sie vom Gerät gesendet werden. So können sie nur für Bidding- und Auktionsdienste, die in vertrauenswürdigen Ausführungsumgebungen mit entsprechenden Sicherheits- und Datenschutzeinstellungen ausgeführt werden, für Gebote und Bewertungen von Anzeigen entschlüsselt werden.
Signalcodierung: Signale werden in regelmäßigen Abständen von einer benutzerdefinierten AdTech-Logik erzeugt. Ein Android-Hintergrundjob führt diese Logik aus, um eine Codierung auf dem Gerät durchzuführen und eine Nutzlast von geschützten App-Signalen zu generieren, die später in Echtzeit während einer geschützten Auktion für die Anzeigenauswahl verwendet werden kann. Die Nutzlast wird sicher auf dem Gerät gespeichert, bis sie für eine Auktion gesendet wird.
Anzeigenauswahl: Zur Auswahl relevanter Anzeigen für den Nutzer senden Verkäufer-SDKs eine verschlüsselte Nutzlast von geschützten App-Signalen und konfigurieren eine geschützte Auktion. In der Auktion bereitet die benutzerdefinierte Logik des Käufers die geschützten App-Signale zusammen mit den vom Publisher bereitgestellten Kontextdaten (Daten, die normalerweise in einer Open-RTB-Anzeigenanfrage weitergegeben werden) vor, um Funktionen für die Anzeigenauswahl (Anzeigenabruf, Inferenz und Gebotserstellung) zu entwickeln. Ähnlich wie bei Protected Audience senden Käufer Anzeigen an den Verkäufer zur abschließenden Bewertung in einer geschützten Auktion.
- Anzeigenabruf: Käufer verwenden geschützte App-Signale und vom Publisher bereitgestellte Kontextdaten, um Funktionen zu entwickeln, die für die Interessen des Nutzers relevant sind. Anhand dieser Funktionen werden Anzeigen abgeglichen, die die Targeting-Kriterien erfüllen. Anzeigen, die nicht im Budgetrahmen enthalten, werden herausgefiltert. Die besten k Anzeigen werden dann für das Bidding ausgewählt.
- Gebote: Die Logik der benutzerdefinierten Gebotseinstellung des Käufers bereitet die vom Publisher bereitgestellten Kontextdaten und Protected App-Signale vor, um Funktionen zu entwickeln, die als Eingabe in Machine-Learning-Modellen des Käufers zur Inferenz und Gebotsabgabe für mögliche Anzeigen innerhalb vertrauenswürdiger datenschutzfreundlicher Grenzen verwendet werden. Der Käufer sendet die ausgewählte Anzeige dann an den Verkäufer zurück.
- Verkäuferbewertung: Die benutzerdefinierten Bewertungslogik des Verkäufers bewertet die Anzeigen, die von teilnehmenden Käufern eingereicht wurden, und wählt eine erfolgreiche Anzeige aus, die zum Rendern an die App zurückgesendet wird.
Berichterstellung: Auktionsteilnehmer erhalten entsprechende Gewinn- und Verlustberichte. Wir untersuchen datenschutzfreundliche Mechanismen, um Daten für das Modelltraining in den Erfolgsbericht aufzunehmen.

Zeitachse

	Entwicklervorschau			Beta
Funktion	4. Quartal 2023	1. Quartal 2024	2. Quartal 2024	3. Quartal 2024
APIs zur Signalauswahl	On-Device-Speicher-APIs	Logik des Speicherkontingents auf dem Gerät Tägliche Aktualisierungen der benutzerdefinierten Logik auf dem Gerät	–	Verfügbar für 1% T+ Geräte
Server zum Abrufen von Anzeigen in einem TEE	MVP	Verfügbar auf der Google Cloud Unterstützung für die Top-K -UDF-Produktion	In AWS verfügbar Debugging, Messwerte und Monitoring mit Einwilligung
Inferenzdienst in einem TEE Unterstützung für die Ausführung von ML-Modellen und ihre Verwendung für Gebote in einem TEE	In Entwicklung	Verfügbar auf der GCP Statische ML-Modelle mit Tensorflow und PyTorch bereitstellen und Prototypen erstellen	Verfügbar in AWS Produktionierte Modellbereitstellung für Tensorflow- und PyTorch-Modelle Telemetrie, Fehlerbehebung mit Einwilligung und Monitoring
Unterstützung von Geboten und Auktionen in einem TEE	Auf der GCP verfügbar	Integration von PAS-B&A- und TEE-Anzeigenabrufen (mit gRPC- und TEE<>TEE-Verschlüsselung) Unterstützung des Anzeigenabrufs über kontextbezogenen Pfad (einschließlich B&A<>K/V-Unterstützung für TEE)	In AWS verfügbar Fehlerbehebungsberichte Debugging, Messwerte und Monitoring mit Einwilligung

Geschützte App-Signale auswählen

Ein Signal ist eine Darstellung verschiedener Nutzerinteraktionen in einer App, die von der Anzeigentechnologie als nützlich für die Auslieferung relevanter Anzeigen bestimmt werden. Eine App oder das integrierte SDK können geschützte App-Signale, die von Anzeigentechnologien definiert wurden, auf Grundlage von Nutzeraktivitäten wie App-Öffnen, Erfolgen, Kaufaktivitäten oder der Zeit in der App speichern oder löschen. Geschützte App-Signale werden sicher auf dem Gerät gespeichert und verschlüsselt, bevor sie vom Gerät gesendet werden. So können sie nur für Gebots- und Auktionsdienste, die in vertrauenswürdigen Ausführungsumgebungen mit entsprechenden Sicherheits- und Datenschutzeinstellungen ausgeführt werden, für Gebote und Datenschutzeinstellungen entschlüsselt werden. Ähnlich wie bei der Custom Audience API können die auf einem Gerät gespeicherten Signale nicht von Apps oder SDKs gelesen oder geprüft werden. Es gibt keine API zum Lesen von Signalwerten und APIs sind darauf ausgelegt, die Weitergabe von Signalen zu verhindern. Die benutzerdefinierte AdTech-Logik hat geschützten Zugriff auf die ausgewählten Signale, um Funktionen zu entwickeln, die als Grundlage für die Anzeigenauswahl in einer geschützten Auktion dienen.

Protected App Signals API

Die Protected App Signals API unterstützt die Verwaltung von Signalen mit einem Delegierungsmechanismus, der dem für benutzerdefinierte Zielgruppen verwendeten Mechanismus ähnelt. Die Protected App Signals API ermöglicht die Signalspeicherung in Form eines einzelnen skalaren Werts oder als Zeitachse. Zeitreihensignale können zum Speichern von Daten wie der Nutzersitzungsdauer verwendet werden. Zeitachsensignale bieten ein Dienstprogramm, um eine bestimmte Länge zu erzwingen. Dazu wird eine Regel zum Entfernen von Einträgen in der Reihenfolge verwendet. Der Datentyp eines skalaren Signals oder jedes der Elemente eines Zeitreihensignals ist ein Bytearray. Jeder Wert wird mit dem Paketnamen der Anwendung, in der das Signal gespeichert wurde, und dem Erstellungszeitstempel des API-Aufrufs für das Speichersignal angereichert. Diese zusätzlichen Informationen sind im JavaScript-Code für die Signalcodierung verfügbar. Dieses Beispiel zeigt die Struktur der Signale einer bestimmten Anzeigentechnologie:

Dieses Beispiel zeigt ein skalares Signal und ein Zeitachsensignal, das adtech1.com zugeordnet ist:

Ein skalares Signal mit dem Base64-Wertschlüssel „A1c“ und dem Wert „c12Z“. Der Signalspeicher wurde am 1. Juni 2023 von com.google.android.game_app ausgelöst.
Eine Liste von Signalen mit dem Schlüssel „dDE“, die von zwei verschiedenen Anwendungen erstellt wurden.

AdTech-Mitarbeitern steht ein bestimmter Speicherplatz zur Verfügung, um Signale auf dem Gerät zu speichern. Für Signale gilt eine maximale TTL, die noch ermittelt werden muss.

Geschützte App-Signale werden aus dem Speicher entfernt, wenn die generierende Anwendung deinstalliert wird, wenn sie nicht mehr verwendet werden kann oder wenn die App-Daten vom Nutzer gelöscht werden.

Die Protected App Signals API besteht aus den folgenden Teilen:

eine Java- und JavaScript-API, um Signale hinzuzufügen, zu aktualisieren oder zu entfernen.
Eine JavaScript API zur Verarbeitung der persistenten Signale, um sie in Echtzeit während einer geschützten Auktion in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) für das Feature Engineering in Echtzeit vorzubereiten.

Signale hinzufügen, aktualisieren oder entfernen

Anzeigentechnologie-Anbieter können Signale mit der fetchSignalUpdates() API hinzufügen, aktualisieren oder entfernen. Diese API unterstützt die Delegierung ähnlich wie die Delegierung für benutzerdefinierte Zielgruppen in der Protected Audience API.

Um ein Signal hinzuzufügen, müssen Anzeigentechnologien von Käufern, die kein SDK in Apps haben, mit Anzeigentechnologie-Anbietern zusammenarbeiten, die auf dem Gerät präsent sind, z. B. Mobile Measurement Partners (MMPs) und Supply-Side-Plattformen (SSPs). Die Protected App Signals API soll diese Anzeigentechnologie unterstützen, indem sie flexible Lösungen für die Verwaltung von Protected App Signals bietet. Dazu wird auf Geräten ermöglicht, die Erstellung von Protected App-Signalen im Namen von Käufern aufzurufen. Dieser Vorgang wird als Delegierung bezeichnet und nutzt die fetchSignalUpdates() API. fetchSignalUpdates() ruft über einen URI eine Liste mit Signalaktualisierungen ab. Zur Veranschaulichung: fetchSignalUpdates() gibt eine GET-Anfrage an den angegebenen URI aus, um die Liste der Aktualisierungen abzurufen, die auf den lokalen Signalspeicher angewendet werden sollen. Der URL-Endpunkt, der dem Käufer gehört, antwortet mit einer JSON-Liste von Befehlen.

Folgende JSON-Befehle werden unterstützt:

put: Ein skalarer Wert für den angegebenen Schlüssel wird eingefügt oder überschrieben.
put_if_not_present: einen skalaren Wert für den angegebenen Schlüssel einfügt, wenn noch kein Wert gespeichert ist Diese Option kann beispielsweise nützlich sein, um eine Test-ID für einen bestimmten Nutzer festzulegen und zu vermeiden, dass sie überschrieben wird, wenn sie bereits von einer anderen Anwendung festgelegt wurde.
Anfügen: fügt der Zeitreihe, die mit dem angegebenen Schlüssel verknüpft ist, ein Element hinzu. Der Parameter „maxSignals“ gibt die maximale Anzahl von Signalen in der Zeitreihe an. Wird die Größe überschritten, werden die vorherigen Elemente entfernt. Wenn der Schlüssel einen Skalarwert enthält, wird er automatisch in eine Zeitachse umgewandelt.
remove: entfernt den mit dem angegebenen Schlüssel verknüpften Inhalt

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Alle Schlüssel und Werte werden in Base64 ausgedrückt.

Die oben aufgeführten Befehle dienen zum Bereitstellen einer Semantik zum Einfügen, Überschreiben und Löschen für skalare Signale sowie zum Überschreiben von Zeitreihensignalen durch Einfügen, Anfügen und Überschreiben von vollständigen Datenreihen. Die Lösch- und Überschreibungssemantik für bestimmte Elemente eines Zeitachsensignals muss während des Codierungs- und Verdichtungsprozesses verwaltet werden. Beispiel: Beim Codierung werden Werte in einer Zeitreihe ignoriert, die durch neuere ersetzt oder korrigiert werden, und während der Verdichtung gelöscht.

Gespeicherte Signale werden automatisch der Anwendung, die die Abrufanfrage durchführt, und dem Anfragenden (die „Website“ oder „Ursprung“ einer registrierten Anzeigentechnologie) sowie dem Erstellungszeitpunkt der Anfrage zugeordnet. Alle Signale werden im Namen einer für die Privacy Sandbox registrierten Anzeigentechnologie gespeichert. In diesem Fall muss der URI „Website“/„Ursprung“ mit den Daten eines registrierten Anzeigentechnologie-Anbieters übereinstimmen. Wenn die anfragende Anzeigentechnologie nicht registriert ist, wird die Anfrage abgelehnt.

Speicherkontingent und Bereinigung

Jede Anzeigentechnologie hat auf dem Gerät des Nutzers nur begrenzten Speicherplatz zum Speichern von Signalen. Dieses Kontingent wird pro Anzeigentechnologie definiert. Signale, die aus verschiedenen Apps ausgewählt werden, teilen sich das Kontingent. Wenn das Kontingent überschritten wird, gibt das System Speicherplatz frei, indem frühere Signalwerte der Reihe nach entfernt werden. Um zu verhindern, dass die Bereinigung zu häufig ausgeführt wird, implementiert das System eine Batch-Logik, um eine begrenzte Kontingentüberziehung zu ermöglichen und zusätzlichen Speicherplatz freizugeben, sobald die Bereinigungslogik ausgelöst wird.

On-Device-Codierung für die Datenübertragung

Zur Vorbereitung von Signalen für die Anzeigenauswahl verfügt die benutzerdefinierte Logik des Käufers über geschützten Zugriff auf die gespeicherten Signale und Ereignisse für die jeweilige App. Ein Android-Systemhintergrundjob wird stündlich ausgeführt, um eine benutzerdefinierte Codierungslogik für einzelne Käufer auszuführen, die auf das Gerät heruntergeladen wird. Die benutzerdefinierte Codierungslogik pro Käufer codiert die Signale pro App und komprimiert sie dann in einer Nutzlast, die dem Kontingent pro Käufer entspricht. Die Nutzlast wird dann innerhalb der Grenzen des geschützten Gerätespeichers verschlüsselt und dann an die Gebots- und Auktionsdienste übertragen.

AdTech-Unternehmen definieren den Grad der Signalverarbeitung, der von ihrer eigenen Logik verarbeitet wird. Sie können Ihre Lösung beispielsweise so einrichten, dass frühere Signale verworfen und ähnliche oder verstärkende Signale aus verschiedenen Anwendungen zu neuen Signalen mit weniger Speicherplatz aggregiert werden.

Wenn ein Käufer keinen Signalencoder registriert hat, werden keine Signale vorbereitet und keines der ausgewählten Signale auf dem Gerät an die Gebots- und Auktionsdienste gesendet.

Weitere Informationen zu Speicher-, Nutzlast- und Anfragekontingenten werden in einem zukünftigen Update verfügbar sein. Außerdem erhalten Sie weitere Informationen zur Bereitstellung benutzerdefinierter Funktionen.

Workflow zur Anzeigenauswahl

Bei diesem Angebot kann der benutzerdefinierte Code für AdTech nur auf die geschützten App-Signale innerhalb einer geschützten Auktion (Ad Selection API) zugreifen, die in einem TEE ausgeführt wird. Damit die Anforderungen für den Anwendungsfall „App-Installation“ weiter erfüllt werden, werden mögliche Anzeigen während der geschützten Auktion in Echtzeit abgerufen. Dies steht im Gegensatz zum Remarketing-Anwendungsfall, bei dem mögliche Anzeigen bereits vor der Auktion bekannt sind.

Für dieses Angebot wird ein ähnlicher Workflow zur Anzeigenauswahl wie beim Protected Audience-Angebot mit Updates zur Unterstützung des Anwendungsfalls „App-Installation“ verwendet. Damit die Computing-Anforderungen für Feature Engineering und Echtzeit-Anzeigenauswahl unterstützt werden, müssen Auktionen für App-Installationsanzeigen für Gebots- und Auktionsdienste ausgeführt werden, die in TEEs ausgeführt werden. Der Zugriff auf geschützte App-Signale während einer geschützten Auktion wird bei On-Device-Auktionen nicht unterstützt.

Abbildung des Workflows für die Anzeigenauswahl — Der Workflow zur Anzeigenauswahl in der Privacy Sandbox für Android.

Der Workflow für die Anzeigenauswahl sieht so aus:

Das SDK des Verkäufers sendet die verschlüsselte Nutzlast der Protected App-Signale auf dem Gerät.
Der Server des Verkäufers erstellt eine Auktionskonfiguration und sendet sie zusammen mit der verschlüsselten Nutzlast an den Dienst für vertrauenswürdige Gebote und Auktionen des Verkäufers, um einen Workflow für die Anzeigenauswahl zu initiieren.
Der Gebots- und Auktionsdienst des Verkäufers übergibt die Nutzlast an die teilnehmenden Frontend-Server der vertrauenswürdigen Käufer.
Der Gebotsdienst des Käufers führt die Logik für die Anzeigenauswahl auf Käuferseite aus.
1. Logik für den Anzeigenabruf auf Käuferseite:
2. Gebotslogik auf Käuferseite:
Die Bewertungslogik auf der Verkäuferseite wird ausgeführt.
Die Anzeige wird gerendert und Berichte werden erstellt.

Workflow für die Anzeigenauswahl initiieren

Wenn in einer Anwendung eine Anzeige ausgeliefert werden kann, initiiert das Ad Tech SDK (in der Regel SSPs) den Workflow für die Anzeigenauswahl, indem relevante kontextbezogene Daten vom Publisher und die pro Käufer verschlüsselten Nutzlasten gesendet werden, die in die Anfrage aufgenommen und über den Aufruf getAdSelectionData an die geschützte Auktion gesendet werden sollen. Dies ist dieselbe API, die für den Remarketing-Workflow verwendet und im Vorschlag zur Integration von Bidding und Auktionen für Android beschrieben wird.

Zum Initiieren der Anzeigenauswahl übergibt der Verkäufer eine Liste der teilnehmenden Käufer und verschlüsselte Nutzlasten der geschützten App-Signale auf dem Gerät. Anhand dieser Informationen bereitet der Ad-Server auf Verkäuferseite ein SelectAdRequest für den vertrauenswürdigen SellerFrontEnd-Dienst vor.

Der Verkäufer legt Folgendes fest:

Die von getAdSelectionData empfangene Nutzlast, die die Protected App-Signale enthält.
Kontextsignale anhand von:
- auction_config.auction_signals (Informationen zur Auktion)
- auction_config.seller_signals (für Signale des Verkäufers
- auction_config.per_buyer_config["buyer"].buyer_signals (für die Käufersignale)
Die Liste der Käufer, die in den Auktionen einbezogen werden. Verwenden Sie dazu das Feld buyer_list.

Logik zur Ausführung der Anzeigenauswahl auf Käuferseite

Im Allgemeinen verwendet die benutzerdefinierte Logik des Käufers Kontextdaten, die vom Publisher zur Verfügung gestellt werden, und Protected App-Signale, um ein Gebot für relevante Anzeigen für die Anzeigenanfrage auszuwählen und anzuwenden. Über die Plattform können Käufer einen großen Pool verfügbarer Anzeigen auf die relevantesten Anzeigen (die Top k) eingrenzen, für die Gebote berechnet werden, bevor die Anzeigen zur endgültigen Auswahl an den Verkäufer zurückgegeben werden.

Abbildung der Ausführungslogik für die Anzeigenauswahl auf Käuferseite — Ausführungslogik für die Anzeigenauswahl auf Käuferseite in der Privacy Sandbox auf Android

Bevor Käufer Gebote abgeben, beginnen sie mit einer großen Anzahl von Anzeigen. Da die Berechnung eines Gebots für jede Anzeige zu langsam ist, müssen die Käufer zuerst die besten k Kandidaten aus dem großen Pool auswählen. Als Nächstes berechnen die Käufer ihre Gebote für jeden dieser kandidierenden Kandidaten. Diese Anzeigen und Gebote werden dann zur endgültigen Auswahl an den Verkäufer zurückgegeben.

Der BuyerFrontEnd-Dienst erhält eine Anzeigenanfrage.
Der BuyerFrontEnd-Dienst sendet eine Anfrage an den Gebotsdienst des Käufers. Der Gebotsdienst des Käufers führt eine UDF mit dem Namen prepareDataForAdRetrieval() aus, die eine Anfrage zum Abrufen der besten k Kandidaten aus dem Anzeigen-Abrufdienst erstellt. Der Bidding-Dienst sendet diese Anfrage an den konfigurierten Abrufserverendpunkt.
Der Anzeigenabrufdienst führt die UDF getCandidateAds() aus, die nach den Top k möglichen Anzeigen filtert, die an den Bidding-Dienst des Käufers gesendet werden.
Der Gebotsdienst des Käufers führt die UDF generateBid() aus, die den besten Kandidaten auswählt, sein Gebot berechnet und dann an den BuyerFrontEnd-Dienst zurückgibt.
Der BuyerFrontEnd-Dienst gibt die Anzeigen und Gebote an den Verkäufer zurück.

Bei diesem Ablauf sind einige wichtige Details zu beachten – insbesondere im Hinblick auf die Kommunikation zwischen den einzelnen Komponenten und die Funktionen der Plattform. Dazu gehören z. B. die Möglichkeit, mithilfe von maschinellem Lernen Vorhersagen zum Abrufen der Top-Anzeigen und zur Berechnung der Gebote zu treffen.

Bevor wir Teile davon genauer betrachten, gibt es einige wichtige Architekturhinweise zu den TEEs im obigen Diagramm.

Der Gebotsdienst des Käufers enthält intern einen Inferenzdienst. AdTechs können Modelle für maschinelles Lernen in den Gebotsdienst des Käufers hochladen. Wir stellen JavaScript APIs für Anzeigentechnologien zur Verfügung, um Vorhersagen zu treffen oder Einbettungen aus diesen Modellen innerhalb der UDFs zu generieren, die im Gebotsdienst des Käufers ausgeführt werden. Im Gegensatz zum Anzeigenabrufdienst hat der Gebotsdienst des Käufers keinen Schlüssel/Wert-Paar-Dienst zum Speichern von Anzeigenmetadaten.

Der Anzeigenabrufdienst umfasst intern einen Schlüssel/Wert-Paar-Dienst. AdTech-Unternehmen können Schlüssel/Wert-Paare von ihren eigenen Servern außerhalb der Datenschutzgrenzen in diesem Dienst erfassen. Wir stellen eine JavaScript API für Anzeigentechnologie-Anbieter zur Verfügung, damit diese aus diesem Schlüssel/Wert-Paar-Dienst in den UDFs lesen können, die im Anzeigen-Abrufdienst ausgeführt werden. Im Gegensatz zum Gebotsdienst des Käufers enthält der Anzeigen-Abrufdienst keinen Inferenzdienst.

Eine zentrale Frage, mit der sich dieses Design befasst, ist die Frage, wie Vorhersagen zur Abrufzeit und zur Gebotszeit getroffen werden können. Die Antwort auf beide Fragen kann eine Lösung namens Modellfaktorisierung beinhalten.

Modellfaktorisierung

Die Modellfaktorisierung ist ein Verfahren, mit dem ein einzelnes Modell in mehrere Teile zerlegt und dann zu einer Vorhersage kombiniert werden kann. Beim Anwendungsfall „App-Installation“ nutzen Modelle häufig drei Arten von Daten: Nutzerdaten, Kontextdaten und Anzeigendaten.

Im nicht faktorisierten Fall wird ein einzelnes Modell mit allen drei Arten von Daten trainiert. Im faktorisierten Fall teilen wir das Modell in mehrere Teile auf. Nur das Element, das die Daten der Nutzenden enthält, ist sensibel. Das bedeutet, dass nur das Modell mit dem Nutzerteil innerhalb der Vertrauensgrenze im Inferenzdienst des Gebotsdiensts des Käufers ausgeführt werden muss.

Dadurch wird das folgende Design ermöglicht:

Teilen Sie das Modell in einen privaten Teil (die Nutzerdaten) und einen oder mehrere nicht private Teile (die Kontext- und Anzeigendaten) auf.
Übergeben Sie optional einige oder alle nicht privaten Teile als Argumente an eine UDF, die Vorhersagen treffen muss. Kontextbezogene Einbettungen werden beispielsweise an UDFs in der per_buyer_signals übergeben.
Optional können Anzeigentechnologie-Anbieter Modelle für nicht private Teile erstellen und dann Einbettungen aus diesen Modellen im Schlüssel/Wert-Speicher des Anzeigen-Abrufdienstes erfassen. UDFs im Anzeigen-Abrufdienst können diese Einbettungen zur Laufzeit abrufen.
Um während einer UDF eine Vorhersage zu treffen, kombinieren Sie private Einbettungen aus dem Inferenzdienst mit nicht privaten Einbettungen aus UDF-Funktionsargumenten oder dem Schlüssel/Wert-Speicher mit einem Vorgang wie einem Punktprodukt. Das ist die endgültige Vorhersage.

So können wir uns jede UDF genauer ansehen. Sie erfahren, was sie tun, wie sie integriert werden und wie sie Prognosen erstellen, um die besten k Anzeigen auszuwählen und ihre Gebote zu berechnen.

Die UDF `prepareDataForAdRetrieval()`

prepareDataForAdRetrieval(), das im Gebotsdienst des Käufers ausgeführt wird, ist für das Erstellen der Nutzlast der Anfrage verantwortlich, die an den Anzeigen-Abrufdienst gesendet wird, um die am stärksten k möglichen Anzeigen abzurufen.

prepareDataForAdRetrieval() verwendet die folgenden Informationen:

Die Nutzlast pro Käufer vom getAdSelectionData. Diese Nutzlast enthält die Protected App-Signale.
auction_signals der Kontextsignale (für Informationen zur Auktion) und buyer_signals (für die Felder Käufersignale).

prepareDataForAdRetrieval() hat zwei Aktionen:

Featurisierung: Wenn eine Inferenz zum Abrufzeit erforderlich ist, werden eingehende Signale in Features umgewandelt, die bei Aufrufen des Inferenzdienstes verwendet werden, um private Einbettungen zum Abrufen abzurufen.
Berechnet private Einbettungen für den Abruf: Wenn Abrufvorhersagen erforderlich sind, wird der Aufruf an den Inferenzdienst mithilfe der oben genannten Features ausgeführt und eine private Einbettung für Vorhersagen zur Abrufzeit wird abgerufen.

prepareDataForAdRetrieval() gibt Folgendes zurück:

Geschützte App-Signale: Nutzlast von Anzeigentechnologie-Signalen.
Auktionsspezifische Signale: plattformspezifische Signale auf Verkäuferseite und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest Dies ähnelt der Option Geschützte Zielgruppen.
Zusätzliche Signale: zusätzliche Informationen wie private Einbettungen, die vom Inferenzdienst abgerufen werden.

Diese Anfrage wird an den Anzeigen-Abrufdienst gesendet, der den Kandidatenabgleich durchführt und dann die UDF getCandidateAds() ausführt.

Die UDF `getCandidateAds()`

getCandidateAds() wird im Anzeigenabrufdienst ausgeführt. Es empfängt die Anfrage, die von prepareDataForAdRetrieval() an den Bidding-Dienst des Käufers erstellt wurde. Der Dienst führt getCandidateAds() aus, der die Top-K-Kandidaten für Gebote abruft. Dazu wird die Anfrage in eine Reihe von Satzabfragen und Datenabrufen umgewandelt und benutzerdefinierte Geschäftslogik sowie andere benutzerdefinierte Abruflogik ausgeführt.

getCandidateAds() verwendet die folgenden Informationen:

Geschützte App-Signale: Nutzlast von Anzeigentechnologie-Signalen.
Auktionsspezifische Signale: plattformspezifische Signale auf Verkäuferseite und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest Dies ähnelt der Option Geschützte Zielgruppen.
Zusätzliche Signale: zusätzliche Informationen wie private Einbettungen, die vom Inferenzdienst abgerufen werden.

getCandidateAds() führt Folgendes aus:

Anfänglichen Satz von Anzeigenkandidaten abrufen: Dieser Bericht wird mithilfe von Targeting-Kriterien wie Sprache, Geografie, Anzeigentyp, Anzeigengröße oder Budget abgerufen, um mögliche Anzeigen zu filtern.
Abruf von Einbettungen: Wenn Einbettungen aus dem Schlüssel/Wert-Dienst benötigt werden, um eine Vorhersage zur Abrufzeit für die Top k-Auswahl zu treffen, müssen sie aus dem Schlüssel/Wert-Paar-Dienst abgerufen werden.
Top k-Kandidatenauswahl: Berechnen Sie einen einfachen Wert für den gefilterten Satz von Anzeigenkandidaten basierend auf den aus dem Schlüssel/Wert-Speicher abgerufenen Anzeigenmetadaten und den vom Gebotsdienst des Käufers gesendeten Informationen. Anhand dieses Werts werden dann die besten k Kandidaten ausgewählt. Der Wert kann beispielsweise die Wahrscheinlichkeit sein, dass eine App aufgrund der Anzeige installiert wird.
Gebotseinbettung abrufen: Wenn Einbettungen aus dem Schlüssel/Wert-Paar-Dienst über Gebotscode benötigt werden, um Vorhersagen zur Gebotszeit zu treffen, können sie vom Schlüssel/Wert-Paar-Dienst abgerufen werden.

Die Punktzahl für eine Anzeige kann die Ausgabe eines Prognosemodells sein, das beispielsweise die Wahrscheinlichkeit vorhersagt, dass ein Nutzer eine App installiert. Diese Art der Generierung des Werts beinhaltet eine Art Modellfaktorisierung: Da getCandidateAds() mit dem Anzeigen-Abrufdienst ausgeführt wird und dieser keinen Inferenzdienst hat, können Vorhersagen durch eine Kombination folgender Elemente generiert werden:

Kontextbezogene Einbettungen, die mithilfe der Eingabe für auktionsspezifische Signale übergeben werden.
Private Einbettungen, die mithilfe der Eingabe zusätzlicher Signale übergeben wurden.
Alle nicht privaten Einbettungen von Anzeigentechnologien wurden von ihren Servern im Schlüssel/Wert-Paar-Dienst des Anzeigen-Abrufdienstes übernommen.

Die UDF generateBid(), die im Gebotsdienst des Käufers ausgeführt wird, kann auch eine eigene Modellfaktorisierung für ihre Gebotsoptionen anwenden. Wenn hierfür Einbettungen von einem Schlüssel/Wert-Paar-Dienst erforderlich sind, müssen sie jetzt abgerufen werden.

getCandidateAds() gibt Folgendes zurück:

Mögliche Anzeigen: Die Top k der Anzeigen, die an generateBid() übergeben werden. Jede Anzeige besteht aus:
- Rendering-URL: Endpunkt für das Rendering des Anzeigen-Creatives.
- Metadaten: Metadaten der Anzeigen auf Käuferseite und der Anzeigentechnologie Dazu gehören beispielsweise Informationen zur Werbekampagne und Ausrichtungskriterien wie Standort und Sprache. Die Metadaten können optionale Einbettungen enthalten, die verwendet werden, wenn eine Modellfaktorisierung erforderlich ist, um während der Gebotsabgabe Inferenzen auszuführen.
Zusätzliche Signale: Optional kann der Anzeigen-Abrufdienst zusätzliche Informationen wie zusätzliche Einbettungen oder Spamsignale zur Verwendung in generateBid() enthalten.

Wir untersuchen weitere Methoden, um Anzeigen zur Bewertung bereitzustellen, einschließlich der Bereitstellung im Rahmen des SelectAdRequest-Aufrufs. Diese Anzeigen können mithilfe einer RTB-Gebotsanfrage abgerufen werden. In solchen Fällen müssen Anzeigen ohne Protected App-Signale abgerufen werden. Wir gehen davon aus, dass Anzeigentechnologie-Anbieter Vor- und Nachteile abwägen werden, bevor sie die beste Option auswählen, einschließlich Größe der Antwortnutzlast, Latenz, Kosten und Verfügbarkeit von Signalen.

Die UDF `generateBid()`

Nachdem Sie die möglichen Anzeigen und die Einbettungen beim Abrufen abgerufen haben, können Sie mit dem Bidding fortfahren, das im Gebotsdienst des Käufers ausgeführt wird. Dieser Dienst führt die vom Käufer bereitgestellte generateBid()-UDF aus, um die Anzeige, für die ein Gebot abgegeben werden soll, aus den obersten k auszuwählen, und gibt sie dann mit dem Gebot zurück.

generateBid() verwendet die folgenden Informationen:

Mögliche Anzeigen: Die Top-K der Anzeigen, die vom Abrufdienst für Anzeigen zurückgegeben wurden.
Auktionsspezifische Signale: plattformspezifische Signale auf Verkäuferseite und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest
Zusätzliche Signale: zusätzliche Informationen, die bei der Gebotseinstellung verwendet werden.

Die Implementierung von generateBid() des Käufers hat drei Funktionen:

Featurisierung: Wandelt Signale in Features zur Verwendung während der Inferenz um.
Inferenz: Hiermit werden mithilfe von Modellen für maschinelles Lernen Vorhersagen generiert, um Werte wie prognostizierte Klick- und Conversion-Raten zu berechnen.
Gebote: Abgeleitete Werte werden mit anderen Eingaben kombiniert, um das Gebot für eine mögliche Anzeige zu berechnen.

generateBid() gibt Folgendes zurück:

Die mögliche Anzeige.
Den berechneten Gebotsbetrag.

Die für App-Installationsanzeigen verwendete generateBid() und die für Remarketing-Anzeigen unterscheiden sich.

In den folgenden Abschnitten werden die Funktion, Inferenz und Gebote ausführlicher beschrieben.

Featurisierung

Auktionssignale können durch generateBid() in Funktionen vorbereitet werden. Diese Funktionen können während der Inferenz verwendet werden, um Dinge wie Klick- und Conversion-Raten vorherzusagen. Außerdem erforschen wir datenschutzfreundliche Mechanismen, um einige davon in den Erfolgsbericht für das Modelltraining zu übertragen.

Inferenz

Bei der Berechnung eines Gebots werden Rückschlüsse auf ein oder mehrere ML-Modelle häufig durchgeführt. Effektive eCPM-Berechnungen verwenden beispielsweise häufig Modelle zur Vorhersage von Klick- und Conversion-Raten.

Clients können eine Reihe von Modellen für maschinelles Lernen zusammen mit ihrer generateBid()-Implementierung bereitstellen. Außerdem stellen wir in generateBid() eine JavaScript API bereit, damit Clients zur Laufzeit Inferenzen ausführen können.

Die Inferenz wird für den Gebotsdienst des Käufers ausgeführt. Dies kann sich auf die Inferenzlatenz und -kosten auswirken, insbesondere da Beschleuniger noch nicht in TEEs verfügbar sind. Einige Kunden stellen fest, dass ihre Anforderungen durch individuelle Modelle erfüllt werden, die im Gebotsdienst des Käufers ausgeführt werden. Einige Kunden – z. B. solche mit sehr großen Modellen – möchten möglicherweise Optionen wie die Modellfaktorisierung in Betracht ziehen, um die Inferenzkosten und die Latenz zum Zeitpunkt der Gebotsabgabe zu minimieren.

Weitere Informationen zu Inferenzfunktionen wie unterstützte Modellformate und Maximalgrößen werden in einem zukünftigen Update bereitgestellt.

Modellfaktorisierung implementieren

Wir haben bereits die Modellfaktorisierung erläutert. Zum Zeitpunkt der Gebotsabgabe lautet der spezifische Ansatz:

Unterteilen Sie das einzelne Modell in einen privaten Teil (die Nutzerdaten) und einen oder mehrere nicht private Teile (die kontextbezogenen und die Anzeigendaten).
Übergeben Sie nicht private Teile an generateBid(). Sie können entweder aus per_buyer_signals oder aus Einbettungen stammen, die von Anzeigentechnologien extern berechnet, im Schlüssel/Wert-Speicher des Abrufdienstes übernommen, zum Abrufzeitpunkt abgerufen und als Teil der zusätzlichen Signale zurückgegeben werden. Dies gilt nicht für private Einbettungen, da diese nicht von außerhalb der Datenschutzgrenzen stammen können.
In generateBid():
1. Inferenz von Modellen ableiten, um private Nutzereinbettungen zu erhalten
2. Kombinieren Sie private Nutzereinbettungen mit kontextbezogenen Einbettungen aus per_buyer_signals oder nicht privaten Anzeigen und kontextbezogenen Einbettungen aus dem Abrufdienst mithilfe eines Vorgangs wie einem Punktprodukt. Dies ist die endgültige Vorhersage, die zur Berechnung von Geboten verwendet werden kann.

Mit diesem Ansatz ist es möglich, zum Zeitpunkt der Gebotsabgabe Inferenzen für Modelle durchzuführen, die andernfalls zu groß oder zu langsam wären, um sie für den Gebotsdienst des Käufers auszuführen.

Bewertungslogik für Verkäufer

Aktuell werden die Anzeigen mit Geboten von allen teilnehmenden Käufern bewertet. Die Ausgabe von generateBid() wird zur Ausführung von scoreAd() an den Auktionsdienst des Verkäufers übergeben. Dabei berücksichtigt scoreAd() jeweils nur eine Anzeige. Anhand der Bewertung wählt der Verkäufer eine erfolgreiche Anzeige aus, die zum Rendern an das Gerät zurückgegeben wird.

Die Bewertungslogik ist dieselbe wie für den Protected Audience-Remarketing-Ablauf und kann aus den Kandidaten für Remarketing und App-Installationen einen Gewinner auswählen.Die Funktion wird für jede in der Protected Auktion eingereichte Anzeige einmal aufgerufen. Weitere Informationen finden Sie in der Erläuterung zu Gebote und Auktionen.

Codelaufzeit für Anzeigenauswahl

Im Angebot wird der Anzeigenauswahlcode für die App-Installation auf dieselbe Weise angegeben wie beim Remarketing-Ablauf „Protected Audience“. Weitere Informationen finden Sie unter Gebots- und Auktionskonfiguration. Der Gebotscode ist am selben Cloud-Speicherort verfügbar, der auch für das Remarketing verwendet wird.

Berichterstellung

Für dieses Angebot werden dieselben Reporting APIs wie für das Protected Audience-Berichtsangebot verwendet (z. B. reportImpression(), das das Senden von Verkäufer- und Käuferberichten an die Plattform auslöst).

Ein häufiger Anwendungsfall für Berichte auf Käuferseite ist das Abrufen der Trainingsdaten für Modelle, die während der Anzeigenauswahl verwendet werden. Zusätzlich zu den vorhandenen APIs bietet die Plattform einen speziellen Mechanismus für den ausgehenden Traffic von Daten auf Ereignisebene von der Plattform an AdTech-Server. Diese Nutzlasten für ausgehenden Traffic können bestimmte Nutzerdaten enthalten.

Langfristig untersuchen wir datenschutzfreundliche Lösungen für das Modelltraining mit Daten, die in geschützten Auktionen verwendet werden, ohne dass Nutzerdaten auf Ereignisebene an externe Dienste gesendet werden, die in TEEs ausgeführt werden. Weitere Einzelheiten geben wir in einem späteren Update bekannt.

Kurzfristig bieten wir eine vorübergehende Möglichkeit, verrauschte Daten von generateBid() aus zu senden. Im Folgenden finden Sie unseren ersten Vorschlag, der als Reaktion auf Feedback aus der Branche weiterentwickelt wird (einschließlich möglicher nicht abwärtskompatibler Änderungen).

Technisch gesehen funktioniert das so:

AdTechs definieren ein Schema für die Daten, die sie übertragen möchten.
In generateBid() erstellen sie die gewünschte Nutzlast für ausgehenden Traffic.
Die Plattform validiert die Nutzlast des ausgehenden Traffics anhand des Schemas und erzwingt Größenbeschränkungen.
Die Plattform fügt der Nutzlast des ausgehenden Traffics Rauschen hinzu.
Die Nutzlast des ausgehenden Traffics ist im Gewinnbericht im Übertragungsformat enthalten, wird auf AdTech-Servern empfangen, decodiert und für das Modelltraining verwendet.

Schema von ausgehenden Nutzlasten definieren

Damit die Plattform neue Datenschutzanforderungen durchsetzen kann, müssen ausgehende Nutzlasten so strukturiert sein, dass sie von der Plattform verarbeitet werden können. AdTechs definieren die Struktur ihrer ausgehenden Nutzlasten durch die Bereitstellung einer JSON-Schemadatei. Dieses Schema wird von der Plattform verarbeitet und von den Gebots- und Auktionsdiensten mit denselben Mechanismen vertraulich behandelt wie andere AdTech-Ressourcen wie UDFs und Modelle.

Wir stellen eine CDDL-Datei zur Verfügung, die die Struktur dieser JSON-Datei definiert. Die CDDL-Datei enthält eine Reihe von unterstützten Elementtypen (z. B. Elemente mit booleschen Werten, Ganzzahlen, Buckets usw.). Sowohl die CDDL-Datei als auch das bereitgestellte Schema werden versioniert.

Beispielsweise würde eine Nutzlast für ausgehenden Traffic, die aus einem einzelnen booleschen Feature gefolgt von einem Bucket-Feature der Größe 2 besteht, in etwa so aussehen:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Details zu den unterstützten Featuretypen finden Sie auf GitHub.

Ausgehende Nutzlasten in `generateBid()` erstellen

Alle geschützten App-Signale eines bestimmten Käufers sind für seine generateBid()-UDF verfügbar. Sobald diese Funktionen verfügbar sind, erstellen Anzeigentechnologie-Anbieter ihre Nutzlast im JSON-Format. Diese Nutzlast des ausgehenden Traffics wird in den Gewinnbericht des Käufers für die Übertragung an AdTech-Server aufgenommen.

Eine Alternative zu diesem Design besteht darin, dass die Berechnung des ausgehenden Vektors in reportWin() statt in generateBid() erfolgt. Jeder Ansatz muss Vor- und Nachteile haben, und wir werden diese Entscheidung als Reaktion auf das Feedback der Branche endgültig festlegen.

Nutzlast des ausgehenden Traffics validieren

Die Plattform validiert alle ausgehenden Nutzlasten, die von der AdTech erstellt wurden. Die Validierung stellt sicher, dass Featurewerte für ihren Typ gültig sind, Größenbeschränkungen eingehalten werden und dass böswillige Akteure nicht versuchen, Datenschutzkontrollen durch das Packen zusätzlicher Informationen in ihre Nutzlasten für ausgehenden Traffic zu umgehen.

Wenn eine Nutzlast für ausgehenden Traffic ungültig ist, wird sie automatisch aus den Eingaben verworfen, die an den Gewinnbericht gesendet werden. Dies liegt daran, dass wir böswilligen Akteuren, die die Validierung zu verhindern versuchen, keine Debugging-Informationen zur Verfügung stellen möchten.

Wir stellen eine JavaScript API für Anzeigentechnologien zur Verfügung, um dafür zu sorgen, dass die in generateBid() erstellte Nutzlast des ausgehenden Traffics die Plattformvalidierung besteht:

validate(payload, schema)

Mit dieser JavaScript API können Aufrufer komplett feststellen, ob eine bestimmte Nutzlast die Plattformvalidierung besteht. Zum Schutz vor schädlichen generateBid()-UDFs muss die tatsächliche Validierung auf der Plattform erfolgen.

Rauschen der Nutzlast des ausgehenden Traffics

Die Plattform verrauscht die Nutzlasten des ausgehenden Traffics, bevor sie in den Gewinnbericht aufgenommen wird. Der anfängliche Rauschgrenzwert liegt bei 1 % und kann sich im Laufe der Zeit ändern. Die Plattform gibt keinen Hinweis darauf, ob eine bestimmte Nutzlast des ausgehenden Traffics verrauscht wurde oder nicht.

Die Rauschmethode ist:

Die Plattform lädt die Schemadefinition für die Nutzlast des ausgehenden Traffics.
1% der ausgehenden Nutzlasten wird für das Rauschen ausgewählt.
Wenn keine Nutzlast für ausgehenden Traffic ausgewählt wird, wird der gesamte ursprüngliche Wert beibehalten.
Wenn eine Nutzlast für ausgehenden Traffic ausgewählt wird, wird der Wert jedes Features durch einen zufälligen gültigen Wert für diesen Featuretyp ersetzt (z. B. entweder 0 oder 1 für ein boolesches Feature).

Übertragen, Empfangen und Decodieren der ausgehenden Nutzlast für das Modelltraining

Die validierte, verrauschte Nutzlast des ausgehenden Traffics wird in die Argumente an reportWin() aufgenommen und an die AdTech-Server des Käufers außerhalb der Datenschutzgrenzen für das Modelltraining übertragen. Die Nutzlast des ausgehenden Traffics liegt im Übertragungsformat vor.

Details zum Übertragungsformat für alle Featuretypen und zur Nutzlast des ausgehenden Traffics selbst sind auf GitHub verfügbar.

Größe der Nutzlast des ausgehenden Traffics bestimmen

Die Größe der ausgehenden Nutzlast in Bits sorgt für ein Gleichgewicht zwischen Dienstprogramm und Datenminimierung. Wir arbeiten mit der Branche zusammen, um die geeignete Größe durch Experimente zu bestimmen. Während dieser Tests werden vorübergehend ausgehende Daten ohne Bitgrößenbeschränkung gesendet. Diese zusätzlichen ausgehenden Daten ohne Bitgrößenbeschränkung werden entfernt, sobald die Tests abgeschlossen sind.

Die Methode zur Bestimmung der Größe lautet:

Anfangs werden zwei Nutzlasten für ausgehenden Traffic in generateBid() unterstützt:
1. egressPayload: die größenbegrenzte Nutzlast des ausgehenden Traffics, die bisher in diesem Dokument beschrieben wurde. Anfänglich ist diese Nutzlast für ausgehenden Traffic 0 Bit groß. Das heißt, sie wird während der Validierung immer entfernt.
2. temporaryUnlimitedEgressPayload: Eine temporäre, unbegrenzte Nutzlast für ausgehenden Traffic für Größentests. Zum Formatieren, Erstellen und Verarbeiten dieser ausgehenden Nutzlast werden dieselben Mechanismen wie bei egressPayload verwendet.
Jede dieser ausgehenden Nutzlasten hat eine eigene JSON-Schemadatei: egress_payload_schema.json und temporary_egress_payload_schema.json.
Wir stellen ein Testprotokoll und eine Reihe von Messwerten zur Verfügung, um die Modellnutzung bei verschiedenen Größen der Nutzlast des ausgehenden Traffics (z. B. 5, 10, ... Bit) zu bestimmen.
Auf der Grundlage der Testergebnisse bestimmen wir die Größe der ausgehenden Nutzlast unter Berücksichtigung der entsprechenden Kompromisse bei Dienstprogramm und Datenschutz.
Wir haben die Größe von egressPayload von 0 Bit auf die neue Größe festgelegt.
Nach einem festgelegten Migrationszeitraum entfernen wir temporaryUnlimitedEgressPayload, sodass nur egressPayload mit der neuen Größe übrig bleibt.

Wir prüfen derzeit zusätzliche technische Sicherheitsvorkehrungen für die Verwaltung dieser Änderung (z. B. die Verschlüsselung von egressPayload, wenn wir die Größe von 0 Bit erhöhen). Diese Details sowie zusätzliche Informationen wie das Testprotokoll, die Zeitangaben für den Test und die Entfernung von temporaryUnlimitedEgressPayload werden in einem späteren Update enthalten sein.

Datenschutzmaßnahmen

Auf ausgehende Daten wenden wir verschiedene Schutzmaßnahmen an, darunter:

egressPayload und temporaryUnlimitedEgressPayload werden verrauscht.
Zur Datenminimierung und zum Schutz von Daten ist temporaryUnlimitedEgressPayload nur für die Dauer von Größentests verfügbar, bei denen wir die richtige Größe für egressPayload ermitteln.

Berechtigungen

Nutzersteuerung

Das Angebot soll Nutzern Einblick in die Liste der installierten Apps geben, in denen mindestens ein geschütztes App-Signal oder eine benutzerdefinierte Zielgruppe gespeichert ist.
Nutzer können Apps blockieren und aus dieser Liste entfernen. Das Sperren und Entfernen hat folgende Auswirkungen:
- Löscht alle geschützten App-Signale und benutzerdefinierten Zielgruppen, die mit der App verknüpft sind.
- Verhindert, dass die Apps neue Protected App-Signale und benutzerdefinierte Zielgruppen speichern.
Nutzer haben die Möglichkeit, die Protected App-Signale und die Protected Audience API vollständig zurückzusetzen. In diesem Fall werden alle vorhandenen Protected App-Signale und benutzerdefinierten Zielgruppen auf dem Gerät gelöscht.
Nutzer haben die Möglichkeit, die Privacy Sandbox für Android, einschließlich der Protected App Signals API und Protected Audience API, vollständig zu deaktivieren. In diesem Fall geben die Protected Audience API und die Protected App Signals API eine standardmäßige Ausnahmenachricht zurück: SECURITY_EXCEPTION.

App-Berechtigungen und -Steuerung

Mit dem Angebot soll den Apps die Kontrolle über die geschützten App-Signale gewährt werden:

Eine App kann ihre Verknüpfungen mit geschützten App-Signalen verwalten.
Eine App kann AdTech-Plattformen von Drittanbietern die Berechtigung erteilen, geschützte App-Signale in ihrem Namen zu verwalten.

Steuerung der AdTech-Plattform

In diesem Vorschlag werden Möglichkeiten beschrieben, wie Anzeigentechnologie-Anbieter ihre geschützten App-Signale steuern können:

Alle Anzeigentechnologie-Anbieter müssen sich bei der Privacy Sandbox registrieren und eine Website- oder Ursprungsdomain angeben, die mit allen URLs für geschützte App-Signale übereinstimmt.
AdTech-Unternehmen können mit Apps oder SDKs zusammenarbeiten, um Bestätigungstokens zur Verfügung zu stellen, mit denen die Erstellung von Protected App-Signalen überprüft wird. Wenn dieser Prozess an einen Partner delegiert wird, kann das Erstellen geschützter App-Signale so konfiguriert werden, dass eine Bestätigung durch die Anzeigentechnologie erforderlich ist.