Cette page a été traduite par l'API Cloud Translation.

Signaux d'application protégés pour prendre en charge des annonces pertinentes incitant à installer une application

Cette proposition est soumise au processus d'inscription à la Privacy Sandbox et attestations. Pour en savoir plus sur les attestations, consultez au lien d'attestation fourni. Dans les prochaines mises à jour de cette proposition, décrire les exigences pour accéder à ce système.

Les annonces incitant à installer une application mobile, également appelées annonces pour l'acquisition d'utilisateurs, sont un type de publicité mobile conçu pour inciter les utilisateurs à télécharger une application mobile. Ces annonces sont généralement diffusées auprès des utilisateurs en fonction de leurs centres d'intérêt et de leurs données démographiques. Elles apparaissent souvent dans d'autres applications mobiles telles que les jeux, les réseaux sociaux et des applications d'actualités. Lorsqu'un utilisateur clique sur une annonce incitant à installer une application, ce dernier est directement redirigé vers la plate-forme de téléchargement d'applications où il lui est possible de la télécharger.

Par exemple, un annonceur qui tente d'augmenter le nombre d'installations d'une nouvelle application mobile de livraison de repas aux États-Unis peut diffuser ses annonces auprès des utilisateurs qui se trouvent aux États-Unis et qui ont déjà utilisé d'autres applications de livraison de repas.

Pour implémenter cette fonctionnalité, vous devez généralement inclure des signaux contextuels, propriétaires et tiers entre les technologies publicitaires afin de créer des profils utilisateur en fonction des identifiants publicitaires. Les modèles de machine learning de technologie publicitaire utilisent ces informations pour choisir les annonces les plus pertinentes pour l'utilisateur et qui ont le plus de chances d'aboutir à une conversion.

Les API suivantes sont proposées pour prendre en charge des annonces incitant à installer une application efficaces et qui préservent davantage la confidentialité des utilisateurs en supprimant la dépendance aux identifiants utilisateur multipartites :

API Protected App Signals : cette API se concentre sur le stockage et la création de fonctionnalités conçues par la technologie publicitaire, qui représentent les centres d'intérêt potentiels d'un utilisateur. Les technologies publicitaires stockent les signaux d'événements auto-définis par application, tels que l'application installations, premières ouvertures, actions de l'utilisateur (niveaux de niveau dans le jeu, réussites), d’achats d’activités ou de temps passé dans l’application. Les signaux sont écrits et stockés sur pour empêcher les fuites de données, et ne sont accessibles qu'au Logique de technologie publicitaire qui a stocké le signal donné lors d'une enchère protégée qui s'exécutent dans un environnement sécurisé.
API Ad Selection: cette API fournit une API pour configurer et exécuter une Enchères protégées exécutées dans un environnement d'exécution sécurisé (TEE) où les technologies publicitaires récupèrent les annonces candidates, exécutent des inférences, calculent les enchères de notation pour choisir une « gagnante » à l'aide de l'API Protected App Signals des informations contextuelles en temps réel fournies par l'éditeur

Diagramme illustrant le processus d'installation d'une application avec des signaux protégés — Organigramme illustrant l'API Protected App Signals et le workflow de sélection des annonces dans la Privacy Sandbox sur Android

Voici un aperçu général du fonctionnement de l'API Protected App Signals afin de comprendre comment celle-ci prend en charge les annonces incitant à installer une application pertinentes. Les sections suivantes de ce document fournissent davantage d'informations sur chacune de ces étapes.

Sélection des signaux: lorsque les utilisateurs se servent d'applications mobiles, les technologies publicitaires sélectionnent des signaux. en stockant les événements d'application définis par la technologie publicitaire pour diffuser des annonces pertinentes à l'aide du API Protected App Signals. Ces événements sont stockés dans un espace protégé sur l'appareil de stockage, comme les audiences personnalisées, et sont chiffrées avant d'être de l'appareil de sorte que seuls les services d'enchères et de mise aux enchères au sein d'environnements d'exécution sécurisés, avec des configurations les paramètres de confidentialité peuvent les déchiffrer pour définir des enchères et évaluer les annonces.
Encodage des signaux : les signaux sont préparés à une cadence planifiée par une logique de technologie publicitaire personnalisée. Une tâche en arrière-plan Android exécute cette logique pour : effectuer un encodage sur l'appareil pour générer une charge utile de signaux d'application protégés. qui peut ensuite être utilisée en temps réel pour la sélection des annonces lors d'une protection Mise aux enchères. La charge utile est stockée de manière sécurisée sur l'appareil jusqu'à ce qu'elle soit envoyée pour une mise aux enchères.
Sélection des annonces: pour sélectionner des annonces pertinentes pour l'utilisateur, les SDK des vendeurs envoie une charge utile chiffrée de signaux d'application protégés et configure un Enchères protégées. Dans le système d'enchères, la logique personnalisée de l'acheteur prépare le modèle Les signaux d'application ainsi que les données contextuelles fournies par l'éditeur (données généralement partagé dans une demande d'annonce OpenRTB) afin qu'ils puissent destinées à la sélection des annonces (récupération d'annonces, inférence et enchères génération). Comme pour Protected Audience, les acheteurs envoient leurs annonces vendeur pour l'évaluation finale dans une enchère protégée.
- Récupération des annonces: les acheteurs utilisent les signaux d'application protégés. les données contextuelles fournies par l'éditeur pour concevoir des fonctionnalités ; correspondant aux centres d'intérêt de l'utilisateur. Ces fonctionnalités sont utilisées pour faire correspondre les annonces qui répondent aux critères de ciblage. Les annonces ne respectant pas le budget sont filtrées. Les k premières annonces sont ensuite sélectionnées pour les enchères.
- Enchères : la logique d'enchères personnalisées des acheteurs prépare les données contextuelles fournies par l'éditeur et l'API Protected App Signals. Ceci a pour but de mettre au point les fonctionnalités utilisées comme entrées pour le machine learning de l'acheteur pour l'inférence et les enchères sur des annonces candidates dans le respect de la confidentialité. L'acheteur renvoie ensuite l'annonce qu'il a choisie au vendeur.
- Évaluation des vendeurs: valeurs des vendeurs la logique d'évaluation personnalisée évalue les annonces soumises par les Acheteurs participants et choisit l'annonce gagnante à envoyer à l'application pour le rendu.
Création de rapports : les participants aux enchères reçoivent des rapports sur les gains et les pertes applicables. Nous étudions des mécanismes de protection de la confidentialité afin d'inclure des données permettant l'entraînement de modèles dans le rapport gagnant.

Calendrier

	Version Preview développeur			Bêta
Fonctionnalité	4e trimestre 2023	1er trimestre 2024	2e trimestre 2024	3e trimestre 2024
API de sélection des signaux	API de stockage sur l'appareil	Logique du quota de stockage sur l'appareil Mises à jour quotidiennes de la logique personnalisée sur l'appareil	N/A	Disponible pour les appareils 1% T+
Serveur de récupération des annonces dans un TEE	MVP	Disponible sur GCP Compatibilité avec la mise en production de l'UDF Top K	Disponible sur AWS Débogage, métriques et surveillance autorisés
Service d'inférence dans un TEE Compatibilité avec l'exécution de modèles de ML et leur utilisation pour définir des enchères dans un TEE	En cours de développement	Disponible sur GCP Capacité à déployer et à prototyper des modèles de ML statiques à l'aide de TensorFlow et de PyTorch	Disponible sur AWS Déploiement de modèles en production pour les modèles TensorFlow et PyTorch Télémétrie, débogage autorisé et surveillance
Assistance pour les enchères et les mises aux enchères dans un TEE	Disponible sur GCP	Intégration de la récupération d'annonces PAS-B&A et TEE (avec chiffrement gRPC et TEE<>TEE) Prise en charge de la récupération d'annonces via un chemin contextuel (inclut la prise en charge des B&A<>K/V sur le TEE)	Disponible sur AWS Rapports de débogage Débogage, métriques et surveillance autorisés

Organiser l'API Protected App Signals

Un signal est une représentation de diverses interactions utilisateur au sein d'une application déterminées par la technologie publicitaire comme étant utiles pour diffuser des annonces pertinentes. Une application ou l' Le SDK intégré peut stocker ou supprimer les signaux d'application protégés définis par les technologies publicitaires en fonction de l'activité de l'utilisateur, comme les ouvertures de l'application, les réussites, les achats ou dans l'application. Les signaux d'application protégés sont stockés de manière sécurisée sur l'appareil et sont chiffrées avant d'être envoyées sur l'appareil, de sorte que seules les enchères des services s'exécutant dans des environnements d'exécution sécurisés avec une sécurité et les paramètres de confidentialité peuvent le déchiffrer pour les enchères et l'évaluation des annonces. Semblable à la section API Custom Audience, les signaux stockés sur un appareil ne peuvent pas être lus ni inspectés par les applications ou les SDK ; aucune API ne permet de lire les valeurs des signaux, et les API conçus pour éviter toute fuite de la présence de signaux. La logique personnalisée de technologie publicitaire protège l'accès aux signaux sélectionnés pour mettre au point des fonctionnalités qui servent de base à la sélection des annonces dans une enchère protégée.

API Protected App Signals

L'API Protected App Signals prend en charge la gestion des signaux à l'aide d'un mécanisme de délégation semblable au mécanisme utilisé pour les audiences personnalisées. L'API Protected App Signals permet de stocker des signaux sous la forme d'une valeur scalaire unique ou d'une série temporelle. Les signaux de série temporelle peuvent être utilisés pour stocker des éléments tels que la durée de la session utilisateur. Les signaux de série temporelle permettent d'appliquer une durée donnée en utilisant une règle d'éviction selon la méthode "first in, first out" (premier entré, premier sorti). Le type de données d'un signal scalaire ou de chacun des éléments d'un signal de série temporelle est un tableau d'octets. Chaque valeur est enrichie du nom du package de l'application ayant stocké le signal et du code temporel de création de l'appel d'API du signal du magasin. Ces informations supplémentaires sont disponibles dans la section concernant l'encodage des signaux JavaScript. Cet exemple montre la structure des signaux appartenant à une technologie publicitaire donnée :

Cet exemple illustre un signal scalaire ainsi qu'un signal de série temporelle associés à adtech1.com :

Un signal scalaire avec une clé de valeur base64 "A1c" et la valeur "c12Z". Le store de signaux a été déclenché par com.google.android.game_app le 1er juin 2023.
Une liste de signaux avec la clé "dDE" ayant été créés par deux applications différentes.

Les technologies publicitaires disposent d'un certain espace pour stocker des signaux sur l'appareil. Les signaux auront une valeur TTL maximale, qui doit être déterminée.

Les signaux d'application protégés sont supprimés de l'espace de stockage si l'application génératrice est désinstallée, si l'API Protected App Signals est bloquée ou si les données de l'application sont effacées par l'utilisateur.

L'API Protected App Signals se compose des parties suivantes :

Une API Java et JavaScript pour ajouter, mettre à jour ou supprimer des signaux
Une API JavaScript pour traiter les signaux persistants afin de les préparer une ingénierie supplémentaire des caractéristiques en temps réel lors d'enchères protégées dans un environnement d'exécution sécurisé (TEE).

Ajouter, modifier ou supprimer des signaux

Grâce à l'API fetchSignalUpdates(), les technologies publicitaires peuvent ajouter, modifier ou supprimer des signaux. Cette API prend en charge la délégation semblable à la délégation d'audience personnalisée de Protected Audience.

Pour ajouter un signal, les technologies publicitaires de l'acheteur qui ne sont pas présentes sur le SDK dans les applications doivent collaborer avec les technologies publicitaires présentes sur l'appareil, telles que les partenaires de mesure pour mobile (MMP) et les plates-formes côté offre (SSP). L'API Protected App Signals vise à soutenir ces technologies publicitaires en fournissant des solutions flexibles pour la gestion des signaux d'application protégés et en permettant aux appelants de l'appareil d'invoquer la création de signaux d'application protégés pour le compte des acheteurs. Ce processus, appelé délégation, repose sur l'API fetchSignalUpdates(). fetchSignalUpdates() prend un URI et récupère la liste des mises à jour du signal. Par exemple, fetchSignalUpdates() envoie une requête GET à l'URI donné pour récupérer le des mises à jour à appliquer au stockage local des signaux. Le point de terminaison de l'URL, appartenant à l'acheteur répond avec une liste de commandes JSON.

Voici les commandes JSON compatibles :

put : insère ou remplace une valeur scalaire pour la clé donnée.
put_if_not_present : insère une valeur scalaire pour la clé donnée si aucune valeur n'est déjà stockée. Cette option peut être utile, par exemple, pour définir pour l'utilisateur donné et évitez de le remplacer s'il était déjà défini par une autre application.
append : ajoute un élément à la série temporelle associée à la clé donnée. Le paramètre maxSignals indique le nombre maximal de signaux dans le temps. de la série. Si le nombre maximal est dépassé, les éléments précédents sont supprimés. Si la clé contient une valeur scalaire qui est automatiquement transformée en série temporelle.
remove : supprime le contenu associé à la clé donnée.

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

Toutes les clés et valeurs sont exprimées en Base64.

Les commandes listées ci-dessus sont destinées à fournir une sémantique d'insertion, d'écrasement et de suppression des signaux scalaires. Elles servent également à écraser les signaux d'insertion, d'ajout et d'écrasement de séries complètes pour les signaux de séries temporelles. La suppression et l'écrasement de la sémantique d'éléments spécifiques d'un signal de série temporelle doivent être gérés lors du processus d'encodage et de compactage (par exemple, lors de l'encodage en ignorant les valeurs d'une série temporelle qui ont été remplacées ou corrigées par des valeurs plus récentes). et les supprimer pendant le processus de compactage.

Les signaux stockés sont automatiquement associés à l'application qui effectue de récupération, et le répondeur de la requête (le "site" ou l'"origine" d'une la technologie publicitaire enregistrée), ainsi que l'heure de création de la requête. Tous les signaux sont susceptibles d'être stockés pour le compte d'une technologie publicitaire enregistrée dans la Privacy Sandbox. L'URI "site"/"origine" doit correspondre aux données d'une technologie publicitaire enregistrée. Si la technologie publicitaire à l'origine de la requête n'est pas enregistrée, la requête est alors rejetée.

Quota de stockage et éviction

Chaque technologie publicitaire dispose d'un espace limité sur l'appareil de l'utilisateur pour stocker des signaux. Ce quota est défini par technologie publicitaire. Les signaux sélectionnés à partir de différentes applications se partagent donc le quota. Lorsque le quota est dépassé, le système libère de l'espace en supprimant les valeurs de signal précédentes, selon le principe du "first in, first out". Pour éviter que le principe d'éviction ne s'applique trop fréquemment, le système implémente une logique de traitement par lot afin de pouvoir dépasser le quota et de libérer de l'espace supplémentaire une fois la logique d'éviction déclenchée.

Encodage sur l'appareil pour la transmission de données

Afin de préparer les signaux pour la sélection des annonces, la logique personnalisée par acheteur protège l'accès aux signaux et événements stockés par application. Une tâche d'arrière-plan du système Android s'exécute toutes les heures pour déclencher la logique d'encodage personnalisé par acheteur téléchargée sur l'appareil. La logique d'encodage personnalisé par acheteur encode les signaux pour chaque application, puis compresse ces signaux dans une charge utile qui respecte le quota par acheteur. La charge utile est ensuite chiffrée dans les limites de l'espace de stockage protégé de l'appareil, puis transmise aux services d'enchères.

Les technologies publicitaires définissent le niveau de traitement du signal géré par leur propre logique personnalisée. Par exemple, vous pouvez instrumenter votre solution pour supprimer les signaux plus anciens, et agréger les signaux similaires ou de renforcement provenant de différentes applications en de nouveaux signaux qui utilisent moins d'espace.

Si aucun encodeur de signaux n'a été enregistré par l'acheteur, les signaux ne sont pas préparés, et aucun des signaux sélectionnés sur l'appareil ne sera envoyé aux services d'enchères.

De plus amples d'informations concernant le stockage, la charge utile et les quotas de requêtes vous seront communiqués prochainement. Nous fournirons également des informations supplémentaires sur la manière de proposer des fonctions personnalisées.

Processus de sélection des annonces

Avec cette proposition, le code personnalisé de technologie publicitaire ne peut accéder aux signaux d'application protégés que lorsque des enchères protégées (API Ad Selection) sont exécutées dans un TEE. Afin de mieux répondre aux besoins du cas d'utilisation de l'installation d'applications, les annonces candidates sont extraites en temps réel lors des enchères protégées. Cela diffère du cas d'utilisation du remarketing, dans lequel les annonces candidates sont connues avant l'enchère.

Cette proposition utilise un workflow de sélection d'annonces semblable à celui de la proposition Protected Audience. Certaines améliorations ont été apportées pour la prise en charge des installations d'applications. Pour répondre aux exigences informatiques liées à l'ingénierie des caractéristiques et à la sélection des annonces en temps réel, les enchères pour les annonces incitant à installer une application doivent être exécutées sur des services d'enchères exécutés dans des TEE. Lors d'enchères protégées sur l'appareil, il est impossible d'accéder à l'API Protected App Signals.

Illustration du workflow de sélection des annonces. — Workflow de sélection des annonces dans la Privacy Sandbox sur Android

Le processus de sélection des annonces se déroule comme suit :

Le SDK du vendeur envoie la charge utile chiffrée sur l'appareil des signaux de l'application protégée.
Le serveur du vendeur crée une configuration d'enchères et l'envoie au service d'enchères de confiance du vendeur, avec la charge utile chiffrée. Cette action conduit au lancement d'un workflow de sélection des annonces.
Le service d'enchères du vendeur transmet la charge utile aux serveurs interface des acheteurs de confiance participants.
Le service d'enchères de l'acheteur exécute la logique de sélection des annonces côté achat.
1. Exécution de la logique de récupération des annonces côté achat.
2. Exécution de la logique d'enchères côté achat.
La logique d'évaluation côté vente est exécutée.
L'annonce s'affiche et la création de rapports est lancée.

Lancer le workflow de sélection des annonces

Lorsqu'une application est prête à diffuser une annonce, le SDK de technologie publicitaire (généralement des SSP) lance le processus de sélection des annonces en envoyant toutes les données contextuelles pertinentes depuis l'éditeur et les charges utiles chiffrées par acheteur à inclure dans la demande à envoyer aux enchères protégées à l'aide de l'appel getAdSelectionData. C'est la même API que celle utilisée pour le processus de remarketing et décrite dans l'article Proposition d'intégration des enchères pour Android.

Pour lancer la sélection des annonces, le vendeur transmet une liste d'acheteurs participants et la charge utile chiffrée des signaux d'application protégés sur l'appareil. Grâce à ces informations, l'ad server côté vente prépare un SelectAdRequest pour son service SellerFrontEnd de confiance.

Le vendeur définit les éléments suivants :

La charge utile transmise par getAdSelectionData, qui contient les signaux d'application protégés.
Les signaux de contexte à l'aide des éléments suivants:
- auction_config.auction_signals (pour informations sur l'enchère)
- auction_config.seller_signals (pour connaître les signaux du vendeur
- auction_config.per_buyer_config["buyer"].buyer_signals (pour le des acheteurs signaux)
La liste des acheteurs figurant dans les enchères à l'aide du champ buyer_list.

Exécution de la logique de sélection des annonces côté achat

De manière générale, la logique personnalisée de l'acheteur utilise les données contextuelles fournies par l'éditeur et les signaux d'application protégés pour sélectionner et appliquer une enchère aux annonces pertinentes pour la demande d'annonce. La plate-forme permet aux acheteurs de réduire un grand nombre d'annonces disponibles aux plus pertinentes (les k premières), pour lesquelles les enchères sont calculées avant qu'elles ne soient renvoyées au vendeur pour la sélection finale.

Illustration de la logique d'exécution de la sélection des annonces côté achat. — Logique d'exécution de la sélection des annonces côté achat dans la Privacy Sandbox sur Android.

Avant d'enchérir, les acheteurs ont accès à un grand nombre d'annonces. Il serait trop lent de calculer une enchère pour chaque annonce. Les acheteurs doivent donc d'abord sélectionner les k premières annonces candidates parmi cet ensemble d'annonces. Les acheteurs doivent ensuite calculer les enchères pour chacune de ces k premières annonces candidates. Ces annonces et enchères sont alors renvoyées au vendeur, qui effectue la sélection finale.

Le service BuyerFrontEnd reçoit une demande d'annonce.
Le service BuyerFrontEnd envoie une demande au service d'enchères de l'acheteur. Le service d'enchères de l'acheteur exécute une fonction définie par l'utilisateur appelée prepareDataForAdRetrieval(), qui crée une demande pour obtenir les k premières annonces candidates à partir de la récupération des annonces de service. Le service d'enchères envoie cette demande à la récupération configurée le point de terminaison du serveur.
Le service de récupération d'annonces exécute la fonction définie par l'utilisateur getCandidateAds(), qui filtre jusqu'à l'ensemble des k premières annonces candidates, qui sont envoyées d'enchères.
Le service d'enchères de l'acheteur exécute la fonction définie par l'utilisateur generateBid(), qui sélectionne la meilleure annonce candidate, calcule son enchère, puis la renvoie au service BuyerFrontEnd.
Le service BuyerFrontEnd renvoie les annonces et les enchères au vendeur.

Ce flux comporte plusieurs informations importantes, notamment concernant la façon dont les éléments communiquent entre eux, et la façon dont la plate-forme propose des fonctionnalités telles que la possibilité d'effectuer des prédictions de machine learning afin de récupérer k premières annonces les plus importantes et à calculer leurs enchères.

Avant de passer en revue certains éléments, voici quelques remarques concernant l'architecture des TEE présentés dans le schéma ci-dessus.

Le service d'enchères de l'acheteur contient un service d'inférence en interne. Les technologies publicitaires peuvent importer des modèles de machine learning dans le service d'enchères de l'acheteur. Nous fournirons des API JavaScript aux technologies publicitaires pour leur permettre d'effectuer des prédictions ou de générer des représentations vectorielles continues inspirées de ces modèles à partir des fonctions définies par l'utilisateur qui s'exécutent sur le service d'enchères de l'acheteur. Contrairement au service de récupération d'annonces, le service d'enchères de l'acheteur ne dispose pas d'un service clés-valeurs permettant de stocker les métadonnées des annonces.

Le service de récupération d'annonces comprend un service clés-valeurs en interne. Les technologies publicitaires peuvent matérialiser des paires clé/valeur dans ce service à partir de leurs propres serveurs, en dehors de la limite de confidentialité. Nous fournirons une API JavaScript aux technologies publicitaires afin qu'elles puissent lire à partir de ce service clés-valeurs à partir des fonctions définies par l'utilisateur s'exécutant sur le service de récupération d'annonces. Contrairement au service d'enchères de l'acheteur, le service de récupération d'annonces ne comprend pas de service d'inférence.

L'une des grandes questions de cette conception est de savoir comment effectuer des prédictions sur le temps de récupération et la durée des enchères. Dans les deux cas, il peut s'agir d'une solution que l'on appelle factorisation de modèle.

Factorisation de modèle

La factorisation de modèle est une technique qui permet de diviser un modèle unique en plusieurs éléments, puis de les combiner afin d'en faire une prédiction. Dans le cas d'utilisation où une application est installée, les modèles exploitent souvent trois types de données : les données sur l'utilisateur, les données contextuelles et les données relatives aux annonces.

Dans le cas où il n'y a pas de factorisation de modèle, un seul modèle est entraîné sur les trois types de données. Dans le cas où il y a une factorisation de modèle, le modèle est décomposé en plusieurs parties. Seul l'élément contenant les données sur l'utilisateur est sensible. Autrement dit, seul le modèle avec l'élément utilisateur doit être exécuté dans la limite de confiance, sur le service d'inférence du service d'enchères de l'acheteur.

Cela rend la conception suivante possible :

Diviser le modèle en un élément privé (les données sur l'utilisateur) et en un ou plusieurs éléments non privés (les données contextuelles et les données relatives aux annonces).
Éventuellement, transmettre tout ou partie des éléments non privés en tant qu'arguments à une fonction définie par l'utilisateur devant effectuer des prédictions. Par exemple, les représentations vectorielles continues contextuelles transmis aux fonctions définies par l'utilisateur dans le fichier per_buyer_signals.
Les technologies publicitaires peuvent éventuellement créer des modèles pour des éléments non privés, puis matérialiser les représentations vectorielles continues issues de ces modèles dans le magasin de clés-valeurs du service de récupération d'annonces. Les fonctions définies par l'utilisateur sur le service de récupération d'annonces peuvent récupérer ces représentations vectorielles continues au moment de l'exécution.
Pour effectuer une prédiction lors d'une fonction définie par l'utilisateur, combiner des représentations vectorielles continues privées issues du service d'inférence avec des représentations vectorielles continues non privées issues des arguments de fonction définis par l'utilisateur ou du magasin de paires clé-valeur, en effectuant une opération telle qu'un produit par point. Voici la prédiction finale.

Nous pouvons maintenant examiner chaque fonction définie par l'utilisateur plus en détail. Nous vous expliquerons leur rôle, la façon dont elles s'intègrent et dont elles peuvent effectuer les prédictions nécessaires pour choisir les annonces les plus performantes et calculer leurs enchères.

UDF `prepareDataForAdRetrieval()`

prepareDataForAdRetrieval(), en cours d'exécution sur le service d'enchères de l'acheteur, est responsable de la création de la charge utile de la demande qui sera envoyée au service de récupération d'annonces pour extraire les k premières annonces candidates.

prepareDataForAdRetrieval() utilise les informations suivantes :

La charge utile par acheteur issue de getAdSelectionData. Cette charge utile contient les signaux d'application protégés.
Les signaux de contexte auction_signals (pour en savoir plus sur l'enchère) et buyer_signals (pour acheteurs signaux).

prepareDataForAdRetrieval() joue deux rôles :

Featurization : si une inférence en temps de récupération est nécessaire, elle transforme les signaux entrants en caractéristiques à utiliser lors des appels au service d'inférence afin d'obtenir des représentations vectorielles continues privées à des fins de récupération.
Calcul des représentations vectorielles continues privées à des fins de récupération: si des prédictions de récupération sont nécessaires, il effectue l'appel auprès du service d'inférence à l'aide de la méthode et obtient une représentation vectorielle continue privée pour prédire le temps de récupération.

La fonction prepareDataForAdRetrieval() renvoie :

Signaux d'application protégés : la charge utile des signaux sélectionnés par la technologie publicitaire.
Signaux propres aux enchères : signaux spécifiques à la plate-forme côté vente et informations contextuelles telles que auction_signals et per_buyer_signals (y compris les représentations vectorielles continues contextuelles) issues de SelectAdRequest Ceci est semblable à Protected Audiences.
Signaux supplémentaires : informations supplémentaires telles que des représentations vectorielles continues privées récupérées à partir du service d'inférence.

Cette requête est envoyée au service de récupération d'annonces, qui effectue la mise en correspondance des annonces candidates, puis exécute la fonction getCandidateAds() définie par l'utilisateur.

UDF `getCandidateAds()`

La fonction getCandidateAds() s'exécute sur le service de récupération des annonces. Elle reçoit la demande créée par la fonction prepareDataForAdRetrieval() du service d'enchères de l'acheteur. Le service exécute getCandidateAds(), qui extrait les k premières annonces candidates aux enchères en convertissant la demande en une série de demandes définies et d'extractions de données, et en exécutant une logique métier ainsi d'autres logiques de récupération personnalisées.

La fonction getCandidateAds() utilise les informations suivantes :

Signaux d'application protégés : la charge utile des signaux sélectionnés par la technologie publicitaire.
Signaux propres aux enchères : signaux spécifiques à la plate-forme côté vente et informations contextuelles telles que auction_signals et per_buyer_signals (y compris les représentations vectorielles continues contextuelles) issues de SelectAdRequest Ceci est semblable à Protected Audiences.
Signaux supplémentaires : informations supplémentaires telles que des représentations vectorielles continues privées récupérées à partir du service d'inférence.

La fonction getCandidateAds() effectue les opérations suivantes :

Extraction d'un ensemble initial d'annonces candidates : avant d'être extraites, les annonces candidates sont filtrées sur la base de critères de ciblage (langue, zone géographique, type d'annonce, taille de l'annonce ou encore budget).
Récupération de représentations vectorielles continues : si des représentations vectorielles continues du service clés-valeurs sont nécessaires pour effectuer une prédiction du temps de récupération pour la sélection des k premières annonces, elles doivent être récupérées à partir du service clés-valeurs.
Sélection des meilleures annonces candidates : calculer un score léger pour l'ensemble d'annonces candidates filtré en fonction des métadonnées d'annonce extraites du magasin de clés-valeurs et des informations envoyées par le service d'enchères de l'acheteur, puis choisir les k premières annonces candidates sur la base de ce score. Par exemple, le score peut correspondre à la probabilité d'installer une application grâce à l'annonce.
Récupération des représentations vectorielles continues d'enchères: si les représentations vectorielles continues du service clés-valeurs sont nécessaires au code d'enchère pour effectuer des prédictions sur la durée des enchères, il peut s'agir récupéré à partir du service clés-valeurs.

Notez que le score d'une annonce peut correspondre à la sortie d'un modèle de prédiction, qui prédit par exemple la probabilité qu'un utilisateur installe une application. Ce type de génération de scores implique une sorte de factorisation de modèle : comme la fonction getCandidateAds() s'exécute sur le service de récupération d'annonces, et que ce service ne dispose d'aucune d'inférence, les prédictions peuvent être générées en combinant les éléments suivants :

Les représentations vectorielles continues contextuelles transmises à l'aide des signaux propres aux enchères saisie.
Les représentations vectorielles continues privées transmises à l'aide de l'entrée d'une entrée de signaux supplémentaires.
Toutes les technologies publicitaires de représentations vectorielles continues non privées se sont matérialisées à partir de leurs serveurs dans le service clé-valeur du service de récupération d'annonces.

À noter que la fonction generateBid() définie par l'utilisateur qui s'exécute sur le service d'enchères de l'acheteur peut également appliquer son propre type de factorisation de modèle pour effectuer ses prédictions d'enchères. Si un service clés-valeurs a besoin de représentations vectorielles continues, celles doivent être extraites immédiatement.

La fonction getCandidateAds() renvoie :

Annonces candidates : k premières annonces à transmettre à la fonction generateBid(). Chaque annonce se compose des éléments suivants :
- URL de rendu : point de terminaison destiné à l'affichage de la création publicitaire.
- Métadonnées : métadonnées d'annonce spécifiques à une technologie publicitaire côté achat. Par exemple, ce peut inclure des informations sur la campagne publicitaire et des critères de ciblage comme la zone géographique et la langue. Les métadonnées peuvent inclure Les représentations vectorielles continues utilisées lorsque la factorisation de modèle est nécessaire pour exécuter l'inférence lors des enchères.
Signaux supplémentaires: le service de récupération d'annonces peut éventuellement inclure des informations supplémentaires, telles que des représentations vectorielles continues ou des signaux de spam, à utiliser dans le pays suivant : generateBid().

Nous étudions d'autres méthodes pour proposer des annonces à évaluer, notamment en les rendant disponibles dans l'appel SelectAdRequest. Ces annonces peuvent être récupérées à l'aide d'une demande d'enchère RTB. Notez que dans de tels cas, les annonces doivent être récupérées sans les signaux d'application protégés. Nous prévoyons de faire en sorte que les technologies publicitaires trouvent le meilleur compromis avant de choisir la bonne option, sur la base de la taille de la charge utile de la réponse, la latence, le coût et la disponibilité des signaux.

UDF `generateBid()`

Une fois que vous avez récupéré l'ensemble des annonces candidates ainsi que les représentations vectorielles continues, vous pouvez passer aux enchères, qui s'exécutent dans le service d'enchères de l'acheteur. Ce service exécute la fonction generateBid() fournie par l'acheteur, définie par l'acheteur, pour sélectionner les k premières annonces sur lesquelles enchérir, puis la renvoie avec son enchère.

La fonction generateBid() utilise les informations suivantes :

Les annonces candidates : les k premières annonces renvoyées par le service de récupération des annonces.
Signaux propres aux enchères : signaux spécifiques à la plate-forme côté vente et informations contextuelles telles que auction_signals et per_buyer_signals (y compris les représentations vectorielles continues contextuelles) issues de SelectAdRequest
Les signaux supplémentaires : informations supplémentaires utilisées au moment des enchères.

L'implémentation de la fonction generateBid() de l'acheteur joue trois rôles :

Featurization: transforme les signaux en caractéristiques utilisables pendant l'inférence.
Inférence : génère des prédictions à l'aide de modèles de machine learning pour calculer des valeurs telles que les taux de clics et de conversion prévus.
Enchères: combinaison de valeurs déduites avec d'autres données pour calculer le pour une annonce candidate.

La fonction generateBid() renvoie :

L'annonce candidate
Le montant calculé de l'enchère

À noter que la fonction generateBid() utilisée pour les annonces incitant à installer une application est différente de celle utilisée pour les annonces de remarketing.

Les sections suivantes expliquent plus en détail la featurization, l'inférence et les enchères.

Featurization

La fonction generateBid() peut préparer les signaux d'enchères en caractéristiques. Ces fonctionnalités pendant l'inférence, pour prédire des éléments tels que les clics les taux de conversion. Nous travaillons également sur des mécanismes de protection de la confidentialité permettant de transmettre certains de ces éléments dans le rapport afin de les utiliser dans le cadre de l'entraînement du modèle.

Inférence

Lors du calcul d'une enchère, il est courant d'effectuer des inférences sur un ou plusieurs modèles de machine learning. Par exemple, les calculs de l'eCPM effectif reposent souvent sur des modèles visant à prédire les taux de clics et de conversion.

Les clients peuvent fournir un certain nombre de modèles de machine learning en plus de l'implémentation de leur fonction generateBid(). Nous fournirons également une API JavaScript dans la fonction generateBid() afin que les clients puissent effectuer des inférences au moment de l'exécution.

L'inférence s'exécute sur le service d'enchères de l'acheteur. Cela peut affecter la latence et les coûts d'inférence, d'autant plus que les accélérateurs ne sont pas encore disponibles au sein des TEE. Certains clients se contenteront des modèles individuels qui s'exécutent sur le service d'enchères de l'acheteur. D'autres clients (par exemple, ceux qui possèdent des modèles très volumineux) envisageront peut-être des options telles que la factorisation de modèles pour minimiser les coûts d'inférence et la latence au moment de l'enchère.

De plus amples informations sur les capacités d'inférence, telles que les formats de modèle compatibles et les tailles maximales, seront fournies prochainement.

Implémenter la factorisation de modèle

Nous avons précédemment expliqué la factorisation de modèle. Au moment de l'enchère, l'approche spécifique est la suivante :

Diviser l'unique modèle en un élément privé (les données sur l'utilisateur) et en un ou plusieurs éléments non privés (les données contextuelles et les données relatives aux annonces).
Transmettre les éléments non privés à la fonction generateBid(). Celles-ci peuvent provenir de la fonction per_buyer_signals ou de représentations vectorielles continues que les technologies publicitaires calculent en externe, matérialisent dans le magasin de clés-valeurs du service de récupération, extraient au moment de la récupération et renvoient dans le cadre des signaux supplémentaires. Cela n'inclut pas les représentations vectorielles continues privées, car elles ne peuvent pas provenir de l'extérieur de la limite de confidentialité.
Dans la fonction generateBid() :
1. Effectuer une inférence sur des modèles pour obtenir des représentations vectorielles continues d'utilisateurs privées
2. Combiner des représentations vectorielles continues d'utilisateurs privées avec des représentations vectorielles continues contextuelles issues de la fonction per_buyer_signals ou d'annonces non privées et de représentations vectorielles continues contextuelles du service de récupération à l'aide d'une opération telle qu'un produit par point. Il s'agit de la et la prédiction finale pour calculer les enchères.

Cette approche permet d'effectuer des inférences au moment des enchères sur des modèles qui seraient autrement trop volumineux ou trop longs à exécuter sur le service d'enchères de l'acheteur.

Logique d'évaluation côté vente

À ce stade, les annonces dont les enchères proviennent de tous les acheteurs participants sont évaluées. La sortie de la fonction generateBid() est transmise au service d'enchères du vendeur pour exécuter la fonction scoreAd(). La fonction scoreAd() ne prend en compte qu'une seule annonce à la fois. Sur la base de ce score, le vendeur choisit l'annonce gagnante à renvoyer sur l'appareil afin de l'afficher.

La logique d'évaluation est la même que celle utilisée pour le flux de remarketing de l'API Protected Audience. Elle permet de sélectionner une annonce gagnante parmi les candidates (annonces de remarketing et annonces incitant à installer une application). La fonction est appelée une fois pour chaque annonce candidate envoyée dans Protected Auction. Pour en savoir plus, visionnez la vidéo d'explication sur le système d'enchères.

Exécution du code de sélection des annonces

Dans la proposition, le code de sélection des annonces pour l'installation de l'application est spécifié dans le même que pour le flux de remarketing Protected Audience. Pour en savoir plus, consultez les Configuration des enchères : Le code d'enchère sera Disponible au même emplacement Cloud Storage que celui utilisé pour le remarketing.

Rapports

Cette proposition utilise les mêmes API de reporting que les rapports Protected Audience d'assistance (par exemple, reportImpression(), qui déclenche l'affichage envoyer des rapports sur les vendeurs et les acheteurs).

Un cas d'utilisation courant de la création de rapports côté achat consiste à obtenir les données d'entraînement pour les modèles utilisés lors de la sélection des annonces. En plus des API existantes, la plate-forme fournit un mécanisme spécifique pour la sortie des données au niveau de l'événement depuis le aux serveurs de technologie publicitaire. Ces charges utiles de sortie peuvent inclure certains données.

À long terme, nous étudions des solutions protégeant la confidentialité pour résoudre entraîner un modèle avec les données utilisées dans les enchères protégées, sans envoyer d'événements au niveau de l'événement des données utilisateur en dehors des services exécutés sur des TEE. Nous vous fournirons des informations supplémentaires dans une prochaine mise à jour.

À court terme, nous fournirons un moyen temporaire d'évacuer les données avec bruit depuis generateBid() Notre proposition initiale à ce sujet est présentée ci-dessous, et nous la ferons évoluer (y compris d'éventuelles modifications susceptibles d'affecter la rétrocompatibilité) en réponse aux commentaires.

Techniquement, voici comment cela fonctionne:

Les technologies publicitaires définissent un schéma pour les données qu'elles souhaitent transmettre.
Dans generateBid(), ils créent la charge utile de sortie souhaitée.
La plate-forme valide la charge utile de sortie par rapport au schéma et applique les limites de taille.
La plate-forme ajoute du bruit à la charge utile de sortie.
La charge utile de sortie est incluse dans le rapport gagnant au format filaire, reçu sur serveurs de technologie publicitaire, décodés et utilisés pour l'entraînement des modèles.

Définir le schéma des charges utiles de sortie

Pour que la plate-forme applique des exigences de confidentialité en constante évolution, les charges utiles de sortie doivent être structuré de façon à ce que la plate-forme soit compréhensible. Les technologies publicitaires définiront la structure de leurs charges utiles de sortie en fournissant un fichier JSON de schéma. Ce schéma seront traitées par la plate-forme et resteront confidentielles et services de mise aux enchères utilisant les mêmes mécanismes que les autres ressources de technologie publicitaire comme les UDF et les modèles.

Nous vous fournirons alors un fichier CDDL qui définit la structure de ce fichier JSON. La CDDL contient un ensemble de types de caractéristiques compatibles (par exemple, (booléens, entiers, buckets, etc.). Le fichier CDDL et le le schéma fourni sera versionné.

Par exemple, une charge utile de sortie constituée d'une seule caractéristique booléenne suivi d'une caractéristique de bucket de taille 2 ressemblerait à ceci:

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

Pour en savoir plus sur l'ensemble des types de caractéristiques compatibles, consultez GitHub.

Créer des charges utiles de sortie dans `generateBid()`

Tous les signaux d'application protégés pour un acheteur donné sont disponibles UDF generateBid(). Une fois ces éléments présentés, les technologies publicitaires créent leur charge utile JSON. Cette charge utile de sortie sera incluse dans le rapport gagnant de l'acheteur pour la transmission aux serveurs de technologie publicitaire.

Une alternative à cette conception consiste à effectuer le calcul du vecteur de sortie reportWin() au lieu de generateBid(). Il existe des compromis pour et nous finaliserons cette décision en réponse aux commentaires du secteur.

Valider la charge utile de sortie

La plate-forme validera toute charge utile de sortie créée par la technologie publicitaire. Validation garantit que les valeurs des caractéristiques sont valides pour leur type, que les contraintes de taille sont respectées, et que des individus malveillants ne tentent pas de contourner les paramètres de confidentialité d'empaqueter des informations supplémentaires dans leurs charges utiles de sortie.

Si une charge utile de sortie n'est pas valide, elle est supprimée sans notification des entrées. envoyé au rapport gagnant. En effet, nous ne voulons pas fournir de service de débogage des informations à tout acteur malveillant tentant de contourner la validation.

Nous fournirons une API JavaScript aux technologies publicitaires afin de garantir la charge utile de sortie qu'elles create dans generateBid() passera avec succès la validation de la plate-forme:

validate(payload, schema)

Cette API JavaScript est entièrement conçue pour permettre aux appelants de déterminer si une charge utile particulière est validé par la plate-forme. La validation réelle doit être effectuée dans la plate-forme pour pour vous protéger contre les UDF generateBid() malveillantes.

Bruit la charge utile de sortie

La plate-forme bruit les charges utiles de sortie avant de les inclure dans le rapport gagnant. Le seuil de bruit initial est de 1%, et cette valeur est susceptible d'évoluer au fil du temps. La plate-forme ne fournit aucune indication si une charge utile de sortie particulière a fait l'objet d'un bruit.

La méthode de bruit est la suivante:

La plate-forme charge la définition de schéma pour la charge utile de sortie.
1% des charges utiles de sortie seront choisies pour le bruit.
Si aucune charge utile de sortie n'est choisie, l'intégralité de la valeur d'origine est conservée.
Si une charge utile de sortie est choisie, la valeur de chaque caractéristique est remplacée par une une valeur aléatoire valide pour ce type de caractéristique (par exemple, 0 ou 1 pour une caractéristique booléenne).

Transmettre, recevoir et décoder la charge utile de sortie pour l'entraînement du modèle

La charge utile de sortie validée et avec bruit sera incluse dans les arguments de reportWin(), et transmis aux serveurs de technologie publicitaire de l'acheteur, en dehors de la confidentialité pour l'entraînement du modèle. La charge utile de sortie est dans son format filaire.

Détails sur le format de communication pour tous les types de caractéristiques et la charge utile de sortie sont disponibles sur GitHub.

Déterminer la taille de la charge utile de sortie

La taille de la charge utile de sortie en bits équilibre l'utilité et la minimisation des données. Nous collaborerons avec le secteur pour déterminer la taille appropriée et l'expérimentation. Pendant que nous effectuons ces tests, nous de sortie sans limite de taille de bits. Ces données de sortie supplémentaires La limite de taille sera supprimée une fois les tests terminés.

La méthode permettant de déterminer la taille est la suivante:

Dans un premier temps, nous accepterons deux charges utiles de sortie dans generateBid(): <ph type="x-smartling-placeholder">
1. egressPayload: charge utile de sortie limitée de taille décrite jusqu'à présent dans ce document. Au départ, la taille de la charge utile de sortie sera de 0 bit (ce qui signifie qu'il sera toujours supprimé lors de la validation).
2. temporaryUnlimitedEgressPayload: sortie temporaire sans taille limitée pour les tests de taille. La mise en forme, la création et le traitement de cette charge utile de sortie utilise les mêmes mécanismes que egressPayload.
Chacune de ces charges utiles de sortie aura son propre fichier JSON de schéma: egress_payload_schema.json et temporary_egress_payload_schema.json.
Nous fournissons un protocole de test et un ensemble de métriques permettant de déterminer le modèle. utilitaire avec différentes tailles de charge utile de sortie (par exemple, 5, 10, ... bits).
Sur la base des résultats du test, nous déterminons la taille de la charge utile de sortie avec la les bons compromis en matière d’utilité et de confidentialité.
Nous définissons la taille de egressPayload de 0 bit à la nouvelle taille.
Après une période de migration définie, nous supprimons temporaryUnlimitedEgressPayload, ne laissant que egressPayload avec sa nouvelle taille.

Nous étudions d'autres garde-fous techniques pour gérer ce changement (par exemple, en chiffrant egressPayload lorsque sa taille passe de 0 bit). Ces détails, ainsi que le calendrier du test et la suppression de temporaryUnlimitedEgressPayload : sera inclus dans une mise à jour ultérieure.

Nous verrons ensuite un protocole de test possible pour finaliser la taille egressPayload Notre objectif est de collaborer avec l'industrie pour trouver un équilibre l'utilité et la minimisation des données. L'artefact que ces tests produira est un graphique où l'axe des x est la taille de la charge utile d'entraînement en bits L'axe des y est le pourcentage de revenus générés par un modèle de cette taille par rapport jusqu'à une taille de référence illimitée.

Supposons que nous entraînons un modèle pInstall et que nos sources de données d'entraînement sont nos journaux et le contenu des temporaryUnlimitedegressPayload que nous que nous recevrons lorsque nous remportons les enchères. Le protocole pour les technologies publicitaires implique d'abord tests:

Déterminer l'architecture des modèles qu'ils utiliseront avec l'application protégée Signaux Par exemple, ils devront déterminer s'ils vont ou non Utilisez la factorisation de modèle.
Définir une métrique pour mesurer la qualité du modèle. Les métriques suggérées sont la perte d'AUC et la perte logistique.
Définir l'ensemble des caractéristiques qu'elles utiliseront lors de l'entraînement du modèle
À l'aide de cette architecture de modèle, de cette métrique de qualité et de cet ensemble de caractéristiques d'entraînement, effectuer des études d'ablation afin de déterminer l'utilité de chaque bit qu'ils souhaitent utiliser dans PAS. Le protocole suggéré pour l'étude d'ablation est: <ph type="x-smartling-placeholder">
1. entraîner le modèle avec toutes les caractéristiques et mesurer son utilité ; c'est le à des fins de comparaison.
2. Pour chaque caractéristique utilisée pour produire la référence, entraînez le modèle avec toutes les fonctionnalités, à l'exception de celle-ci.
3. Mesurez l'utilité obtenue. Diviser le delta par la taille de l'élément géographique en bits ; il s'agit de l'utilitaire par bit attendu pour cette fonctionnalité.
Déterminez la taille des charges utiles d'entraînement qui vous intéressent pour les tests. Mer suggérer [5, 10, 15, ..., size_of_all_training_features_for_baseline] bits. Chacun de ces éléments représente une taille possible pour egressPayload que le que le test va évaluer.
Pour chaque taille possible, sélectionnez un ensemble de caractéristiques inférieures ou égales à celle-ci qui maximisent l'utilité par bit, à l'aide des résultats de l'étude d'ablation.
Entraînez un modèle pour chaque taille possible et évaluez son utilité en tant que pourcentage d'utilité du modèle de référence entraîné sur toutes les caractéristiques.
Représenter les résultats sur un graphique où l'axe des x représente la taille de l'entraînement en bits, et l'axe des y est le pourcentage de revenu généré par par rapport à la référence.

Ensuite, les technologies publicitaires peuvent répéter les étapes 5 à 8 des tests de trafic en temps réel, à l'aide de la fonctionnalité données envoyées via temporaryUnlimitedEgressPayload. Les technologies publicitaires peuvent choisir de partager les résultats des tests sur le trafic en temps réel et hors connexion avec la Privacy Sandbox. pour décider de la taille de egressPayload.

Calendrier de ces tests et calendrier de définition de la taille de egressPayload par rapport à la valeur résultante, n'entre pas dans le cadre de ce document. et nous les mettrons à jour plus tard.

Mesures de protection des données

Nous appliquerons un certain nombre de protections aux données sortantes, y compris les suivantes:

egressPayload et temporaryUnlimitedEgressPayload seront tous les deux bruités.
Pour la minimisation et la protection des données, temporaryUnlimitedEgressPayload va ne sera disponible que pendant la durée des tests de taille, Déterminez la taille correcte pour egressPayload.

Autorisations

Contrôle des utilisateurs

Cette proposition vise à permettre aux utilisateurs de voir la liste des applications installées ayant stocké au moins un signal d'application protégé ou une audience personnalisée.
Les utilisateurs peuvent bloquer et supprimer des applications de cette liste. Le blocage et la suppression des applications ont les conséquences suivantes :
- Efface tous les signaux d'application protégés et les audiences personnalisées associés à l'application.
- Les applications ne pourront plus stocker de nouveaux signaux d'application protégés ni de nouvelles audiences personnalisées.
Les utilisateurs auront la possibilité de réinitialiser complètement les signaux d'application et l'API Protected Audience. Dans ce cas, toute application protégée existante Les signaux et les audiences personnalisées sont effacés sur l'appareil.
Les utilisateurs auront la possibilité de désactiver complètement la Privacy Sandbox sur Android, ce qui inclut les API Protected App Signals et Protected Audience. Dans ce cas, les API Protected Audience et Protected App Signals renvoient un message d'exception standard : SECURITY_EXCEPTION.

Autorisations et contrôle de l'application

Cette proposition vise à permettre aux applications de contrôler leurs signaux d'application protégés :

Une application peut gérer ses associations à l'aide de signaux d'application protégés.
Une appli peut accorder à des plates-formes ad tech tierces des autorisations pour gérer d'applications protégées en son nom.

Contrôle de la plate-forme ad tech

Cette proposition décrit les moyens permettant aux technologies publicitaires de contrôler leurs signaux d'application protégés :

Toutes les technologies publicitaires doivent s'inscrire à la Privacy Sandbox et fournir un domaine "site" ou "origine" qui correspond à toutes les URL des signaux d'application protégés.
Les technologies publicitaires peuvent s'associer à des applications ou des SDK pour fournir des jetons de validation qui permettent de vérifier la création de signaux d'application protégés. Lorsque ce processus est délégué à un partenaire, la création d'un signal d'application protégé peut être configurée pour exiger la confirmation de la technologie publicitaire.