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

Permettre le ciblage d'audience personnalisée avec l'API Protected Audience

Informations récentes

Ajout d'informations sur la planification des mises à jour d'audiences personnalisées
Ajout de l'intégration d'Attribution Reporting avec les audiences protégées
Publication d'un calendrier des fonctionnalités de l'API Protected Audience.
FLEDGE a été renommé API Protected Audience.
Ajout d'une proposition de délégation d'audience personnalisée.
Suppression de l'exigence de k-anonymat pour l'URL de mise à jour quotidienne.

L'API Protected Audience est en version bêta et peut être testée sur des appareils publics.

Elle vous permet d'effectuer les actions suivantes :

Gérer les audiences personnalisées en fonction des actions précédentes des utilisateurs
Lancer les enchères sur l'appareil grâce à la médiation avec un seul vendeur ou à la médiation en cascade
Tester la génération de rapports sur les impressions après la sélection des annonces

Pour commencer, consultez le guide du développeur de l'API Protected Audience. N'hésitez pas à nous faire part de vos commentaires pour nous aider à développer Protected Audience.

Calendrier

De nouvelles fonctionnalités seront déployées dans les mois à venir. Les dates de sortie exactes varient selon la fonctionnalité, et ce tableau sera mis à jour avec des liens vers la documentation pertinente dès qu'elle sera disponible.

Fonctionnalité	Disponible dans la version Preview développeur	Disponible en version bêta
Création de rapports au niveau des événements	1er trimestre 2023	3e trimestre 2023
Médiation en cascade	1er trimestre 2023	4e trimestre 2023
Filtrage des annonces incitant à installer une application	2e trimestre 2023	3e trimestre 2023
Filtrage de la limite de la fréquence d'exposition	2e trimestre 2023	3e trimestre 2023
Transmission des annonces contextuelles au workflow de sélection des annonces pour le filtrage	2e trimestre 2023	3e trimestre 2023
Création de rapports sur les interactions	2e trimestre 2023	3e trimestre 2023
Participation à la délégation d'audience personnalisée	3e trimestre 2023	4e trimestre 2023
Facturation autre qu'au CPM	3e trimestre 2023	4e trimestre 2023
Intégration des services d'enchères et de mise aux enchères	3e trimestre 2023	4e trimestre 2023
Création de rapports de débogage	3e trimestre 2023	4e trimestre 2023
Intégration d'Attribution Reporting	N/A	4e trimestre 2023
Médiation Open Bidding	4e trimestre 2023	4e trimestre 2023
Gestion des devises	1er trimestre 2024	2e trimestre 2024
Intégration de K-anon	N/A	2e trimestre 2024
Intégration des rapports agrégables	3e trimestre 2024	4e trimestre 2024

Présentation

Dans le domaine de la publicité pour mobile, les annonceurs ont généralement besoin de 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 appli 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ée".

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 ad tech. Les annonceurs peuvent ainsi sélectionner des annonces pertinentes sur leurs serveurs.

L'API Protected Audience sur Android (anciennement FLEDGE) comprend les API ci-dessous pour les plates-formes ad tech et les annonceurs. Elle répond aux cas d'utilisation courants basés sur les interactions, en limitant le partage des deux identifiants entre les applications et le partage des informations sur les interactions de l'utilisateur avec des tiers :

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.
API Ad Selection: elle fournit un framework qui orchestre les plates-formes ad tech workflows qui utilisent des signaux sur l'appareil pour déterminez si vous êtes gagnant en tenant compte des annonces candidates stockées localement et un traitement supplémentaire sur les annonces candidates qu'une plate-forme ad tech est renvoyée à l'appareil.

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

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

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 ad tech pour diffuser ses annonces auprès des utilisateurs de sa liste d'audience. Cette plate-forme gère les métadonnées des listes d'audience et propose des annonces candidates qui sont mises à la disposition du workflow de sélection des annonces, qui choisit 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).
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 ad tech, 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 ad tech 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'appli d'éclairer la sélection des annonces, tout en limitant le partage de ces données avec des tiers.
Le SDK de l'appli de diffusion d'annonces ou de la plate-forme ad tech affiche l'annonce sélectionnée.
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 ad tech peuvent être personnalisées en fonction des types de rapports dont elles ont besoin.

Accéder aux API Protected Audience sur Android

Les plates-formes ad tech doivent s'inscrire pour accéder à l'API Protected Audience. 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 l'API Protected Audience dans Chrome et ne peuvent pas être partagées sur le Web ni entre les applications. Elles permettent 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ée

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 ad tech 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 ad tech 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 ad tech.
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. L'API Protected Audience permet de définir et de configurer des audiences personnalisées tout en protégeant la confidentialité des utilisateurs. 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). L'API Protected Audience vise à 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);

fetchAndJoinCustomAudience()

Une appli 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 fetchAndJoinCustomAudience() avec les paramètres attendus, comme dans l'exemple suivant :

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // 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("{...}")
);

fetchAndJoinCustomAudience(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 "Buyer" (Acheteur) et "Owner" (Propriétaire) de l'audience personnalisée sont ignorés (et sont renseignés automatiquement par l'API). L'API fait aussi en sorte que l'URL de mise à jour quotidienne corresponde également à l'eTLD+1 de l'acheteur.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "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/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

L'API fetchAndJoinCustomAudience() 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'appli 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. Hormis la vérification eTLD+1, il n'existe aucune autre validation de fetchUri, et en particulier aucune vérification k-anon. L'API fetchAndJoinCustomAudience() 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 fetchAndJoinCustomAudience. 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. L'appel d'API échoue également si la réponse de l'acheteur est incorrecte. Les échecs sont signalés à l'appelant de l'API responsable des nouvelles tentatives en raison d'échecs temporaires (par exemple, lorsque le serveur ne répond pas) ou de la gestion des é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 ces valeurs sont définies dans la requête, elles ne peuvent pas être remplacées par la réponse de l'acheteur reçue par la plate-forme. L'API Protected Audience ignore les champs de la réponse. Si elles ne sont pas définies dans la requête, alors elles doivent l'être dans la réponse, car ces champs sont obligatoires pour créer une audience personnalisée. Une représentation JSON du contenu de CustomAudience tel que défini partiellement par l'appelant de l'API est incluse dans la demande GET adressée à fetchUri dans un en-tête spécial X-CUSTOM-AUDIENCE-DATA. La taille de la forme sérialisée des données spécifiée pour l'audience personnalisée est limitée à 8 Ko. Si la taille est dépassée, l'appel d'API fetchAndJoinCustomAudience échoue.

En l'absence de vérification k-anon, vous pouvez utiliser fetchUri pour valider l'acheteur et pour permettre 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 fetchAndJoinCustomAudience() 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 l'API Protected Audience. Il 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 de l'API Protected Audience 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);

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 complètement l'API Protected Audience. Dans ce cas, toutes les audiences personnalisées existantes sur l'appareil sont effacées.
Les utilisateurs ont la possibilité de désactiver complètement la Privacy Sandbox sur Android, ce qui comprend l'API Protected Audience. Si l'utilisateur a désactivé la Privacy Sandbox, l'API Protected Audience échoue silencieusement.

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

Mises à jour planifiées

Les solutions décrites précédemment exigent que le SDK de l'application ou de la technologie publicitaire appelle les API lorsque l'application est au premier plan et fournisse les propriétés complètes de l'audience personnalisée, directement ou par délégation. Toutefois, il n'est pas toujours possible pour les annonceurs et les fournisseurs de technologie publicitaire de définir les audiences auxquelles un utilisateur appartient en temps réel lorsqu'il utilise l'application.

Pour faciliter ce processus, la technologie publicitaire peut appeler l'API scheduleCustomAudienceUpdate(). Cette API permet à l'appelant de spécifier un délai pour l'appel d'API, ce qui laisse plus de temps à la technologie publicitaire répondante pour traiter les événements au niveau de l'application et déterminer les audiences protégées auxquelles l'utilisateur doit adhérer ou être supprimé.

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest contient les informations nécessaires pour enregistrer une tâche différée à exécuter avec la plate-forme. Après ce délai, une tâche d'arrière-plan s'exécutera régulièrement et enverra les requêtes. La ScheduleCustomAudienceUpdateRequest peut contenir les informations suivantes:

UpdateUri: point de terminaison de l'URI devant recevoir un appel GET pour récupérer la mise à jour. L'identité de l'acheteur est intrinsèquement déduite de l'eTLD+1 et ne doit pas nécessairement être fourni explicitement et ne peut pas être modifiée par la réponse de mise à jour. GET attend un objet JSON contenant une liste d'objets customAudience dans retour.
DelayTime: temps indiquant le retard à partir du moment où scheduleCustomAudienceUpdate() pour planifier la mise à jour.

PartialCustomAudience : l'API permet également au SDK sur l'appareil d'envoyer une liste d'audiences personnalisées partiellement construites. Cela permet aux SDK intégrés à l'application de jouer un double rôle, du contrôle complet à la gestion partielle de l'audience personnalisée en fonction de leur partenariat avec les DSP.
- Cela permet également de la rendre compatible avec l'API fetchAndJoinCustomAudience(), qui permet de partager des informations similaires.
ShouldReplacePendingUpdates: valeur booléenne déterminant si des éléments en attente planifiées doivent être annulées et remplacées par la mise à jour détaillée dans le ScheduleCustomAudienceUpdateRequest actuel. Si cette valeur est définie sur false et des mises à jour demandées précédemment sont toujours en attente pour le même acheteur dans le même application, un appel à scheduleCustomAudienceUpdate avec cette ScheduleCustomAudienceUpdateRequest échouera. La valeur par défaut est false.

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 appli peut accorder à des plates-formes ad tech tierces des autorisations permettant de gérer les audiences personnalisées en son nom.

La conception de cette fonctionnalité est en cours. Des informations détaillées seront communiquées ultérieurement.

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 fetchAndJoinCustomAudience à 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.

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 l'API Protected Audience filtre les annonces en fonction des données sur l'appareil. Pour en savoir plus, consultez la section concernant la logique de filtrage côté achat.

Processus de sélection des annonces

Cette proposition vise à améliorer la confidentialité grâce à la mise en œuvre de l'API Ad Selection, qui orchestre l'exécution des enchères pour les plates-formes ad tech.

Aujourd'hui, les plates-formes ad tech 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 seront 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 ad tech 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 ad tech 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.

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 :

Exécution de la logique d'enchères côté achat
Traitement et filtrage des annonces côté achat
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 ad tech 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 ad tech 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 ad tech 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, d'informations de localisation approximatives ou du coût par clic sur l'annonce.
Signaux utilisateur : il peut s'agir d'informations sur les packages installés disponibles.

Coût des annonces

En plus de l'enchère, les plates-formes côté achat ont la possibilité de renvoyer le coût par clic dans le cadre de generateBid(). Par exemple :

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

Si cette annonce gagne, adCost est arrondi de manière stochastique à 8 bits pour des raisons de confidentialité. La valeur arrondie adCost est ensuite transmise au paramètre contextual_signals dans reportWin lors de la création de rapports sur les impressions.

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 Protected Audience, 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 ad tech 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 ad tech à 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 ad tech 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'appli 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 cloisonnés dans Chrome).

Rapports sur les impressions et les événements

Une fois l'annonce affichée, l'impression gagnante peut être signalée aux plates-formes côté achat et côté vente participantes. Cela permet aux acheteurs et aux vendeurs d'inclure des informations sur la mise aux enchères, telles que l'enchère ou le nom de l'audience personnalisée, dans le rapport sur les impressions gagnantes. De plus, la plate-forme côté vente et la plate-forme côté achat gagnante peuvent recevoir des rapports supplémentaires sur les événements concernant l'annonce gagnante. Vous pouvez inclure des informations sur la mise aux enchères (enchère, nom de l'audience personnalisée, etc.) avec les clics, les vues et d'autres types d'événements d'annonce. La plate-forme appelle la logique de création de rapports dans cet ordre :

Rapports côté vente
Rapports côté achat

Les plates-formes côté achat et côté vente peuvent ainsi renvoyer aux serveurs des informations importantes sur l'appareil afin d'activer des fonctionnalités comme la budgétisation en temps réel, la mise à jour des modèles d'enchères et des workflows de facturation précis. La prise en charge des rapports sur les impressions est complémentaire à l'API Attribution Reporting.

La création de rapports sur les événements s'effectue en deux étapes : JavaScript côté vente et côté achat doit enregistrer les événements pour lesquels il doit recevoir des rapports. Le côté vente est responsable de la création des rapports au niveau des événements.

Protected Audience permet de s'abonner aux futurs événements liés à une enchère gagnante en enregistrant des balises. Dans la fonction JavaScript reportResult() d'un vendeur, les plates-formes côté vente peuvent enregistrer des balises à l'aide de la fonction registerAdBeacon() de la plate-forme. De même, les plates-formes côté achat peuvent appeler la méthode registerAdBeacon() à partir de leur fonction JavaScript reportWin().

registerAdBeacon(beacons)

Entrée :

event_key : chaîne indiquant le type d'interaction demandé. Elle permet d'identifier le point de terminaison contacté par la plate-forme lors de la création de rapports sur les résultats de la mise aux enchères.
reporting_url : URL détenue par la plate-forme ad tech pour gérer l'événement.

Les clés d'événement sont des identifiants de chaîne détenus par le SDK côté vente chargé de créer des rapports sur les résultats de la mise aux enchères. Pour qu'un rappel soit effectué, les technologies publicitaires enregistrent les balises avec des clés qui correspondent à celles utilisées par le côté vente lors de la création de rapports sur les événements. Il n'est pas nécessaire que ces clés soient k-anonymes. Toutefois, la quantité et la longueur des clés pouvant être enregistrées pour une audience personnalisée donnée sont limitées. Si reportEvent() est appelé, les plates-formes côté vente qui ont participé à l'enchère continuent à pouvoir recevoir ces rapports sur les événements. Seule la plate-forme côté achat gagnante peut recevoir ces rapports.

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) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

Résultat : un objet JSON contenant

État : 0 en cas de réussite, ou toute autre valeur en cas d'échec.
URL de rapport : la plate-forme appelle cette URL affichée par la fonction.
Signaux pour l'acheteur : objet JSON à transmettre à la fonction reportWin de l'acheteur.

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 reportWin() 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.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

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 contient les informations sur l'audience personnalisée. D'autres informations pourront être ajoutées à l'avenir.

Sortie :

État : 0 en cas de réussite, ou toute autre valeur en cas d'échec.
URL de rapport : la plate-forme appelle cette URL affichée par la fonction.

Événements de rapport

Vous ne pouvez créer des événements de rapport qu'une fois que le rapport sur les impressions a été généré pour l'enchère. Le SDK côté vente est chargé de signaler tous les événements. La plate-forme expose une API qui utilise un objet ReportEventRequest spécifiant l'enchère récemment exécutée, la clé d'événement concernée et les données associées à cette clé. Elle précise si le rapport doit être envoyé ou non à l'acheteur ou au vendeur (ou aux deux), et un événement d'entrée facultatif pour les événements d'annonce. Le client définit la clé d'événement et la collecte des données qui seront prises en compte dans le rapport.

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

Entrée :

ad_selection_id doit être l'AdSelectionId d'une enchère récemment exécutée et récupérée à partir de l'AdSelectionOutcome.
event_key est une chaîne définie côté vente qui décrit l'événement d'interaction.
event_data est une chaîne représentant les données associées à l'event_key.
reporting_destinations est un masque de bits défini à l'aide des options fournies par la plate-forme. Il peut s'agir de FLAG_REPORTING_DESTINATION_SELLER, de FLAG_REPORTING_DESTINATION_BUYER ou des deux.
input_event (facultatif) est utilisé pour l'intégration à l'API Attribution Reporting. Il s'agit d'un objet InputEvent (pour un événement de clic) ou d'une valeur nulle (pour un événement de vue). Pour en savoir plus sur ce paramètre, consultez Intégration de l'API Attribution Reporting.

Une fois que le SDK côté vente a appelé reportEvent et selon l'indicateur reporting_destinations, la plate-forme tente de faire correspondre l'event_key avec les clés enregistrées par les acheteurs et les vendeurs dans leurs fonctions JavaScript reportWin et reportResult. En cas de correspondance, la plate-forme publie les event_data sur la reporting_url associée. Le type de contenu de la requête correspond à du texte brut, tandis que le corps correspond à l'event_data. Cette requête est effectuée dans les meilleurs délais et échoue en mode silencieux en cas d'erreur réseau, de réponse d'erreur du serveur ou de non-correspondance d'une clé.

Intégration de l'API Attribution Reporting

Pour aider les acheteurs qui participent à une mise aux enchères Protected Audience, nous fournissons des fonctionnalités multi-API dans les API Protected Audience et Attribution Reporting (ARA). Cette fonctionnalité permet aux technologies publicitaires d'évaluer leurs performances d'attribution selon différentes stratégies de remarketing, afin d'identifier les types d'audiences qui génèrent le ROI le plus élevé.

Grâce à cette intégration multi-API, les technologies publicitaires peuvent :

Créez un mappage clé-valeur des URI à utiliser à la fois pour 1) les rapports sur les interactions avec les annonces et pour 2) l'enregistrement de la source.
Inclure les données d'enchères issues des enchères Protected Audience dans leur mappage de clé côté source pour les rapports récapitulatifs agrégés (à l'aide de l'API Attribution Reporting). Pour en savoir plus, consultez la proposition de conception de l'ARA.

Lorsqu'un utilisateur voit une annonce ou clique dessus :

L'URL utilisée pour enregistrer ces interactions d'événements avec Protected Audience fournira à l'acheteur les données nécessaires pour qu'il puisse enregistrer une vue ou un clic en tant que source éligible avec l'API Attribution Reporting.
La technologie publicitaire peut choisir de transmettre des CustomAudience (ou d'autres informations contextuelles pertinentes sur l'annonce, telles que l'emplacement de l'annonce ou la durée de visionnage) à l'aide de cette URL afin que ces métadonnées puissent se propager dans les rapports récapitulatifs lorsque la technologie publicitaire examine les performances agrégées de la campagne.

Activer l'enregistrement de la source

reportEvent() accepte un nouveau paramètre facultatif InputEvent. Les acheteurs gagnants qui enregistrent des balises publicitaires peuvent choisir les rapports reportEvent à enregistrer auprès des API Attribution Reporting en tant que source enregistrée. L'en-tête de requête "Attribution-Reporting-Éligible" sera ajouté à toutes les demandes de création de rapports sur les événements envoyées depuis reportEvent(). Toutes les réponses avec des en-têtes ARA appropriés seront analysées de la même manière que toute autre réponse d'enregistrement de source ARA standard. Consultez la vidéo d'explication de l'API Attribution Reporting pour découvrir comment enregistrer une URL source.

Étant donné que l'ARA sur Android est compatible avec les événements de vue et de clic, les InputEvents permettent de distinguer ces deux types. Tout comme pour l'enregistrement d'une source ARA, l'API reportEvent() interprétera un InputEvent validé par la plate-forme comme un événement de clic. Si l'InputEvent est manquant, nul ou non valide, l'enregistrement de la source sera considéré comme une vue.

Notez que le eventData post-enchères peut contenir des informations sensibles. Par conséquent, la plate-forme supprime l'eventData dans les requêtes d'enregistrement de la source redirigée.

Exemple de rapport sur l'engagement et les conversions

Dans cet exemple, nous allons l'examiner du point de vue de l'acheteur, qui souhaite associer les données de la mise aux enchères, de l'annonce affichée et de l'application de conversion.

Dans ce workflow, l'acheteur se coordonne avec le vendeur pour envoyer un identifiant unique à la mise aux enchères. Lors de l'enchère, l'acheteur envoie cet identifiant unique avec les données d'enchères. Au moment de l'affichage et de la conversion, les données de l'annonce affichée sont également envoyées avec le même identifiant unique. Par la suite, l'identifiant unique pourra être utilisé pour associer ces rapports.

Workflow : avant le début de l'enchère, l'acheteur envoie un ID unique au vendeur dans le cadre de sa réponse à l'enchère en temps réel (RTB) programmatique. L'identifiant peut être défini en tant que variable, par exemple auctionId. L'identifiant est transmis en tant que perBuyerSignals dans auctionConfig. Il devient disponible dans la logique d'enchères de l'acheteur.

Lors de l'exécution de reportWin, l'acheteur peut enregistrer une balise publicitaire à déclencher pendant le délai d'affichage de l'annonce et pour des événements d'interaction spécifiques (registerAdBeacon()). Pour associer des signaux d'enchères à un événement d'annonce, définissez auctionId en tant que paramètre de requête de l'URL de la balise.
Pendant le délai d'affichage de l'annonce, les balises que vous avez enregistrées au moment des enchères peuvent être déclenchées ou améliorées à l'aide de données au niveau des événements. Le vendeur doit déclencher reportEvent() et transmettre les données au niveau de l'événement. La plate-forme pingue l'URL de la balise publicitaire enregistrée par l'acheteur qui est en corrélation avec l'élément reportEvent() déclenché.
L'acheteur enregistre l'annonce auprès de l'API Attribution Reporting en répondant aux requêtes de balise publicitaire avec l'en-tête Attribution-Reporting-Register-Source. Pour associer des signaux d'enchères à un événement de conversion, définissez auctionId dans l'URL source d'enregistrement.

Une fois le processus ci-dessus terminé, l'acheteur dispose d'un rapport sur les enchères, d'un rapport sur les interactions et d'un rapport sur les conversions. Ces rapports peuvent être mis en corrélation à l'aide de l'identifiant unique permettant de s'associer les uns aux autres.

Un workflow similaire s'applique à un vendeur s'il a besoin d'accéder aux données d'attribution. Le vendeur peut également utiliser un identifiant unique à envoyer avec registerAdBeacon(). L'appel reportEvent() contient une propriété de destination qui peut être utilisée pour envoyer le rapport à l'acheteur et au vendeur.

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 : lorsque la plate-forme côté achat initie la logique d'enchères côté achat, elle effectue une extraction HTTP des données d'enchères approuvées à partir du serveur de confiance. L'URL la procédure consiste à ajouter l'URL et les clés présentes dans le Métadonnées des signaux de l'audience personnalisée concernée traités. 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.