Pourquoi les problèmes de GPP sont difficiles à repérer

Lorsqu'un visiteur américain refuse la vente ou le partage de ses données, ce choix doit atteindre chaque partenaire publicitaire présent sur la page. Avec l'IAB Global Privacy Platform (GPP), il circule sous la forme d'une chaîne compacte et d'une liste d'identifiants de section. Si l'un des deux est erroné — manquant, périmé ou portant la mauvaise section — rien ne casse visiblement. Les annonces se chargent toujours, la bannière a toujours bonne allure, et le problème n'apparaît que plus tard, lorsque des partenaires ignorent les refus ou enchérissent moins sur votre inventaire.

La bonne nouvelle, c'est que l'on peut inspecter presque tout depuis la console du navigateur. Ce tutoriel passe en revue les vérifications dans l'ordre où nous les exécuterions sur une page en production.

Étape 1 : confirmer que l'API existe et est prête

Un CMP compatible GPP expose une fonction globale __gpp. Ouvrez les DevTools sur votre page et exécutez une commande ping :

__gpp('ping', function (data) { console.log(data); });

L'objet renvoyé en dit long au premier coup d'œil :

• gppVersion — doit indiquer 1.1 pour les implémentations actuelles.
• cmpStatus — indique si le CMP s'est chargé ou a rencontré une erreur.
• cmpDisplayStatus — indique si la bannière est visible, masquée ou désactivée pour ce visiteur.
• signalStatus — « ready » une fois que le CMP a arrêté un état de consentement, « not ready » tant qu'il hésite encore.
• supportedAPIs — les sections que le CMP peut produire.
• applicableSections — les identifiants de section qui s'appliquent à ce visiteur à cet instant.
• gppString — la chaîne encodée elle-même.

Si __gpp est undefined, le stub du CMP est absent ou se charge trop tard. Le stub doit être en place avant tout script publicitaire qui l'attend ; sinon ces scripts ne verront aucun CMP et attendront, ou poursuivront sans signal.

Étape 2 : vérifier la section applicable

Chaque cadre de confidentialité du GPP possède un identifiant de section numérique. Ceux que les éditeurs rencontrent le plus souvent sont 2 (EU TCF v2), 5 (TCF canadien), 7 (US National, « usnat ») et 8 et suivants pour les sections d'États individuels comme la Californie, la Virginie, le Colorado, l'Utah et le Connecticut. Un visiteur d'un État américain devrait normalement voir dans applicableSections soit la section nationale, soit la section de son État, et non la section européenne.

Testez depuis plusieurs lieux. Un bogue courant : un CMP qui détecte correctement la géographie pour la bannière mais écrit une section par défaut dans la chaîne quoi qu'il arrive, ou l'inverse. À l'aide d'un VPN ou des outils d'aperçu de votre CMP, comparez ce que montre la bannière avec ce que rapporte applicableSections.

Étape 3 : lire les données de la section

Plutôt que de décoder la chaîne à la main, demandez au CMP la section analysée :

__gpp('getSection', function (data, success) { console.log(data, success); }, 'usnat');

Dans la section US National, les champs de refus suivent une convention simple : 0 signifie non applicable, 1 signifie que l'utilisateur a refusé, et 2 signifie que l'utilisateur n'a pas refusé. Concentrez-vous d'abord sur ces champs :

• SaleOptOut et SharingOptOut
• TargetedAdvertisingOptOut
• Les champs notice correspondants, qui indiquent si le visiteur a reçu une information sur chaque pratique

Effectuez maintenant le refus sur la page — cliquez sur votre lien « Do Not Sell or Share » ou basculez le réglage dans le centre de préférences — puis relancez getSection. Les champs de refus devraient passer de 2 à 1. Sinon, l'interface et le signal ne sont pas synchronisés.

Étape 4 : tester le chemin Global Privacy Control

Plusieurs lois d'État exigent que les entreprises traitent un signal Global Privacy Control comme un refus. Activez le GPC dans un navigateur ou une extension qui le prend en charge, confirmez que navigator.globalPrivacyControl renvoie true dans la console, puis chargez la page dans une session vierge. Les champs de refus concernés devraient déjà indiquer 1 sans que le visiteur ait touché à la bannière. Certaines sections comportent aussi un champ indiquant que le choix provient d'un signal GPC.

Étape 5 : surveiller les événements, pas seulement des instantanés

Les scripts publicitaires ne devraient pas lire la chaîne une seule fois au chargement de la page puis l'oublier. Enregistrez un listener pour voir ce que voient les partenaires :

__gpp('addEventListener', function (evt) { console.log(evt.eventName, evt.pingData); });

Vous devriez observer des événements tels que listenerRegistered, signalStatus et sectionChange. Lorsque le visiteur modifie un choix, un événement sectionChange avec une chaîne mise à jour doit suivre. Si votre wrapper de header bidding ou votre intégration de l'ad server ne lit la chaîne qu'avant que signalStatus ne passe à « ready », il peut envoyer une valeur vide ou obsolète.

Étape 6 : suivre la chaîne jusque dans les requêtes publicitaires

Enfin, ouvrez l'onglet Network et filtrez vos requêtes publicitaires. De nombreux points d'accès publicitaires acceptent les paramètres gpp et gpp_sid (la chaîne et les identifiants de section applicables). Vérifiez que :

1. les deux paramètres sont présents sur les requêtes des visiteurs américains ;
2. la chaîne correspond à celle renvoyée par ping au moment de la requête ;
3. après un refus, les requêtes suivantes portent la nouvelle chaîne et non une version en cache.

Si vous utilisez Prebid.js, confirmez que son module de gestion du consentement est configuré pour le GPP, et inspectez les requêtes d'enchères qui quittent le wrapper ainsi que l'appel final à l'ad server.

Schémas de défaillance courants

• Le stub se charge après les balises publicitaires — les partenaires ne voient aucun CMP.
• Mauvaise section pour la région — section européenne envoyée pour du trafic américain, ou aucune section.
• Interface et signal désynchronisés — le réglage change, la chaîne non.
• GPC ignoré — le signal du navigateur ne devient jamais un refus.
• Chaînes périmées dans les requêtes — le wrapper met en cache la première valeur vue.

À retenir

• Commencez par ping : version, statut, sections applicables et chaîne en disent la majeure partie.
• Utilisez getSection pour lire les champs de refus ; 1 signifie refus, 2 signifie absence de refus.
• Testez séparément le lien de refus et le GPC, et confirmez que les deux modifient le signal.
• Écoutez les événements et attendez un signal « ready » avant que les requêtes publicitaires ne lisent la chaîne.
• Vérifiez gpp et gpp_sid dans les vraies requêtes réseau, avant et après un refus.