La limitation de la fréquence d'exposition est une pratique publicitaire qui limite le nombre d'annonces d'une catégorie donnée diffusées auprès d'un utilisateur pendant une période donnée. Elle améliore l'expérience des utilisateurs finaux en renouvelant les impressions d'annonces et aide les annonceurs à gérer leur budget publicitaire.
Cette proposition explique comment l'API Protected Audience sur Android peut être utilisée pour implémenter une fonctionnalité de limitation de la fréquence d'exposition de manière précise tout en protégeant la confidentialité.
L'API Protected Audience implémente la limitation de la fréquence d'exposition en combinant deux fonctionnalités : le stockage sur l'appareil de compteurs pour les événements spécifiques aux annonces et la possibilité de filtrer les annonces en fonction d'un ensemble prédéfini de stratégies de filtrage. La limitation de la fréquence d'exposition permet aux annonceurs d'indiquer un seuil de compteur au-dessus d'une somme de valeurs d'histogramme pour une période donnée.
Les compteurs sont uniques pour chaque combinaison de profil d'appareil, de technologie publicitaire et de clé de compteur. Chaque annonce doit contenir un ensemble de clés de compteur à utiliser si une vue ou une impression est enregistrée pour l'annonce. Pour chaque clé, l'API Protected Audience stocke un ensemble de compteurs. Chaque compteur comptabilise tous les événements propres aux annonces qui se produisent dans un intervalle de temps spécifique. Les compteurs sur l'appareil sont incrémentés à chaque impression ou vue, et les données du compteur sont conservées sur l'appareil. La durée de conservation exacte est définie ultérieurement.
La logique de filtrage des annonces du workflow de sélection d'annonces de l'API Protected Audience a accès aux compteurs, aux annonces de remarketing et aux annonces contextuelles. La limitation de la fréquence d'exposition de l'API Protected Audience permet ainsi d'utiliser tous ces types de demandes d'annonces.
Remarque : Le filtrage des annonces n'est disponible que dans la Privacy Sandbox sur Android. L'implémentation de l'API Protected Audience dans Chrome n'offre actuellement pas de mécanisme pour filtrer des annonces contextuelles autres que celles de Protected Audience. Cette proposition ne traite que de la prise en charge côté achat. Si la demande est suffisante, nous proposerons la prise en charge côté vente ultérieurement.
La limitation de la fréquence d'exposition de l'API Protected Audience est compatible avec un large éventail d'exigences, y compris :
- Filtrage en temps réel, avec un retard minimal côté serveur lorsque les compteurs sur l'appareil sont mis à jour
- Hiérarchie flexible des clés, y compris pour les annonces individuelles, les campagnes ou tout autre regroupement
- Congruence avec d'autres méthodes de limitation de la fréquence d'exposition, sans dépendre de l'identifiant publicitaire
- Compatibilité avec toutes les applications d'un profil utilisateur donné
- Compteurs précis et complets
- Prise en charge des définitions personnalisées des événements d'annonce, comme les vues ou les impressions
- Une seule fonctionnalité aussi bien pour les annonces de remarketing que pour les annonces contextuelles
Pour configurer la limitation de la fréquence d'exposition, procédez comme suit :
Étape 1 : ajouter aux annonces les informations de limitation de la fréquence d'exposition
Les annonces contextuelles et de remarketing indiquent les compteurs d'histogramme pertinents à mettre à jour en cas de vue ou d'impression à l'aide du champ ad_counter_keys qui contient une liste de nombres entiers arbitraires. Ce champ n'est pas inclus dans le champ metadata, qui n'est pas analysé par l'API Protected Audience.
L'exemple suivant présente le format de données du champ adsData dans AdSelectionConfig. Pour le remarketing, le format de la liste d'annonces pour une audience personnalisée donnée est cohérent avec le contenu du champ ads illustré dans l'exemple suivant :
'adsData': [
{
"buyer": "ads.example.com",
"ads": [
{
'render_url': 'exampleUrl',
'metadata': {...}, /* metadata are opaque to Protected Audience are
required to be in valid JSON format */
'ad_counter_keys': [1234, 5678]
}]
}]
}
Étape 2 : enregistrer une vue ou une impression
Les technologies publicitaires peuvent appeler la méthode updateAdCounterHistogram pour enregistrer des occurrences d'événements utilisées pour la limitation de la fréquence d'exposition. Une méthode peut être invoquée plusieurs fois au cours d'un même événement pour les clés spécifiées dans l'eventType de l'annonce gagnante.
void updateAdCounterHistogram(@EventType eventType, long adSelectionId)
Entrées :
eventType: indique si un événement est compté comme une vue, une impression, un clic ou une victoire dans le processus de sélection des annonces.adSelectionId: valeurs d'ID dans l'objetAdSelectionOutcomequi sont renvoyées par les appelsselectAds.
L'appel updateAdCounterHistogram met à jour l'histogramme pour l'ensemble de clés défini pour les annonces de remarketing récupérées par un CustomAudience ou pour les annonces contextuelles incluses dans le paramètre AdSelectionConfig pour selectAds.
Supposons que l'annonce de l'étape 1 remporte l'AdSelection avec une valeur d'id de 9999. L'appel à updateAdCounterHistogram(FrequencyCapFilters.AD_EVENT_TYPE_VIEW,
adSelectionId: 999) incrémente les compteurs des trois clés principales suivantes :
{'ads.example.com', 1234, VIEW}{'ads.example.com', 5678, VIEW}
Le nom de la technologie publicitaire provient du champ "buyer" (Acheteur) des annonces contextuelles ou des audiences personnalisées, selon l'origine des annonces gagnantes.
L'API Protected Audience pour Android incrémente automatiquement tous les compteurs mentionnés ci-dessus pour le type d'événement FrequencyCapFilters.AD_EVENT_TYPE_WIN correspondant aux annonces renvoyées par un appel d'API selectAds. D'un point de vue fonctionnel, cela revient à ajouter l'argument prev_wins à browser_signals dans generateBid dans l'implémentation Chrome de l'API Protected Audience.
Étape 3 : implémenter le filtrage de la limitation de la fréquence d'exposition
Pour des performances optimales, la fonction de filtrage de la limitation de la fréquence d'exposition est exécutée dans AdServices. L'API Protected Audience est en mesure de déterminer si un message doit être filtré en lisant le champ de filtres de l'objet AdsData. Une liste de filtres est spécifiée dans frequency_cap. Les valeurs de clé event_type et interval_in_seconds permettent de récupérer un histogramme des événements utilisés pour le filtrage et pour Protected Audience.
Les informations de filtrage peuvent être spécifiées pour les annonces de remarketing fournies par une audience personnalisée et pour les annonces contextuelles incluses dans l'objet AdSelectionConfig.
Pour les annonces contextuelles comportant des filtres de limitation de la fréquence d'exposition, les annonces sont transmises à l'aide du champ "ads" (Annonces) de l'objet AdSelectionConfig. Les annonces sont filtrées, et l'annonce avec l'enchère la plus élevée est renvoyée à la suite de l'appel selectAds.
Pour les annonces de remarketing comportant des filtres de limitation de la fréquence d'exposition, les annonces sont filtrées avant que la fonction JavaScript generateBid() fournie par l'acheteur ne soit appelée.
L'exemple suivant présente un message avec filtrage de la limitation de la fréquence d'exposition :
{
'render_url': 'url',
'metadata': {...}, /* metadata are opaque to Protected Audience and assumed
to be in valid JSON format */
'ad_counter_keys': [1234, 5678],
"filters": {
"frequency_cap": {
"view": [
{
"ad_counter_key": 1234
"max_count": 10,
"interval_in_seconds": 86400
},
{
"ad_counter_key": 5678
"max_count": 10,
"interval_in_seconds": 86400
},
],
"win": [
{
"ad_counter_key": 1234
"max_count": 5,
"interval_in_seconds": 604800
},
{
"ad_counter_key": 5678
"max_count": 5,
"interval_in_seconds": 345600
},
]
},
// This field is only required in contextual ads and is used in
// reportImpression calls to fetch the reportWin function.
'reportingJS': "https://ads.example.com?reportWin.js"
}
Étape 4 : générer des rapports sur les annonces gagnantes
À la fin du processus de sélection d'annonces, un objet AdSelectionOutcome contenant les identifiants renderUri et adSelectionId, identifiant numérique de l'appel selectAds, est renvoyé. Cet ID peut être utilisé pour appeler l'API reportImpression, qui prend actuellement en charge la création de rapports au niveau des événements. Dans la version bêta 1, cette méthode prend en charge les rapports sur les annonces de remarketing. Elle sera étendue aux rapports sur les annonces contextuelles dans une prochaine version. Pour les annonces contextuelles, l'acheteur doit indiquer où la fonction reportWin peut être récupérée lors d'un appel reportImpression en utilisant un champ supplémentaire appelé reportingJS dans la structure de l'annonce, comme dans l'exemple ci-dessus.
Bonnes pratiques pour la sélection des annonces candidates
Protected Audience transfère l'application de la limitation de la fréquence d'exposition du serveur à l'appareil. Bien que les enchères gagnantes soient signalées avec la Privacy Sandbox, les développeurs ne peuvent pas savoir pourquoi une annonce n'est pas diffusée. Les annonces peuvent ne pas être diffusées pour cause d'enchère perdue ou en raison de la limitation de la fréquence d'exposition. Sans visibilité complète sur les raisons pour lesquelles certaines annonces ne gagnent pas, les systèmes d'enchères ont besoin d'opérations supplémentaires pour garantir une diffusion d'annonces optimales. Ces bonnes pratiques vous aideront à optimiser la diffusion d'annonces avec l'API Protected Audience.
Envoyer suffisamment d'annonces de remarketing
Les annonces de remarketing ne peuvent pas être optimisées par utilisateur. Si un utilisateur voit un grand nombre d'annonces provenant d'une audience personnalisée et que les limites d'annonces sont faibles, toutes les annonces risquent d'être filtrées. Les annonces de remarketing sont actualisées régulièrement. Par conséquent, la limitation de la fréquence d'exposition doit permettre la transmission d'un inventaire publicitaire suffisant pour garantir la diffusion des annonces de remarketing. Cette exigence doit être contrebalancée par des limites sur la taille des annonces, qui peuvent être spécifiées lors de l'appel joinCustomAudience et de la mise à jour quotidienne de l'audience personnalisée. Les acheteurs doivent tenir compte d'une augmentation potentielle de la latence lors de la phase d'enchères. Pour minimiser l'impact de ces problèmes, le filtrage de la limitation de la fréquence d'exposition est effectué avant l'appel de generateBid.
Conserver les compteurs contextuels sur le serveur
Avec l'estimation côté serveur, un développeur peut estimer approximativement quand la limitation de la fréquence d'exposition est active. Ces estimations peuvent indiquer qu'une annonce a probablement atteint le seuil de limitation de la fréquence d'exposition et doit donc être envoyée avec davantage d'annonces candidates ou être complètement éliminée.
Envoyer plusieurs annonces candidates sur la réponse contextuelle
Envoyez plusieurs annonces candidates avec une réponse contextuelle avant une mise aux enchères Protected Audience. Ainsi, si plusieurs annonces sont filtrées, d'autres continuent d'être diffusées. Il est possible de donner la priorité à certaines annonces candidates afin que certaines d'entre elles puissent être utilisées en remplacement.
Comme l'exécution est limitée dans le temps, les annonces candidates doivent être choisies en fonction de leur probabilité de remporter une mise aux enchères et de ne pas être filtrées.
Limites
Voici les limites connues de la limitation de la fréquence d'exposition Protected Audience :
- La limitation de la fréquence d'exposition Protected Audience fonctionne au niveau du profil utilisateur sur l'appareil. Aucun compteur n'est actuellement partagé sur d'autres appareils ni d'autres profils. Au besoin, vous pouvez intégrer manuellement les incréments des annonces diffusées depuis d'autres appareils.
- Les compteurs sont stockés sur l'appareil et accessibles depuis celui-ci. Les compteurs côté serveur doivent être gérés séparément.
- Étant donné que la limitation de la fréquence d'exposition et le filtrage des annonces associé sont traités sur l'appareil, les plates-formes ad tech ne contrôlent pas directement ces opérations. Pour contourner le seuil de limitation de la fréquence d'exposition de l'appareil, les plates-formes ad tech peuvent envoyer plusieurs annonces candidates avec des filtres différents.
- Les ajustements des enchères basés sur la fréquence enregistrée ne sont pas acceptés. Les fonctions
generateBidne peuvent pas afficher les compteurs de fréquence.
Recommandations personnalisées
- Remarque : Le texte du lien s'affiche lorsque JavaScript est désactivé
- API Protected Audience : guide d'intégration
- Guide du développeur de l'API Protected Audience sur Android
- Permettre le ciblage d'audience personnalisée avec l'API Protected Audience