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 et aux attestations de la Privacy Sandbox. Pour en savoir plus sur les attestations, veuillez consulter le lien fourni. Les futures mises à jour de cette proposition décriront les conditions requises 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énement définis pour chaque application, tels que les installations d'application, les premières ouvertures, les actions de l'utilisateur (niveaux de jeu, réussites), les activités d'achat ou le temps passé dans l'application. Les signaux sont écrits et stockés sur l'appareil pour éviter les fuites de données. Ils ne sont mis à la disposition de la logique de technologie publicitaire qui a stocké le signal donné lors d'enchères protégées exécutées dans un environnement sécurisé.
API Ad Selection: cette API fournit une API permettant de configurer et d'exécuter une enchère protégée exécutée 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 des enchères et procèdent à l'évaluation pour choisir une annonce "gagnante" à l'aide des signaux d'application protégés et 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 les signaux d'application protégés 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 les signaux en stockant des événements d'application définis par les technologies publicitaires pour diffuser des annonces pertinentes à l'aide de l'API Protected App Signals. Ces événements sont stockés dans un espace de stockage protégé sur l'appareil, comme les audiences personnalisées, et sont chiffrés avant d'être envoyés depuis l'appareil. Ainsi, seuls les services d'enchères et de mise aux enchères exécutés dans des environnements d'exécution fiables disposant du contrôle de sécurité et de confidentialité approprié peuvent les déchiffrer pour les enchères et l'évaluation des 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 d'arrière-plan Android exécute cette logique pour effectuer un encodage sur l'appareil afin de générer une charge utile de signaux d'application protégés, qui peuvent ensuite être utilisés en temps réel pour la sélection des annonces lors d'une enchère protégée. La charge utile est stockée de manière sécurisée sur l'appareil jusqu'à son envoi pour une mise aux enchères.
Sélection des annonces: pour sélectionner des annonces pertinentes pour l'utilisateur, les SDK de vendeurs envoient une charge utile chiffrée de signaux d'application protégés et configurent une enchère protégée. Lors de la mise aux enchères, la logique personnalisée de l'acheteur prépare les signaux de l'application protégée avec les données contextuelles fournies par l'éditeur (données généralement partagées dans une demande d'annonce Open-RTB) pour concevoir les fonctionnalités destinées à la sélection des annonces (récupération des annonces, inférence et génération d'enchères). Comme pour Protected Audience, les acheteurs envoient les annonces au vendeur pour l'évaluation finale lors d'enchères protégées.
- Récupération des annonces: les acheteurs utilisent des signaux d'application protégés et des données contextuelles fournies par l'éditeur pour extraire des fonctionnalités pertinentes pour les centres d'intérêt de l'utilisateur. Ces fonctionnalités permettent de faire correspondre les annonces qui répondent aux critères de ciblage. Les annonces ne respectant pas le budget sont filtrées. Les k annonces les plus performantes 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: la logique d'évaluation personnalisée des vendeurs évalue les annonces envoyées par les Acheteurs participants et choisit une annonce gagnante à renvoyer à l'application pour être affichée.
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
Sélection	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 le SDK intégré peut stocker ou supprimer des signaux d'application protégés définis par des technologies publicitaires en fonction de l'activité de l'utilisateur, comme les ouvertures de l'application, les réussites, l'activité d'achat ou le temps passé 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és avant d'être envoyés sur l'appareil. Ainsi, seuls les services d'enchères et de mise aux enchères exécutés dans des environnements d'exécution sécurisés avec des annonces et des contrôles de confidentialité appropriés peuvent les déchiffrer pour les enchères et l'évaluation. Comme pour l'API Custom Audience, les signaux stockés sur un appareil ne peuvent pas être lus ni inspectés par les applications ou les SDK. Il n'existe pas d'API pour lire les valeurs des signaux, et les API sont conçues pour éviter les fuites 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 extraction plus poussée des caractéristiques en temps réel lors d'enchères protégées exécuté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() utilise un URI et récupère la liste des mises à jour des signaux. Par exemple, fetchSignalUpdates() envoie une requête GET à l'URI donné pour récupérer la liste des mises à jour à appliquer au stockage local des signaux. Le point de terminaison de l'URL, qui appartient à l'acheteur, répond avec une liste JSON de commandes.

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 un ID de test pour l'utilisateur donné et éviter de le remplacer s'il a déjà été 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 spécifie le nombre maximal de signaux dans la série temporelle. Si le nombre maximal est dépassé, les éléments précédents sont supprimés. Si la clé contient une valeur scalaire, elle 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 la requête d'extraction et au répondant à la requête (le "site" ou l'"origine" d'une technologie publicitaire enregistrée), ainsi qu'à 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 une SSP) lance le workflow de sélection des annonces en envoyant toutes les données contextuelles pertinentes de l'éditeur et des charges utiles chiffrées par acheteur à inclure dans la demande d'envoi aux enchères protégées à l'aide de l'appel getAdSelectionData. Il s'agit de la même API que celle utilisée pour le workflow de remarketing et décrite dans la proposition Intégration des enchères et 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 utilisant:
- auction_config.auction_signals (pour en savoir plus sur l'enchère)
- auction_config.seller_signals (pour les signaux du vendeur)
- auction_config.per_buyer_config["buyer"].buyer_signals (pour les signaux des acheteurs)
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 d'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 requête 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 requête pour obtenir les k meilleurs candidats à partir du service de récupération des annonces. Le service d'enchères envoie cette requête au point de terminaison du serveur de récupération configuré.
Le service de récupération d'annonces exécute la fonction getCandidateAds() définie par l'utilisateur, qui filtre jusqu'à l'ensemble des k annonces candidates qui sont envoyées au service d'enchères de l'acheteur.
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 sont transmises aux UDF dans le 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 champs auction_signals (pour en savoir plus sur l'enchère) et buyer_signals (pour les signaux des acheteurs) des signaux de contexte.

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.
Calcule des représentations vectorielles continues privées pour la récupération: si des prédictions de récupération sont nécessaires, le service d'inférence est appelé à l'aide des caractéristiques ci-dessus et obtient une représentation vectorielle continue privée pour les prédictions 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 des enchères: si des représentations vectorielles continues du service clés-valeurs sont nécessaires au code d'enchères pour effectuer des prédictions au moment des enchères, elles peuvent être récupérées depuis le 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 :

Représentations vectorielles continues transmises à l'aide de l'entrée de signaux spécifiques aux enchères.
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 vers 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. Il peut s'agir d'informations sur la campagne publicitaire et de critères de ciblage tels que la zone géographique et la langue. Les métadonnées peuvent inclure des représentations vectorielles continues facultatives utilisées lorsque la factorisation du modèle est nécessaire pour exécuter l'inférence lors des enchères.
Signaux supplémentaires: le service de récupération des annonces peut éventuellement inclure des informations supplémentaires, telles que des représentations vectorielles continues ou des signaux de spam supplémentaires à utiliser dans 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 :

Féaturisation: transforme les signaux en caractéristiques à utiliser lors de 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: combine les valeurs déduites avec d'autres entrées pour calculer l'enchère d'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 peuvent être utilisées lors de l'inférence pour prédire des éléments tels que les taux de clics et 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 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 prédiction finale qui peut être utilisée 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 d'annonces pour l'installation d'une application est spécifié de la même manière que pour le flux de remarketing Protected Audience. Pour en savoir plus, consultez Configuration des enchères et des enchères. Le code d'enchère sera disponible dans le même emplacement de stockage cloud que celui utilisé pour le remarketing.

Utilisation des rapports

Cette proposition utilise les mêmes API de création de rapports que la proposition de création de rapports Protected Audience (par exemple, reportImpression(), qui déclenche l'envoi de rapports sur les vendeurs et les acheteurs via la plate-forme).

Un cas d'utilisation courant de la création de rapports côté achat consiste à obtenir les données d'entraînement des 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 des événements de la plate-forme vers les serveurs de technologie publicitaire. Ces charges utiles de sortie peuvent inclure certaines données utilisateur.

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

À court terme, nous fournirons un moyen temporaire de sortir des données avec bruit de generateBid(). Vous trouverez ci-dessous notre proposition initiale, et nous allons la faire évoluer (y compris d'éventuelles modifications susceptibles d'affecter la rétrocompatibilité) en réponse aux commentaires du secteur.

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 des 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 sous forme de communication, reçue sur les serveurs de technologie publicitaire, décodée et utilisée pour l'entraînement du modèle.

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

Pour que la plate-forme applique des exigences en constante évolution en termes de confidentialité, les charges utiles de sortie doivent être structurées de manière à ce qu'elle puisse être compréhensible par la plate-forme. Les technologies publicitaires définiront la structure de leurs charges utiles de sortie en fournissant un fichier JSON de schéma. Ce schéma sera traité par la plate-forme et restera confidentiel par les services d'enchères et de mise aux enchères à l'aide des mêmes mécanismes que les autres ressources ad tech, telles que les UDF et les modèles.

Nous fournirons un fichier CDDL qui définit la structure de ce fichier JSON. Le fichier CDDL comprend un ensemble de types de caractéristiques compatibles (par exemple, des caractéristiques booléennes, des entiers, des buckets, etc.). Le fichier CDDL et le schéma fourni auront tous deux des versions gérées.

Par exemple, une charge utile de sortie composée d'une seule caractéristique booléenne suivie 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
        }
      ]
    }
  ]
}

Des informations détaillées sur les types de fonctionnalités compatibles sont disponibles sur GitHub.

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

Tous les signaux d'application protégés pour un acheteur donné sont disponibles pour sa UDF generateBid(). Une fois ces fonctionnalités activées, les technologies publicitaires créent leur charge utile au format JSON. Cette charge utile de sortie sera incluse dans le rapport sur les gains de l'acheteur pour être transmise aux serveurs de technologie publicitaire.

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

Valider la charge utile de sortie

La plate-forme valide toute charge utile de sortie créée par la technologie publicitaire. La validation garantit que les valeurs des caractéristiques sont valides pour leur type, que les contraintes de taille sont respectées et que les acteurs malveillants ne tentent pas de déjouer les contrôles de confidentialité en insérant des informations supplémentaires dans leurs charges utiles de sortie.

Si une charge utile de sortie n'est pas valide, elle est silencieusement supprimée des entrées envoyées au rapport sur les victoires. En effet, nous ne voulons pas fournir d'informations de débogage aux acteurs malintentionnés qui tentent de contourner la validation.

Nous fournirons aux technologies publicitaires une API JavaScript pour s'assurer que la charge utile de sortie qu'elles créent dans generateBid() réussira la validation de la plate-forme:

validate(payload, schema)

Cette API JavaScript permet uniquement aux appelants de déterminer si une charge utile particulière sera validée pour la plate-forme. Une validation réelle doit être effectuée sur la plate-forme pour se prémunir contre les UDF generateBid() malveillantes.

Bruit la charge utile de sortie

La plate-forme affiche du bruit sur les charges utiles de sortie avant de les inclure dans le rapport d'attribution. Le seuil de bruit initial sera de 1 %. Cette valeur peut é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 ou non.

La méthode de bruit est la suivante:

La plate-forme charge la définition du schéma pour la charge utile de sortie.
1% des charges utiles de sortie sera choisie 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 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 avec bruit et validée est incluse dans les arguments de reportWin() et transmise aux serveurs de technologie publicitaire de l'acheteur en dehors des limites de confidentialité pour l'entraînement du modèle. La charge utile de sortie sera dans son format de communication.

Des détails sur le format de communication pour tous les types de fonctionnalités et sur la charge utile de sortie elle-même sont disponibles sur GitHub.

Déterminer la taille de la charge utile de sortie

La taille en bits de la charge utile de sortie équilibre l'utilité et la minimisation des données. Nous collaborerons avec les acteurs du secteur pour déterminer la taille appropriée par le biais d'expérimentations. Pendant que nous exécutons ces tests, nous produisons temporairement des données de sortie sans limite de taille. Ces données de sortie supplémentaires, sans limitation de taille, seront supprimées une fois les tests terminés.

La méthode pour déterminer la taille est la suivante:

Dans un premier temps, nous accepterons deux charges utiles de sortie dans generateBid() :
1. egressPayload: charge utile de sortie à taille limitée que nous avons décrite dans ce document. Au départ, la taille de cette charge utile de sortie sera de 0 bit (ce qui signifie qu'elle sera toujours supprimée lors de la validation).
2. temporaryUnlimitedEgressPayload: charge utile de sortie temporaire illimitée pour les tests de taille. Le formatage, la création et le traitement de cette charge utile de sortie utilisent les mêmes mécanismes que egressPayload.
Chacune de ces charges utiles de sortie possède 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 l'utilité du modèle 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 en faisant les bons compromis en termes 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 pour ne conserver que egressPayload avec sa nouvelle taille.

Nous étudions d'autres garde-fous techniques pour gérer cette modification (par exemple, chiffrer egressPayload lorsque nous augmentons sa taille de 0 bit). Ces détails, ainsi que d'autres informations telles que le protocole du test, la date et l'heure du test et le calendrier de suppression de temporaryUnlimitedEgressPayload, seront inclus dans une mise à jour ultérieure.

Mesures de protection des données

Nous allons appliquer un certain nombre de protections aux données sortantes, parmi lesquelles:

egressPayload et temporaryUnlimitedEgressPayload feront l'objet d'un bruit.
Pour la minimisation et la protection des données, temporaryUnlimitedEgressPayload ne sera disponible que pendant les tests de taille, pendant lesquels nous déterminerons 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, tous les signaux d'application protégée et les audiences personnalisées existants sur l'appareil sont effacés.
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 application peut accorder à des plates-formes ad tech tierces des autorisations permettant de gérer les signaux d'application protégée 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 permettant de valider 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.