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

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Dieser Vorschlag unterliegt dem Registrierungsverfahren und den Attestationen der Privacy Sandbox. Weitere Informationen zu den Attestierungen finden Sie in diesem Link. In zukünftigen Updates zu diesem Vorschlag werden die Anforderungen für den Zugriff auf dieses System beschrieben.

App-Installationsanzeigen, auch Anzeigen zur Nutzergewinnung genannt, sind eine Art von mobiler Werbung, mit der Nutzer zum Herunterladen einer App animiert werden sollen. Diese Anzeigen werden Nutzern in der Regel basierend auf ihren Interessen und demografischen Merkmalen ausgeliefert und sind häufig in anderen mobilen Apps wie Spiele-, Social-Media- und Nachrichten-Apps zu sehen. Wenn ein Nutzer auf eine Anzeige für die App-Installation klickt, wird er direkt zum App-Shop weitergeleitet, um die App herunterzuladen.

Ein Werbetreibender, der beispielsweise mehr neue Installationen für eine neue mobile Lieferservice-App in den USA erzielen möchte, kann seine Anzeigen auf Nutzer in den USA ausrichten, die bereits mit anderen Lieferservice-Apps interagiert haben.

Normalerweise werden dazu kontextbezogene Signale, selbst erhobene Daten und Drittanbietersignale zwischen den Anzeigentechnologien verwendet, um Nutzerprofile auf der Grundlage von Anzeigen-IDs zu erstellen. Diese Informationen werden von den Modellen für maschinelles Lernen in der Anzeigentechnologie verwendet, um Anzeigen auszuwählen, die für den Nutzer relevant sind und mit der höchsten Wahrscheinlichkeit zu einer Conversion führen.

Die folgenden APIs sollen effektive Anzeigen für App-Installationen unterstützen, die den Datenschutz für Nutzer verbessern, da die Abhängigkeit von dienstleisterübergreifenden Nutzerkennungen aufgehoben wird:

1. Protected App Signals API: Diese API dient zum Speichern und Erstellen von Funktionen, die mithilfe von Anzeigentechnologien entwickelt wurden und die potenziellen Interessen eines Nutzers repräsentieren. Anbieter von Anzeigentechnologien speichern selbstdefinierte App-Ereignissignale wie App-Installationen, erste Öffnungen, Nutzeraktionen (Level-Aufstieg, Erfolge), Kaufaktivitäten oder die Zeit in der App. Signale werden auf dem Gerät geschrieben und gespeichert, um Datenlecks zu verhindern. Sie werden nur der Anzeigentechnologie-Logik zur Verfügung gestellt, 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 geschützten Auktion, die in einer Trusted Execution Environment (TEE) ausgeführt wird. Dort rufen Anzeigentechnologien Anzeigenkandidaten ab, führen Inferenzen aus, berechnen Gebote und bewerten, um eine „gewinnende“ Anzeige auszuwählen. Dabei werden sowohl die Protected App-Signale als auch von Publishern bereitgestellte kontextbezogene Echtzeitinformationen verwendet.

Hier finden Sie eine allgemeine Übersicht darüber, wie geschützte App-Signale für relevante App-Installationsanzeigen verwendet werden. In den folgenden Abschnitten dieses Dokuments finden Sie weitere Informationen zu den einzelnen Schritten.

• Signalauswahl: Wenn Nutzer mobile Apps verwenden, werden von Anbietern von Anzeigentechnologien Signale ausgewählt, indem sie von Anbietern von Anzeigentechnologien definierte App-Ereignisse mithilfe der Protected App Signals API speichern, um relevante Anzeigen auszuliefern. Diese Ereignisse werden ähnlich wie benutzerdefinierte Zielgruppen in einem geschützten lokalen Speicher auf dem Gerät gespeichert und verschlüsselt, bevor sie vom Gerät gesendet werden. So können nur Gebots- und Auktionsdienste, die in vertrauenswürdigen Ausführungsumgebungen mit den entsprechenden Sicherheits- und Datenschutzeinstellungen ausgeführt werden, sie für Gebote und die Bewertung von Anzeigen entschlüsseln.
• Signalcodierung: Signale werden mithilfe benutzerdefinierter AdTech-Logik in einem geplanten Rhythmus erstellt. Diese Logik wird von einem Android-Hintergrundjob ausgeführt, um eine On-Device-Codierung durchzuführen und eine Nutzlast mit Protected App-Signalen zu generieren, die später in Echtzeit für die Anzeigenauswahl während einer Protected-Auktion 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 geschützten App-Signalen und konfigurieren eine geschützte Auktion. In der Auktion werden die geschützten App-Signale zusammen mit den vom Publisher bereitgestellten Kontextdaten (Daten, die in der Regel in einer Open-RTB-Anzeigenanfrage freigegeben werden) mithilfe der benutzerdefinierten Logik des Käufers verarbeitet, um Funktionen für die Anzeigenauswahl zu entwickeln (Anzeigenabruf, Inferenz und Gebotsgenerierung). Ähnlich wie bei Protected Audience reichen Käufer Anzeigen für die endgültige Bewertung in einer geschützten Auktion beim Verkäufer ein.
  • Anzeigenabruf: Käufer verwenden geschützte App-Signale und vom Publisher bereitgestellte Kontextdaten, um Funktionen zu entwickeln, die für die Interessen der Nutzer relevant sind. Mit diesen Funktionen werden Anzeigen abgeglichen, die die Ausrichtungskriterien erfüllen. Anzeigen, die das Budget überschreiten, werden herausgefiltert. Die „Top k“-Anzeigen werden dann für Gebote ausgewählt.
  • Gebote: Die benutzerdefinierte Gebotslogik von Käufern bereitet die vom Publisher bereitgestellten Kontextdaten und geschützten App-Signale auf, um Funktionen zu entwickeln, die als Eingabe für die Machine-Learning-Modelle von Käufern für die Inferenz und Gebote für ausgewählte 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 der Verkäufer bewertet die von teilnehmenden Käufern eingereichten Anzeigen und wählt eine Gewinneranzeige aus, die zum Rendern an die App zurückgesendet wird.
• Berichterstellung: Auktionsteilnehmer erhalten entsprechende Berichte zu gewonnenen und verlorenen Geboten. Wir arbeiten an datenschutzfreundlichen Mechanismen, um Daten für das Modelltraining in den Bericht zur Anzeigenauslieferung aufzunehmen.

Zeitachse

Protected App Signals zusammenstellen

Ein Signal ist eine Darstellung verschiedener Nutzerinteraktionen in einer App, die von der Anzeigentechnologie als nützlich für die Auslieferung relevanter Anzeigen eingestuft werden. Eine App oder das integrierte SDK kann geschützte App-Signale speichern oder löschen, die von Anzeigentechnologien basierend auf Nutzeraktivitäten wie App-Öffnungen, Erfolgen, Kaufaktivitäten oder der Zeit in der App definiert wurden. Geschützte App-Signale werden sicher auf dem Gerät gespeichert und verschlüsselt, bevor sie vom Gerät gesendet werden. So können nur Gebots- und Auktionsdienste, die in Trusted Execution Environments mit entsprechenden Sicherheits- und Datenschutzeinstellungen ausgeführt werden, sie für Gebote und die Bewertung 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 der Anzeigentechnologie hat geschützten Zugriff auf die ausgewählten Signale, um Funktionen zu entwickeln, die als Grundlage für die Anzeigeauswahl in einer geschützten Auktion dienen.

Protected App Signals API

Die Protected App Signals API unterstützt die Verwaltung von Signalen mit einem Delegierungmechanismus, der dem für benutzerdefinierte Zielgruppen verwendeten ähnelt. Die Protected App Signals API ermöglicht das Speichern von Signalen in Form eines einzelnen Skalarwerts oder als Zeitreihe. Mit Zeitreihensignalen können beispielsweise die Dauer von Nutzersitzungen gespeichert werden. Mit Zeitreihensignalen können Sie eine bestimmte Länge erzwingen, indem Sie eine Auslagerungsregel vom Typ „First In, First Out“ verwenden. Der Datentyp eines Skalarsignals oder jedes der Elemente eines Zeitreihensignals ist ein Byte-Array. Jeder Wert wird um den Paketnamen der Anwendung ergänzt, in der das Signal gespeichert wurde, und um den Zeitstempel der Erstellung des API-Aufrufs für das Speichersignal. Diese zusätzlichen Informationen sind im JavaScript für die Signalcodierung verfügbar. Dieses Beispiel zeigt die Struktur der Signale einer bestimmten Anzeigentechnologie:

Dieses Beispiel zeigt ein Skalarsignal und ein Zeitreihensignal, die mit adtech1.com verknüpft sind:

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

Anbieter von Anzeigentechnologien erhalten einen bestimmten Speicherplatz, um Signale auf dem Gerät zu speichern. Signale haben eine maximale TTL, die noch festgelegt werden muss.

Geschützte App-Signale werden aus dem Speicher entfernt, wenn die App, die sie generiert, deinstalliert wird, die Verwendung der Protected App Signals API 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, mit der die persistierten Signale verarbeitet werden, um sie für weitere Feature-Entwicklung in Echtzeit während einer geschützten Auktion vorzubereiten, die in einer Trusted Execution Environment (TEE) ausgeführt wird.

Signale hinzufügen, aktualisieren oder entfernen

Anbieter von Anzeigentechnologien können mit der fetchSignalUpdates() API Signale hinzufügen, aktualisieren oder entfernen. Diese API unterstützt die Delegierung ähnlich wie die Delegierung von benutzerdefinierten Zielgruppen bei Protected Audience.

Um ein Signal hinzuzufügen, müssen Käufer-Werbetechnologien, die in Apps kein SDK haben, mit Werbetechnologien zusammenarbeiten, die On-Device-Technologien verwenden, z. B. mobile Analysepartner (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-Signalen bietet. So können On-Device-Caller im Namen von Käufern Protected App-Signale erstellen. Dieser Vorgang wird als Delegierung bezeichnet und nutzt die fetchSignalUpdates() API. fetchSignalUpdates() nimmt einen URI an und ruft eine Liste der Signalaktualisierungen ab. Zur Veranschaulichung sendet fetchSignalUpdates() eine GET-Anfrage an den angegebenen URI, um die Liste der Updates abzurufen, die auf den lokalen Signalspeicher angewendet werden sollen. Der URL-Endpunkt des Käufers antwortet mit einer JSON-Liste von Befehlen.

Folgende JSON-Befehle werden unterstützt:

• 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 jeweiligen Nutzer festzulegen und zu verhindern, dass sie überschrieben wird, wenn sie bereits von einer anderen Anwendung festgelegt wurde.
• append: Fügen Sie der Zeitreihe, die mit dem angegebenen Schlüssel verknüpft ist, ein Element hinzu. Der Parameter „maxSignals“ gibt die maximale Anzahl von Signalen in der Zeitreihe an. Wenn die Größe überschritten wird, werden die vorherigen Elemente entfernt. Wenn der Schlüssel einen Skalarwert enthält, wird er automatisch in eine Zeitreihe umgewandelt.
• remove: Entfernt die mit dem angegebenen Schlüssel verknüpften Inhalte.

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

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

Die oben aufgeführten Befehle sollen die Semantik für Einfügen, Überschreiben und Löschen für Skalarsignale und Einfügen, Anhängen und vollständiges Überschreiben der Reihe für Zeitreihensignale bereitstellen. Die Lösch- und Überschreibsemantik für bestimmte Elemente eines Zeitreihensignals muss während des Codierungs- und Komprimierungsprozesses verwaltet werden. Beispielsweise können während der Codierung Werte in einer Zeitreihe ignoriert werden, die durch neuere ersetzt oder korrigiert werden, und während des Komprimierungsprozesses gelöscht werden.

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

Speicherkontingent und Auslagerung

Jede Anzeigentechnologie hat nur eine begrenzte Speicherkapazität auf dem Nutzergerät, um Signale zu speichern. Dieses Kontingent wird pro Anzeigentechnologie definiert. Signale aus verschiedenen Apps teilen sich also das Kontingent. Wenn das Kontingent überschritten wird, schafft das System Speicherplatz frei, indem es frühere Signalwerte nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ entfernt. Um zu verhindern, dass die Auslagerung zu häufig ausgeführt wird, implementiert das System eine Batch-Logik, die einen begrenzten Überziehungsbetrag des Kontingents zulässt und zusätzlichen Speicherplatz freigibt, sobald die Auslagerungslogik ausgelöst wird.

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

Um Signale für die Anzeigenauswahl vorzubereiten, hat die benutzerdefinierte Logik pro Käufer geschützten Zugriff auf die gespeicherten App-spezifischen Signale und Ereignisse. Alle 60 Minuten wird ein Android-System-Hintergrundjob ausgeführt, um benutzerdefinierte Codierungslogik pro Käufer auszuführen, die auf das Gerät heruntergeladen wird. Die benutzerdefinierte Codierungslogik pro Käufer codiert die pro App-Signale und komprimiert sie dann in eine Nutzlast, die dem Kontingent pro Käufer entspricht. Die Nutzlast wird dann innerhalb des geschützten Gerätespeichers verschlüsselt und an Gebote- und Auktionsdienste übertragen.

Anbieter von Anzeigentechnologien legen die Signalverarbeitungsebene mithilfe ihrer eigenen benutzerdefinierten Logik fest. Sie können Ihre Lösung beispielsweise so instrumentieren, dass frühere Signale verworfen und ähnliche oder sich verstärkende Signale aus verschiedenen Anwendungen in neue Signale zusammengefasst werden, die weniger Speicherplatz belegen.

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

Weitere Informationen zu Speicher-, Nutzlast- und Anfragekontingenten folgen in einem zukünftigen Update. Außerdem erhalten Sie weitere Informationen dazu, wie Sie benutzerdefinierte Funktionen bereitstellen.

Workflow für die Anzeigenauswahl

Bei diesem Vorschlag kann benutzerdefinierter Code für Anzeigentechnologien nur in einer geschützten Auktion (Ad Selection API), die in einem TEE ausgeführt wird, auf die geschützten App-Signale zugreifen. Um die Anforderungen für den Anwendungsfall „App-Installation“ weiter zu unterstützen, werden in der geschützten Auktion in Echtzeit Anzeigenvorschläge abgerufen. Das ist im Gegensatz zum Anwendungsfall für Remarketing, bei dem die Anzeigenvorschläge vor der Auktion bekannt sind.

Bei diesem Vorschlag wird ein ähnlicher Workflow für die Anzeigenauswahl wie beim Vorschlag für Protected Audience verwendet, der für den Anwendungsfall „App-Installation“ optimiert wurde. Um die Rechenanforderungen für die Feature-Entwicklung und die Echtzeitauswahl von Anzeigen zu erfüllen, müssen Auktionen für Anzeigen für App-Installationen auf Gebots- und Auktionsdiensten ausgeführt werden, die in TEEs ausgeführt werden. Der Zugriff auf geschützte App-Signale während einer geschützten Auktion wird bei On-Device-Auktionen nicht unterstützt.

So funktioniert die Anzeigenauswahl:

1. Das SDK des Verkäufers sendet die verschlüsselte Nutzlast der Signale für geschützte Apps auf dem Gerät.
2. Der Server des Verkäufers erstellt eine Auktionskonfiguration und sendet sie zusammen mit der verschlüsselten Nutzlast an den Trusted Bidding- und Auktionsdienst 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 Gebotsservice des Käufers führt die Logik für die Anzeigenauswahl auf Käuferseite aus.
   1. Ausführung der Logik für die Abrufung von Anzeigen auf Käuferseite
   2. Ausführung der Gebotslogik für Käufer
5. Die Bewertungslogik für die Sell-Side wird ausgeführt.
6. Die Anzeige wird gerendert und die Berichterstellung wird gestartet.

Workflow für die Anzeigenauswahl starten

Wenn eine Anwendung bereit ist, eine Anzeige zu präsentieren, initiiert das Ad Tech-SDK (in der Regel SSPs) den Workflow zur Anzeigenauswahl, indem alle relevanten Kontextdaten vom Publisher und die pro Käufer verschlüsselten Nutzlasten gesendet werden, die in die Anfrage aufgenommen werden sollen, die über den getAdSelectionData-Aufruf an die Protected Audience-Auktion gesendet wird. Es handelt sich dabei um dieselbe API, die auch für den Remarketing-Workflow verwendet wird und im Vorschlag Gebots- und Auktionsintegration für Android beschrieben wird.

Um die Anzeigenauswahl zu starten, gibt der Verkäufer eine Liste der teilnehmenden Käufer und die verschlüsselte Nutzlast der geschützten App-Signale auf dem Gerät weiter. Anhand dieser Informationen bereitet der Ad-Server auf der Verkaufsseite eine SelectAdRequest für seinen vertrauenswürdigen SellerFrontEnd-Dienst vor.

Der Verkäufer legt Folgendes fest:

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

• Die Kontextsignale verwenden:

  • auction_config.auction_signals (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 an den Auktionen mit dem Feld buyer_list teilnehmen.

Ausführung der Logik zur Anzeigenauswahl auf der Buy-Side

Die benutzerdefinierte Logik des Käufers verwendet im Wesentlichen kontextbezogene Daten des Publishers und geschützte App-Signale, 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.

Bevor Käufer Gebote abgeben, haben sie eine große Auswahl an Anzeigen. Es ist zu langsam, ein Gebot für jede Anzeige zu berechnen. Daher müssen Käufer zuerst die Top-K-Kandidaten aus dem großen Pool auswählen. Als Nächstes müssen Käufer Gebote für jeden dieser Top-Kандидатen berechnen. Anschließend werden diese Anzeigen und Gebote zur endgültigen Auswahl an den Verkäufer zurückgegeben.

1. Der BuyerFrontEnd-Dienst empfängt eine Anzeigenanfrage.
2. Der BuyerFrontEnd-Dienst sendet eine Anfrage an den Gebotsservice des Käufers. Der Gebotsservice des Käufers führt eine UDF namens prepareDataForAdRetrieval() aus, die eine Anfrage erstellt, um die Top-K-Kandidaten vom Anzeigenabrufdienst abzurufen. Der Gebotsservice sendet diese Anfrage an den konfigurierten Endpunkt des Abrufservers.
3. Der Anzeigenabrufdienst führt die getCandidateAds()-UDF aus, die die Top-k-Anzeigenkandidaten herausfiltert, die an den Gebotsservice des Käufers gesendet werden.
4. Der Gebotsservice des Käufers führt die generateBid()-UDF aus, die den besten Kandidaten auswählt, das Gebot berechnet und dann an den BuyerFrontEnd-Dienst zurückgibt.
5. Der BuyerFrontEnd-Dienst gibt die Anzeigen und Gebote an den Verkäufer zurück.

Bei diesem Ablauf gibt es mehrere wichtige Details, insbesondere in Bezug darauf, wie die einzelnen Teile miteinander kommunizieren und wie die Plattform Funktionen wie die Möglichkeit bietet, mithilfe von maschinellem Lernen die Top-K-Anzeigen abzurufen und ihre Gebote zu berechnen.

Bevor wir uns einige dieser Aspekte genauer ansehen, gibt es einige wichtige architektonische Hinweise zu den TEEs im Diagramm oben.

Der Gebotsservice des Käufers enthält intern einen Inferenzdienst. Anbieter von Anzeigentechnologien können Modelle für maschinelles Lernen in den Gebotsservice des Käufers hochladen. Wir stellen JavaScript APIs für AdTech-Anbieter bereit, mit denen sie Vorhersagen treffen oder Embeds aus diesen Modellen in den UDFs generieren können, die im Gebotsservice des Käufers ausgeführt werden. Im Gegensatz zum Anzeigenabrufdienst hat der Gebotsservice des Käufers keinen Schlüssel/Wert-Dienst zum Speichern von Anzeigenmetadaten.

Der Anzeigenabrufdienst enthält intern einen Schlüssel/Wert-Dienst. Anbieter von Anzeigentechnologien können Schlüssel/Wert-Paare von ihren eigenen Servern außerhalb der Datenschutzgrenze in diesen Dienst einschleusen. Wir stellen eine JavaScript API für Anbieter von Anzeigentechnologien bereit, mit der sie Daten aus diesem Schlüssel/Wert-Dienst über die UDFs lesen können, die im Anzeigenabrufdienst ausgeführt werden. Im Gegensatz zum Gebotsservice des Käufers enthält der Anzeigenabrufdienst keinen Inferenzdienst.

Eine zentrale Frage, die mit diesem Design angegangen wird, ist, wie sich die Abruf- und Gebotszeiten vorhersagen lassen. Die Lösung für beide Probleme kann eine sogenannte Modellfaktorisierung sein.

Modellfaktorisierung

Die Modellfaktorisierung ist ein Verfahren, mit dem ein einzelnes Modell in mehrere Teile zerlegt und diese Teile dann zu einer Vorhersage kombiniert werden können. Beim Anwendungsfall „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 Datentypen trainiert. Im faktorisierten Fall wird das Modell in mehrere Teile zerlegt. Nur der Teil, der Nutzerdaten enthält, ist vertraulich. Das bedeutet, dass nur das Modell mit dem Nutzerteil innerhalb der Vertrauensgrenze ausgeführt werden muss, im Inferenzdienst des Gebotsdienstes des Käufers.

Das ermöglicht das folgende Design:

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 soll. Beispielsweise werden kontextbezogene Einbettungen in der per_buyer_signals an UDFs übergeben.
3. Optional können Anbieter von Anzeigentechnologien Modelle für nicht private Elemente erstellen und dann Einbettungen aus diesen Modellen im Schlüssel/Wert-Speicher des Anzeigenabrufdiensts materialisieren. UDFs im Anzeigenabrufdienst können diese Einbettungen zur Laufzeit abrufen.
4. Wenn Sie während einer UDF eine Vorhersage treffen möchten, kombinieren Sie private Einbettungen aus dem Inferenzdienst mit nicht privaten Einbettungen aus UDF-Funktionsargumenten oder dem Schlüssel/Wert-Speicher mit einer Operation wie dem Skalarprodukt. Dies ist die endgültige Vorhersage.

Nachdem wir das geklärt haben, können wir uns die einzelnen UDFs genauer ansehen. Wir erklären, wie sie funktionieren, wie sie eingebunden werden und wie sie die Vorhersagen treffen können, die erforderlich sind, um die Top k-Anzeigen auszuwählen und ihre Gebote zu berechnen.

Die prepareDataForAdRetrieval()-UDF

prepareDataForAdRetrieval(), die im Gebotsservice des Käufers ausgeführt wird, ist für die Erstellung der Anfragenlast verantwortlich, die an den Anzeigenabrufdienst gesendet wird, um die Top-K-Anzeigenkandidaten abzurufen.

prepareDataForAdRetrieval() verwendet die folgenden Informationen:

• Die vom getAdSelectionData empfangene Nutzlast pro Käufer. Diese Payload enthält die Protected App Signals.
• Die Felder auction_signals (für Informationen zur Auktion) und buyer_signals (für Felder mit Signalen von Käufern) der Kontextsignale.

prepareDataForAdRetrieval() hat zwei Funktionen:

• Feature-Erstellung: Wenn eine Inferenz zum Zeitpunkt des Abrufs erforderlich ist, werden eingehende Signale in Features umgewandelt, die bei Aufrufen des Inferenzdienstes verwendet werden, um private Einbettungen für den Abruf abzurufen.
• Berechnet private Einbettungen für die Abfrage: Wenn Abrufvorhersagen erforderlich sind, wird der Abrufdienst mit den oben genannten Funktionen aufgerufen und eine private Einbettung für Vorhersagen zur Abrufzeit abgerufen.

prepareDataForAdRetrieval() gibt Folgendes zurück:

• Protected App Signals: Nutzlast mit von AdTech-Anbietern kuratierten Signalen.
• Auktionsspezifische Signale: Plattformspezifische Signale auf Verkäuferseite und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) aus SelectAdRequest. Das ist ähnlich wie bei Protected Audiences.
• Zusätzliche Signale: Zusätzliche Informationen wie private Einbettungen, die vom Inferenzdienst abgerufen werden.

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

Die getCandidateAds()-UDF

getCandidateAds() wird vom Anzeigenabrufdienst ausgeführt. Er empfängt die von prepareDataForAdRetrieval() im Gebotsservice des Käufers erstellte Anfrage. Der Dienst führt getCandidateAds() aus, um die Top-K-Kandidaten für Gebote abzurufen. Dazu wird die Anfrage in eine Reihe von Abfragen und Datenabrufen umgewandelt und benutzerdefinierte Geschäftslogik und andere benutzerdefinierte Abruflogik ausgeführt.

getCandidateAds() verwendet die folgenden Informationen:

• Protected App Signals: Nutzlast mit von AdTech-Anbietern kuratierten Signalen.
• Auktionsspezifische Signale: Plattformspezifische Signale auf Verkäuferseite und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) aus SelectAdRequest. Das ist ähnlich wie bei Protected Audiences.
• Zusätzliche Signale: Zusätzliche Informationen wie private Einbettungen, die vom Inferenzdienst abgerufen werden.

getCandidateAds() führt Folgendes aus:

1. Erste Anzeigenvorschläge abrufen: Anzeigenvorschläge werden anhand von Ausrichtungskriterien wie Sprache, Standort, Anzeigentyp, Anzeigengröße oder Budget abgerufen, um sie zu filtern.
2. Abrufen von Einbettungen: Wenn Einbettungen aus dem Schlüssel/Wert-Dienst erforderlich sind, um eine Vorhersage der Abrufzeit für die Top-K-Auswahl zu treffen, müssen sie aus dem Schlüssel/Wert-Dienst abgerufen werden.
3. Top-K-Kandidatenauswahl: Berechnen Sie eine einfache Bewertung für die gefilterten Anzeigenkandidaten anhand der Anzeigenmetadaten, die aus dem Schlüssel/Wert-Speicher abgerufen wurden, und der Informationen, die vom Gebotsservice des Käufers gesendet wurden. Wählen Sie dann anhand dieser Bewertung die Top-K-Kandidaten aus. Die Bewertung kann beispielsweise die Wahrscheinlichkeit sein, dass eine App aufgrund der Anzeige installiert wird.
4. Abruf von Geboteinbettungen: Wenn Gebotecode für die Erstellung von Geboten in Echtzeit Einbettungen aus dem Schlüssel/Wert-Dienst benötigt, werden diese möglicherweise aus dem Schlüssel/Wert-Dienst abgerufen.

Die Bewertung einer Anzeige kann die Ausgabe eines Prognosemodells 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 Anzeigenabrufdienst ausgeführt wird und dieser Dienst keinen Inferenzdienst hat, können Vorhersagen durch Kombination der folgenden Faktoren generiert werden:

• Kontextbezogene Einbettungen, die über die Eingabe Auktionsspezifische Signale übergeben werden.
• Private Einbettungen, die über den Eingabeparameter zusätzliche Signale übergeben werden.
• Alle nicht privaten Anzeigentechnologien für eingebettete Anzeigen wurden von ihren Servern in den Schlüssel/Wert-Dienst des Anzeigenabrufdiensts übertragen.

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

getCandidateAds() gibt Folgendes zurück:

• Anzeigen in der Kandidatenliste: Die k besten Anzeigen, die an generateBid() übergeben werden. Jede Anzeige besteht aus:
  • Render-URL: Endpunkt für das Rendern des Creatives.
  • Metadaten: Anzeigenmetadaten auf der Buy-Side, die sich auf die Anzeigentechnologie beziehen. Das können beispielsweise Informationen zur Werbekampagne und Targeting-Kriterien wie Standort und Sprache sein. Die Metadaten können optionale Embeds enthalten, die verwendet werden, wenn eine Modellfaktorisierung erforderlich ist, um die Inferenz während der Gebotseinstellung auszuführen.
• Zusätzliche Signale: Optional kann der Anzeigenabrufdienst zusätzliche Informationen wie zusätzliche Einbettungen oder Spamsignale enthalten, die in generateBid() verwendet werden.

Wir prüfen derzeit andere Methoden, wie Anzeigen für die Bewertung bereitgestellt werden können, z. B. als Teil des SelectAdRequest-Aufrufs. Diese Anzeigen können mit einer RTB-Gebotsanfrage abgerufen werden. In solchen Fällen müssen Anzeigen ohne geschützte App-Signale abgerufen werden. Wir gehen davon aus, dass Anbieter von Anzeigentechnologien die Vor- und Nachteile verschiedener Optionen abwägen, bevor sie sich für die beste entscheiden. Dabei spielen unter anderem die Größe der Antwortnutzlast, die Latenz, die Kosten und die Verfügbarkeit von Signalen eine Rolle.

Die generateBid()-UDF

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

generateBid() verwendet die folgenden Informationen:

• Anzeigenvorschläge: Die k wichtigsten Anzeigen, die vom Anzeigenabrufdienst zurückgegeben werden.
• Auktionsspezifische Signale: Plattformspezifische Signale auf Verkäuferseite und Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) aus SelectAdRequest.
• Zusätzliche Signale: Zusätzliche Informationen, die bei der Gebotsabgabe verwendet werden.

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

• Feature-Engineering: Signale werden in Features umgewandelt, die bei der Inferenz verwendet werden.
• Inferenz: Es werden Vorhersagen mithilfe von Machine-Learning-Modellen erstellt, um Werte wie die prognostizierte Klick- und Conversion-Rate zu berechnen.
• Gebote: Kombinieren abgeleiteter Werte mit anderen Eingaben, um das Gebot für eine ausgewählte Anzeige zu berechnen.

generateBid() gibt Folgendes zurück:

• Die Anzeige des Kandidaten.
• Der berechnete Gebotsbetrag.

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

In den folgenden Abschnitten werden die Funktionsweise von Features, Inferenzen und Geboten genauer beschrieben.

Featurization

Auktionssignale können von generateBid() in Funktionen umgewandelt werden. Diese Merkmale können während der Inferenz verwendet werden, um z. B. Klick- und Conversion-Raten vorherzusagen. Wir arbeiten auch an datenschutzfreundlichen Mechanismen, um einige davon im Bericht zum Gewinn zur Verwendung beim Modelltraining zu übertragen.

Inferenz

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

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

Die Inferenz wird im Gebotsservice des Käufers ausgeführt. Dies kann sich auf die Inferenzlatenz und die Kosten auswirken, insbesondere da Acceleratoren noch nicht in TEEs verfügbar sind. Für einige Kunden reichen individuelle Modelle, die im Gebotsservice 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 Inferenzkosten und die Latenz bei der Gebotsabgabe zu minimieren.

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

Modellfaktorisierung implementieren

Zuvor haben wir die Modellfaktorisierung erläutert. Bei der Gebotseinstellung wird Folgendes berücksichtigt:

1. Teilen Sie das einzelne Modell in einen privaten Teil (die Nutzerdaten) und einen oder mehrere nicht private Teile (die Kontext- und Anzeigendaten) auf.
2. Übergeben Sie nicht private Teile an generateBid(). Diese können entweder aus per_buyer_signals oder aus Einbettungen stammen, die von Werbetechnologien extern berechnet, im Schlüssel/Wert-Speicher des Abrufdiensts gespeichert, zum Zeitpunkt des Abrufs abgerufen und als Teil der zusätzlichen Signale zurückgegeben werden. Private Einbettungen sind davon ausgenommen, da sie nicht von außerhalb der Datenschutzgrenze stammen können.
3. In generateBid():
   1. Führen Sie eine Inferenz mit Modellen durch, um private Nutzer-Embeddings zu erhalten.
   2. Kombinieren Sie Embeddings privater Nutzer mit kontextbezogenen Embeddings aus per_buyer_signals oder nicht privaten Anzeigen und kontextbezogenen Embeddings aus dem Abrufdienst mithilfe einer Operation wie dem Skalarprodukt. Dies ist die endgültige Vorhersage, die zur Berechnung von Geboten verwendet werden kann.

Mit diesem Ansatz ist es möglich, bei der Gebotsabgabe Inferenzen für Modelle auszuführen, die sonst zu groß oder zu langsam für die Ausführung im Gebotsservice des Käufers wären.

Bewertungslogik für die Sell-Side

In dieser Phase werden die Anzeigen mit Geboten, die von allen teilnehmenden Käufern erhalten wurden, bewertet. Die Ausgabe von generateBid() wird an den Auktionsdienst des Verkäufers übergeben, um scoreAd() auszuführen. Dabei wird bei scoreAd() jeweils nur eine Anzeige berücksichtigt. Basierend auf der Bewertung wählt der Verkäufer eine erfolgreiche Anzeige aus, die zum Rendern an das Gerät zurückgegeben wird.

Die Bewertungslogik ist dieselbe wie für den Protected Audience-Remarketing-Vorgang und kann einen Gewinner aus den Remarketing- und App-Installationskandidaten auswählen.Die Funktion wird einmal für jede eingereichte Anzeigenkampagne in der Protected Audience-Auktion aufgerufen. Weitere Informationen finden Sie im Hilfeartikel Gebote und Auktionen.

Laufzeit des Anzeigenauswahlcodes

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

Berichte

Für diesen Vorschlag werden dieselben Berichts-APIs verwendet wie für den Vorschlag für Protected Audience-Berichte (z. B. reportImpression(), über die die Plattform zum Senden von Verkäufer- und Käuferberichten veranlasst wird).

Ein häufiger Anwendungsfall für Berichte auf der Buy-Side 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 für den Export von Daten auf Ereignisebene von der Plattform zu AdTech-Servern. Diese ausgehenden Nutzlasten können bestimmte Nutzerdaten enthalten.

Langfristig arbeiten wir an datenschutzfreundlichen Lösungen, um das Modelltraining mit Daten aus geschützten Auktionen zu ermöglichen, ohne Nutzerdaten auf Ereignisebene an Dienste außerhalb von TEEs zu senden. Weitere Informationen erhalten Sie in einem späteren Update.

Auf kurze Sicht bieten wir eine vorübergehende Möglichkeit, gestörte Daten aus generateBid() zu exportieren. Unser erster Vorschlag dazu ist unten aufgeführt. Wir werden ihn auf Grundlage des Feedbacks der Branche weiterentwickeln, auch wenn dies möglicherweise zu nicht abwärtskompatiblen Änderungen führt.

So funktioniert das technisch:

1. Anbieter von Anzeigentechnologien definieren ein Schema für die Daten, die sie übertragen möchten.
2. In generateBid() erstellt er die gewünschte ausgehende Nutzlast.
3. Die Plattform validiert die ausgehende Nutzlast anhand des Schemas und erzwingt Größenlimits.
4. Die Plattform fügt der ausgehenden Nutzlast Rauschen hinzu.
5. Die ausgehende Nutzlast ist im Win-Bericht im Binärformat enthalten, wird auf AdTech-Servern empfangen, decodiert und für das Modelltraining verwendet.

Schema für ausgehende Nutzlasten definieren

Damit die Plattform die sich ändernden Datenschutzanforderungen durchsetzen kann, müssen ausgehende Nutzlasten so strukturiert sein, dass sie von der Plattform verstanden werden können. Anbieter von Anzeigentechnologien definieren die Struktur ihrer ausgehenden Nutzlasten, indem sie eine JSON-Schemadatei bereitstellen. Dieses Schema wird von der Plattform verarbeitet und von den Gebots- und Auktionsdiensten vertraulich behandelt. Dabei werden die gleichen Mechanismen wie bei anderen AdTech-Ressourcen wie UDFs und Modellen verwendet.

Wir stellen eine CDDL bereit, die die Struktur dieser JSON-Datei definiert. Die CDDL-Datei enthält eine Reihe von unterstützten Featuretypen, z. B. boolesche Ausdrücke, Ganzzahlen, Bucket-Typen usw. Sowohl die CDDL-Datei als auch das bereitgestellte Schema werden versioniert.

Eine ausgehende Nutzlast, die aus einem einzelnen booleschen Merkmal gefolgt von einem Bucket-Merkmal mit einer Größe von zwei besteht, würde beispielsweise so aussehen:

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-Nutzlast in generateBid() erstellen

Alle geschützten App-Signale für einen bestimmten Käufer sind für seine generateBid()-UDF verfügbar. Sobald diese Funktionen hinzugefügt wurden, erstellen Anbieter von Anzeigentechnologien ihre Nutzlast im JSON-Format. Diese Nutzlast wird in den Bericht zum Gewinn des Käufers aufgenommen und an AdTech-Server übertragen.

Eine Alternative zu diesem Design besteht darin, die Berechnung des Ausgangsvektors in reportWin() statt in generateBid() durchzuführen. Beide Ansätze haben Vor- und Nachteile. Wir werden diese Entscheidung in Reaktion auf das Feedback der Branche treffen.

Egress-Nutzlast validieren

Die Plattform validiert jede von der Anzeigentechnologie erstellte ausgehende Nutzlast. Dabei wird sichergestellt, dass die Funktionswerte für ihre Typen gültig sind, die Größenbeschränkungen eingehalten werden und dass böswillige Akteure nicht versuchen, die Datenschutzeinstellungen zu umgehen, indem sie zusätzliche Informationen in ihre ausgehenden Nutzlasten einbetten.

Wenn eine ausgehende Nutzlast ungültig ist, wird sie stillschweigend aus den Eingaben entfernt, die an den Win-Bericht gesendet werden. Das liegt daran, dass wir keine Informationen zur Fehlerbehebung an böswillige Akteure weitergeben möchten, die versuchen, die Validierung zu umgehen.

Wir stellen eine JavaScript API für Anbieter von Anzeigentechnologien bereit, damit die in generateBid() erstellte Ausgangnutzlast die Plattformüberprüfung besteht:

validate(payload, schema)

Mit dieser JavaScript API können Aufrufer feststellen, ob eine bestimmte Nutzlast die Plattformvalidierung besteht. Die eigentliche Validierung muss auf der Plattform erfolgen, um vor schädlichen generateBid()-UDFs zu schützen.

Ausgehende Nutzlast mit Rauschen versehen

Die Plattform entfernt Nutzlasten für ausgehende Zugriffe, bevor sie in den Gewinnbericht aufgenommen werden. Der anfängliche Geräuschgrenzwert beträgt 1 %. Dieser Wert kann sich im Laufe der Zeit ändern. Die Plattform gibt keinen Hinweis darauf, ob eine bestimmte ausgehende Nutzlast gestört wurde.

Die Rauschmethode ist:

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

Übertragung, Empfang und Dekodierung der ausgehenden Nutzlast für das Modelltraining

Die validierte, mit Rauschen versehene ausgehende Nutzlast wird in die Argumente für reportWin() aufgenommen und für das Modelltraining an die AdTech-Server der Käufer außerhalb der Datenschutzgrenze gesendet. Die ausgehende Nutzlast wird im Wire-Format übertragen.

Details zum Bitübertragungsformat für alle Featuretypen und für die ausgehende Nutzlast selbst finden Sie auf GitHub.

Größe der ausgehenden Nutzlast ermitteln

Die Größe der ausgehenden Nutzlast in Bits ist ein Kompromiss zwischen Nützlichkeit und Datenminimierung. Wir arbeiten mit der Branche zusammen, um die richtige Größe durch Tests zu ermitteln. Während dieser Tests werden Daten vorübergehend ohne Bitgrößenbeschränkung exportiert. Diese zusätzlichen ausgehenden Daten ohne Bitgrößenbeschränkung werden nach Abschluss der Tests entfernt.

So ermitteln Sie die Größe:

1. Anfangs werden in generateBid() zwei Ausgang-Nutzlasten unterstützt:
   1. egressPayload: die größenbegrenzte Ausgangnutzlast, die wir bisher in diesem Dokument beschrieben haben. Die Größe dieser ausgehenden Nutzlast beträgt anfangs 0 Bit, d. h. sie wird bei der Validierung immer entfernt.
   2. temporaryUnlimitedEgressPayload: eine temporäre, unbegrenzte Ausgangnutzlast für Größentests. Für die Formatierung, Erstellung und Verarbeitung dieser ausgehenden Nutzlast werden dieselben Mechanismen wie bei egressPayload verwendet.
2. Jede dieser ausgehenden Nutzlasten hat eine eigene JSON-Schemadatei: egress_payload_schema.json und temporary_egress_payload_schema.json.
3. Wir stellen ein Testprotokoll und eine Reihe von Messwerten zur Verfügung, um die Nützlichkeit des Modells bei verschiedenen Ausgangnutzlastgrößen (z. B. 5, 10, … Bit) zu bestimmen.
4. Anhand der Testergebnisse ermitteln wir die Größe der ausgehenden Nutzlast mit dem richtigen Kompromiss 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 wird temporaryUnlimitedEgressPayload entfernt und es bleibt nur egressPayload mit der neuen Größe übrig.

Wir prüfen derzeit zusätzliche technische Schutzmaßnahmen für diese Änderung, z. B. die Verschlüsselung von egressPayload, wenn wir seine Größe von 0 Bit erhöhen. Diese Details sowie die Zeitplanung für den Test und die Entfernung von temporaryUnlimitedEgressPayload werden in einem späteren Update veröffentlicht.

Als Nächstes erklären wir ein mögliches Testprotokoll zur Festlegung der Größe von egressPayload. Unser Ziel ist es, gemeinsam mit der Branche eine Größe zu finden, die Nützlichkeit und Datenminimierung in Einklang bringt. Die Tests liefern 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 unbegrenzten Größe generiert wird.

Angenommen, wir trainieren ein pInstall-Modell und unsere Trainingsdatenquellen sind unsere Protokolle und der Inhalt der temporaryUnlimitedegressPayloads, die wir erhalten, wenn wir Auktionen gewinnen. Das Protokoll für Anzeigentechnologien umfasst zuerst Offlinetests:

1. Architektur der Modelle bestimmen, die mit geschützten App-Signalen verwendet werden So muss er beispielsweise entscheiden, ob er die Modellfaktorisierung verwenden möchte.
2. Definieren Sie einen Messwert für die Modellqualität. Als Messwerte werden AUC-Verlust und Log-Verlust vorgeschlagen.
3. Definieren Sie die Features, die während des Modelltrainings verwendet werden sollen.
4. Anhand dieser Modellarchitektur, des Qualitätsmesswerts und der Trainingsfunktionen werden Ablationsstudien durchgeführt, um den Nutzen pro Bit für jedes Modell zu ermitteln, das in PAS verwendet werden soll. Das empfohlene Protokoll für die Ablatiostudie lautet:
   1. Trainieren Sie das Modell mit allen Funktionen und messen Sie den Nutzen. Dies ist der Vergleichswert.
   2. Trainieren Sie für jedes Merkmal, das zur Erstellung des Baseline-Modells verwendet wurde, das Modell mit allen außer diesem Merkmal.
   3. Messen Sie den daraus resultierenden Nutzen. Dividieren Sie das Delta durch die Größe des Features in Bits. Das ist der erwartete Nutzen pro Bit für dieses Feature.
5. Legen Sie die Nutzlastgrößen für das Training fest, die für den Test relevant sind. Wir empfehlen [5, 10, 15, …, size_of_all_training_features_for_baseline] Bits. Jede davon stellt eine mögliche Größe für egressPayload dar, die im Test ausgewertet wird.
6. Wählen Sie für jede mögliche Größe eine Reihe von Funktionen aus, die kleiner oder gleich dieser Größe sind und mit denen der Nutzen pro Bit maximiert wird. Verwenden Sie dabei die Ergebnisse des Ablationstests.
7. Trainieren Sie ein Modell für jede mögliche Größe und bewerten Sie seine Nützlichkeit als Prozentsatz der Nützlichkeit 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 Prozentsatz des mit diesem Modell erzielten Umsatzes im Vergleich zur Baseline auf der y-Achse ist.

Als Nächstes können Anbieter von Anzeigentechnologien die Schritte 5 bis 8 in Tests mit Live-Traffic wiederholen und dabei über temporaryUnlimitedEgressPayload gesendete Feature-Daten verwenden. Anbieter von Anzeigentechnologien können die Ergebnisse ihrer Offline- und Live-Traffic-Tests mit der Privacy Sandbox teilen, um die Entscheidung über die Größe von egressPayload zu beeinflussen.

Der Zeitplan für diese Tests sowie der Zeitplan für die Festlegung der Größe von egressPayload auf den resultierenden Wert fallen nicht in den Geltungsbereich dieses Dokuments und werden in einem späteren Update veröffentlicht.

Datenschutzmaßnahmen

Wir wenden eine Reihe von Schutzmaßnahmen auf Daten an, die an externe Systeme gesendet werden, darunter:

1. Sowohl egressPayload als auch temporaryUnlimitedEgressPayload werden mit Rauschen versehen.
2. Aus Gründen der Datenminimierung und des Datenschutzes ist temporaryUnlimitedEgressPayload nur während der Laufzeit von Tests zur Größe verfügbar. Dabei ermitteln wir die richtige Größe für egressPayload.

Berechtigungen

Nutzersteuerung

• Mit dem Vorschlag soll Nutzern die Liste der installierten Apps angezeigt werden, in denen mindestens ein geschütztes App-Signal oder eine benutzerdefinierte Zielgruppe gespeichert wurde.
• Nutzer können Apps aus dieser Liste blockieren und entfernen. Durch Blockieren und Entfernen geschieht Folgendes:
  • Alle Protected App Signals und benutzerdefinierten Zielgruppen, die mit der App verknüpft sind, werden gelöscht.
  • Verhindert, dass die Apps neue Protected App Signals und benutzerdefinierte Zielgruppen speichern
• Nutzer können die Protected App Signals API und die Protected Audience API vollständig zurücksetzen. In diesem Fall werden alle vorhandenen Signale für geschützte Apps und benutzerdefinierten Zielgruppen auf dem Gerät gelöscht.
• Nutzer können die Privacy Sandbox auf Android-Geräten vollständig deaktivieren. Dazu gehören 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 -Steuerung

Mit dem Vorschlag soll es Apps ermöglicht werden, ihre Protected App Signals zu steuern:

• Eine App kann ihre Verknüpfungen mit geschützten App-Signalen verwalten.
• Eine App kann Drittanbieter-Werbetechnologieplattformen Berechtigungen erteilen, geschützte App-Signale in ihrem Namen zu verwalten.

Steuerelement für AdTech-Plattform

In diesem Vorschlag werden Möglichkeiten beschrieben, wie Anbieter von Anzeigentechnologien ihre Protected App Signals steuern können:

• Alle Anbieter von Anzeigentechnologien müssen sich bei der Privacy Sandbox registrieren und eine „Website“- oder „Herkunft“-Domain angeben, die mit allen URLs für geschützte App-Signale übereinstimmt.
• Anbieter von Anzeigentechnologien können mit Apps oder SDKs zusammenarbeiten, um Bestätigungstokens bereitzustellen, mit denen die Erstellung von geschützten App-Signalen überprüft wird. Wenn dieser Vorgang an einen Partner delegiert wird, kann die Erstellung von Protected App-Signalen so konfiguriert werden, dass eine Bestätigung durch die Anzeigentechnologie erforderlich ist.