Permettre le ciblage d'audience personnalisée avec FLEDGE

Remarque : Cet article reflète la Privacy Sandbox dans les propositions de conception actuelles d'Android et est susceptible d'être modifié. Nous vous invitons à nous faire part de vos retours et commentaires pour nous aider dans cette démarche.

Envoyer un commentaire

Informations récentes

• Ajout d'une proposition de délégation d'audience personnalisée.
• Suppression de l'exigence de k-anonymat pour l'URL d'information quotidienne

Présentation

Dans le domaine de la publicité pour mobile, les annonceurs souhaitent généralement diffuser des annonces auprès des utilisateurs potentiellement intéressés, en fonction de l'engagement dont ils ont fait preuve dans l'application de l'annonceur. Par exemple, le développeur d'une application d'articles de sport peut vouloir diffuser des annonces auprès des utilisateurs qui ont laissé des articles dans le panier afin de les inciter à finaliser l'achat. Dans le jargon, ces pratiques sont généralement décrites avec des termes tels que "remarketing" et "ciblage d'audience personnalisé".

De nos jours, ces cas d'utilisation sont habituellement mis en œuvre via le partage d'informations contextuelles sur la façon dont l'annonce est diffusée (comme le nom de l'application) et d'informations privées (telles que des listes d'audience) avec les plates-formes de technologie publicitaire. Les annonceurs peuvent ainsi sélectionner des annonces pertinentes sur leurs serveurs.

FLEDGE sur Android comprend les API suivantes pour les plates-formes de technologie publicitaire et les annonceurs. Il répond aux cas d'utilisation courants basés sur les interactions en limitant le partage des identifiants entre les applications et le partage des informations d'interaction de l'application d'un utilisateur avec des tiers :

1. API Custom Audience : cette API se concentre sur l'abstraction "audience personnalisée", qui représente une audience désignée par l'annonceur, avec des intentions communes. Les informations sur l'audience sont stockées sur l'appareil et peuvent être associées à des annonces candidates pertinentes et à des métadonnées arbitraires, telles que des signaux d'enchères. Ces informations permettent de prendre des décisions éclairées concernant les enchères, le filtrage des annonces et leur affichage.
2. API Ad Selection : cette API offre un framework qui assure l'orchestration des workflows des plates-formes de technologie publicitaire. Ces workflows exploitent les signaux sur l'appareil afin de déterminer si une annonce est "gagnante" en tenant compte des annonces candidates stockées localement et en effectuant un traitement supplémentaire sur les annonces candidates qu'une plate-forme de technologie publicitaire renvoie à l'appareil.

Figure 1 : Organigramme illustrant le workflow personnalisé de gestion des audiences et de sélection des annonces dans la Privacy Sandbox sur Android

Remarque : Cette proposition de conception se concentre actuellement sur les cas d'utilisation publicitaires basés sur les interactions des utilisateurs entre les applications. Dans ce cas, une application peut enregistrer des audiences personnalisées auxquelles des annonces peuvent être diffusées dans d'autres applications. Nous envisageons d'ajouter d'autres informations liées à d'autres cas d'utilisation (interaction de l'utilisateur dans une application Web avec des composants WebView et le navigateur, par exemple) à l'avenir.

De manière générale, cette intégration fonctionne comme suit :

1. Une application d'articles de sport souhaite rappeler aux utilisateurs qu'il leur reste deux jours pour acheter les produits qu'ils ont laissés dans leur panier. Elle utilise l'API Custom Audience pour ajouter les utilisateurs concernés à la liste d'audience "Produits laissés dans le panier". La plate-forme gère et stocke cette liste d'audience sur l'appareil, ce qui limite le partage avec des tiers. L'application d'articles de sport s'associe à une plate-forme de technologie publicitaire pour diffuser ses annonces auprès des utilisateurs de sa liste d'audience. Cette plate-forme gérera les métadonnées des listes d'audience et proposera des annonces candidates qui seront mises à la disposition du workflow de sélection des annonces, qui choisira de les diffuser ou non. Elle peut être configurée pour extraire périodiquement les annonces mises à jour basées sur l'audience en arrière-plan. La liste des annonces candidates en fonction de l'audience sera ainsi toujours actualisée et ne dépendra pas des demandes envoyées à des ad servers tiers lors de l'opportunité publicitaire (demande d'annonces contextuelles, par exemple).

2. Lorsqu'un utilisateur joue au jeu XXX sur le même appareil, une annonce lui rappelant de finaliser l'achat de produits laissés dans le panier de l'application d'articles de sport peut lui être présentée. Pour ce faire, le jeu XXX (à l'aide d'un SDK publicitaire intégré) appelle l'API Ad Selection afin de choisir une annonce gagnante en fonction de la liste d'audience à laquelle l'utilisateur appartient. Dans cet exemple, il s'agit de l'audience personnalisée "Produits laissés dans le panier" créée par l'application d'articles de sport. Le workflow de sélection d'annonce peut être configuré pour prendre en compte les annonces extraites à partir des serveurs des plates-formes de technologie publicitaire, en plus des annonces sur l'appareil associées aux audiences personnalisées, ainsi qu'à d'autres signaux. Le workflow peut également être personnalisé par la plate-forme de technologie publicitaire et le SDK publicitaire, avec des enchères et une logique d'évaluation personnalisées permettant d'atteindre les objectifs publicitaires appropriés. Cette approche permet aux données sur les centres d'intérêt de l'utilisateur ou sur ses interactions avec l'application d'éclairer la sélection des annonces, tout en limitant le partage de ces données avec des tiers.

3. Le SDK de l'application de diffusion d'annonces ou de la plate-forme de technologie publicitaire affiche l'annonce sélectionnée.

4. La plate-forme facilite la création de rapports sur les impressions et sur les résultats de la sélection d'annonces. Cette fonctionnalité est complémentaire à l'API Attribution Reporting. Les plates-formes de technologie publicitaire peuvent être personnalisées en fonction des types de rapports dont elles ont besoin.

Obtenir l'accès aux API FLEDGE pour Android

Les plates-formes ad tech doivent demander l'accès aux API FLEDGE pour Android. Pour en savoir plus, consultez la section Créer un compte Privacy Sandbox.

Gestion des audiences personnalisées

Audience personnalisée

Une audience personnalisée représente un groupe d'utilisateurs déterminé par l'annonceur, ayant des intentions ou des centres d'intérêt communs. Une application ou un SDK peut utiliser une audience personnalisée pour faire référence à une audience particulière (personne "ayant laissé des articles dans son panier" ou "ayant terminé le niveau débutant" d'un jeu, par exemple). La plate-forme gérera et stockera les informations sur l'audience localement sur l'appareil. Elle n'indiquera pas dans quelles audiences personnalisées se trouve l'utilisateur. Les audiences personnalisées sont différentes des groupes de centres d'intérêt de FLEDGE sur Chrome. Elles ne peuvent pas être partagées sur le Web ni dans des applications. Elles permettent ainsi un meilleur contrôle des informations utilisateur.

L'application d'un annonceur ou le SDK intégré pourront rejoindre ou quitter une audience personnalisée en fonction, par exemple, de l'engagement des utilisateurs dans une application.

Métadonnées d'audience personnalisées

Chaque audience personnalisée contient les métadonnées suivantes :

• Propriétaire : nom de package de l'application propriétaire. Il est implicitement défini sur le nom de package de l'application appelante.
• Acheteur : réseau publicitaire acheteur qui gère les annonces pour cette audience personnalisée. L'acheteur représente également la partie qui peut accéder à l'audience personnalisée et extraire les informations publicitaires pertinentes. La spécification de l'acheteur doit respecter le format eTLD+1.
• Nom : nom ou identifiant arbitraire de l'audience personnalisée ("utilisateur ayant abandonné son panier d'achat", par exemple). Cet attribut peut être utilisé, par exemple, comme l'un des critères de ciblage des campagnes publicitaires de l'annonceur ou comme chaîne de requête dans l'URL afin d'extraire le code d'enchère.
• Heure d'activation et heure d'expiration : ces champs définissent la période pendant laquelle cette audience personnalisée sera effective. La plate-forme se servira de ces informations pour supprimer des utilisateurs d'une audience personnalisée. Pour limiter la durée de vie d'une audience personnalisée, l'heure d'expiration ne peut pas aller au-delà d'une période maximale.
• URL de mise à jour quotidienne : URL utilisée par la plate-forme pour extraire les annonces candidates et d'autres métadonnées définies dans les champs "Signaux d'enchères utilisateur" et "Signaux d'enchères approuvés" de manière récurrente. Pour en savoir plus, découvrez comment extraire des annonces candidates pour les audiences personnalisées.
• Signaux d'enchères utilisateur : signaux propres à la plate-forme de technologie publicitaire pour toutes les enchères d'annonces de remarketing. Il peut s'agir de la position approximative de l'utilisateur, de ses paramètres régionaux préférés, etc.
• Données d'enchères approuvées : les plates-formes de technologie publicitaire s'appuient sur des données en temps réel pour optimiser la récupération et l'évaluation des annonces. Imaginons une annonce qui épuise son budget et dont la diffusion doit être immédiatement interrompue. Une technologie publicitaire peut définir un point de terminaison d'URL à partir duquel les données en temps réel peuvent être extraites, ainsi que l'ensemble de clés pour lequel la recherche en temps réel doit être effectuée. Le serveur qui gère cette demande est un serveur approuvé géré par la plate-forme de technologie publicitaire.
• URL de la logique d'enchères : URL utilisée par la plate-forme pour extraire le code d'enchère à partir de la plate-forme côté demande. Cette étape est effectuée lorsque des enchères sont lancées.
• Annonces : liste d'annonces candidates correspondant à l'audience personnalisée. Cela inclut les métadonnées d'annonce spécifiques à la plate-forme publicitaire et une URL pour afficher l'annonce. Lorsqu'une enchère est lancée pour l'audience personnalisée, cette liste de métadonnées d'annonce est prise en compte. Dans la mesure du possible, cette liste d'annonces est actualisée à l'aide du point de terminaison de l'URL de mise à jour quotidienne. En raison de contraintes liées aux ressources sur les appareils mobiles, le nombre d'annonces pouvant être stockées dans une audience personnalisée est limité.

Délégation d'audience personnalisée

La définition et la configuration d'audiences personnalisées traditionnelles reposent généralement sur des technologies et des intégrations côté serveur, générées par des technologies publicitaires en association avec les clients et partenaires d'agences et d'annonceurs. FLEDGE permet de définir et de configurer des audiences personnalisées tout en protégeant la confidentialité. Pour rejoindre une audience personnalisée, 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). Les API FLEDGE visent à assurer la compatibilité avec ces SDK en fournissant des solutions flexibles pour la gestion d'audience personnalisée en permettant aux appelants de l'appareil d'invoquer la création d'audiences personnalisées pour le compte d'acheteurs. Ce processus s'appelle la délégation d'audience personnalisée. Pour configurer la délégation d'audience personnalisée, procédez comme suit :

Rejoindre une audience personnalisée

Il existe deux façons de rejoindre une audience personnalisée :

joinCustomAudience()

Une application ou un SDK peut demander à rejoindre une audience personnalisée en appelant joinCustomAudience() après avoir instancié l'objet CustomAudience avec les paramètres attendus. Voici un exemple d'extrait de code :

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchCustomAudience()

Une application ou un SDK peut demander à rejoindre une audience personnalisée au nom d'une technologie publicitaire qui n'est pas présente sur l'appareil en appelant fetchCustomAudience() avec les paramètres attendus, comme dans l'exemple suivant :

CustomAudienceFetchRequest fetchRequest = new CustomAudienceFetchRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchCustomAudience(fetchRequest);

Le point de terminaison de l'URL, qui appartient à l'acheteur, répond avec un objet JSON CustomAudience dans le corps de la réponse. Les champs "Acheteur" et "Propriétaire" de l'audience personnalisée sont ignorés (et sont renseignés automatiquement par l'API). L'API fait également en sorte que l'URL de mise à jour quotidienne corresponde également à l'eTLD+1 de l'acheteur.

{
 "name": "running-shoes",
 "activation_time": 1680603133,
 "expiration_time": 1680803133,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": "key1",
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": "key2",
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

L'API fetchCustomAudience() détermine l'identité de l'acheteur à partir de l'eTLD+1 de fetchUri. L'identité de l'acheteur CustomAudience permet d'effectuer les mêmes vérifications d'inscription et d'autorisation de l'application que celles effectuées par joinCustomAudience(), et ne peut pas être modifiée par la réponse de récupération. Le propriétaire CustomAudience est le nom de package de l'application appelante. Il n'existe aucune autre validation de fetchUri autre que la vérification eTLD+1, et en particulier aucune vérification k-anon. L'API fetchCustomAudience() envoie une requête HTTP GET à fetchUri et s'attend à un objet JSON représentant l'audience personnalisée. Les mêmes contraintes obligatoires, contraintes facultatives et valeurs par défaut des champs d'objet d'audience personnalisée sont appliquées à la réponse. Pour en savoir plus sur les exigences et les limites actuelles, consultez le guide du développeur. Toute réponse d'erreur HTTP de l'acheteur entraîne l'échec de CustomAudience. Plus spécifiquement, une réponse d'état HTTP 429 (requêtes excessives) bloque les requêtes de l'application actuelle pendant une période à définir. Les échecs sont signalés à l'appelant de l'API qui est responsable des nouvelles tentatives en cas d'échec temporaire (par exemple, lorsque le serveur ne répond pas ou dépasse le délai) ou qui gère les échecs persistants (tels que les échecs de validation des données ou toute autre erreur non temporaire dans la communication avec le serveur).

L'objet CustomAudienceFetchRequest permet à l'appelant de l'API de définir certaines informations pour l'audience personnalisée à l'aide des propriétés facultatives présentées dans l'exemple ci-dessus. Si elles sont spécifiées, ces valeurs ne peuvent pas être remplacées par la réponse reçue de l'acheteur. FLEDGE ignore les champs de la réponse. Une représentation JSON du contenu de l'audience personnalisée tel que défini partiellement par l'appelant de l'API est incluse dans la requête GET adressée à fetchUri dans un en-tête spécial X-CUSTOM-AUDIENCE-DATA. La taille des données spécifiées pour l'audience personnalisée est limitée à 8 Ko.

En l'absence de vérification k-anon, vous pouvez utiliser fetchUri pour valider l'acheteur et activer le partage d'informations entre l'acheteur et le SDK. Pour faciliter la validation d'audience personnalisée, l'acheteur peut fournir un jeton de validation. Le SDK sur l'appareil doit inclure ce jeton dansfetchUri afin que le point de terminaison hébergé par l'acheteur puisse récupérer le contenu de l'audience personnalisée et utiliser le jeton de validation pour vérifier que l'opération fetchCustomAudience() correspond à l'acheteur et provient d'un partenaire de confiance sur l'appareil. Pour partager des informations, l'acheteur peut convenir avec l'appelant sur l'appareil que certaines des informations à utiliser pour créer l'audience personnalisée seront ajoutées en tant que paramètres de requête à fetchUri. Cela permet à l'acheteur d'effectuer un audit des appels et de détecter si un jeton de validation a été utilisé par une technologie publicitaire malveillante pour créer plusieurs audiences personnalisées différentes.

Remarque sur la définition des jetons de validation et leur stockage

• Le jeton de validation n'est utilisé à aucune fin par FLEDGE et est facultatif.

  • L'acheteur peut utiliser le jeton de validation pour vérifier que les audiences en cours de création sont effectuées en son nom.
  • La proposition FLEDGE ne spécifie ni le format du jeton de validation, ni la manière dont l'acheteur le transfère à l'appelant. Par exemple, le jeton de validation peut être préchargé dans le SDK ou le backend du propriétaire, ou récupéré en temps réel par le SDK du propriétaire sur le serveur de l'acheteur.

Quitter une audience personnalisée

Le propriétaire d'une audience personnalisée peut choisir de la quitter en appelant leaveCustomAudience(), comme illustré dans l'extrait de code ci-dessous :

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

Remarque : Cette API n'utilise pas de valeur renvoyée pour empêcher les applications de recourir à cette méthode afin de déduire l'appartenance d'un utilisateur à une audience personnalisée.

Pour vous aider à préserver l'utilisation du stockage et d'autres ressources de l'appareil, les audiences personnalisées expirent et sont supprimées de l'espace de stockage de l'appareil après une période prédéterminée. La valeur par défaut doit être déterminée. Le propriétaire peut remplacer cette valeur par défaut.

Contrôle des utilisateurs

• Cette proposition vise à permettre aux utilisateurs de voir la liste des applications installées qui ont créé au moins une audience personnalisée.
• Les utilisateurs peuvent supprimer des applications de cette liste. Cette suppression effacera toutes les audiences personnalisées associées aux applications et empêchera ces dernières de rejoindre de nouvelles audiences personnalisées.
• Les utilisateurs ont la possibilité de réinitialiser FLEDGE complètement. Dans ce cas, les audiences personnalisées existantes sur l'appareil sont effacées.
• Les utilisateurs peuvent se désinscrire complètement de la Privacy Sandbox sur Android, ce qui inclut FLEDGE. Dans ce cas, les API FLEDGE renverront un message d'exception standard : SECURITY_EXCEPTION.

La conception de cette fonctionnalité est en cours, et plus de détails seront inclus dans une mise à jour ultérieure.

Autorisations et contrôle de l'application

Cette proposition vise à permettre aux applications de contrôler leurs audiences personnalisées :

• Une application peut gérer ses associations avec des audiences personnalisées.
• Une application peut accorder à des plates-formes de technologie publicitaire tierces des autorisations permettant de gérer les audiences personnalisées en son nom.

La conception de cette fonctionnalité est en cours, et plus de détails seront inclus dans une mise à jour ultérieure.

Contrôle de la plate-forme ad tech

Cette proposition décrit comment les technologies publicitaires peuvent contrôler leurs audiences personnalisées :

• Les technologies publicitaires s'inscrivent à la Privacy Sandbox et fournissent un domaine eTLD+1 correspondant à toutes les URL d'une audience personnalisée.
• Les technologies publicitaires peuvent s'associer à des applications ou des SDK pour fournir des jetons de validation permettant de valider une création d'audience personnalisée. Lorsque ce processus est délégué à un partenaire, la création d'audience personnalisée peut être configurée pour exiger la confirmation de la technologie publicitaire.
• Une technologie publicitaire peut choisir de désactiver les appels joinCustomAudience en son nom et de n'autoriser que l'API fetchCustomAudience à activer toutes les audiences personnalisées par appel. Le contrôle peut être modifié lors de l'inscription à la Privacy Sandbox. Notez que le contrôle autorise toutes les technologies publicitaires ou aucune. En raison des limitations de la plate-forme, les autorisations de délégation ne peuvent pas être basées sur la technologie publicitaire.

La conception de cette fonctionnalité est en cours, et plus de détails seront inclus dans une mise à jour ultérieure.

Annonces candidates et métadonnées renvoyées

Les annonces candidates et les métadonnées renvoyées à partir d'une plate-forme côté achat doivent inclure les champs suivants :

• 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.
• URL de rendu : point de terminaison destiné à l'affichage de la création publicitaire.
• Filtre : informations facultatives nécessaires pour que FLEDGE puisse filtrer les annonces en fonction des données sur l'appareil. Pour en savoir plus, consultez la section Logique de filtrage côté achat.

Processus de sélection des annonces

Cette proposition vise à améliorer la confidentialité avec l'API Ad Selection, qui orchestre l'exécution des enchères pour les plates-formes de technologie publicitaire.

Aujourd'hui, les plates-formes de technologie publicitaire effectuent généralement les enchères et sélectionnent les annonces exclusivement sur leurs serveurs. Avec cette proposition, les audiences personnalisées et d'autres signaux utilisateur sensibles, tels que les informations disponibles sur les packages installés, seront accessibles uniquement via l'API Ad Selection. En outre, dans le cas d'utilisation du remarketing, les annonces candidates sont extraites hors bande (à savoir, en dehors du contexte de diffusion des annonces). Les plates-formes ad tech doivent se préparer à déployer une partie de leur logique d'enchères et de sélection des annonces sur l'appareil. Elles peuvent prendre en compte les modifications suivantes dans leur workflow de sélection des annonces :

• En l'absence d'informations sur les packages installés sur le serveur, il se peut que les plates-formes de technologie publicitaire souhaitent renvoyer plusieurs annonces contextuelles à l'appareil et qu'elles appellent le workflow de sélection des annonces afin de permettre un filtrage basé sur l'installation de l'application afin de maximiser les chances de diffuser une annonce pertinente.
• Comme les annonces de remarketing seront extraites hors bande, vous devrez peut-être mettre à jour les modèles d'enchères actuels. Les plates-formes de technologie publicitaire souhaitent parfois créer des sous-modèles d'enchères (l'implémentation peut être basée sur un modèle à deux tours) qui peuvent fonctionner séparément sur les fonctionnalités publicitaires et les signaux contextuels et combiner les sorties du sous-modèle sur l'appareil afin de prédire les enchères. Cela peut s'avérer utile tant pour les enchères côté serveur que pour n'importe quelle opportunité publicitaire.

Cette approche permet aux données sur les interactions de l'utilisateur avec l'application d'éclairer la sélection des annonces, tout en limitant le partage de ces données avec des tiers.

Figure 2 : Organigramme illustrant le lancement du workflow de sélection des annonces

Ce processus de sélection des annonces orchestre l'exécution sur l'appareil d'un code JavaScript fourni par une technologie publicitaire en fonction de la séquence suivante :

1. Exécution de la logique d'enchères côté achat
2. Traitement et filtrage des annonces côté achat
3. Exécution de la logique de décision côté vente

Pour les sélections d'annonces impliquant des audiences personnalisées, la plate-forme récupère le code JavaScript fourni côté achat en fonction du point de terminaison de l'URL publique défini par les métadonnées "URL de la logique d'enchères" de l'audience personnalisée. Le point de terminaison de l'URL pour le code de décision côté vente est également transmis en tant qu'entrée pour lancer le processus de sélection des annonces.

Nous travaillons activement à l'élaboration de sélections d'annonces qui n'impliquent pas d'audiences personnalisées.

Lancer le workflow de sélection des annonces

Lorsqu'une application doit diffuser une annonce, le SDK de la plate-forme publicitaire peut lancer le workflow de sélection de l'annonce en appelant la méthode selectAds() après avoir instancié l'objet AdSelectionConfig avec les paramètres attendus :

• Vendeur : identifiant de la plate-forme côté vente, avec le format eTLD+1.
• URL de la logique de décision : lorsqu'une enchère est lancée, la plate-forme utilise cette URL pour extraire le code JavaScript de la plate-forme côté vente et évaluer une annonce gagnante.
• Acheteurs d'audiences personnalisées : liste de plates-formes côté achat avec une demande basée sur l'audience personnalisée pour cette enchère, avec le format eTLD+1.
• Signaux de sélection d'annonces : informations sur l'enchère (taille de l'annonce, format de l'annonce, etc.).
• Signaux du vendeur : signaux spécifiques à la plate-forme côté offre.
• URL des signaux d'évaluation de confiance : point de terminaison de l'URL du signal de confiance côté vente à partir duquel des informations en temps réel spécifiques à la création peuvent être extraites.
• Signaux par acheteur : les plates-formes côté demande qui participent peuvent utiliser ce paramètre pour fournir des données pour l'enchère. Par exemple, ce paramètre peut inclure des informations contextuelles complètes utiles pour déterminer les enchères.

L'extrait de code suivant illustre un SDK de plate-forme de technologie publicitaire qui lance le workflow de sélection des annonces. Il commence par définir l'élément AdSelectionConfig, puis appelle selectAds pour générer l'annonce gagnante :

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

Logique d'enchères côté achat

La logique d'enchères est généralement fournie par des plates-formes côté achat. L'objectif du code est de déterminer les enchères pour les annonces candidates. Il peut appliquer une logique métier supplémentaire pour déterminer le résultat.

La plate-forme utilise les métadonnées "URL de la logique d'enchères" de l'audience personnalisée pour extraire le code JavaScript qui devrait inclure la signature de la fonction ci-dessous :

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

La méthode generateBid() renvoie le montant de l'enchère calculé. La plate-forme appelle successivement cette fonction pour toutes les annonces (contextuelles ou de remarketing). S'il existe plusieurs fournisseurs de logique d'enchères, le système ne garantit pas leur ordre d'exécution.

La fonction attend les paramètres suivants :

• Annonce : annonce examinée par le code d'enchère côté achat. Cette annonce est issue d'une audience personnalisée éligible.
• Signaux d'enchères : signaux spécifiques à la plate-forme côté vente.
• Signaux par acheteur : les plates-formes côté demande qui participent peuvent utiliser ce paramètre pour fournir des données pour l'enchère. Par exemple, ce paramètre peut inclure des informations contextuelles complètes utiles pour déterminer les enchères.
• Signaux d'enchères approuvés : les plates-formes de technologie publicitaire s'appuient sur des données en temps réel pour optimiser la récupération et l'évaluation des annonces. Imaginons une campagne publicitaire qui épuise son budget et qui doit arrêter de diffuser des annonces immédiatement. Une technologie publicitaire peut définir un point de terminaison d'URL à partir duquel les données en temps réel peuvent être extraites, ainsi que l'ensemble de clés pour lequel la recherche en temps réel doit être effectuée. Le serveur géré de la plate-forme de technologie publicitaire qui diffuse cette requête est un serveur de confiance géré par cette plate-forme.
• Signaux contextuels : il peut s'agir d'un horodatage grossier ou d'informations de localisation approximatives.
• Signaux utilisateur : il peut s'agir d'informations sur les packages installés disponibles.

Logique de filtrage côté achat

Les plates-formes côté achat peuvent filtrer les annonces en fonction des signaux supplémentaires disponibles sur l'appareil pendant la phase de sélection des annonces. Par exemple, les plates-formes ad tech peuvent implémenter ici des fonctionnalités de limitation de la fréquence d'exposition. S'il existe plusieurs fournisseurs de filtrage, le système ne garantit pas l'ordre d'exécution des différents fournisseurs.

La logique de filtrage côté acheteur peut être mise en œuvre dans le cadre de la logique d'enchères en renvoyant la valeur d'enchère 0 pour une annonce donnée.

En outre, les plates-formes côté achat peuvent indiquer qu'une annonce donnée doit être filtrée en fonction d'autres signaux sur l'appareil disponibles pour FLEDGE, signaux qui ne quitteront pas l'appareil. À mesure que nous consolidons la conception des logiques de filtrage supplémentaires, les plates-formes côté achat suivront cette même structure pour signaler que le filtrage doit se produire.

Logique d'évaluation côté vente

La logique d'évaluation est généralement fournie par la plate-forme côté vente. L'objectif de ce code est de déterminer une annonce gagnante en fonction des résultats de la logique d'enchères. Il peut appliquer une logique métier supplémentaire pour déterminer le résultat. S'il existe plusieurs fournisseurs de logique de décision, le système ne garantit pas leur ordre d'exécution. La plate-forme utilise le paramètre d'entrée "URL de la logique de décision" de l'API selectAds() pour extraire le code JavaScript qui devrait inclure la signature de la fonction ci-dessous :

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

La fonction attend les paramètres suivants :

• Annonce : annonce en cours d'évaluation et résultat de la fonction generateBid().
• Enchère : sortie correspondant au montant de l'enchère à partir de la fonction generateBid().
• Configuration de l'enchère : paramètre d'entrée dans la méthode selectAds().
• Signaux d'évaluation de confiance : les plates-formes de technologie publicitaire s'appuient sur des données en temps réel pour optimiser le filtrage et l'évaluation des annonces. Par exemple, si un éditeur d'application empêche la diffusion d'annonces dans une campagne publicitaire, ces données seront extraites du paramètre d'URL des signaux de confiance pour la configuration de l'enchère. Le serveur qui diffuse cette demande doit être un serveur de confiance géré par une technologie publicitaire.
• Signal contextuel : il peut s'agir d'un horodatage grossier ou d'informations de localisation approximatives.
• Signal utilisateur : il peut s'agir d'informations telles que la plate-forme de téléchargement ayant lancé l'installation de l'application.
• Signal d'audience personnalisée : si l'annonce évaluée provient d'une audience personnalisée sur l'appareil, elle contient des informations telles que le lecteur et le nom de l'audience personnalisée.

Exécution du code de sélection des annonces

Dans la proposition, le système extrait le code d'enchère fourni par la plate-forme de technologie publicitaire à partir de points de terminaison d'URL configurables, puis l'exécute sur l'appareil. Compte tenu des contraintes liées aux ressources sur les appareils mobiles, le code d'enchère doit respecter les directives suivantes :

• L'exécution du code doit se terminer dans un délai prédéfini. Cette limite doit s'appliquer de manière uniforme à tous les réseaux publicitaires des acheteurs. Les détails de cette limite seront partagés dans une mise à jour ultérieure.
• Le code doit être autonome et ne doit pas avoir de dépendances externes.

Étant donné que le code d'enchère, tel que la logique d'enchères, peut avoir besoin d'accéder à des données utilisateur privées telles que les sources d'installation d'applications, l'environnement d'exécution ne permet pas l'accès au réseau ni au stockage.

Langage de programmation

Le code d'enchère fourni par la plate-forme publicitaire doit être écrit en JavaScript. Les plates-formes de technologie publicitaire peuvent ainsi partager, par exemple, le code d'enchère entre les plates-formes compatibles avec la Privacy Sandbox.

Affichage des annonces gagnantes

L'annonce avec le score le plus élevé est considérée comme ayant remporté l'enchère. Dans cette proposition initiale, l'annonce gagnante est transmise au SDK pour être affichée.

La stratégie consiste à faire évoluer la solution pour que l'application et le SDK ne puissent pas déterminer les informations concernant l'appartenance d'un utilisateur à une audience personnalisée ou concernant son historique d'engagement à partir des informations sur l'annonce gagnante (comme dans la proposition de frames clôturés dans Chrome).

Rapports sur les impressions

Une fois l'annonce affichée, l'impression gagnante peut être signalée aux plates-formes côté achat et côté vente participantes. La plate-forme appelle la logique de création de rapports dans cet ordre :

1. Rapports côté vente
2. Rapports côté acheteur

Cela permet aux plates-formes côté achat et côté vente d'envoyer des informations importantes sur l'appareil telles que les informations sur les enchères, le nom de l'audience personnalisée, etc. aux serveurs afin d'activer des fonctionnalités comme la budgétisation en temps réel, la mise à jour des modèles d'enchères ou des workflows de facturation précis. La prise en charge des rapports sur les impressions est complémentaire à l'API Attribution Reporting.

Remarque : La proposition prévoit actuellement la création de rapports au niveau des événements. À l'avenir, nous utiliserons un mécanisme de création de rapports globaux.

Rapports côté vente

La plate-forme appelle la fonction JavaScript reportResult() dans le code fourni côté offre qui a été téléchargé à partir du paramètre URL de la logique de décision du vendeur pour l'API selectAds() :

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    return reporting_url, signals_for_buyer;
}

Sortie :

• URL de rapport : la plate-forme appelle cette URL renvoyée par la fonction.

Le côté offre peut encoder les signaux pertinents dans l'URL de rapport afin d'obtenir des informations supplémentaires sur l'enchère et l'annonce gagnante. Voici quelques exemples de signaux possibles :

• URL de rendu de l'annonce
• Montant de l'enchère gagnante
• Nom de l'application
• Identifiants de requête
• Signaux pour l'acheteur (pour permettre le partage de données entre l'offre et la demande, la plate-forme transmet cette valeur renvoyée en tant que paramètre d'entrée au code de rapport côté demande)

Rapports côté achat

La plate-forme appelle la fonction JavaScript reportResult() dans le code fourni côté demande qui a été téléchargé à partir des métadonnées de l'URL de logique d'enchères de l'audience personnalisée associée à l'enchère.

reportResult(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    return reporting_url;
}

Entrée :

• auction_signals et per_buyer_signals sont extraits d'AuctionConfig. Toute information que la plate-forme côté achat doit transmettre à l'URL de rapport peut provenir de ces données.
• signals_for_buyer correspond à la sortie de reportResult côté vente. La plate-forme côté vente a la possibilité de partager des données avec la plate-forme côté achat afin de créer des rapports.
• contextual_signals contient des informations telles que le nom de l'application, tandis que custom_audience_signals inclut les informations sur l'audience personnalisée. D'autres informations pourront être ajoutées à l'avenir.

Sortie :

• URL de rapport : la plate-forme appelle cette URL renvoyée par la fonction.

Serveur de confiance géré par la plate-forme de technologie publicitaire

Aujourd'hui, la logique de sélection des annonces requiert des informations en temps réel, telles que l'état d'épuisement du budget, afin de déterminer si les annonces candidates doivent être sélectionnées pour l'enchère. Les plates-formes côté achat et côté vente pourront obtenir ces informations auprès des serveurs qu'elles utilisent. Afin de réduire la fuite d'informations sensibles via ces serveurs, la proposition implique les restrictions suivantes :

• Le comportement de ces serveurs, décrit plus loin dans cette section, ne doit pas divulguer d'informations sur les utilisateurs.
• Les serveurs ne doivent pas créer de profils pseudonymes en fonction des données qu'ils voient. Autrement dit, ils devront être "de confiance".

Côté achat : une fois que la logique d'enchères côté achat initiera la logique d'achat, la plate-forme effectue une extraction HTTP des données d'enchères approuvées à partir du serveur de confiance. La composition de l'URL repose sur l'ajout de l'URL elle-même et des clés présentes dans les métadonnées "Signaux d'enchère approuvés" correspondant à l'audience personnalisée en cours de traitement. Cette extraction ne s'effectue que lors du traitement des annonces à partir des audiences personnalisées sur l'appareil. À ce stade, le côté achat peut appliquer des budgets, vérifier l'état de mise en veille ou de réactivation d'une campagne, procéder à un ciblage, etc.

Vous trouverez ci-dessous un exemple d'URL permettant d'extraire les données d'enchères approuvées en fonction des métadonnées des signaux d'enchères de confiance de l'audience personnalisée :

https://www.kv-server.example/getvalues?keys=key1,key2

La réponse du serveur doit être un objet JSON dont les clés sont key1, key2, etc., et dont les valeurs sont mises à la disposition des fonctions d'enchères de l'acheteur.

Côté vente : à l'instar du processus côté achat ci-dessus, le côté vendeur peut extraire des informations sur les créations prises en compte dans l'enchère. Par exemple, un éditeur peut souhaiter que certaines créations ne s'affichent pas dans son application pour des raisons de brand safety. Ces informations peuvent être extraites et mises à la disposition de la logique d'enchères côté vente. Comme pour le côté achat, la recherche de serveurs de confiance côté vente s'effectue également via une extraction HTTP. La composition de l'URL repose sur l'ajout de l'URL des signaux d'évaluation de confiance avec les URL de rendu des créations pour lesquelles les données doivent être extraites.

Vous trouverez ci-dessous un exemple d'URL permettant d'extraire des informations sur les créations concernées par l'enchère, en fonction des URL d'affichage :

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

La réponse du serveur doit être un objet JSON dont les clés sont des URL de rendu envoyées dans la requête.

Ces serveurs fonctionnent de manière sécurisée et offrent ainsi divers avantages en termes de sécurité et de confidentialité :

• La valeur renvoyée par le serveur pour chaque clé ne peut être approuvée que pour cette clé spécifique.
• Le serveur n'effectue pas de journalisation au niveau des événements.
• Il n'implique aucun autre effet secondaire basé sur ces requêtes.

Comme mécanisme temporaire, l'acheteur et le vendeur peuvent récupérer ces signaux d'enchères à partir de n'importe quel serveur, y compris celui qu'ils exploitent eux-mêmes. Cependant, dans la version finale, la requête n'est envoyée qu'à un serveur de type clé-valeur approuvé.

Les acheteurs et les vendeurs peuvent utiliser un serveur de clés-valeurs approuvé commun pour les plates-formes compatibles avec la Privacy Sandbox sur Android et pour le Web.