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

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 d'attestation 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 :

1. 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 des signaux d'événement par application définis par l'utilisateur, tels que les installations d'applications, les premières ouvertures, les actions des utilisateurs (niveaux dans le jeu, succès), 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 et ne sont mis à la disposition que 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é.
2. API Ad Selection: 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 les enchères et effectuent un scoring 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.

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 des événements d'application définis par la technologie publicitaire 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, semblable aux audiences personnalisées, et sont chiffrés avant d'être envoyés depuis l'appareil. Ainsi, seuls les services d'enchères qui s'exécutent dans des environnements d'exécution sécurisés avec le contrôle de sécurité et de confidentialité appropriés 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 en 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 peut être utilisée ultérieurement 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'à ce qu'elle soit mise aux enchères.
• Sélection des annonces: afin de sélectionner des annonces qui soient pertinentes pour l'utilisateur, les SDK du vendeur envoient une charge utile chiffrée provenant de l'API Protected App Signals et configure une enchère protégée. Dans l'enchère, la logique personnalisée de l'acheteur prépare l'API Protected App Signals ainsi que les données contextuelles fournies par l'éditeur (données généralement partagées dans une demande d'annonce Open RTB) afin de mettre au point des fonctionnalités destinées à sélectionner les annonces (récupération d'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 l'API Protected App Signals ainsi que des données contextuelles fournies par l'éditeur pour mettre au point des fonctionnalités correspondant aux centres d'intérêt de l'utilisateur. Ces fonctionnalités sont utilisées pour proposer des 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: la logique d'évaluation personnalisée des vendeurs attribue un score aux annonces envoyées par les acheteurs participants et choisit une annonce gagnante, qui sera renvoyée à l'application pour y ê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

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 les technologies publicitaires en fonction de l'activité de l'utilisateur, comme les ouvertures d'applications, les succès, 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 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 sécurisés avec un contrôle de la sécurité et de la confidentialité appropriés peuvent les déchiffrer pour les enchères et l'évaluation des annonces. 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 capable de lire les valeurs des signaux, mais elles sont conçues pour éviter la fuite de ces 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 à d'autres extractions de 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() prend un URI et récupère la liste des mises à jour du signal. Par exemple, fetchSignalUpdates() envoie une demande 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 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 un identifiant 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 indique le nombre maximal de signaux pouvant figurer au sein de 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 de récupération, au répondeur de 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.

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

1. Le SDK du vendeur envoie la charge utile chiffrée sur l'appareil des signaux de l'application protégée.
2. 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.
3. Le service d'enchères du vendeur transmet la charge utile aux serveurs interface des acheteurs de confiance participants.
4. 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.
5. La logique d'évaluation côté vente est exécutée.
6. 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 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 requête à envoyer à Protected Auction via l'appel getAdSelectionData. Il s'agit de la même API que celle utilisée pour le workflow de remarketing présentée dans la proposition Bidding And Auction Integration for Android (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 obtenir des 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 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.

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.

1. Le service BuyerFrontEnd reçoit une demande d'annonce.
2. 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 permettant d'obtenir les k premières annonces candidates à partir du service de récupération des annonces. Le service d'enchères envoie cette demande au point de terminaison du serveur de récupération configuré.
3. Le service de récupération d'annonces exécute la fonction définie par l'utilisateur getCandidateAds(), qui filtre pour n'afficher que l'ensemble des k premières annonces candidates, qui sont envoyées au service d'enchères de l'acheteur.
4. 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.
5. 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 :

1. 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).
2. É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 fonctions définies par l'utilisateur dans le per_buyer_signals.
3. 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.
4. 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.

Fonction définie par l'utilisateur 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.
• auction_signals des signaux de contexte (pour en savoir plus sur l'enchère) et buyer_signals (pour les champs des signaux des acheteurs).

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 embeddings privés à des fins de récupération: si des prédictions de récupération sont nécessaires, le service d'inférence est appelé à l'aide des fonctionnalités citées ci-dessus et obtient un embedding privé 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.

Fonction définie par l'utilisateur 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 :

1. 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).
2. 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.
3. 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.
4. Extraction des représentations vectorielles continues d'enchères: si le code d'enchères a besoin des représentations vectorielles continues du service clés-valeurs pour effectuer des prédictions au moment de l'enchère, elles peuvent être récupérées à 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 :

• Représentations vectorielles continues contextuelles transmises à l'aide de l'entrée de signaux propres 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 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. Elles sont 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 d'annonces peut éventuellement inclure des informations supplémentaires, telles que des représentations vectorielles continues ou des signaux de spam, à 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.

Fonction définie par l'utilisateur 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 afin de 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 :

1. 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).
2. 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é.
3. 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 prédiction finale. Celle-ci 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 des annonces pour l'installation de l'application est indiqué de la même manière que pour le flux de remarketing Protected Audience. Pour en savoir plus, consultez la section Bidding and Auction configuration (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 création de rapports que la proposition de création de rapports Protected Audience (par exemple, reportImpression(), qui déclenche l'envoi de rapports au vendeur et à l'acheteur par la plate-forme).

Un cas d'utilisation courant des rapports côté acheteur 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 fournira un mécanisme spécifique pour l'exportation 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 l'entraînement de modèles avec les 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 des informations supplémentaires prochainement.

À court terme, nous allons fournir un moyen temporaire d'extraire des données bruitées de generateBid(). Vous trouverez ci-dessous notre proposition initiale. Nous l'adapterons (y compris les modifications incompatibles avec les versions antérieures) en fonction des commentaires du secteur.

Techniquement, voici comment cela fonctionne:

1. Les technologies publicitaires définissent un schéma pour les données qu'elles souhaitent transmettre.
2. Dans generateBid(), il crée la charge utile de sortie souhaitée.
3. La plate-forme valide la charge utile de sortie par rapport au schéma et applique des limites de taille.
4. La plate-forme ajoute du bruit à la charge utile de sortie.
5. La charge utile de sortie est incluse dans le rapport "Victoires" au format filaire, 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 puisse appliquer les exigences de confidentialité en constante évolution, les charges utiles de sortie doivent être structurées de manière à être compréhensibles 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 sera gardé 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, comme les fonctions définies par l'utilisateur et les modèles.

Nous vous fournirons un fichier CDDL qui définit la structure de ce fichier JSON. Le fichier CDDL inclura un ensemble de types de fonctionnalités compatibles (par exemple, des fonctionnalités booléennes, des entiers, des buckets, etc.). Le fichier CDDL et le schéma fourni seront versionnés.

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 deux se présente comme suit:

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

Vous trouverez des informations sur l'ensemble des types d'éléments géographiques compatibles sur GitHub.

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

Tous les signaux d'application protégés d'un acheteur donné sont disponibles pour sa fonction définie par l'utilisateur generateBid(). Une fois ces éléments transformés en fonctionnalités, les technologies publicitaires créent leur charge utile au format JSON. Cette charge utile de sortie sera incluse dans le rapport "Victoire" de l'acheteur pour être transmise aux serveurs de technologie publicitaire.

Une autre option consiste à effectuer le calcul du vecteur de sortie dans reportWin() au lieu de generateBid(). Chaque approche présente des avantages et des inconvénients. Nous prendrons une décision définitive en fonction des 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 fonctionnalités sont valides pour leurs types, que les contraintes de taille sont respectées et que les acteurs malveillants ne tentent pas de contourner les contrôles de confidentialité en incluant des informations supplémentaires dans leurs charges utiles de sortie.

Si une charge utile de sortie n'est pas valide, elle est supprimée de manière silencieuse des entrées envoyées au rapport "win". En effet, nous ne souhaitons pas fournir d'informations de débogage à un acteur malveillant qui tente de contourner la validation.

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

validate(payload, schema)

Cette API JavaScript permet aux appelants de déterminer si une charge utile particulière passera la validation de la plate-forme. La validation réelle doit être effectuée dans la plate-forme pour se protéger contre les fonctions définies par l'utilisateur generateBid() malveillantes.

Ajouter du bruit à la charge utile de sortie

La plate-forme ajoute du bruit aux charges utiles de sortie avant de les inclure dans le rapport "Victoires". Le seuil de bruit initial est de 1%, et cette valeur peut évoluer avec le temps. La plate-forme n'indiquera pas si une charge utile de sortie spécifique a été perturbée ou non.

La méthode de bruitage est la suivante:

1. La plate-forme charge la définition du schéma pour la charge utile de sortie.
2. 1% des charges utiles de sortie seront choisies pour le bruitage.
3. Si aucune charge utile de sortie n'est choisie, la valeur d'origine est entièrement conservée.
4. Si une charge utile de sortie est choisie, la valeur de chaque élément géographique sera remplacée par une valeur valide aléatoire pour ce type d'élément géographique (par exemple, 0 ou 1 pour un élément géographique booléen).

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 bruitée sera incluse dans les arguments de reportWin() et transmise aux serveurs de technologie publicitaire de l'acheteur en dehors de la limite de confidentialité pour l'entraînement du modèle. La charge utile de sortie sera au format filaire.

Vous trouverez des informations sur le format de transmission pour tous les types d'éléments géographiques et pour la charge utile de sortie elle-même 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 via des tests. Pendant ces tests, nous exporterons temporairement des données sans limite de taille de bits. Ces données de sortie supplémentaires sans limite de taille de bits seront supprimées une fois les tests terminés.

Pour déterminer la taille, procédez comme suit:

1. Initialement, nous acceptons deux charges utiles de sortie dans generateBid() :
   1. egressPayload: la charge utile de sortie limitée en taille que nous avons décrite jusqu'à présent dans ce document. Au départ, la taille de cette charge utile de sortie est de 0 bits (ce qui signifie qu'elle sera toujours supprimée lors de la validation).
   2. temporaryUnlimitedEgressPayload: charge utile de sortie temporaire sans limite de taille pour les tests de taille. La mise en forme, la création et le traitement de cette charge utile de sortie utilisent les mêmes mécanismes que egressPayload.
2. 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.
3. Nous fournissons un protocole de test et un ensemble de métriques pour déterminer l'utilité du modèle à différentes tailles de charge utile de sortie (par exemple, 5, 10, etc. bits).
4. Sur la base des résultats des tests, nous déterminons la taille de la charge utile de sortie avec les compromis d'utilité et de confidentialité appropriés.
5. Nous définissons la taille de egressPayload de 0 bits à la nouvelle taille.
6. Après une période de migration définie, nous supprimons temporaryUnlimitedEgressPayload, ne laissant que egressPayload avec sa nouvelle taille.

Nous étudions des mesures techniques supplémentaires pour gérer ce changement (par exemple, le chiffrement de egressPayload lorsque nous augmentons sa taille à partir de 0 bits). Ces informations, ainsi que le calendrier du test et la suppression de temporaryUnlimitedEgressPayload, seront incluses dans une mise à jour ultérieure.

Nous allons ensuite expliquer un protocole de test possible pour finaliser la taille de egressPayload. Notre objectif est de travailler avec le secteur pour trouver une taille qui équilibre l'utilité et la minimisation des données. L'artefact que ces tests produiront est un graphique dont l'axe X correspond à la taille de la charge utile d'entraînement en bits, et l'axe Y au pourcentage de revenus générés par un modèle de cette taille par rapport à une référence sans limite de taille.

Nous allons supposer 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 recevons lorsque nous remportons des enchères. Le protocole pour les technologies publicitaires implique d'abord des tests hors connexion:

1. Déterminer l'architecture des modèles qu'ils utiliseront avec les signaux d'application protégés Par exemple, il devra déterminer s'il utilisera ou non la factorisation de modèle.
2. Définissez une métrique pour mesurer la qualité du modèle. Les métriques suggérées sont la perte AUC et la perte logistique.
3. Définissez l'ensemble de fonctionnalités qu'il utilisera lors de l'entraînement du modèle.
4. À l'aide de cette architecture de modèle, de cette métrique de qualité et de cet ensemble de fonctionnalités d'entraînement, exécutez des études d'ablation pour déterminer l'utilité apportée par bit pour chaque modèle qu'il souhaite utiliser dans PAS. Le protocole suggéré pour l'étude d'ablation est le suivant :
   1. Entraînez le modèle avec toutes les fonctionnalités et mesurez l'utilité. Il s'agit de la référence pour la comparaison.
   2. Pour chaque caractéristique utilisée pour générer la référence, entraînez le modèle avec toutes les caractéristiques sauf cette caractéristique.
   3. Mesurez l'utilité obtenue. Divisez le delta par la taille de la fonctionnalité en bits. Il s'agit de l'utilité attendue par bit pour cette fonctionnalité.
5. Déterminez les tailles de charge utile d'entraînement qui vous intéressent pour les tests. Nous vous recommandons de choisir [5, 10, 15, …, size_of_all_training_features_for_baseline] bits. Chacune d'elles représente une taille possible pour egressPayload que le test évaluera.
6. Pour chaque taille possible, sélectionnez un ensemble de fonctionnalités inférieures ou égales à cette taille qui maximise l'utilité par bit, à l'aide des résultats de l'étude d'ablation.
7. Entraînez un modèle pour chaque taille possible et évaluez son utilité en pourcentage de l'utilité du modèle de référence entraîné sur toutes les fonctionnalités.
8. Représentez les résultats dans un graphique où l'axe X correspond à la taille de la charge utile d'entraînement en bits, et l'axe Y au pourcentage de revenus générés par ce modèle par rapport à la référence.

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

Le calendrier de ces tests, ainsi que le calendrier de définition de la taille de egressPayload sur la valeur obtenue, ne relèvent pas du champ d'application de ce document et seront communiqués ultérieurement.

Mesures de protection des données

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

1. egressPayload et temporaryUnlimitedEgressPayload seront bruités.
2. Pour la réduction et la protection des données, temporaryUnlimitedEgressPayload ne sera disponible que pendant la durée des tests de taille, au cours desquels nous déterminerons la taille appropriée 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 les audiences personnalisées et les signaux d'application protégés 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és et les audiences personnalisées existantes 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 de technologies publicitaires 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.