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

Dieses Angebot unterliegt dem Registrierungsprozess für die Privacy Sandbox und Attestierungen. Weitere Informationen zu den Bescheinigungen finden Sie unter mit dem bereitgestellten Attestierungslink. Künftige Aktualisierungen dieses Angebots werden die Anforderungen für den Zugriff auf dieses System beschrieben.

App-Installationsanzeigen, auch Anzeigen zur Nutzergewinnung genannt, sind eine Art von mobile Werbung, die Nutzer zum Herunterladen einer mobilen App ermutigt. Diese Anzeigen werden in der Regel auf Grundlage ihrer Interessen und demografischen Merkmale für Nutzer ausgeliefert. Sie erscheinen häufig in anderen mobilen Apps wie Spielen, sozialen Medien und Nachrichten. Apps. Wenn ein Nutzer auf eine App-Installationsanzeige klickt, wird er direkt zur App Store herunterladen.

Beispiel: Ein Werbetreibender, der die Anzahl der Installationen für ein neues Mobilgerät steigern möchte, ihre Anzeigen auf Nutzer ausrichten, deren Standort sich in den USA befindet und die bereits andere Lebensmittellieferungen Apps.

Dies geschieht in der Regel durch Einbeziehen von kontext-, Erst- und Drittanbieter- zwischen AdTechs verwenden, um Nutzerprofile auf Grundlage von Werbe-IDs zu erstellen. AdTech-Modelle für maschinelles Lernen verwenden diese Informationen als Grundlage für die Auswahl von Anzeigen die für den Nutzer relevant sind und bei denen die Wahrscheinlichkeit am höchsten ist, dass Conversion.

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

1. Protected App Signals API: Diese API konzentriert sich Erstellung von AdTech-Funktionen, die das Potenzial eines Nutzers darstellen Interessen. Anzeigentechnologie-Anbieter speichern selbst definierte App-Ereignissignale, z. B. App-Kampagnen Installationen, erstes Öffnen, Nutzeraktionen (In-Game-Leveling, Erfolge) Kaufaktivitäten oder eine Zeit in der App. Signale werden in einem zum Schutz vor Datenlecks. Sie werden nur dem AdTech-Logik, mit der das jeweilige Signal während einer geschützten Auktion gespeichert wurde in einer sicheren Umgebung ausgeführt werden.
2. Ad Selection API: Diese API stellt eine API zum Konfigurieren und Ausführen einer Geschützte Auktion in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) Hier können AdTech-Teams Anzeigenkandidaten abrufen, Inferenzen ausführen, Gebote berechnen Punkte, um einen "Sieger" zu wählen Anzeigen mit den geschützten App-Signalen vom Publisher bereitgestellte Echtzeit-Kontextinformationen

</ph>

Hier finden Sie eine allgemeine Übersicht dazu, wie Protected App-Signale unterstützt werden. relevante App-Installations-Anzeigen. In den folgenden Abschnitten dieses Dokuments finden Sie weitere Informationen Details zu jedem dieser Schritte.

• Signalauswahl: Wenn Nutzer mobile Apps verwenden, werden von Anzeigentechnologien Signale ausgewählt. App-Ereignisse, die von AdTech definiert wurden, für die Auslieferung relevanter Anzeigen gespeichert werden, Protected App Signals API Diese Ereignisse werden in geschützten Geräten auf dem Gerät gespeichert ähnlich wie bei benutzerdefinierten Zielgruppen, und werden vor der sodass nur Gebots- und Auktionsdienste in vertrauenswürdigen Ausführungsumgebungen mit der entsprechenden Sicherheit und Datenschutzeinstellungen können sie für Gebote und Bewertungen von Anzeigen entschlüsseln.
• Signalcodierung: Die Signale werden nach einem festgelegten Rhythmus vorbereitet, AdTech-Logik. Ein Android-Hintergrundjob führt diese Logik aus, On-Device-Codierung durchführen, um eine Nutzlast von Protected App-Signalen zu generieren die später in Echtzeit während einer geschützten Umgebung für die Anzeigenauswahl verwendet werden können Auktion. Die Nutzlast wird sicher auf dem Gerät gespeichert, bis sie für eine Auktion.
• Anzeigenauswahl: Verkäufer-SDKs, um relevante Anzeigen für den Nutzer auszuwählen sendet eine verschlüsselte Nutzlast mit geschützten App-Signalen und konfiguriert eine Geschützte Auktion. In der Auktion bereitet die benutzerdefinierte Logik des Käufers App-Signale zusammen mit den vom Publisher bereitgestellten Kontextdaten (Daten normalerweise in einer Open-RTB-Anzeigenanfrage) an das Entwicklerteam Funktionen zur Anzeigenauswahl (Anzeigenabruf, Ableitung und Gebot) Generation). Ähnlich wie bei Protected Audience reichen Käufer Anzeigen an die Verkäufer für die endgültige Bewertung in einer geschützten Auktion.
  • Anzeigenabruf: Käufer verwenden geschützte App-Signale und vom Publisher bereitgestellte Kontextdaten für die Entwicklung von Features die für die Interessen des Nutzers relevant sind. Diese Funktionen werden verwendet, um Anzeigen die die Targeting-Kriterien erfüllen. Anzeigen außerhalb des Budgets werden herausgefiltert. Die leistungsstärksten Anzeigen werden dann für Gebote ausgewählt.
  • Gebote: die benutzerdefinierte Gebotseinstellung vom Publisher bereitgestellte Kontextdaten und geschützte App-Signale die als Eingabe für Machine-Learning-Modelle für Käufer herangezogen werden, Ableitung und Gebote für mögliche Anzeigen innerhalb vertrauenswürdiger, datenschutzfreundlicher grenzen. Der Käufer sendet seine gewählte Anzeige an den Verkäufer zurück.
  • Verkäuferbewertung: des Verkäufers Anzeigen mit benutzerdefinierter Bewertung mit Logik für Bewertungen von teilnehmenden Käufern eingereicht und eine erfolgreiche Anzeige bestimmt. zum Rendern zurück zur App.
• Berichte: Auktionsteilnehmer erhalten entsprechende Berichte zu den gewonnenen Erkenntnissen und Verlustberichte. Wir erforschen datenschutzfreundliche Mechanismen zur Daten für das Modelltraining im Gewinnbericht.

Zeitachse

Geschützte App-Signale auswählen

Ein Signal ist eine Darstellung verschiedener Nutzerinteraktionen in einer App, die von AdTech als nützlich für die Auslieferung relevanter Anzeigen eingestuft. Eine App oder der integriertes SDK kann von AdTechs definierte geschützte App-Signale speichern oder löschen die auf Nutzeraktivitäten wie App-Starts, Erfolgen, Kaufaktivitäten oder Zeit in der App. Geschützte App-Signale werden sicher auf dem Gerät gespeichert und werden vor dem Versand vom Gerät verschlüsselt, sodass nur Gebote und Auktionen Dienste, die in vertrauenswürdigen Ausführungsumgebungen mit angemessener Sicherheit ausgeführt werden und Datenschutzeinstellungen entschlüsseln können, um Gebote abzugeben und Anzeigen zu bewerten. Ähnlich wie die können die auf einem Gerät gespeicherten Signale weder gelesen noch untersucht werden. durch Apps oder SDKs; Es gibt keine API zum Lesen von Signalwerten. um den Verlust von Signalen zu vermeiden. Die benutzerdefinierte Logik von Anzeigentechnologie Zugriff auf ihre ausgewählten Signale zu Entwickler-Features, für die Anzeigenauswahl in einer geschützten Auktion.

Protected App Signals API

Die Protected App Signals API unterstützt die Verwaltung von Signalen mithilfe eines Delegationsmechanismus, der dem für benutzerdefinierte Zielgruppen verwendete ähnelt. Die Die Protected App Signals API ermöglicht das Speichern von Signalen in Form eines einzelnen Skalars oder als Zeitreihe. Mit Zeitreihensignalen können u. a. folgende Daten gespeichert werden: Dauer der Nutzersitzung. Mit Zeitreihensignalen lässt sich eine bestimmte indem Sie eine Regel zum Entfernen nach dem ersten Der Datentyp eines Skalars oder jedes der Elemente eines Zeitreihensignals ein Byte-Array. Jedes wird mit dem Paketnamen der Anwendung angereichert, in der die und den Erstellungszeitstempel des API-Aufrufs für das Store-Signal. Dieses Extra Informationen hierzu finden Sie im JavaScript-Code für die Signalcodierung. Dieses Beispiel Hier sehen Sie die Struktur der Signale einer bestimmten Anzeigentechnologie:

Dieses Beispiel zeigt ein skalares Signal und ein Zeitreihensignal, mit adtech1.com:

• Ein skalares Signal mit dem base64-Wertschlüssel „A1c“ und den Wert "c12Z". Das Signal Shop wurde am 1. Juni von com.google.android.game_app ausgelöst 2023
• Eine Liste der Signale mit dem Schlüssel „dDE“ die von zwei verschiedenen Anwendungen.

Anzeigentechnologie-Anbietern wird ein bestimmter Speicherplatz zugewiesen, um Signale auf dem Gerät zu speichern. Für Signale gilt eine maximale TTL, die noch festgelegt wird.

Geschützte App-Signale werden aus dem Speicher entfernt, wenn die generierende App deinstalliert ist, für die Nutzung der Protected App Signals API blockiert ist oder vom Nutzer gelöscht wurde.

Die Protected App Signals API besteht aus den folgenden Teilen:

• eine Java- und JavaScript-API, um Signale hinzuzufügen, zu aktualisieren oder zu entfernen.
• eine JavaScript API, um die beibehaltenen Signale zu verarbeiten und sie auf Feature Engineering in Echtzeit während einer geschützten Auktion weiter ausbauen. in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE).

Signale hinzufügen, aktualisieren oder entfernen

AdTechs können mit der fetchSignalUpdates() API Signale hinzufügen, aktualisieren oder entfernen. Diese API unterstützt das Delegieren ähnlich wie die benutzerdefinierte Protected Audience-Zielgruppe Delegierung.

Um ein Signal hinzuzufügen, müssen Anzeigentechnologien von Käufern, die kein SDK in Apps haben, Zusammenarbeit mit Anzeigentechnologie-Anbietern, die eine On-Device-Präsenz betreiben, z. B. ein Mobilgerät Analysepartnern (MMPs) und Supply-Side-Plattformen (SSPs). Die geschützte App Die Signals API unterstützt diese Anzeigentechnologie durch flexible Lösungen Verwaltung von geschützten App-Signalen durch Aktivieren von Aufrufen auf dem Gerät Erstellung geschützter App-Signale im Namen von Käufern. Dieser Prozess wird als Delegierung und nutzt die fetchSignalUpdates() API. fetchSignalUpdates() ruft für einen URI eine Liste mit Signalaktualisierungen ab. Zur Veranschaulichung: fetchSignalUpdates() gibt eine GET-Anfrage an den angegebenen URI aus, um die Liste der Aktualisierungen, die auf den lokalen Signalspeicher angewendet werden sollen. Der URL-Endpunkt, der zu antwortet der Käufer mit einer JSON-Liste von Befehlen.

Folgende JSON-Befehle werden unterstützt:

• put: Fügt einen Skalarwert für den gegebenen Schlüssel ein oder überschreibt ihn.
• put_if_not_present: Fügt einen Skalarwert für den gegebenen Schlüssel ein, wenn kein Wert bereits gespeichert. Diese Option kann nützlich sein, Test-ID des jeweiligen Nutzers. Überschreiben Sie diese nicht, wenn sie von einer anderen Anwendung festgelegt.
• Anfügen: Fügt der Zeitreihe, die mit dem jeweiligen Schlüssel verknüpft ist, ein Element hinzu. Der Parameter „maxSignals“ gibt die maximale Anzahl von Signalen in der Zeit 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 den mit dem angegebenen Schlüssel verknüpften Inhalt.

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

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

Die oben aufgeführten Befehle dienen zum Einfügen, Überschreiben und Löschen. Semantik für skalare Signale und Überschreiben des Einfügens, Anfügens und Überschreibens von ganzen Reihen für Zeitreihensignalen. Löschen und Überschreiben der Semantik bestimmter Elemente eines Das Zeitreihensignal muss während des Codierungs- und Verdichtungsprozesses verwaltet werden. So können Sie z. B. während der Codierung Werte in einer Zeitreihe ignorieren, die durch neuere ersetzt oder korrigiert und während Verdichtungsprozess.

Gespeicherte Signale werden automatisch der App zugeordnet, die die Fetch-Anfrage und der Person, die die Anfrage beantwortet, (die „Website“ oder „Ursprung“ eines registrierte Anzeigentechnologie) sowie den Erstellungszeitpunkt der Anfrage. Alle Signale sind werden im Auftrag einer für Privacy Sandbox registrierten Anzeigentechnologie gespeichert. URI „site“/„origin“ müssen mit den Daten eines registrierten Anzeigentechnologie-Anbieters übereinstimmen. Wenn die Wenn die Anzeigentechnologie nicht registriert ist, wird die Anfrage abgelehnt.

Speicherkontingent und Bereinigung

Jede Anzeigentechnologie hat auf dem Nutzergerät nur einen begrenzten Platz zum Speichern von Signalen. Dieses Kontingent wird pro Anzeigentechnologie festgelegt. Die von verschiedenen Apps ausgewählten Signale teilen sich also mit Kontingent. Wenn das Kontingent überschritten wird, gibt das System Speicherplatz frei, indem es frühere auf der Grundlage des First-In-First-Out-Prinzips. Um zu verhindern, dass Bereinigungen ausgeführt wird, implementiert das System eine Batch-Logik, um begrenzt ist, und um Speicherplatz freizugeben, sobald Bereinigungslogik ausgelöst.

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

Zur Vorbereitung von Signalen für die Anzeigenauswahl verfügt die benutzerdefinierte Logik pro Käufer über geschützten Zugriff den gespeicherten App-Signalen und -Ereignissen. Ein Android-Systemhintergrundjob wird ausgeführt. stündlich, um die benutzerdefinierte Codierungslogik des Käufers auszuführen, die in den . Die benutzerdefinierte Codierungslogik pro Käufer codiert die Signale pro App. und komprimiert die App-Signale dann zu einer Nutzlast, die den pro Käufer. Die Nutzlast wird dann innerhalb der Grenzen und an die Gebots- und Auktionsdienste gesendet werden.

AdTechs definieren den Grad der Signalverarbeitung, der von ihrem eigenen benutzerdefinierten Logik. Sie können Ihre Lösung beispielsweise so instrumentieren, dass frühere und ähnliche oder bestärkende Signale aus verschiedenen in neue Signale mit geringerem Speicherplatz um.

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

Weitere Informationen zu Speicher-, Nutzlast- und Anfragekontingenten finden Sie in einer für zukünftige Updates. Außerdem erhalten Sie von uns weitere Informationen dazu, wie Sie benutzerdefinierte Funktionen bereitstellen.

Workflow für die Anzeigenauswahl

Mit diesem Vorschlag kann der benutzerdefinierte AdTech-Code nur auf die geschützte App zugreifen Signale in einer geschützten Auktion (Ad Selection API), die in einem TEE ausgeführt wird. Bis die Anforderungen für den Anwendungsfall der App-Installation weiter decken, sind mögliche Anzeigen die während der geschützten Auktion in Echtzeit abgerufen werden. Dies steht im Gegensatz zu den Remarketing-Anwendungsfall, bei dem mögliche Anzeigen vor der Auktion bekannt sind

Für dieses Angebot wird ein ähnlicher Workflow für die Anzeigenauswahl verwendet wie für die Protected Audience API. mit Aktualisierungen, die den Anwendungsfall für die App-Installation unterstützen. Zur Unterstützung der Computing-Anforderungen für Feature Engineering und Echtzeit-Anzeigenauswahl, Auktionen für App-Installationsanzeigen müssen über Gebote und Auktionen ausgeführt werden. in TEEs ausgeführte Dienste. Zugriff auf geschützte App-Signale während eines Auktionen werden bei On-Device-Auktionen nicht unterstützt.

</ph>

Der Arbeitsablauf für die Anzeigenauswahl ist wie folgt:

1. Das SDK des Verkäufers sendet die verschlüsselte Nutzlast von Protected App-Signale.
2. Der Server des Verkäufers erstellt eine Auktionskonfiguration und sendet sie an den des Verkäufers auf vertrauenswürdige Gebote und Auktionen zugreifen. Nutzlast, zum Initiieren eines Anzeigenauswahl-Workflows.
3. Der Gebots- und Auktionsdienst des Verkäufers übergibt die Nutzlast an das der teilnehmenden vertrauenswürdigen Käufer.
4. Der Gebotsdienst des Käufers führt die Logik der Anzeigenauswahl auf Käuferseite aus. <ph type="x-smartling-placeholder">
   </ph>
   1. Ausführung der Logik des Anzeigenabrufs auf Käuferseite:
   2. Ausführung der Gebotslogik auf Käuferseite:
5. Die Bewertungslogik auf Verkäuferseite wird ausgeführt.
6. Die Anzeige wird gerendert und Berichte werden initiiert.

Workflow für Anzeigenauswahl initiieren

Wenn eine Anwendung zur Auslieferung einer Anzeige bereit ist, wird das AdTech SDK (in der Regel SSPs) eingesetzt. initiiert den Anzeigenauswahl-Workflow durch Senden aller relevanten kontextbezogenen Daten von vom Publisher und den vom Käufer verschlüsselten Nutzlasten, die in die Anfrage die mithilfe des getAdSelectionData-Aufrufs an die geschützte Auktion gesendet werden sollen. Dies ist die für den Remarketing-Workflow verwendet und im Abschnitt Gebote und Auktionsintegration für Android.

Um mit der Anzeigenauswahl zu beginnen, übergibt der Verkäufer eine Liste teilnehmender Käufer und verschlüsselter Nutzlast der Protected App Signals auf dem Gerät. Damit bereitet der Ad-Server auf Verkäuferseite eine SelectAdRequest für die vertrauenswürdigen SellerFrontEnd-Dienst.

Der Verkäufer legt Folgendes fest:

• Die von getAdSelectionData empfangene Nutzlast, die den Geschützte App-Signale.

• Kontextsignale anhand von:

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

  • auction_config.seller_signals (für die Verkäufersignale)

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

• Die Liste der Käufer, die mithilfe des buyer_list.

Ausführung der Logik zur Anzeigenauswahl auf Käuferseite

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

</ph>

Bevor ein Käufer ein Gebot abgibt, beginnt er mit einer großen Auswahl an Anzeigen. Es ist zu langsam, Für jede Anzeige wird ein Gebot berechnet, sodass Käufer zuerst die besten k Kandidaten auswählen müssen. aus dem großen Pool. Als Nächstes müssen die Käufer Gebote für diese Top-K zu bewerben. Diese Anzeigen und Gebote werden dann für die endgültige Auswahl.

</ph>
1. Der BuyerFrontEnd-Dienst erhält eine Anzeigenanfrage.
2. Der BuyerFrontEnd-Dienst sendet eine Anfrage an den Gebotsdienst des Käufers. Der Gebotsdienst des Käufers führt eine UDF mit dem Namen prepareDataForAdRetrieval() aus. Dadurch wird eine Anfrage erstellt, um über den Anzeigenabruf die Top-K-Kandidaten zu ermitteln. Dienst. Der Bidding-Dienst sendet diese Anfrage an den konfigurierten Abruf. Serverendpunkt.
3. Der Anzeigenabrufdienst führt die UDF getCandidateAds() aus, die Filter für bis hin zur Gruppe der k potenziellen Anzeigen, die an das Bidding-Service.
4. Der Gebotsdienst des Käufers führt die UDF generateBid() aus, die die bester Kandidat, berechnet sein Gebot und gibt es dann an BuyerFrontEnd zurück .
5. Der BuyerFrontEnd-Dienst gibt die Anzeigen und Gebote an den Verkäufer zurück.

Bei diesem Ablauf gibt es einige wichtige Details, insbesondere in Bezug auf wie die einzelnen Komponenten miteinander kommunizieren und wie die Plattform Funktionen wie die Möglichkeit, Vorhersagen für maschinelles Lernen zu treffen, um die Top-K-Anzeigen abzurufen und die Berechnung ihrer Gebote.

Bevor wir näher darauf eingehen, möchte ich Ihnen einige wichtige Punkte Hinweise zur Architektur zu den TEEs im obigen Diagramm.

Der Gebotsdienst des Käufers enthält intern einen Inferenzdienst. Anzeigentechnologie Modelle für maschinelles Lernen in den Gebotsdienst des Käufers hochladen. Wir werden JavaScript-APIs für Anzeigentechnologien bereitstellen, um Vorhersagen zu treffen oder Einbettungen zu generieren aus den UDFs stammen, die im Gebotsdienst des Käufers ausgeführt werden. Im Gegensatz zum Anzeigenabrufdienst hat der Gebotsdienst des Käufers keinen Schlüssel/Wert-Paar-Service zum Speichern von Anzeigenmetadaten.

Der Anzeigenabrufdienst umfasst intern einen Schlüssel/Wert-Dienst. Anzeigentechnologie-Anbieter können Schlüssel/Wert-Paare von ihren eigenen Servern aus außerhalb die Datenschutzgrenze erreicht. Wir stellen eine JavaScript-API bereit, aus der Anzeigentechnologie-Experten Daten abrufen können. innerhalb der UDFs, die mit dem Anzeigenabrufdienst ausgeführt werden. Im Gegensatz zum Gebotsdienst des Käufers enthält der Anzeigenabrufdienst keine einen Inferenzdienst.

Eine zentrale Frage, die sich in diesem Design beantwortet, ist die Frage, wie auf Prognosen zur Gebotszeit aus. Die Antwort auf beide kann eine Lösung beinhalten, die Modellfaktorisierung.

Modellfaktorisierung

Die Modellfaktorisierung ist eine Technik, mit der ein einzelnes in mehrere Teile zerlegen und diese Teile dann zu einer Vorhersage kombinieren. In im Anwendungsfall App-Installationen verwenden Modelle häufig drei Arten von Daten: Kontext- und Anzeigendaten.

Im nicht-faktorisierten Fall wird ein einzelnes Modell mit allen drei Arten von Daten. Im faktorisierten Fall wird das Modell in mehrere Teile zerlegt. Nur der Teil, der die Nutzerdaten enthält, vertraulich ist. Das bedeutet, dass nur das Modell mit der muss innerhalb der Vertrauensgrenze gemäß dem Gebot des Käufers ausgeführt werden. Inferenzdienst des Dienstes.

Dies macht das folgende Design möglich:

1. Teilen Sie das Modell in einen privaten Teil (die Nutzerdaten) und einen oder mehrere Teile auf. nicht private Inhalte (Kontext- und Anzeigendaten)
2. Optional: Übergeben Sie einige oder alle nicht privaten Teile als Argumente an eine UDF. das Vorhersagen treffen muss. Kontextuelle Einbettungen sind beispielsweise an UDFs im per_buyer_signals übergeben.
3. Optional können AdTechs Modelle für nicht private Objekte erstellen, Einbettungen aus diesen Modellen in die Schlüssel/Wert-Paar-Speicher. UDFs im Ad Retrieval Service können diese Einbettungen abrufen. während der Laufzeit.
4. Um während einer UDF eine Vorhersage zu treffen, kombinieren Sie private Einbettungen aus der mit nicht privaten Einbettungen aus UDF-Funktionsargumenten oder Schlüssel/Wert-Paar-Speicher mit einem Vorgang wie einem Punktprodukt. Dies ist die letzte eine Vorhersage treffen.

So können wir uns die einzelnen UDFs genauer ansehen. Wir erklären Ihnen, wie sie integriert werden und wie sie die erforderlichen Vorhersagen treffen können, die leistungsstärksten Anzeigen auswählen und die zugehörigen Gebote berechnen.

Die UDF prepareDataForAdRetrieval()

prepareDataForAdRetrieval(), die im Gebotsdienst des Käufers ausgeführt wird, ist ist für die Erstellung der Anfragenutzlast verantwortlich, die an die Anzeige gesendet wird. -Abrufdienst, um die besten Anzeigen zu ermitteln.

prepareDataForAdRetrieval() verwendet die folgenden Informationen:

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

prepareDataForAdRetrieval() hat zwei Möglichkeiten:

• Featurisierung: Wenn eine Inferenz zum Abruf erforderlich ist, erfolgt eine Transformation. eingehende Signale an Funktionen weiterleiten, damit diese bei Aufrufen des Inferenzdiensts verwendet werden können um private Einbettungen abzurufen.
• Berechnet private Einbettungen zum Abrufen: wenn Abrufvorhersagen erforderlich sind, wird der Aufruf an den Inferenzdienst mit und erhält eine private Einbettung für Abrufzeitvorhersagen.

prepareDataForAdRetrieval() gibt Folgendes zurück:

• Geschützte App-Signale: Nutzlast der von der Anzeigentechnologie ausgewählten Signalen.
• Auktionsspezifische Signale: plattformspezifische Signale auf der Verkäuferseite Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest. Ähnlich wie bei Geschützte Zielgruppen:
• Zusätzliche Signale: zusätzliche Informationen, z. B. abgerufene private Einbettungen aus dem Inferenzdienst stammen.

Diese Anfrage wird an den Anzeigenabrufdienst gesendet, der die Kandidatenzuordnung und führt dann die UDF getCandidateAds() aus.

Die UDF getCandidateAds()

getCandidateAds() läuft vom Anzeigenabrufdienst. Die Anfrage wird empfangen. das von prepareDataForAdRetrieval() im Gebotsdienst des Käufers erstellt wurde. Die Der Dienst führt getCandidateAds() aus, um die Top-K-Kandidaten für in eine Reihe von festgelegten Abfragen, Datenabrufen, und andere benutzerdefinierte Abruflogik ausführen.

getCandidateAds() verwendet die folgenden Informationen:

• Geschützte App-Signale: Nutzlast der von der Anzeigentechnologie ausgewählten Signalen.
• Auktionsspezifische Signale: plattformspezifische Signale auf der Verkäuferseite Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest. Ähnlich wie bei Geschützte Zielgruppen:
• Zusätzliche Signale: zusätzliche Informationen, z. B. abgerufene private Einbettungen aus dem Inferenzdienst stammen.

getCandidateAds() führt Folgendes aus:

1. Ersten Satz Anzeigenkandidaten abrufen: Mit Targeting-Kriterien abgerufen z. B. Sprache, Geografie, Anzeigentyp, Anzeigengröße oder Budget, um relevante Anzeigen herauszufiltern.
2. Abruf von Einbettungen: Wenn Einbettungen aus dem Schlüssel/Wert-Paardienst die für eine Vorhersage der Abrufzeit für die Top-K-Auswahl erforderlich sind, aus dem Schlüssel/Wert-Paar-Dienst abgerufen.
3. Top-K-Kandidatenauswahl: Berechnen Sie einen einfachen Wert für die gefilterte Gruppe von Anzeigenkandidaten basierend auf den aus dem Schlüssel/Wert-Speicher abgerufenen Anzeigenmetadaten und Informationen, die vom Gebotsdienst des Käufers gesendet wurden, und zur Auswahl basierend auf dieser Punktzahl. Zum Beispiel kann der Wert die Chance sein, die für die Anzeige eine App installiert.
4. Gebotseinbettung abrufen: wenn Einbettungen aus dem Schlüssel/Wert-Paar-Dienst die vom Gebotscode benötigt werden, um Vorhersagen zum Zeitpunkt der Gebotseinstellung zu treffen, aus dem Schlüssel/Wert-Paar-Dienst abgerufen.

Beachten Sie, dass der Wert für eine Anzeige die Ausgabe eines Vorhersagemodells sein kann. wird vorhergesagt, wie wahrscheinlich es ist, dass ein Nutzer eine App installiert. Diese Art von Bewertung die Generation eine Art der Modellfaktorisierung beinhaltet: da getCandidateAds() wird vom Anzeigenabrufdienst ausgeführt. Da der Abruf von Anzeigen Dienst keinen Inferenzdienst hat, können Vorhersagen durch Kombination:

• Kontextbezogene Einbettungen, die mithilfe der auktionsspezifischen Signale übergeben werden Eingabe.
• Private Einbettungen, die mithilfe der zusätzlichen Signale übergeben werden.
• Alle nicht privaten Einbettungen von AdTechs sind von ihren Servern materialisiert in den Schlüssel/Wert-Paar-Service des Anzeigenabrufdienstes ein.

Beachten Sie, dass die UDF generateBid(), die im Gebotsdienst des Käufers ausgeführt wird, möglicherweise eine eigene Art der Modellfaktorisierung anwenden, um ihre Gebote Vorhersagen zu treffen. Falls Einbettungen von einem Schlüssel/Wert-Paar-Dienst benötigt werden, Sie müssen jetzt abgerufen werden.

getCandidateAds() gibt Folgendes zurück:

• Anzeigenkandidaten: Die leistungsstärksten Anzeigen, die an generateBid() übergeben werden sollen. Jede Anzeige ist bestehend aus: <ph type="x-smartling-placeholder">
  </ph>
  • Render-URL: Endpunkt für das Rendering des Anzeigen-Creatives.
  • Metadaten: Anzeigentechnologie-spezifische Metadaten auf Käuferseite Zum Beispiel kann Informationen über die Werbekampagne und Ausrichtungskriterien enthalten. wie Standort und Sprache. Die Metadaten können optionale Einbettungen, die verwendet werden, wenn für die Ausführung die Modellfaktorisierung erforderlich ist Ableitung bei der Gebotsabgabe.
• Zusätzliche Signale: Der Anzeigenabrufdienst kann optional zusätzliche Informationen wie zusätzliche Einbettungen oder Spam-Signale in generateBid().

Wir untersuchen derzeit andere Methoden zur Bereitstellung von Anzeigen, die bewertet werden sollen, darunter: und es im Rahmen des SelectAdRequest-Aufrufs verfügbar gemacht wird. Diese Anzeigen können mit einer RTB-Gebotsanfrage abgerufen werden. Beachten Sie, dass Anzeigen in solchen Fällen vom ohne Protected App Signals abgerufen. Wir gehen davon aus, dass Anzeigentechnologie-Anbieter Kompromisse bewerten, bevor Sie die beste Option auswählen, einschließlich der Antwortnutzlast Größe, Latenz, Kosten und Verfügbarkeit von Signalen.

Die UDF generateBid()

Sobald Sie den Satz möglicher Anzeigen und die Einbettungen während können Sie mit der Gebotsabgabe fortfahren. . Dieser Dienst führt die vom Käufer bereitgestellte generateBid() aus UDF wählt die Anzeige, auf die Sie bieten möchten, aus dem obersten K aus und gibt sie mit ihrem Gebot zurück.

generateBid() verwendet die folgenden Informationen:

• Anzeigenkandidaten: die Top-T-Anzeigen, die beim Abrufen von Anzeigen zurückgegeben wurden .
• Auktionsspezifische Signale: plattformspezifische Signale auf der Verkäuferseite Kontextinformationen wie auction_signals und per_buyer_signals (einschließlich kontextbezogener Einbettungen) von SelectAdRequest.
• Zusätzliche Signale: zusätzliche Informationen, die bei der Gebotsabgabe verwendet werden sollen.

Mit der generateBid()-Implementierung des Käufers werden drei Dinge erreicht:

• Featurisierung: Wandelt Signale in Funktionen um, die während Inferenz.
• Inferenz: Generiert Vorhersagen mithilfe von Modellen für maschinelles Lernen, um Werte wie prognostizierte Klick- und Conversion-Raten berechnen
• Gebote: Abgeleitete Werte mit anderen Eingaben kombinieren, um den Wert zu berechnen für eine mögliche Anzeige bieten.

generateBid() gibt Folgendes zurück:

• Die mögliche Anzeige.
• Den berechneten Gebotsbetrag

Der generateBid() für App-Installationsanzeigen und der für Remarketing-Anzeigen sind anders.

In den folgenden Abschnitten werden Leistung, Inferenz und Gebote Details.

Featurisierung

Auktionssignale können von generateBid() in Funktionen vorbereitet werden. Diese Funktionen kann während der Inferenz verwendet werden, um Dinge wie Klicks und Conversion-Raten. Wir erforschen auch datenschutzfreundliche Mechanismen, im Win-Bericht zur Verwendung beim Modelltraining übertragen.

Inferenz

Bei der Berechnung eines Gebots werden häufig Inferenzen auf ein oder mehrere Modelle für maschinelles Lernen. Effektive eCPM-Berechnungen verwenden beispielsweise häufig um Klick- und Conversion-Raten vorherzusagen.

Kunden können neben ihren eigenen generateBid()-Implementierung. Außerdem stellen wir ein JavaScript-API in generateBid(), damit Clients zur Laufzeit Inferenzen ausführen können.

Die Inferenz wird über den Gebotsdienst des Käufers ausgeführt. Dies kann die Inferenz beeinflussen Latenz und Kosten, vor allem, da Beschleuniger in TEEs noch nicht verfügbar sind. Einige Kunden werden feststellen, dass ihre Anforderungen durch individuelle Modelle erfüllt werden, die auf der den Gebotsdienst des Käufers. Einige Kunden, z. B. Kunden mit sehr großen Modelle – Sie sollten Optionen wie die Modellfaktorisierung in Betracht ziehen, um die Inferenzkosten und die Latenz zum Zeitpunkt der Gebotsabgabe.

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

Modellfaktorisierung implementieren

Wir haben bereits die Modellfaktorisierung erläutert. Bei der Gebotsabgabe Ansatz lautet:

1. Teilen Sie das Modell in einen privaten Teil (die Nutzerdaten) auf und teilen Sie mehr nicht private Teile (Kontext- und Anzeigendaten)
2. Gib nicht private Gegenstände an generateBid() weiter. Diese können entweder aus per_buyer_signals oder von Einbettungen, die AdTechs extern berechnet haben, in den Schlüssel/Wert-Speicher des Abrufdienstes eintreten, und kehren als Teil der zusätzlichen Signale zurück. Dies gilt nicht für private Einbettungen, da diese nicht außerhalb des Datenschutzes stammen dürfen. Grenze.
3. In generateBid(): <ph type="x-smartling-placeholder">
   </ph>
   1. Modelle ableiten, um private Nutzereinbettungen zu erhalten.
   2. Kombinieren Sie private Nutzereinbettungen mit kontextbezogenen Einbettungen aus per_buyer_signals oder nicht private Anzeigen und kontextbezogene Einbettungen aus der Datenabrufdienst mithilfe einer Operation wie einem Punktprodukt. Dies ist die eine endgültige Vorhersage, die zur Berechnung von Geboten verwendet werden kann.

Mit diesem Ansatz ist es möglich, bei der Gebotsabgabe eine Inferenz für die sonst zu groß oder zu langsam für die Ausführung auf den Bidding-Service.

Bewertungslogik auf Verkäuferseite

In dieser Phase werden die Anzeigen mit Geboten von allen teilnehmenden Käufern Punkte. Die Ausgabe von generateBid() wird an den Auktionsdienst des Verkäufers übergeben. um scoreAd() auszuführen, und dass scoreAd() jeweils nur eine Anzeige berücksichtigt. Basierend auf für den Wert eine Anzeige, die den Zuschlag erhält, zu verbessern.

Die Bewertungslogik wird auch beim Protected Audience-Remarketing und ist in der Lage, eine Kombination aus Remarketing und App-Installationskampagnen auszuwählen. Kandidaten.Die Funktion wird für jede eingereichte mögliche Anzeige im Geschützte Auktion. Weitere Informationen finden Sie in der Erläuterung zu Geboten und Auktionen für Details.

Laufzeit des Anzeigenauswahlcodes

Im Angebot wird der Anzeigenauswahlcode für die App-Installation im selben wie beim Protected Audience-Remarketing-Vorgang. Weitere Informationen finden Sie in der Konfiguration von Geboten und Auktionen: Der Gebotscode wird am selben Cloud-Speicherstandort wie dem verwendeten verfügbar sind für das Remarketing.

Berichterstellung

Für dieses Angebot werden dieselben APIs für die Berichterstellung wie für die Protected Audience-Berichte verwendet. Angebot (z. B. reportImpression(), wodurch die Plattform Verkäufer- und Käuferberichte senden.

Ein häufiger Anwendungsfall für Berichte auf Käuferseite ist das Abrufen von Trainingsdaten. für Modelle, die bei der Anzeigenauswahl verwendet werden. Zusätzlich zu den bestehenden APIs hat die Plattform einen speziellen Mechanismus für ausgehenden Traffic auf Ereignisebene vom und AdTech-Server. Diese Nutzlasten für ausgehenden Traffic können bestimmte Nutzer Daten.

Langfristig suchen wir nach datenschutzfreundlichen Lösungen, Modelltraining mit Daten aus geschützten Auktionen, ohne das Ereignis auf Ereignisebene zu senden Nutzerdaten außerhalb von Diensten, die auf TEEs ausgeführt werden. Wir stellen Ihnen weitere Details zur Verfügung. in einem späteren Update.

Kurzfristig werden wir eine vorübergehende Möglichkeit bieten, verrauschte Daten aus generateBid() Unser erster Vorschlag hierfür finden Sie unten, der auch in Zukunft folgen wird. (einschließlich möglicher nicht abwärtskompatibler Änderungen) als Reaktion auf die Branche Feedback geben.

Technisch gesehen funktioniert das folgendermaßen:

1. AdTechs definieren ein Schema für die Daten, die sie übertragen möchten.
2. In generateBid() wird die gewünschte Nutzlast für ausgehenden Traffic erstellt.
3. Die Plattform validiert die Nutzlast des ausgehenden Traffics anhand des Schemas und erzwingt Größenbeschränkungen.
4. Die Plattform fügt der Nutzlast des ausgehenden Traffics Rauschen hinzu.
5. Die Nutzlast des ausgehenden Traffics ist im Gewinnbericht im Wire-Format enthalten, empfangen am AdTech-Server, die decodiert und für das Modelltraining verwendet werden.

Schema der Nutzlasten für ausgehenden Traffic definieren

Damit die Plattform neue Datenschutzanforderungen durchsetzen kann, muss der Nutzlasten des ausgehenden Traffics so strukturiert sein, dass die Plattform sie versteht. AdTechs definieren die der Nutzlasten des ausgehenden Traffics durch Bereitstellung einer JSON-Schemadatei. Dieses Schema werden von der Plattform verarbeitet und vom Bidding-Team und Auktionsdienste werden mit denselben Mechanismen wie andere Anzeigentechnologie-Ressourcen verwaltet. wie UDFs und Modelle.

Wir stellen eine CDDL-Datei zur Verfügung, die die Struktur dieser JSON definiert. Die Die CDDL-Datei enthält eine Reihe unterstützter Elementtypen (z. B. Features die boolesche Werte, Ganzzahlen, Buckets usw. sind). Sowohl die CDDL-Datei als auch die das angegebene Schema versioniert wird.

Zum Beispiel eine Nutzlast für ausgehenden Traffic, die aus einem einzelnen booleschen Merkmal besteht. gefolgt von einem Bucket-Feature der Größe 2 in etwa so aus:

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

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

Ausgehende Nutzlasten in generateBid() erstellen

Alle geschützten App-Signale eines Käufers sind generateBid()-UDF. Sobald diese eingerichtet sind, erstellen AdTechs ihre Nutzlast in JSON-Format. Diese ausgehende Nutzlast wird in den Gewinnbericht des Käufers für an AdTech-Server übertragen werden.

Alternativ kann die Berechnung des ausgehenden Vektors in reportWin() statt generateBid(). Es gibt Vor- und Nachteile Die Entscheidung wird als Reaktion auf das Feedback aus der Branche endgültig getroffen.

Nutzlast des ausgehenden Traffics validieren

Die Plattform validiert jede ausgehende Nutzlast, die von der Anzeigentechnologie erstellt wird. Validierung stellen sicher, dass Featurewerte für ihre Typen gültig sind, und dass böswillige Akteure nicht versuchen, zusätzliche Informationen in die Nutzlasten für ausgehenden Traffic packen.

Wenn eine ausgehende Nutzlast ungültig ist, wird sie bei den Eingaben ohne Meldung verworfen. an den Gewinnbericht gesendet. Das liegt daran, dass wir kein Debugging und böswilligen Akteuren, die die Validierung verhindern möchten, Informationen liefern.

Wir stellen AdTechs eine JavaScript-API zur Verfügung, um die ausgehende Nutzlast Das Erstellen in generateBid() besteht die Plattformvalidierung:

validate(payload, schema)

Diese JavaScript API ist ausschließlich für Aufrufer gedacht, um festzustellen, ob eine bestimmte Nutzlast besteht die Plattformvalidierung. Die tatsächliche Validierung muss auf der Plattform erfolgen, um Schutz vor schädlichen generateBid()-UDFs.

Rauschen für ausgehenden Traffic

Die Plattform verrauscht den Schadcode des ausgehenden Traffics, bevor er in den Gewinnbericht aufgenommen wird. Der anfängliche Rauschgrenzwert liegt bei 1 % und dieser Wert kann sich im Laufe der Zeit ändern. Die bietet die Plattform keinen Hinweis darauf, ob eine bestimmte ausgehende Nutzlast aufgeklärt.

Die Rauschmethode ist:

1. Die Plattform lädt die Schemadefinition für die Nutzlast des ausgehenden Traffics.
2. 1% der ausgehenden Nutzlasten werden für das Rauschen ausgewählt.
3. Wenn keine Nutzlast für ausgehenden Traffic ausgewählt wird, wird der gesamte ursprüngliche Wert beibehalten.
4. Wenn eine Nutzlast für ausgehenden Traffic ausgewählt wird, wird der Wert jeder Funktion durch einen Zufälliger gültiger Wert für diesen Elementtyp (z. B. 0 oder 1 für ein boolesches Merkmal).

Ausgehende Nutzlast für das Modelltraining senden, empfangen und decodieren

Die validierte, verrauschte Nutzlast des ausgehenden Traffics wird in die Argumente aufgenommen, reportWin(). Die Daten werden außerhalb des Datenschutzes an die AdTech-Server des Käufers übertragen. Grenze für das Modelltraining ein. Die ausgehende Nutzlast hat das Wire-Format.

Details zum Wire-Format für alle Feature-Typen und für die Nutzlast des ausgehenden Traffics sind auf GitHub verfügbar.

Größe der ausgehenden Nutzlast bestimmen

Die Größe der ausgehenden Nutzlast in Bits gleicht die Dienstprogramm- und Datenminimierung aus. Wir arbeiten mit der Branche zusammen, zu experimentieren. Während wir diese Tests durchführen, ausgehender Traffic ohne Bitgrößenbeschränkung. Diese zusätzlichen ausgehenden Daten Die Größenbeschränkung wird aufgehoben, sobald die Tests abgeschlossen sind.

Die Methode zur Bestimmung der Größe lautet:

1. Anfangs werden zwei Nutzlasten für ausgehenden Traffic in generateBid() unterstützt: <ph type="x-smartling-placeholder">
   </ph>
   1. egressPayload: die bisher beschriebene größenbeschränkte Nutzlast für ausgehenden Traffic in diesem Dokument. Anfänglich beträgt die Größe dieser ausgehenden Nutzlast 0 Bits Das heißt, sie wird während der Validierung immer entfernt.
   2. temporaryUnlimitedEgressPayload: ein temporärer, unbegrenzter ausgehender Traffic für Größentests an. Die Formatierung, Erstellung und Verarbeitung dieser ausgehenden Nutzlast nutzt dieselben Mechanismen wie egressPayload.
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 Bestimmung des Modells zur Verfügung. bei verschiedenen Nutzlastgrößen für ausgehenden Traffic (z. B. 5, 10, ... Bit).
4. Anhand der Testergebnisse wird die Größe des ausgehenden Traffics mit dem Parameter Kompromisse bei Funktionalität und Datenschutz eingehen.
5. Wir haben die Größe von egressPayload von 0 Bit auf die neue Größe festgelegt.
6. Nach einem festgelegten Migrationszeitraum entfernen wir temporaryUnlimitedEgressPayload, So bleibt nur egressPayload in der neuen Größe.

Wir untersuchen derzeit zusätzliche technische Schutzmaßnahmen für den Umgang mit dieser Änderung Beispielsweise wird egressPayload verschlüsselt, wenn die Größe von 0 Bit erhöht wird. Diese Details, einschließlich des Zeitplans für den Test und der Entfernung temporaryUnlimitedEgressPayload wird in einem späteren Update enthalten sein.

Als Nächstes erläutern wir ein mögliches Testprotokoll zur Bestimmung der Größe egressPayload Unser Ziel ist es, gemeinsam mit der Branche eine Größe zu finden, Dienstprogramm- und Datenminimierung. Das Artefakt aus diesen Tests ist Grafik, wobei die x-Achse die Größe der Trainingsnutzlast in Bit darstellt. Die y-Achse ist der Prozentsatz des Umsatzes, der von einem Modell dieser Größe im Vergleich bis zu einer größenunbegrenzten Referenz.

Wir gehen davon aus, dass wir ein pInstall-Modell trainieren, und unsere Quellen der Trainingsdaten sind unsere Logs und der Inhalt der temporaryUnlimitedegressPayloads, wenn wir Auktionen gewinnen. Das Protokoll für Anzeigentechnologie-Anbieter umfasst zuerst die Offline-Nutzung. Tests:

1. Architektur der Modelle bestimmen, die mit Protected App verwendet werden sollen Signale. Sie müssen beispielsweise entscheiden, ob sie Verwenden Sie die Modellfaktorisierung.
2. Definieren Sie einen Messwert zum Messen der Modellqualität. Vorgeschlagene Messwerte sind AUC-Verlust und logarithmischen Verlust.
3. Definieren Sie die Funktionen, die während des Modelltrainings verwendet werden sollen.
4. Mit dieser Modellarchitektur, den Qualitätsmetriken und den Trainingsfeatures Ablationsstudien durchführen, um den Nutzen pro Bit für jedes das sie für die Anzeigenbereitstellung verwenden möchten. Das vorgeschlagene Protokoll für die Ablationsstudie lautet: <ph type="x-smartling-placeholder">
   </ph>
   1. Modell mit allen Features trainieren und den Nutzen messen dies ist die Baseline für den Vergleich.
   2. Trainieren Sie für jedes Feature, das zum Erstellen der Baseline verwendet wird, das Modell mit allen außer dieser Funktion.
   3. Messen Sie den resultierenden Nutzen. Delta durch die Größe des Elements dividieren in Bits; das erwartete Dienstprogramm pro Bit.
5. Bestimmen Sie die Trainingsnutzlastgrößen, die Sie für Tests interessieren. Mi. Vorschlag [5, 10, 15, ..., size_of_all_training_features_for_baseline] Teile. Jede davon stellt eine mögliche Größe für egressPayload dar, die der wird der Test bewertet.
6. Wählen Sie für jede mögliche Größe einen Satz von Elementen aus, die kleiner oder gleich dieser Größe sind. die den Nutzen pro Bit maximieren, basierend auf den Ergebnissen der Ablationsstudie.
7. Trainieren Sie ein Modell für jede mögliche Größe und bewerten Sie seinen Nutzen als Prozentsatz des Nutzens des Basismodells, das mit allen Features trainiert wurde.
8. Stelle die Ergebnisse in einem Diagramm dar, wobei die x-Achse die Größe des Trainings darstellt. die Nutzlast in Bits an. Die Y-Achse ist der Prozentsatz des Umsatzes, dieses Modell mit der Baseline vergleichen.

Als Nächstes können Anzeigentechnologie-Anbieter die Schritte 5 bis 8 in Live-Traffic-Tests mit der Funktion Daten, die per temporaryUnlimitedEgressPayload gesendet wurden. Anzeigentechnologie-Anbieter können die Ergebnisse ihrer Offline- und Live-Traffic-Tests mit der Privacy Sandbox um Entscheidungen über die Größe von egressPayload zu treffen.

Der Zeitplan für diese Tests und der Zeitplan zum Festlegen der Größe von egressPayload zum resultierenden Wert, wird in diesem Dokument nicht behandelt. und wird in einer späteren Aktualisierung veröffentlicht.

Datenschutzmaßnahmen

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

1. Sowohl egressPayload als auch temporaryUnlimitedEgressPayload werden verrauscht.
2. Für Datenminimierung und ‐schutz gilt: temporaryUnlimitedEgressPayload nur für die Dauer von Größentests verfügbar sind, um die richtige Größe für egressPayload zu ermitteln.

Berechtigungen

Nutzersteuerung

• Das Angebot soll Nutzern Einblick in die Liste der installierten Apps geben für die mindestens ein Protected App-Signal oder eine benutzerdefinierte Zielgruppe gespeichert wurde.
• Nutzer können Apps blockieren und aus dieser Liste entfernen. Durch das Blockieren und Entfernen Folgendes: <ph type="x-smartling-placeholder">
  </ph>
  • Löscht alle Protected App-Signale und benutzerdefinierten Zielgruppen, die mit in der App.
  • Verhindert, dass Apps neue Protected App-Signale und benutzerdefinierte Zielgruppen
• Nutzer können die Protected App-Signale und Audience API vollständig. In diesem Fall werden alle vorhandenen geschützten Apps Signale und benutzerdefinierte Zielgruppen auf dem Gerät werden gelöscht.
• Nutzer haben die Möglichkeit, die Privacy Sandbox vollständig zu deaktivieren: Android, einschließlich der Protected App Signals API und der Protected Audience API der API erstellen. In diesem Fall werden die Signale der Protected Audience API und der Protected App APIs geben eine standardmäßige Ausnahmemeldung zurück: SECURITY_EXCEPTION.

App-Berechtigungen und ‐Einstellungen

Mit dem Vorschlag soll Apps die Kontrolle über ihre geschützten App-Signale gegeben werden:

• Eine App kann ihre Verknüpfungen mit geschützten App-Signalen verwalten.
• Über eine App können Drittanbieter-Anzeigentechnologie-Plattformen Berechtigungen zum Verwalten Geschützte App-Signale in seinem Namen.

Steuerung der Anzeigentechnologie-Plattform

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

• Alle Anzeigentechnologie-Anbieter müssen sich für die Privacy Sandbox registrieren und eine „Website“ zur Verfügung stellen. oder „Ursprung“ Domain, die mit allen URLs für geschützte App-Signale übereinstimmt.
• AdTechs können mit Apps oder SDKs zusammenarbeiten, um Bestätigungstokens zur Verfügung zu stellen, werden verwendet, um die Erstellung von geschützten App-Signalen zu prüfen. Wenn dieser Vorgang an einen Partner delegiert wurde, kann die Erstellung von Protected App-Signalen so konfiguriert werden, die Anerkennung durch die Anzeigentechnologie erfordern.