Prise en charge des annonces pertinentes incitant à installer une application sur Android grâce à l'API Protected App Signals

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 définis par l'application comme l'installation d'applications, les premières ouvertures, les actions de l'utilisateur (niveaux dans le jeu, succès), les activités d'achat ou le temps passé dans l'application. Ces signaux sont écrits et stockés sur l'appareil pour éviter les fuites de données. Ils ne sont mis à la disposition que de la logique de technologie publicitaire ayant stocké le signal donné lors d'enchères protégées exécutées dans un environnement sécurisé.
  2. API Ad Selection : fournit une API pour configurer et 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 les inférences, calculent les enchères et évaluent les annonces pour choisir la "gagnante" à l'aide de l'API Protected App Signals et des informations contextuelles fournies en temps réel par le diffuseur.
Diagramme illustrant le processus d'installation d'une application avec des signaux protégés
Figure 1. Organigramme illustrant l'API Protected App Signals et le workflow de sélection des annonces dans la Privacy Sandbox sur Android

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

  • Sélection des signaux : lorsque les utilisateurs se servent d'applications mobiles, les technologies publicitaires sélectionnent des signaux en stockant 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. Ils sont chiffrés avant d'être envoyés depuis l'appareil, de sorte que seuls les services d'enchères exécutés au sein des environnements d'exécution sécurisés dotés du contrôle de sécurité et de confidentialité appropriés puissent les déchiffrer afin d'enchérir et d'évaluer les annonces.
  • Encodage des signaux : les signaux sont préparés à une cadence planifiée par une logique de technologie publicitaire personnalisée. Une tâche en arrière-plan Android exécute cette logique pour effectuer un encodage sur l'appareil 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

Version Preview développeur Bêta
Fonctionnalité 4e trimestre 2023 1er trimestre 2024 2e trimestre 2024 3e trimestre 2024
API de sélection des signaux API de stockage sur l'appareil Logique du quota de stockage sur l'appareil

Mises à jour quotidiennes de la logique personnalisée sur l'appareil
N/A Disponible pour les appareils 1% T+
Serveur de récupération des annonces dans un TEE MVP Disponible sur GCP

Compatibilité avec la mise en production
de l'UDF Top K
Disponible sur AWS

Débogage, métriques et surveillance autorisés
Service d'inférence dans un TEE

Compatibilité avec l'exécution de modèles de ML et leur utilisation pour définir des enchères dans un TEE
En cours de développement Disponible sur GCP

Capacité à déployer et à prototyper des modèles de ML statiques à l'aide de TensorFlow et de PyTorch
Disponible sur AWS

Déploiement de modèles en production pour les modèles TensorFlow et PyTorch

Télémétrie, débogage autorisé et surveillance
Assistance pour les enchères et les mises aux enchères dans un TEE

Disponible sur GCP Intégration de la récupération d'annonces PAS-B&A et TEE (avec chiffrement gRPC et TEE<>TEE)

Prise en charge de la récupération d'annonces via un chemin contextuel (inclut la prise en charge des B&A<>K/V sur le TEE)
Disponible sur AWS

Rapports de débogage

Débogage, métriques et surveillance autorisés

Organiser l'API Protected App Signals

Un signal est une représentation de diverses interactions utilisateur au sein d'une application déterminées par la technologie publicitaire comme étant utiles pour diffuser des annonces pertinentes. Une application ou 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 le nombre d'ouvertures de l'application, les succès, les achats ou le temps passé sur 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 par l'appareil. Ainsi, seuls les services d'enchères exécutés dans des environnements d'exécution sécurisés disposant des paramètres de sécurité et de confidentialité appropriés peuvent les déchiffrer pour les enchères et l'attribution de scores. 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 updateSignals(), 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 updateSignals(). updateSignals() prend un URI et récupère la liste des mises à jour du signal. Par exemple, updateSignals() 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'extraction de 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.
Figure 2. Workflow de sélection des annonces dans la Privacy Sandbox sur Android

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 :
  • 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.
Figure 3. Logique d'exécution de la sélection des annonces côté achat dans la Privacy Sandbox sur Android.

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

  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.

La fonction prepareDataForAdRetrieval() définie par l'utilisateur

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 :

prepareDataForAdRetrieval() joue deux rôles :

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

La fonction prepareDataForAdRetrieval() renvoie :

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

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

La fonction getCandidateAds() définie par l'utilisateur

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 :

  • Les représentations vectorielles continues contextuelles transmises à l'aide d'une 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 la fonction 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.

La fonction generateBid() définie par l'utilisateur

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

Au sein de 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.

Pour activer l'optimisation des enchères et l'entraînement du modèle, nous travaillons également sur des moyens de sortir des données issues de la fonction generateBid() dans les rapports d'enchères gagnantes, tout en protégeant la confidentialité, afin de les utiliser pour l'entraînement. Nous vous fournirons des informations supplémentaires prochainement.

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 seront effacés, au même titre que les audiences personnalisées existantes sur l'appareil.
  • Les utilisateurs auront la possibilité de désactiver complètement la Privacy Sandbox sur Android, ce qui inclut les API Protected App Signals et Protected Audience. Dans ce cas, les API Protected Audience et Protected App Signals renvoient un message d'exception standard : SECURITY_EXCEPTION.

Autorisations et contrôle de l'application

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

  • Une application peut gérer ses associations à l'aide de signaux d'application protégés.
  • Une 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.