- Le tag du fournisseur doit voyager avec le créatif, de la configuration de campagne jusqu’à la réponse d’enchère.
- Le storefront doit insérer le script dans la bannière rendue après que l’acheteur a donné son consentement.
@topsort/verification pour gérer ces étapes.
La bibliothèque d’aide prend actuellement en charge IAS uniquement. Elle réduit le code personnalisé nécessaire pour gérer l’insertion des tags, les re-renders de bannières, la rotation des publicités et les changements de consentement.
La bibliothèque est disponible pour tous les clients Topsort et fonctionne avec ou sans Banners.js. Suivez les étapes ci-dessous pour un moteur de rendu de bannières personnalisé. Si vous utilisez Banners.js, consultez aussi Utilisation de Banners.js.
Avant de commencer
- Vos bannières doivent utiliser des modèles JSON, qui définissent des champs créatifs nommés.
- Vous avez besoin d’une Consent Management Platform (CMP) pour collecter et enregistrer le consentement de l’acheteur. Topsort et cette bibliothèque ne fournissent pas de CMP. Vous connectez la bibliothèque à votre CMP existante via un adaptateur de consentement.
Étape 1 : Configurer le modèle de bannière
Lors de la création du modèle de bannière, incluez un champ texte nomméverificationTag. Ce champ contient le tag de vérification de l’annonceur.
Vous pouvez utiliser un autre nom de champ, à condition que votre storefront lise le même nom dans la réponse d’enchère. Ce guide utilise verificationTag.
Étape 2 : Fournir le tag de vérification
Lors de la création de campagne, l’annonceur colle dans le champ du modèle le tag fourni par son fournisseur de vérification. Pour la prise en charge IAS actuelle de la bibliothèque, la valeur acceptée est exactement un tag script externe :- L’URL doit utiliser HTTPS.
- Le hostname doit être
staticjs.adsafeprotected.com. - Le chemin doit être
/fw.js. - L’URL doit contenir exactement un
advEntityIdnumérique et unpubEntityIdnumérique. - Le JavaScript inline, les attributs supplémentaires, les éléments supplémentaires, les autres hôtes, les ports explicites et les fragments d’URL sont rejetés.
Étape 3 : Lire le tag dans la réponse d’enchère
Les champs du modèle sont renvoyés dans l’objetcontent de l’asset gagnant. Lisez verificationTag en même temps que l’URL de l’image, le titre et les autres champs créatifs.
Dans la réponse d’enchère brute, il s’agit de winner.asset[index].content.verificationTag, où index identifie l’asset que vous affichez.
Les exemples ci-dessous supposent que votre application mappe l’objet content de cet asset vers banner.content et le resolvedBidId du gagnant vers banner.resolvedBidId. Il s’agit de mappings au niveau de l’application, pas d’un format de réponse d’enchère différent.
Étape 4 : Enregistrer la bannière rendue
La bibliothèque insère le script validé dans le conteneur de la bannière une fois le consentement accordé. Elle gère aussi les changements d’enregistrement lorsque les bannières sont re-rendues, rotées ou retirées. Trois termes apparaissent dans les exemples :- Runtime : L’objet renvoyé par
createVerificationRuntime(...). Il se connecte à votre adaptateur de consentement et suit les éléments de bannière enregistrés. Créez un runtime pour la page et réutilisez-le pour toutes les bannières. - Register : L’appel à
register(...)fournit l’élément de bannière, le tag de vérification et la clé de rendu. La bibliothèque vérifie le consentement avant d’insérer le script. - Handle : L’objet renvoyé par
register(...). Sa méthodedispose()termine l’enregistrement et supprime le nœud script inséré par la bibliothèque.
consentSource décrit dans Connectez votre CMP, puis enregistrez chaque bannière une fois son élément conteneur disponible :
renderKey distingue un re-render de la même publicité d’une nouvelle publicité rendue dans le même élément. L’enregistrement d’un nouveau renderKey sur le même élément démonte et remplace automatiquement l’enregistrement précédent.
Gardez la clé stable pour les re-renders de la même publicité, et changez-la pour le rendu d’une nouvelle publicité.
Si element n’est pas un élément valide, si le tag est vide ou si renderKey est vide, register ne fait rien et ne charge rien. Il ne lève pas d’erreur dans votre code de rendu de bannières.
Utilisation de React
Pour React, créez le runtime une fois dans un module partagé et importez-le partout où vous rendez des bannières. Ne le créez pas à l’intérieur d’un composant, où des montages répétés créeraient des runtimes et des abonnements de consentement distincts.useVerificationRef renvoie un callback ref. React l’appelle avec le nœud DOM au montage de la bannière et avec null au démontage. Le helper enregistre la bannière et gère le nettoyage, vous n’appelez donc pas dispose() vous-même.
Connectez votre CMP
La bibliothèque n’affiche aucune UI de consentement et ne communique pas directement avec votre CMP. Vous fournissez un adaptateur avec deux fonctions :current()renvoie l’état de consentement actuel.subscribe(listener)signale les changements de consentement et renvoie une fonction qui arrête l’écoute.
"unknown", "granted" ou "denied".
L’exemple suivant illustre la structure de l’adaptateur. Remplacez readMyCmp() et myCmp.on/off par les APIs réelles de votre CMP :
unknown: Attend sans parser le tag, récupérer le script du fournisseur ni modifier le DOM.granted: Valide le tag, crée un nouvel élément<script>à partir dusrcvalidé et l’ajoute dans l’élément de bannière. Elle n’insère pas de markup stocké viainnerHTML.denied: Termine l’enregistrement sans charger le script.
"granted" contourne le contrôle du consentement et permet à IAS de se charger dès l’enregistrement de la bannière.
Si le consentement est retiré plus tard, la bibliothèque termine l’enregistrement et supprime son propre nœud script. Elle ne peut pas annuler le code fournisseur déjà exécuté, les requêtes déjà envoyées, les globals déjà définis ni le stockage déjà écrit. Le nettoyage est au mieux et ne couvre que le nœud script créé par la bibliothèque.
Vérifier l’intégration
Passez un callbackonDiagnostic à la création du runtime pour recevoir des codes d’état tels que :
registeredactiveconsent_deniedinvalid_tagprovider_load_failedprovider_load_timeout
active signifie seulement que le script du fournisseur a fini de se charger. Cela ne confirme pas qu’IAS a enregistré une impression, considéré la publicité comme visible ou accepté les données. Confirmez la mesure dans les rapports IAS.
Content Security Policy
Si votre storefront utilise une Content Security Policy (CSP), autorisezstaticjs.adsafeprotected.com dans script-src pour que le navigateur puisse charger le script IAS.
Ceci n’est pas une allowlist de production complète. L’ensemble des origines IAS requises pour script-src, connect-src, img-src et frame-src reste soumis à la validation côté IAS.
Utilisation de Banners.js
La même configuration de modèle et le même adaptateur de consentement s’appliquent lorsque vous utilisez Banners.js. Après que Banners.js a rendu une bannière et déclenché son événementready :
- Identifiez l’élément conteneur de la bannière rendue.
- Lisez
verificationTagdans le content de modèle du créatif gagnant. - Enregistrez l’élément, le tag et la clé de rendu auprès du runtime de vérification, comme indiqué à l’étape 4.