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 Nutzerakquisition 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 die Lieferung von Lebensmitteln erzielen möchte, kann seine Anzeigen beispielsweise auf Nutzer ausrichten, die sich in den USA befinden und bereits mit anderen Apps für die Lieferung von Lebensmitteln 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 für 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 sie die Abhängigkeit von dienstleisterübergreifenden Nutzerkennungen entfernen:

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 geschützte App-Signale relevante App-Installationsanzeigen 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 die SDKs des Verkäufers 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. Mithilfe dieser Funktionen werden Anzeigen abgeglichen, die den Ausrichtungskriterien entsprechen. Anzeigen, die nicht dem Budget entsprechen, werden herausgefiltert. Die k besten Anzeigen werden dann für Gebote ausgewählt.
  • Gebotsabgabe: Die benutzerdefinierte Gebotslogik der Käufer bereitet die vom Publisher bereitgestellten kontextbezogenen Daten und Protected App Signals vor, 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.
• Berichte: Teilnehmer an Auktionen erhalten entsprechende Berichte zu gewonnenen und verlorenen Auktionen. Wir untersuchen 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 Bidding- und Auktionsdienste, die in Trusted Execution Environments mit angemessener Sicherheits- und Datenschutzkontrolle ausgeführt werden, können sie zum Gebieten 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) für das Entfernen von Elementen verwendet 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 ein bestimmter Speicherplatz zum Speichern von Signalen auf dem Gerät zugewiesen. Signale haben eine maximale TTL, die noch festgelegt werden muss.

Signale geschützter Apps werden aus dem Speicher entfernt, wenn die App, die sie generiert hat, deinstalliert wird, die Verwendung der 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 in Echtzeit während einer Protected Auction, die in einem Trusted Execution Environment (TEE) ausgeführt wird, für weiteres Feature Engineering vorzubereiten.

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 Anzeigentechnologien 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() nimmt einen URI entgegen 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 vermeiden, 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 für das Löschen und Überschreiben bestimmter Elemente eines Zeitachsensignals muss während des Codierungs- und Komprimierungsprozesses verwaltet werden. So können beispielsweise während der Codierung Werte in einer Zeitachse ignoriert werden, die durch neuere Werte ersetzt oder korrigiert wurden, und während des Komprimierungsprozesses gelöscht werden.

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 Kontingentü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 Kontingent für Käufer 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, die durch ihre eigene benutzerdefinierte Logik erfolgt. 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 zusammengefasst werden, 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 Gebots- und Auktionsdienste 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. Es gibt jedoch Updates zur Unterstützung des Anwendungsfalls für die App-Installation. 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-Installationsanzeigen ü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-Dienst 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 Berichte werden erstellt.

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. Anhand dieser 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 Protected App Signals 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 eine große Anzahl verfügbarer Anzeigen auf die relevantesten (die oberen 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 einen großen Pool 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 Dienst „BuyerFrontEnd“ 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 getCandidateAds()-UDF aus, die die Menge der Top-k-Kandidatenanzeigen herausfiltert. Diese werden an den Gebotsdienst des Käufers gesendet.
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 App-Install-Kampagnen 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 im 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 Signale von Käufern).

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 Funktionen 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) aus SelectAdRequest. Das ähnelt Protected Audience.
• Zusätzliche Signale: Zusätzliche Informationen wie private Einbettungen, die vom Inferenzdienst abgerufen werden.

Diese Anfrage wird an den Dienst zum Abrufen von Anzeigen 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, um die k besten Gebotskandidaten abzurufen. Dazu wird die Anfrage in eine Reihe von festgelegten Abfragen und Datenabrufen umgewandelt und benutzerdefinierte Geschäftslogik sowie andere benutzerdefinierte Abrufslogik 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) aus 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 Ausrichtungskriterien 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-Store abgerufen wurden, und Informationen, die vom Gebotsdienst des Käufers gesendet wurden, und wählen Sie anhand dieser Punktzahl die k besten Kandidaten aus. Der Wert kann beispielsweise die Wahrscheinlichkeit sein, dass eine App nach der Anzeige installiert wird.
4. Abruf von Gebett-Einbettungen: Wenn Gebett-Code Einbettungen aus dem Schlüssel/Wert-Dienst benötigt, um Vorhersagen zum Zeitpunkt der Gebotsabgabe zu treffen, können diese 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 Anzeigen mit der höchsten Punktzahl, die an generateBid() übergeben werden. Jede Anzeige besteht aus:
  • Render-URL: Endpunkt zum Rendern des Anzeigen-Creatives.
  • Metadaten: Anzeigenmetadaten für die Kaufseite und Ad-Tech-Unternehmen. 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 eine Modellfaktorisierung erforderlich ist, um während der Gebotsabgabe Inferenz auszuführen.
• 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 Dienst „Ad Retrieval“ zurückgegeben werden.
• Auktionsspezifische Signale: plattformspezifische Sell-Side-Signale und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) aus SelectAdRequest.
• Zusätzliche Signale: zusätzliche Informationen, die zum Zeitpunkt des Gebots verwendet werden.

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

• Featurization (Featurisierung): Signale werden in Features umgewandelt, die während der Inferenz verwendet werden.
• Inferenz: Hier werden Vorhersagen mithilfe von Machine-Learning-Modellen generiert, um Werte wie die prognostizierten 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 „Featurization“, „Inference“ und „Bidding“ 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 davon im Gewinnbericht 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 vertraulichen Teil (die Nutzerdaten) und einen oder mehrere nicht vertrauliche Teile (die Kontext- und Anzeigendaten) unterteilt.
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.

Sell-Side-Bewertungslogik

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. Bei scoreAd() wird jeweils nur eine Anzeige berücksichtigt. 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 Leitfaden 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 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 ist das Abrufen der Trainingsdaten für Modelle, die bei der Anzeigenauswahl verwendet werden. Zusätzlich zu den vorhandenen 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 Protected Auctions 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 verrauschten Daten aus generateBid() bereitstellen. Unser erster Vorschlag dazu folgt. Wir werden ihn auf Grundlage von Feedback aus der Branche weiterentwickeln. Dabei kann es auch zu nicht abwärtskompatiblen Änderungen kommen.

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 dieses 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-Nutzlasten 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-Lösung 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.

Ausgangsnutzlast mit Rauschen versehen

Die Plattform fügt den Ausgangs-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 Nutzlast für den ausgehenden Traffic wird im Wire-Format übertragen.

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 ist ein Kompromiss zwischen Nützlichkeit und Datenminimierung. Wir arbeiten mit der Branche zusammen, 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 entfernt, sobald die Tests abgeschlossen sind.

Die Größe wird so bestimmt:

1. Anfangs werden zwei Egress-Nutzlasten in generateBid() 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ößenversuche. Die Formatierung, Erstellung und Verarbeitung dieser Egress-Nutzlast erfolgt mit 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 bestimmen 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 beschrieben, mit dem die Größe von egressPayload festgelegt werden kann. 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 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 Bit 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. Zur Minimierung und zum Schutz von Daten 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

Kontrolle durch Nutzer

• 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 soll Apps die Möglichkeit gegeben werden, 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.