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

Dieser Vorschlag unterliegt dem Registrierungsprozess und den Attestierungen für die Privacy Sandbox. Weitere Informationen zu den Attestierungen finden Sie unter dem bereitgestellten Attestierungslink. In zukünftigen Aktualisierungen dieses Vorschlags werden die Anforderungen für den Zugriff auf dieses System beschrieben.

App-Installationsanzeigen, auch Anzeigen zur Nutzergewinnung genannt, sind eine Art von mobiler Werbung, die Nutzer zum Herunterladen einer mobilen App anregen soll. Diese Anzeigen werden Nutzern in der Regel basierend auf ihren Interessen und demografischen Merkmalen präsentiert und erscheinen häufig in anderen mobilen Apps wie Spielen, sozialen Medien und Nachrichten-Apps. Wenn ein Nutzer auf eine Anzeige für die App-Installation klickt, wird er direkt zum App-Store weitergeleitet, um die App herunterzuladen.

Ein Werbetreibender, der in den USA neue Installationen für eine neue mobile App für Essenslieferungen erzielen möchte, könnte seine Anzeigen beispielsweise auf Nutzer ausrichten, die sich in den USA befinden und bereits mit anderen Apps für Essenslieferungen interagiert haben.

Dies wird in der Regel durch die Einbeziehung von kontextbezogenen, selbst erhobenen und Drittanbietersignalen zwischen Ad-Tech-Unternehmen implementiert, um Nutzerprofile auf Grundlage von Werbe-IDs zu erstellen. Die Modelle für maschinelles Lernen in der Anzeigentechnologie verwenden diese Informationen als Eingaben, um Anzeigen auszuwählen, die für den Nutzer relevant sind und bei denen die Wahrscheinlichkeit einer Conversion am höchsten ist.

Die folgenden APIs werden vorgeschlagen, um effektive App-Installationsanzeigen zu unterstützen, die den Datenschutz für Nutzer verbessern, indem die Abhängigkeit von dienstleisterübergreifenden Nutzerkennungen entfernt wird:

1. Protected App Signals API: Hier geht es um das Speichern und Erstellen von Ad-Tech-Funktionen, die die potenziellen Interessen eines Nutzers darstellen. Ad-Tech-Unternehmen speichern selbst definierte ereignisbezogene Signale pro App, z. B. App-Installationen, erstes Öffnen, Nutzeraktionen (Leveling im Spiel, Erfolge), Kaufaktivitäten oder die in der App verbrachte Zeit. Signale werden auf dem Gerät geschrieben und gespeichert, um Datenlecks zu verhindern. Sie sind nur für die Ad-Tech-Logik verfügbar, die das jeweilige Signal während einer geschützten Auktion in einer sicheren Umgebung gespeichert hat.
2. Ad Selection API: Diese API dient zum Konfigurieren und Ausführen einer Protected Auction in einer Trusted Execution Environment (TEE). Dort rufen Ad-Tech-Unternehmen Anzeigenkandidaten ab, führen Inferenz aus, berechnen Gebote und führen die Bewertung durch, um eine „Gewinneranzeige“ auszuwählen. Dabei werden sowohl die Protected App Signals als auch die vom Publisher bereitgestellten kontextbezogenen Echtzeitinformationen verwendet.

Hier finden Sie einen allgemeinen Überblick darüber, wie Protected App Signals funktionieren, um relevante App-Installationsanzeigen zu unterstützen. In den folgenden Abschnitten dieses Dokuments werden die einzelnen Schritte genauer beschrieben.

• Signal-Curation: Wenn Nutzer mobile Apps verwenden, werden Signale von Ad-Tech-Unternehmen kuratiert. Dazu werden von Ad-Tech-Unternehmen definierte App-Ereignisse gespeichert, um mithilfe der Protected App Signals API relevante Anzeigen auszuliefern. Diese Ereignisse werden in einem geschützten Speicher auf dem Gerät gespeichert, ähnlich wie benutzerdefinierte Zielgruppen. Sie werden verschlüsselt, bevor sie vom Gerät gesendet werden, sodass nur Gebots- und Auktionsdienste, die in Trusted Execution Environments mit der entsprechenden Sicherheits- und Datenschutzkontrolle ausgeführt werden, sie für Gebote und die Bewertung von Anzeigen entschlüsseln können.
• Signalcodierung: Signale werden in einem geplanten Rhythmus durch benutzerdefinierte Ad-Tech-Logik vorbereitet. Ein Android-Hintergrundjob führt diese Logik aus, um eine On-Device-Codierung durchzuführen und eine Nutzlast mit Protected App Signals zu generieren, die später in Echtzeit für die Anzeigenauswahl während einer Protected Auction verwendet werden kann. Die Nutzlast wird sicher auf dem Gerät gespeichert, bis sie für eine Auktion gesendet wird.
• Anzeigenauswahl: Um relevante Anzeigen für den Nutzer auszuwählen, senden Verkäufer-SDKs eine verschlüsselte Nutzlast mit Protected App Signals und konfigurieren eine Protected Auction. In der Auktion bereitet die benutzerdefinierte Logik des Käufers die Protected App Signals zusammen mit den vom Publisher bereitgestellten Kontextdaten (Daten, die in der Regel in einer Open-RTB-Anzeigenanfrage freigegeben werden) vor, um Funktionen für die Anzeigenauswahl (Abrufen von Anzeigen, Inferenz und Gebotsgenerierung) zu entwickeln. Ähnlich wie bei Protected Audience reichen Käufer Anzeigen beim Verkäufer ein, damit diese in einer Protected Auction eine endgültige Bewertung erhalten.
  • Abruf von Anzeigen: 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. Diese Funktionen werden verwendet, um Anzeigen abzugleichen, die die Ausrichtungskriterien erfüllen. Anzeigen, die nicht dem Budget entsprechen, werden herausgefiltert. Die k Anzeigen mit der höchsten Wahrscheinlichkeit werden dann für Gebote ausgewählt.
  • Gebotsabgabe: Mit der benutzerdefinierten Gebotslogik der Käufer werden die vom Publisher bereitgestellten kontextbezogenen Daten und Protected App Signals vorbereitet, um Funktionen zu entwickeln, die als Eingabe für die Machine-Learning-Modelle der Käufer für die Inferenz und Gebotsabgabe für infrage kommende 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 benutzerdefinierte Bewertungslogik des Verkäufers bewertet Anzeigen, die von teilnehmenden Käufern eingereicht wurden, und wählt eine Gewinneranzeige aus, die zum Rendern an die App zurückgesendet wird.
• Berichterstellung: Teilnehmer an Auktionen erhalten entsprechende Berichte zu gewonnenen und verlorenen Auktionen. Wir prüfen derzeit datenschutzfreundliche Mechanismen, um Daten für das Modelltraining in den Win-Bericht aufzunehmen.

Zeitachse

Protected App Signals kuratieren

Ein Signal ist eine Darstellung verschiedener Nutzerinteraktionen in einer App, die von Ad-Tech-Unternehmen als nützlich für die Auslieferung relevanter Anzeigen eingestuft werden. Eine App oder das integrierte SDK können geschützte App-Signale, die von Ad-Tech-Unternehmen definiert werden, basierend auf Nutzeraktivitäten wie App-Öffnungen, Erfolgen, Kaufaktivitäten oder der in der App verbrachten Zeit 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. Nur Gebots- und Auktionsdienste, die in Trusted Execution Environments mit angemessener Sicherheits- und Datenschutzkontrolle ausgeführt werden, können sie zum Bieten und Bewerten von Anzeigen entschlüsseln. Ä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 so konzipiert, dass das Vorhandensein von Signalen nicht preisgegeben wird. Die benutzerdefinierte Logik für Anzeigentechnologien hat geschützten Zugriff auf die kuratierten Signale, um Funktionen zu entwickeln, die als Grundlage für die Anzeigenauswahl in einer Protected Auction dienen.

Protected App Signals API

Die Protected App Signals API unterstützt die Verwaltung von Signalen über einen Delegierungsmechanismus, der dem für benutzerdefinierte Zielgruppen verwendeten Mechanismus ähnelt. Mit der Protected App Signals API können Signale in Form eines einzelnen skalaren Werts oder als Zeitreihe gespeichert werden. Mit Zeitreihensignalen können Dinge wie die Dauer von Nutzersitzungen gespeichert werden. Mit Zeitreihensignalen lässt sich eine bestimmte Länge erzwingen, indem eine FIFO-Regel (First In, First Out) angewendet wird. Der Datentyp eines skalaren Signals oder jedes Elements eines Zeitreihensignals ist ein Byte-Array. Jeder Wert wird mit dem Paketnamen der Anwendung, die das Signal gespeichert hat, und dem Zeitstempel der Erstellung des API-Aufrufs zum Speichern des Signals angereichert. Diese zusätzlichen Informationen sind im JavaScript für die Signalcodierung verfügbar. In diesem Beispiel sehen Sie die Struktur der Signale, die einer bestimmten Ad-Tech-Plattform gehören:

In diesem Beispiel sehen Sie ein skalares Signal und ein Zeitachsensignal, die mit adtech1.com verknüpft sind:

• Ein Skalarsignal mit dem Base64-Wertschlüssel „A1c“ und dem Wert „c12Z“. Der Signal-Store 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.

Ad-Tech-Anbietern wird eine bestimmte Menge an Speicherplatz zum Speichern von Signalen auf dem Gerät zugewiesen. Signale haben eine maximale TTL, die noch festgelegt werden muss.

Protected App Signals werden aus dem Speicher entfernt, wenn die App, die sie generiert hat, deinstalliert wird, die Protected App Signals API für die App blockiert wird oder die App-Daten vom Nutzer gelöscht werden.

Die Protected App Signals API besteht aus den folgenden Teilen:

• Eine Java- und JavaScript-API zum Hinzufügen, Aktualisieren oder Entfernen von Signalen.
• Eine JavaScript-API zum Verarbeiten der gespeicherten Signale, um sie für das weitere Feature-Engineering in Echtzeit während einer Protected Auction vorzubereiten, die in einem Trusted Execution Environment (TEE) ausgeführt wird.

Signale hinzufügen, aktualisieren oder entfernen

Mit der fetchSignalUpdates() API können Ad-Tech-Unternehmen Signale hinzufügen, aktualisieren oder entfernen. Diese API unterstützt die Delegierung ähnlich wie die Delegierung benutzerdefinierter Zielgruppen in Protected Audience.

Wenn Sie ein Signal hinzufügen möchten, müssen Buyer-Ad-Techs, die kein SDK in Apps haben, mit Ad-Techs zusammenarbeiten, die auf dem Gerät präsent sind, z. B. mobile Measurement-Partner (MMPs) und Supply-Side-Plattformen (SSPs). Die Protected App Signals API soll diese Ad-Tech-Unternehmen unterstützen, indem sie flexible Lösungen für die Verwaltung von Protected App Signals bietet. Dazu können On-Device-Aufrufer die Erstellung von Protected App Signals im Namen von Käufern aufrufen. Dieser Vorgang wird als Delegation bezeichnet und nutzt die fetchSignalUpdates() API. fetchSignalUpdates() verwendet einen URI und ruft eine Liste von Signalaktualisierungen ab. Zur Veranschaulichung: fetchSignalUpdates() sendet eine GET-Anfrage an den angegebenen URI, um die Liste der Updates 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.

Die unterstützten JSON-Befehle sind:

• put: Fügt einen skalaren Wert für den angegebenen Schlüssel ein oder überschreibt ihn.
• put_if_not_present: Fügt einen Skalarwert für den angegebenen Schlüssel ein, wenn noch kein Wert gespeichert ist. Diese Option kann beispielsweise nützlich sein, um eine Test-ID für den angegebenen Nutzer festzulegen und zu verhindern, dass sie überschrieben wird, wenn sie bereits von einer anderen Anwendung festgelegt wurde.
• append: Fügt der Zeitreihe, die dem angegebenen Schlüssel zugeordnet ist, ein Element hinzu. Der Parameter „maxSignals“ gibt die maximale Anzahl von Signalen in der Zeitreihe an. Wenn die Größe überschritten wird, werden die früheren Elemente entfernt. Wenn der Schlüssel einen skalaren Wert enthält, wird er automatisch in eine Zeitreihe umgewandelt.
• remove: Entfernt die Inhalte, die dem angegebenen Schlüssel zugeordnet sind.

{
   "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 aufgeführten Befehle sind für das Einfügen, Überschreiben und Löschen von Skalarsignalen sowie für das Einfügen, Anhängen und vollständige Überschreiben von Zeitreihensignalen vorgesehen. Die Semantik zum Löschen und Überschreiben bestimmter Elemente eines Zeitachsensignals muss während des Codierungs- und Komprimierungsprozesses verwaltet werden. Das kann beispielsweise durch Ignorieren von Werten in einer Zeitachse während der Codierung erfolgen, die durch neuere Werte ersetzt oder korrigiert werden, und durch Löschen dieser Werte während der Komprimierung.

Gespeicherte Signale werden automatisch der Anwendung zugeordnet, die die Abrufanfrage ausführt, sowie dem Responder der Anfrage (der „Website“ oder dem „Ursprung“ einer registrierten Ad-Tech-Lösung) und der Erstellungszeit der Anfrage. Alle Signale werden im Namen einer in der Privacy Sandbox registrierten Anzeigentechnologie gespeichert. Der URI „site“/„origin“ muss mit den Daten einer registrierten Anzeigentechnologie übereinstimmen. Wenn die anfragende Anzeigentechnologie nicht registriert ist, wird die Anfrage abgelehnt.

Speicherkontingent und Entfernung

Für jede Ad-Tech-Lösung steht auf dem Gerät des Nutzers nur eine begrenzte Menge an Speicherplatz zum Speichern von Signalen zur Verfügung. Dieses Kontingent wird pro Ad-Tech-Unternehmen definiert. Signale, die aus verschiedenen Apps stammen, teilen sich also das Kontingent. Wenn das Kontingent überschritten wird, schafft das System Platz, indem es frühere Signalwerte nach dem FIFO-Prinzip (First In, First Out) entfernt. Damit das Entfernen nicht zu häufig ausgeführt wird, implementiert das System eine Batching-Logik, die einen begrenzten Quota-Überzug ermöglicht und zusätzlichen Speicherplatz freigibt, sobald die Entfernungslogik ausgelöst wird.

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

Um Signale für die Anzeigenauswahl vorzubereiten, hat die benutzerdefinierte Logik des Käufers geschützten Zugriff auf die gespeicherten App-spezifischen Signale und Ereignisse. Ein Android-System-Hintergrundjob wird stündlich ausgeführt, um die benutzerdefinierte Codierungslogik für jeden Käufer auszuführen, die auf das Gerät heruntergeladen wird. Die benutzerdefinierte Codierungslogik für Käufer codiert die app-bezogenen Signale und komprimiert sie dann in eine Nutzlast, die dem Käuferkontingent entspricht. Die Nutzlast wird dann innerhalb des geschützten Gerätespeichers verschlüsselt und an die Gebots- und Auktionsdienste übertragen.

Anbieter von Anzeigentechnologien definieren den Grad der Signalverarbeitung, der von ihrer eigenen benutzerdefinierten Logik übernommen wird. Sie könnten Ihre Lösung beispielsweise so konfigurieren, dass frühere Signale verworfen werden, und ähnliche oder sich verstärkende Signale aus verschiedenen Anwendungen in neuen Signalen zusammenfassen, die weniger Speicherplatz benötigen.

Wenn ein Käufer keinen Signal-Encoder registriert hat, werden keine Signale vorbereitet und keine der auf dem Gerät kuratierten Signale werden an die Dienste für Gebote und Auktionen gesendet.

Weitere Informationen zu Speicher-, Nutzlast- und Anfragekontingenten werden in einem zukünftigen Update verfügbar sein. Außerdem werden wir weitere Informationen dazu bereitstellen, wie Sie benutzerdefinierte Funktionen bereitstellen können.

Workflow für die Anzeigenauswahl

Mit diesem Vorschlag kann über benutzerdefinierten Ad-Tech-Code nur in einer Protected Auction (Ad Selection API), die in einer TEE ausgeführt wird, auf die Protected App Signals zugegriffen werden. Um die Anforderungen für den Anwendungsfall „App-Installation“ weiter zu unterstützen, werden in der geschützten Auktion Kandidatenanzeigen in Echtzeit abgerufen. Das ist anders als beim Remarketing, wo die infrage kommenden Anzeigen vor der Auktion bekannt sind.

Bei diesem Vorschlag wird ein ähnlicher Workflow für die Anzeigenauswahl wie beim Protected Audience-Vorschlag verwendet. Er wurde jedoch aktualisiert, um den Anwendungsfall für die App-Installation zu unterstützen. Um die Rechenanforderungen für die Entwicklung von Funktionen und die Auswahl von Anzeigen in Echtzeit zu erfüllen, müssen Auktionen für App-Install-Anzeigen über Gebots- und Auktionsdienste in TEEs ausgeführt werden. Der Zugriff auf Protected App Signals während einer Protected Auction wird bei On-Device-Auktionen nicht unterstützt.

Der Workflow für die Anzeigenauswahl sieht so aus:

1. Das SDK des Verkäufers sendet die verschlüsselte On-Device-Nutzlast von Protected App Signals.
2. Der Server des Verkäufers erstellt eine Auktionskonfiguration und sendet sie zusammen mit der verschlüsselten Nutzlast an den Trusted Bidding and Auction Service des Verkäufers, um einen Workflow zur Anzeigenauswahl zu starten.
3. Der Gebots- und Auktionsdienst des Verkäufers übergibt die Nutzlast an die Frontend-Server der teilnehmenden vertrauenswürdigen Käufer.
4. Der Gebotsdienst des Käufers führt die Logik zur Auswahl von Anzeigen auf Käuferseite aus.
   1. Ausführung der Logik zum Abrufen von Anzeigen auf der Käuferseite:
   2. Ausführung der Gebotslogik auf der Käuferseite:
5. Die Logik für die Bewertung auf der Verkäuferseite wird ausgeführt.
6. Die Anzeige wird gerendert und die Berichterstellung wird gestartet.

Workflow für die Anzeigenauswahl starten

Wenn in einer App eine Anzeige ausgeliefert werden soll, wird der Workflow zur Anzeigenauswahl vom Ad-Tech-SDK (in der Regel SSPs) initiiert. Dazu werden alle relevanten Kontextdaten vom Publisher und die verschlüsselten Nutzlasten pro Käufer in die Anfrage aufgenommen, die mit dem getAdSelectionData-Aufruf an die Protected Audience API gesendet wird. Dies ist dieselbe API, die für den Remarketing-Workflow verwendet wird und im Vorschlag Bidding And Auction Integration for Android beschrieben ist.

Um die Anzeigenauswahl zu starten, übergibt der Verkäufer eine Liste der teilnehmenden Käufer und die verschlüsselte Nutzlast der Protected App Signals auf dem Gerät. Mit diesen Informationen bereitet der Ad-Server auf der Verkaufsseite eine SelectAdRequest für den vertrauenswürdigen SellerFrontEnd-Dienst vor.

Der Verkäufer legt Folgendes fest:

• Die vom getAdSelectionData empfangene Nutzlast, die die Signale geschützter Apps enthält.

• Die Kontextsignale werden verwendet, um:

  • auction_config.auction_signals (für Informationen zur Auktion)

  • auction_config.seller_signals (für die Signale des Verkäufers

  • auction_config.per_buyer_config["buyer"].buyer_signals (für die Signale der Käufer)

• Die Liste der Käufer, die in den Auktionen mit dem Feld buyer_list enthalten sind.

Ausführung der Logik zur Anzeigenauswahl auf der Buy Side

Die benutzerdefinierte Logik des Käufers verwendet kontextbezogene Daten, die vom Publisher bereitgestellt werden, und Protected App Signals, um ein Gebot für relevante Anzeigen für die Anzeigenanfrage auszuwählen und anzuwenden. Auf der Plattform können Käufer einen großen Pool verfügbarer Anzeigen auf die relevantesten (die Top-k) eingrenzen. Für diese werden Gebote berechnet, bevor die Anzeigen zur endgültigen Auswahl an den Verkäufer zurückgegeben werden.

Vor dem Bieten haben Käufer Zugriff auf eine große Anzahl von Anzeigen. Es ist zu langsam, ein Gebot für jede Anzeige zu berechnen. Daher müssen Käufer zuerst die k besten Kandidaten aus dem großen Pool auswählen. Als Nächstes müssen Käufer Gebote für jeden dieser Top-k-Kandidaten berechnen. Anschließend werden diese Anzeigen und Gebote zur endgültigen Auswahl an den Verkäufer zurückgegeben.

1. Der Dienst „BuyerFrontEnd“ empfängt eine Anzeigenanfrage.
2. Der BuyerFrontEnd-Dienst sendet eine Anfrage an den Gebotsdienst des Käufers. Der Gebotsdienst des Käufers führt eine UDF namens prepareDataForAdRetrieval() aus, mit der eine Anfrage erstellt wird, um die k besten Kandidaten vom Ad Retrieval Service abzurufen. Der Gebotsdienst sendet diese Anfrage an den konfigurierten Serverendpunkt für den Abruf.
3. Der Ad Retrieval Service führt die UDF getCandidateAds() aus, die die Menge der Top-k-Kandidatenanzeigen filtert, die an den Gebotsdienst des Käufers gesendet werden.
4. Der Gebotsdienst des Käufers führt die UDF generateBid() aus, wählt den besten Kandidaten aus, berechnet sein Gebot und gibt es dann an den Dienst „BuyerFrontEnd“ zurück.
5. Der BuyerFrontEnd-Dienst gibt die Anzeigen und Gebote an den Verkäufer zurück.

Es gibt mehrere wichtige Details zu diesem Ablauf, insbesondere in Bezug darauf, wie die einzelnen Komponenten miteinander kommunizieren und wie die Plattform Funktionen wie die Möglichkeit bietet, Vorhersagen für maschinelles Lernen zu treffen, um die k besten Anzeigen abzurufen und ihre Gebote zu berechnen.

Bevor wir uns einige Teile dieses Diagramms genauer ansehen, sind einige wichtige architektonische Hinweise zu den TEEs zu beachten.

Der Gebotsdienst des Käufers enthält intern einen Inferenzdienst. Ad-Tech-Unternehmen können Modelle für maschinelles Lernen in den Gebotsdienst des Käufers hochladen. Wir stellen JavaScript-APIs für AdTech-Unternehmen bereit, mit denen Vorhersagen getroffen oder Einbettungen aus diesen Modellen innerhalb der UDFs generiert werden können, die im Gebotsdienst des Käufers ausgeführt werden. Im Gegensatz zum Dienst zum Abrufen von Anzeigen hat der Gebotsdienst des Käufers keinen Schlüssel/Wert-Dienst zum Speichern von Anzeigenmetadaten.

Der Dienst zum Abrufen von Anzeigen umfasst intern einen Schlüssel/Wert-Dienst. Anzeigentechnologien können Schlüssel/Wert-Paare von ihren eigenen Servern aus in diesen Dienst übertragen, also außerhalb der Datenschutzgrenze. Wir stellen eine JavaScript API für Anzeigentechnologien bereit, mit der sie aus diesem Schlüssel/Wert-Dienst in den UDFs lesen können, die im Ad Retrieval Service ausgeführt werden. Im Gegensatz zum Gebotsdienst des Käufers enthält der Dienst zum Abrufen von Anzeigen keinen Inferenzdienst.

Eine zentrale Frage, die mit diesem Design beantwortet wird, ist, wie Vorhersagen für die Abruf- und Gebotszeit erstellt werden. Die Antwort für beide kann eine Lösung namens Modellfaktorisierung umfassen.

Modellfaktorisierung

Die Modellfaktorisierung ist eine Technik, mit der ein einzelnes Modell in mehrere Teile zerlegt und diese Teile dann zu einer Vorhersage kombiniert werden können. Bei der App-Installation werden in Modellen häufig drei Arten von Daten verwendet: Nutzerdaten, Kontextdaten und Anzeigendaten.

Im nicht faktorisierten Fall wird ein einzelnes Modell mit allen drei Arten von Daten trainiert. Im faktorisierten Fall zerlegen wir das Modell in mehrere Teile. Nur der Teil, der Nutzerdaten enthält, ist vertraulich. Das bedeutet, dass nur das Modell mit dem Nutzerteil innerhalb der Vertrauensgrenze im Inferenzdienst des Gebotsdienstes des Käufers ausgeführt werden muss.

Dadurch ist das folgende Design möglich:

1. Teilen Sie das Modell in einen privaten Teil (die Nutzerdaten) und einen oder mehrere nicht private Teile (die Kontext- und Anzeigendaten) auf.
2. Optional können Sie einige oder alle nicht privaten Teile als Argumente an eine UDF übergeben, die Vorhersagen treffen muss. Kontextbezogene Einbettungen werden beispielsweise an UDFs in der per_buyer_signals übergeben.
3. Optional können Ad-Tech-Unternehmen Modelle für nicht private Teile erstellen und dann Einbettungen aus diesen Modellen in den Schlüssel/Wert-Speicher des Ad Retrieval Service materialisieren. Mit UDFs im Ad Retrieval Service können diese Einbettungen zur Laufzeit abgerufen werden.
4. Um während einer benutzerdefinierten Funktion eine Vorhersage zu treffen, kombinieren Sie private Einbettungen aus dem Inferenzdienst mit nicht privaten Einbettungen aus benutzerdefinierten Funktionsargumenten oder dem Schlüssel/Wert-Speicher mit einer Operation wie einem Skalarprodukt. Das ist die endgültige Vorhersage.

Nachdem wir das geklärt haben, können wir uns die einzelnen benutzerdefinierten Funktionen genauer ansehen. Wir erklären, was sie tun, wie sie integriert werden und wie sie die Vorhersagen treffen können, die erforderlich sind, um die k besten Anzeigen auszuwählen und ihre Gebote zu berechnen.

Die prepareDataForAdRetrieval()-UDF

prepareDataForAdRetrieval(), das auf dem Gebotsdienst des Käufers ausgeführt wird, ist für die Erstellung der Anfrage-Payload verantwortlich, die an den Dienst zum Abrufen von Anzeigen gesendet wird, um die k besten infrage kommenden Anzeigen abzurufen.

prepareDataForAdRetrieval() verwendet die folgenden Informationen:

• Die Nutzlast pro Käufer, die von getAdSelectionData empfangen wurde. Diese Nutzlast enthält die Protected App Signals.
• Die kontextbezogenen Signale auction_signals (für Informationen zur Auktion) und buyer_signals (für die Felder Signale der Käufer).

prepareDataForAdRetrieval() hat zwei Funktionen:

• Featurisierung: Wenn eine Inferenz zur Abrufzeit erforderlich ist, werden eingehende Signale in Features umgewandelt, die bei Aufrufen des Inferenzdienstes verwendet werden, um private Einbettungen für den Abruf zu erhalten.
• Berechnet private Einbettungen für den Abruf: Wenn Vorhersagen für den Abruf erforderlich sind, wird der Aufruf mit diesen Features an den Inferenzdienst gesendet und eine private Einbettung für Vorhersagen zum Abrufzeitpunkt abgerufen.

prepareDataForAdRetrieval() gibt Folgendes zurück:

• Protected App Signals: Nutzlast mit Signalen, die von Ad-Tech-Unternehmen zusammengestellt wurden.
• Auktionsspezifische Signale: plattformspezifische Sell-Side-Signale und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest. Das ähnelt Protected Audience.
• Zusätzliche Signale: Zusätzliche Informationen wie private Einbettungen, die vom Inferenzdienst abgerufen werden.

Diese Anfrage wird an den Ad Retrieval Service gesendet, der Kandidaten abgleicht und dann die UDF getCandidateAds() ausführt.

Die getCandidateAds()-UDF

getCandidateAds() wird im Dienst zum Abrufen von Anzeigen ausgeführt. Sie empfängt die Anfrage, die von prepareDataForAdRetrieval() im Gebotsdienst des Käufers erstellt wurde. Der Dienst führt getCandidateAds() aus, wodurch die k besten Gebotskandidaten abgerufen werden. Dazu wird die Anfrage in eine Reihe von Set-Abfragen und Datenabrufen umgewandelt und benutzerdefinierte Geschäftslogik sowie andere benutzerdefinierte Abruflogik ausgeführt.

getCandidateAds() verwendet die folgenden Informationen:

• Protected App Signals: Nutzlast mit Signalen, die von Ad-Tech-Unternehmen zusammengestellt wurden.
• Auktionsspezifische Signale: plattformspezifische Sell-Side-Signale und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest. Das ähnelt Protected Audience.
• Zusätzliche Signale: Zusätzliche Informationen wie private Einbettungen, die vom Inferenzdienst abgerufen werden.

getCandidateAds() führt Folgendes aus:

1. Abrufen einer ersten Gruppe von Anzeigekandidaten: Anzeigekandidaten werden anhand von Targeting-Kriterien wie Sprache, geografische Einheit, Anzeigentyp, Anzeigengröße oder Budget gefiltert.
2. Abrufen von Retrieval-Einbettungen: Wenn Einbettungen aus dem Schlüssel/Wert-Dienst benötigt werden, um eine Vorhersage zur Abrufzeit für die Auswahl der Top-k-Ergebnisse zu treffen, müssen sie aus dem Schlüssel/Wert-Dienst abgerufen werden.
3. Auswahl der k besten Kandidaten: Berechnen Sie eine einfache Punktzahl für die gefilterte Gruppe von Anzeigenkandidaten basierend auf Anzeigenmetadaten, die aus dem Key-Value-Speicher abgerufen wurden, und Informationen, die vom Gebotsdienst des Käufers gesendet wurden, und wählen Sie die k besten Kandidaten basierend auf dieser Punktzahl aus. Der Wert kann beispielsweise die Wahrscheinlichkeit sein, dass eine App nach der Anzeige installiert wird.
4. Abruf von Gebett-Embeddings: Wenn Gebett-Embeddings aus dem Schlüssel/Wert-Dienst vom Gebotscode benötigt werden, um Vorhersagen zur Gebotszeit zu treffen, können sie aus dem Schlüssel/Wert-Dienst abgerufen werden.

Die Bewertung einer Anzeige kann das Ergebnis eines Vorhersagemodells sein, das beispielsweise die Wahrscheinlichkeit vorhersagt, dass ein Nutzer eine App installiert. Bei dieser Art der Bewertung wird eine Art Modellfaktorisierung verwendet: Da getCandidateAds() im Ad Retrieval Service ausgeführt wird und dieser Dienst keinen Inferenzdienst hat, können Vorhersagen durch Kombination der folgenden Elemente generiert werden:

• Kontextbezogene Einbettungen, die über die Eingabe auktionsspezifische Signale übergeben werden.
• Private Einbettungen, die über die Eingabe additional_signals übergeben werden.
• Alle nicht privaten Einbettungs-Ad-Techs wurden von ihren Servern in den Schlüssel/Wert-Dienst des Ad Retrieval Service übertragen.

Die generateBid()-UDF, die im Gebotsdienst des Käufers ausgeführt wird, kann auch eine eigene Art der Modellfaktorisierung anwenden, um Gebotsvorhersagen zu treffen. Falls dazu Einbettungen aus einem Schlüssel/Wert-Dienst erforderlich sind, müssen sie jetzt abgerufen werden.

getCandidateAds() gibt Folgendes zurück:

• Kandidatenanzeigen: Die k besten Anzeigen, die an generateBid() übergeben werden sollen. Jede Anzeige besteht aus:
  • Render-URL: Endpunkt zum Rendern des Anzeigen-Creatives.
  • Metadaten: Anzeigenmetadaten, die für die Kaufseite und Ad-Tech-Unternehmen spezifisch sind. Dazu können beispielsweise Informationen zur Werbekampagne und Targeting-Kriterien wie Standort und Sprache gehören. Die Metadaten können optionale Einbettungen enthalten, die verwendet werden, wenn für die Inferenzausführung während der Gebotsabgabe eine Modellfaktorisierung erforderlich ist.
• Zusätzliche Signale: Optional kann der Dienst zum Abrufen von Anzeigen zusätzliche Informationen wie zusätzliche Einbettungen oder Spamsignale enthalten, die in generateBid() verwendet werden.

Wir untersuchen derzeit andere Methoden, um Anzeigen für die Bewertung bereitzustellen, z. B. als Teil des SelectAdRequest-Aufrufs. Diese Anzeigen können über eine RTB-Gebotsanfrage abgerufen werden. In solchen Fällen müssen Anzeigen ohne Protected App Signals abgerufen werden. Wir gehen davon aus, dass Ad-Tech-Unternehmen die Vor- und Nachteile abwägen, bevor sie sich für die beste Option entscheiden. Dazu gehören die Größe der Antwortnutzlast, die Latenz, die Kosten und die Verfügbarkeit von Signalen.

Die generateBid()-UDF

Nachdem Sie die Gruppe der infrage kommenden Anzeigen und die Einbettungen während des Abrufs abgerufen haben, können Sie mit dem Gebotsverfahren fortfahren, das im Gebotsdienst des Käufers ausgeführt wird. Bei diesem Dienst wird die vom Käufer bereitgestellte generateBid()-UDF ausgeführt, um die Anzeige aus den k besten Anzeigen auszuwählen, auf die geboten werden soll. Anschließend wird sie mit dem Gebot zurückgegeben.

generateBid() verwendet die folgenden Informationen:

• Kandidatenanzeigen: Die k besten Anzeigen, die vom Abrufdienst für Anzeigen zurückgegeben werden.
• Auktionsspezifische Signale: plattformspezifische Sell-Side-Signale und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest.
• Zusätzliche Signale: zusätzliche Informationen, die zum Zeitpunkt der Gebotsabgabe verwendet werden.

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

• Featurization: Wandelt Signale in Features um, die während der Inferenz verwendet werden.
• Inferenz: Hier werden Vorhersagen mithilfe von Machine-Learning-Modellen generiert, um Werte wie die voraussichtlichen Klick- und Conversion-Raten zu berechnen.
• Gebotseinstellung: Hier werden abgeleitete Werte mit anderen Eingaben kombiniert, um das Gebot für eine infrage kommende Anzeige zu berechnen.

generateBid() gibt Folgendes zurück:

• Die Anzeige des Kandidaten.
• Der berechnete Gebotsbetrag.

Die generateBid() für App-Installationsanzeigen und Remarketing-Anzeigen sind unterschiedlich.

In den folgenden Abschnitten werden die Schritte „Featurisierung“, „Inferenz“ und „Gebote“ genauer beschrieben.

Featurisierung

Auktionssignale können von generateBid() in Features umgewandelt werden. Diese Merkmale können während der Inferenz verwendet werden, um beispielsweise die Klick- und Conversion-Raten vorherzusagen. Wir prüfen auch datenschutzfreundliche Mechanismen, um einige dieser Daten im Bericht zu Kampagnenerfolgen für das Modelltraining zu übertragen.

Inferenz

Bei der Berechnung eines Gebots wird häufig eine Inferenz für ein oder mehrere Modelle für maschinelles Lernen durchgeführt. Bei der Berechnung des effektiven eCPM werden beispielsweise häufig Modelle verwendet, um die Klick- und Conversion-Raten vorherzusagen.

Kunden können eine Reihe von Modellen für maschinelles Lernen zusammen mit ihrer generateBid()-Implementierung bereitstellen. Wir stellen auch eine JavaScript API in generateBid() bereit, damit Clients zur Laufzeit Inferenz durchführen können.

Die Inferenz wird im Gebotsdienst des Käufers ausgeführt. Dies kann sich auf die Latenz und die Kosten der Inferenz auswirken, insbesondere da Beschleuniger noch nicht in TEEs verfügbar sind. Einige Kunden werden feststellen, dass ihre Anforderungen mit einzelnen Modellen erfüllt werden, die im Gebotsdienst des Käufers ausgeführt werden. Einige Kunden, z. B. solche mit sehr großen Modellen, sollten Optionen wie die Modellfaktorisierung in Betracht ziehen, um die Kosten und Latenz für die Inferenz zum Zeitpunkt des Gebots zu minimieren.

Weitere Informationen zu den Inferenzfunktionen, z. B. zu unterstützten Modellformaten und maximalen Größen, werden in einem zukünftigen Update bereitgestellt.

Modellfaktorisierung implementieren

Wir haben bereits Modellfaktorisierung erläutert. Bei der Gebotsabgabe wird so vorgegangen:

1. Das einzelne Modell wird in einen privaten Teil (die Nutzerdaten) und einen oder mehrere nicht private Teile (die Kontext- und Anzeigendaten) aufgeteilt.
2. Übergeben Sie nicht private Teile an generateBid(). Diese können entweder von per_buyer_signals stammen oder von Einbettungen, die von Ad-Tech-Unternehmen extern berechnet, im Schlüssel/Wert-Speicher des Abrufdienstes materialisiert, zum Abrufzeitpunkt abgerufen und als Teil der zusätzlichen Signale zurückgegeben werden. Private Einbettungen sind davon ausgeschlossen, da sie nicht von außerhalb der Datenschutzgrenze stammen können.
3. In generateBid():
   1. Inferenz für Modelle ausführen, um private Nutzereinbettungen zu erhalten.
   2. Kombinieren Sie private Nutzer-Embeddings mit kontextbezogenen Embeddings aus per_buyer_signals oder nicht privaten Anzeigen- und kontextbezogenen Embeddings aus dem Abrufdienst mithilfe einer Operation wie einem Skalarprodukt. Dies ist die endgültige Vorhersage, die zur Berechnung von Geboten verwendet werden kann.

Mit diesem Ansatz ist es möglich, zur Gebotszeit Inferenz für Modelle auszuführen, die andernfalls zu groß oder zu langsam für die Ausführung im Gebotsdienst des Käufers wären.

Scoring-Logik auf Verkäuferseite

In dieser Phase werden die Anzeigen mit Geboten aller teilnehmenden Käufer bewertet. Die Ausgabe von generateBid() wird an den Auktionsdienst des Verkäufers übergeben, um scoreAd() auszuführen. Dabei wird jeweils nur eine Anzeige berücksichtigt.scoreAd() Anhand der Punktzahl wählt der Verkäufer eine erfolgreiche Anzeige aus, die auf dem Gerät gerendert werden soll.

Die Scoring-Logik ist dieselbe wie für den Protected Audience-Remarketing-Ablauf und kann einen Gewinner unter den Remarketing- und App-Installationskandidaten auswählen.Die Funktion wird einmal für jede eingereichte Kandidatenanzeige in der Protected Auction aufgerufen. Weitere Informationen finden Sie im Erklärvideo zu Geboten und Auktionen.

Laufzeit des Codes für die Anzeigenauswahl

Im Vorschlag wird der Code für die Anzeigenauswahl für die App-Installation auf dieselbe Weise wie für den Protected Audience-Remarketing-Ablauf angegeben. Weitere Informationen finden Sie unter Gebots- und Auktionskonfiguration. Der Gebotscode ist am selben Cloud Storage-Speicherort wie der für Remarketing verwendete Code verfügbar.

Berichte

In diesem Vorschlag werden dieselben Reporting-APIs wie im Vorschlag für Protected Audience-Berichte verwendet, z. B. reportImpression(), wodurch die Plattform Verkäufer- und Käuferberichte sendet.

Ein häufiger Anwendungsfall für Berichte auf der Käuferseite sind die Trainingsdaten für Modelle, die bei der Anzeigenauswahl verwendet werden. Zusätzlich zu den bestehenden APIs bietet die Plattform einen speziellen Mechanismus zum Exportieren von Daten auf Ereignisebene von der Plattform auf Ad-Tech-Server. Diese Egress-Nutzlasten 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 Nutzerdaten auf Ereignisebene außerhalb von Diensten zu senden, die auf TEEs ausgeführt werden. Weitere Informationen folgen in einem späteren Update.

Kurzfristig werden wir eine temporäre Möglichkeit zum Exportieren von anonymisierten Daten aus generateBid() bereitstellen. Unser ursprünglicher Vorschlag dazu folgt. Wir werden ihn auf Grundlage von Branchenfeedback weiterentwickeln (einschließlich möglicher nicht abwärtskompatibler Änderungen).

So funktioniert es technisch:

1. Ad-Tech-Unternehmen definieren ein Schema für die Daten, die sie übertragen möchten.
2. In generateBid() wird die ausgewählte Egress-Nutzlast erstellt.
3. Die Plattform validiert die Egress-Nutzlast anhand des Schemas und erzwingt Größenbeschränkungen.
4. Die Plattform fügt der Egress-Nutzlast Rauschen hinzu.
5. Die Egress-Nutzlast ist im Win-Bericht im Wire-Format enthalten, der auf Ad-Tech-Servern empfangen, decodiert und für das Modelltraining verwendet wird.

Schema von Egress-Nutzlasten definieren

Damit die Plattform sich ändernde Datenschutzanforderungen durchsetzen kann, müssen die Egress-Nutzlasten so strukturiert sein, dass die Plattform sie verstehen kann. Ad-Tech-Unternehmen definieren die Struktur ihrer Egress-Nutzlasten, indem sie eine Schema-JSON-Datei bereitstellen. Dieses Schema wird von der Plattform verarbeitet und von den Bidding- und Auktionsdiensten mit denselben Mechanismen wie andere Ad-Tech-Ressourcen wie benutzerdefinierte Funktionen und Modelle vertraulich behandelt.

Wir stellen eine CDDL-Datei bereit, die die Struktur des JSON definiert. Die CDDL-Datei enthält eine Reihe unterstützter Feature-Typen (z. B. Features, die boolesche Werte, Ganzzahlen, Klassen usw. sind). Sowohl die CDDL-Datei als auch das bereitgestellte Schema werden versioniert.

Eine Egress-Nutzlast, die aus einem einzelnen booleschen Merkmal gefolgt von einem Bucket-Merkmal der Größe 2 besteht, sieht beispielsweise so aus:

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

Details zu den unterstützten Feature-Typen finden Sie auf GitHub.

Egress-Payloads in generateBid() erstellen

Alle Protected App Signals für einen bestimmten Käufer sind für seine generateBid()-UDF verfügbar. Sobald diese Daten in Features umgewandelt wurden, erstellen Ad-Tech-Unternehmen ihre Nutzlast im JSON-Format. Diese Egress-Nutzlast wird in den Win-Bericht des Käufers aufgenommen, um an AdTech-Server gesendet zu werden.

Eine Alternative zu diesem Design besteht darin, die Berechnung des Egress-Vektors in reportWin() anstelle von generateBid() durchzuführen. Jeder Ansatz hat Vor- und Nachteile. Wir werden die endgültige Entscheidung auf Grundlage des Branchenfeedbacks treffen.

Egress-Nutzlast validieren

Die Plattform validiert alle Egress-Nutzlasten, die von der Ad-Tech erstellt werden. Bei der Validierung wird geprüft, ob die Funktionswerte für ihre Typen gültig sind, ob die Größenbeschränkungen eingehalten werden und ob böswillige Akteure versuchen, Datenschutzkontrollen zu umgehen, indem sie zusätzliche Informationen in ihre Egress-Nutzlasten packen.

Wenn eine Egress-Nutzlast ungültig ist, wird sie stillschweigend aus den Eingaben entfernt, die an den Win-Bericht gesendet werden. Wir möchten keine Debugging-Informationen für böswillige Akteure bereitstellen, die versuchen, die Validierung zu umgehen.

Wir stellen eine JavaScript API für Ad-Tech-Unternehmen bereit, mit der sie prüfen können, ob die von ihnen in generateBid() erstellte Egress-Nutzlast die Plattformvalidierung besteht:

validate(payload, schema)

Diese JavaScript API ist ausschließlich für Anrufer bestimmt, um festzustellen, ob eine bestimmte Nutzlast die Plattformvalidierung besteht. Die tatsächliche Validierung muss auf der Plattform erfolgen, um böswillige generateBid()-UDFs zu verhindern.

Egress-Nutzlast mit Rauschen versehen

Die Plattform fügt Ausstiegs-Payloads Rauschen hinzu, bevor sie in den Gewinnbericht aufgenommen werden. Der anfängliche Rauschschwellenwert beträgt 1 %. Dieser Wert kann sich im Laufe der Zeit ändern. Die Plattform gibt nicht an, ob eine bestimmte Egress-Nutzlast verrauscht wurde.

Die Methode zum Hinzufügen von Rauschen ist:

1. Die Plattform lädt die Schemadefinition für die Ausgangsnutzlast.
2. 1% der Egress-Nutzlasten werden für das Hinzufügen von Rauschen ausgewählt.
3. Wenn keine Egress-Nutzlast ausgewählt wird, bleibt der gesamte ursprüngliche Wert erhalten.
4. Wenn eine Egress-Nutzlast ausgewählt wird, wird der Wert jedes Features durch einen zufälligen gültigen Wert für diesen Feature-Typ ersetzt (z. B. entweder 0 oder 1 für ein boolesches Feature).

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

Die validierte, mit Rauschen versehene Nutzlast für ausgehenden Traffic wird in die Argumente für reportWin() aufgenommen und zur Modelltrainierung an die Ad-Tech-Server des Käufers außerhalb der Datenschutzgrenze übertragen. Die ausgehende Nutzlast hat das Wire-Format.

Details zum Wire-Format für alle Funktionstypen und für die Egress-Nutzlast selbst finden Sie auf GitHub.

Größe der Egress-Nutzlast ermitteln

Die Größe der Egress-Nutzlast in Bit gleicht Nützlichkeit und Datenminimierung aus. Wir werden mit der Branche zusammenarbeiten, um die geeignete Größe durch Tests zu ermitteln. Während dieser Tests werden wir Daten vorübergehend ohne Einschränkung der Bitgröße übertragen. Diese zusätzlichen Egress-Daten ohne Bitgrößenbeschränkung werden nach Abschluss der Tests entfernt.

Die Größe wird so bestimmt:

1. Anfangs werden in generateBid() zwei Egress-Nutzlasten unterstützt:
   1. egressPayload: die bisher in diesem Dokument beschriebene Egress-Nutzlast mit Größenbeschränkung. Anfangs hat diese Egress-Nutzlast eine Größe von 0 Bit, d. h., sie wird bei der Validierung immer entfernt.
   2. temporaryUnlimitedEgressPayload: Eine temporäre Egress-Nutzlast ohne Größenbeschränkung für Größenexperimente. Die Formatierung, Erstellung und Verarbeitung dieser Egress-Nutzlast erfolgt nach denselben Mechanismen wie bei egressPayload.
2. Jede dieser Egress-Nutzlasten hat eine eigene Schema-JSON-Datei: egress_payload_schema.json und temporary_egress_payload_schema.json.
3. Wir stellen ein Testprotokoll und eine Reihe von Messwerten zur Verfügung, um den Nutzen des Modells bei verschiedenen Größen der Egress-Nutzlast (z. B. 5, 10, … Bits) zu bestimmen.
4. Anhand der Testergebnisse ermitteln wir die Größe der Egress-Nutzlast mit den richtigen Kompromissen zwischen Nützlichkeit und Datenschutz.
5. Wir legen die Größe von egressPayload von 0 Bit auf die neue Größe fest.
6. Nach einem festgelegten Migrationszeitraum entfernen wir temporaryUnlimitedEgressPayload, sodass nur noch egressPayload mit seiner neuen Größe vorhanden ist.

Wir prüfen zusätzliche technische Schutzmaßnahmen 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 der Zeitplan für den Test und die Entfernung von temporaryUnlimitedEgressPayload werden in einem späteren Update bekannt gegeben.

Als Nächstes wird ein mögliches Testprotokoll für die endgültige Festlegung der Größe von egressPayload erläutert. Unser Ziel ist es, gemeinsam mit der Branche eine Größe zu finden, die ein Gleichgewicht zwischen Nutzen und Datenminimierung schafft. Das Artefakt dieser Tests ist ein Diagramm, in dem die x-Achse die Größe der Trainingsnutzlast in Bits und die y-Achse den Prozentsatz des Umsatzes darstellt, der mit einem Modell dieser Größe im Vergleich zu einer Größenbeschränkung generiert wird.

Wir gehen davon aus, dass wir ein pInstall-Modell trainieren. Die Quellen für unsere Trainingsdaten sind unsere Logs und die Inhalte der temporaryUnlimitedegressPayload, die wir erhalten, wenn wir Auktionen gewinnen. Das Protokoll für Ad-Techs umfasst zuerst Offline-Tests:

1. Die Architektur der Modelle festlegen, die mit Protected App Signals verwendet werden sollen. Sie müssen beispielsweise festlegen, ob sie die Modellfaktorisierung verwenden möchten.
2. Definieren Sie einen Messwert für die Modellqualität. Vorgeschlagene Messwerte sind AUC-Verlust und logarithmischer Verlust.
3. Definieren Sie die Gruppe von Features, die während des Modelltrainings verwendet werden sollen.
4. Mit dieser Modellarchitektur, diesem Qualitätsmesswert und diesem Satz von Trainingsfunktionen führen sie Ablationsstudien durch, um den Nutzen pro Bit für jedes Modell zu ermitteln, das sie in PAS verwenden möchten. Das empfohlene Protokoll für die Ablationsstudie lautet:
   1. Trainieren Sie das Modell mit allen Funktionen und messen Sie den Nutzen. Dies ist die Baseline für den Vergleich.
   2. Trainieren Sie das Modell für jedes Feature, das zum Erstellen der Baseline verwendet wird, mit allen Features außer diesem Feature.
   3. Messen Sie den resultierenden Nutzen. Teilen Sie das Delta durch die Größe des Features in Bit. Das ist der erwartete Nutzen pro Bit für dieses Feature.
5. Bestimmen Sie die Nutzlastgrößen für das Training, die für Tests infrage kommen. Wir empfehlen [5, 10, 15, ..., size_of_all_training_features_for_baseline] Bits. Jeder dieser Werte stellt eine mögliche Größe für egressPayload dar, die im Test untersucht wird.
6. Wählen Sie für jede mögliche Größe eine Reihe von Features aus, die kleiner oder gleich dieser Größe sind und den Nutzen pro Bit maximieren. Verwenden Sie dazu die Ergebnisse der Ablationsstudie.
7. Trainieren Sie ein Modell für jede mögliche Größe und bewerten Sie den Nutzen als Prozentsatz des Nutzens des Basismodells, das mit allen Features trainiert wurde.
8. Stellen Sie die Ergebnisse in einem Diagramm dar, in dem die Größe der Trainingsnutzlast in Bits auf der x-Achse und der prozentuale Umsatz, der mit diesem Modell im Vergleich zur Baseline erzielt wurde, auf der y-Achse dargestellt wird.

Als Nächstes können Ad-Tech-Unternehmen die Schritte 5 bis 8 in Live-Traffic-Tests wiederholen und dabei Funktionsdaten verwenden, die über temporaryUnlimitedEgressPayload gesendet werden. Unternehmen im Bereich Anzeigentechnologie können die Ergebnisse ihrer Offline- und Live-Traffic-Tests mit Privacy Sandbox teilen, um die Entscheidung über die Größe von egressPayload zu treffen.

Der Zeitplan für diese Tests sowie der Zeitplan für die Festlegung der Größe von egressPayload auf den resultierenden Wert werden in einem späteren Update bekannt gegeben.

Datenschutzmaßnahmen

Wir wenden eine Reihe von Schutzmaßnahmen auf exportierte Daten an, darunter:

1. Sowohl egressPayload als auch temporaryUnlimitedEgressPayload werden mit Rauschen versehen.
2. Aus Gründen der Datenminimierung und des Datenschutzes ist temporaryUnlimitedEgressPayload nur für die Dauer von Größen-Tests verfügbar, in denen wir die richtige Größe für egressPayload ermitteln.

Berechtigungen

Nutzersteuerung

• Mit dem Vorschlag soll Nutzern die Liste der installierten Apps angezeigt werden, in denen mindestens ein Protected App Signal oder eine benutzerdefinierte Zielgruppe gespeichert ist.
• Nutzer können Apps in dieser Liste blockieren und entfernen. Wenn Sie einen Nutzer blockieren und entfernen, passiert Folgendes:
  • Löscht alle Protected App Signals und benutzerdefinierten Zielgruppen, die mit der App verknüpft sind.
  • Verhindert, dass in den Apps neue Protected App Signals und benutzerdefinierte Zielgruppen gespeichert werden.
• Nutzer haben die Möglichkeit, die Protected App Signals API und die Protected Audience API vollständig zurückzusetzen. In diesem Fall werden alle vorhandenen Signale geschützter Apps und benutzerdefinierten Zielgruppen auf dem Gerät gelöscht.
• Nutzer können die Privacy Sandbox auf Android komplett deaktivieren. Das umfasst die Protected App Signals API und die Protected Audience API. In diesem Fall geben die Protected Audience API und die Protected App Signals API eine Standardausnahmemeldung zurück: SECURITY_EXCEPTION.

App-Berechtigungen und ‑Einstellungen

Mit dem Vorschlag sollen Apps die Möglichkeit erhalten, ihre Protected App Signals zu verwalten:

• Eine App kann ihre Zuordnungen zu Protected App Signals verwalten.
• Eine App kann Drittanbieter-Ad-Tech-Plattformen Berechtigungen zum Verwalten von Signalen geschützter Apps in ihrem Namen erteilen.

Einstellungen für AdTech-Plattformen

In diesem Vorschlag werden Möglichkeiten für Ad-Tech-Unternehmen beschrieben, ihre Protected App Signals zu verwalten:

• Alle Anbieter von Anzeigentechnologien müssen sich für die Privacy Sandbox registrieren und eine „site“- oder „origin“-Domain angeben, die mit allen URLs für Protected App Signals übereinstimmt.
• Ad-Tech-Unternehmen können mit Apps oder SDKs zusammenarbeiten, um Bestätigungstokens bereitzustellen, mit denen die Erstellung von Protected App Signals überprüft wird. Wenn dieser Prozess an einen Partner delegiert wird, kann die Erstellung von Protected App Signals so konfiguriert werden, dass eine Bestätigung durch die Ad-Tech-Plattform erforderlich ist.