Changer de plateforme de gestion du consentement sans casser votre suivi

Tous les articles

Procédez dans cet ordre : installez la nouvelle plateforme à côté de l'ancienne, rebranchez chaque condition de consentement sur le nouveau signal, puis retirez l'ancienne plateforme en dernier. Ce qui casse une migration, c'est rarement la nouvelle bannière. C'est ce que l'ancienne laisse derrière elle dans votre gestionnaire de balises : des variables qui lisent des cookies qui n'existent plus, et les exceptions construites dessus.

Pourquoi la nouvelle bannière est-elle la moitié facile ?

Les pages de migration publiées par les fournisseurs de consentement s'accordent globalement sur l'ordre des étapes : audit, export de vos enregistrements de consentement, déploiement du nouveau script, mise en ligne. Ces pages annoncent généralement trois à dix jours. Cet ordre est exact, et c'est la moitié du travail qui se signale d'elle-même quand elle échoue.

La moitié dont personne ne parle, c'est ce que la plateforme sortante laisse dans le conteneur. Un outil de consentement installé dans un gestionnaire de balises n'est jamais une seule balise. C'est un modèle, des variables qui lisent ses cookies, des déclencheurs à l'écoute de ses événements et, surtout, les exceptions que d'autres ont construites sur ces variables au fil des années. Supprimez la balise et tout cela reste exactement où c'était, toujours activé, toujours évalué à chaque chargement de page.

Que fait une variable morte à une règle de blocage ?

Une variable qui lit un cookie de consentement renvoie la valeur de ce cookie. Une fois partie la plateforme qui l'écrivait, le cookie disparaît, et la variable renvoie undefined sur chaque page.

Prenez maintenant la règle construite dessus. Les conditions de blocage s'écrivent à la forme négative : bloquer cette balise quand la variable de consentement ne contient pas la catégorie dont elle a besoin. Face à un vrai cookie, c'est faux dès que le consentement a été donné, et la balise se déclenche. Face à undefined, c'est vrai. Toujours, pour chaque visiteur, y compris ceux qui ont tout accepté.

Une exception toujours vraie, c'est une balise qui ne se déclenchera plus jamais.

Sur un site en production que nous avons audité après un changement de plateforme, quatre balises avaient été bloquées en silence de cette façon pendant environ huit mois, dont la conversion publicitaire principale. Personne n'avait touché à ces balises. Le conteneur était valide, la nouvelle bannière fonctionnait et le signal Consent Mode était correct. Les règles de blocage pointaient simplement vers une plateforme qui n'était plus là.

Comment changer de plateforme sans trou dans le suivi ?

1. Inventoriez ce qui appartient à l'ancienne plateforme

   Exportez le conteneur en JSON et cherchez-y le nom de l'ancien fournisseur. Vous cherchez quatre choses, pas une : son modèle de balise, les variables qui lisent ses cookies, les déclencheurs à l'écoute de ses événements et chaque exception construite sur ces variables.

2. Notez quel signal conditionne chaque balise, avant et après

   Une ligne par balise conditionnée : la condition qui la retient aujourd'hui, et celle qui la retiendra une fois la nouvelle plateforme en place. Faites-le tant que l'ancienne configuration est encore active et lisible. C'est ce qui vous permettra de vérifier le changement ensuite.

3. Laissez la nouvelle plateforme gérer les valeurs par défaut

   La nouvelle plateforme se place sur Consent Initialization et fixe les valeurs par défaut refusées pour ad_storage, analytics_storage, ad_user_data et ad_personalization. Le guide de Google sur le mode de consentement demande que ces valeurs par défaut soient en place avant qu'une balise n'envoie des données de mesure. Retirez les anciennes valeurs par défaut dans la même version : deux commandes default concurrentes sont un vrai risque, pas une double sécurité.

4. Reconstruisez les exceptions avant de supprimer quoi que ce soit

   Chaque règle de blocage construite sur les variables de l'ancienne plateforme est d'abord réécrite sur le nouvel état du consentement, tant que les anciennes variables renvoient encore de vraies valeurs et que vous pouvez comparer les comportements. C'est l'étape que les migrations sautent, parce que les exceptions vivent ailleurs dans le conteneur.

5. Supprimez les anciennes variables et les modèles en dernier

   Seulement une fois que plus rien n'y fait référence. Un gestionnaire de balises vous indique ce qui pointe encore vers une variable : travaillez jusqu'à ce que cette liste soit vide, puis supprimez les variables et le modèle du fournisseur. Un modèle orphelin reste enregistré.

6. Vérifiez ce qui se déclenche, pas seulement ce qui fuit

   Sur un profil vierge, refusez tout et vérifiez qu'aucun cookie publicitaire ou d'analyse n'est déposé. Puis acceptez, et parcourez votre liste de l'étape deux en vérifiant que chaque balise se déclenche réellement. Enfin, comparez les conversions de cette semaine avec celles de la semaine précédant le changement.

Le volet refus de cette vérification mérite d'être mené sérieusement plutôt qu'à la va-vite : la séquence complète d'avant mise en ligne est ici, et les deux lectures qui confirment le signal Consent Mode sont ici.

Qu'est-ce qui survit à une migration alors que ça ne devrait pas ?

Les modèles de variables orphelins. Supprimer les balises d'un fournisseur ne désinstalle pas ses modèles. Ils restent dans le conteneur, inutilisés mais enregistrés, et faciles à manquer. Supprimez-les avec les variables.

Les mappings de consentement en tout ou rien. Les configurations anciennes conditionnent souvent tout à un unique événement d'acceptation globale plutôt qu'à des catégories. Si c'est ce que vous migrez, chaque visiteur qui avait accepté certaines catégories et refusé les autres était déjà invisible, indépendamment du changement. Vous touchez de toute façon à chaque balise conditionnée : passez donc à des conditions par catégorie plutôt que de reproduire l'ancienne logique dans un nouvel outil.

Les scripts qui n'ont jamais été dans le conteneur. Un script de fournisseur collé directement dans le head du site n'était pas non plus conditionné par l'ancienne plateforme, et la nouvelle ne l'atteindra pas tant que vous ne l'aurez pas déplacé dans le conteneur ou encapsulé. Savoir si un script donné peut être déplacé mérite d'être tranché script par script, et une migration est le moment naturel pour le faire.

Qu'advient-il du consentement que les visiteurs ont déjà donné ?

Prévoyez que les visiteurs soient sollicités à nouveau. Une plateforme lit sa propre décision enregistrée : sauf si la nouvelle est configurée pour lire le cookie de l'ancienne, les visiteurs qui reviennent voient la bannière une fois de plus après le changement.

Conservez les anciens enregistrements. Au titre de l'article 7(1) du RGPD, lorsque le traitement repose sur le consentement, le responsable du traitement doit être en mesure de démontrer que le visiteur l'a donné. Cette obligation ne prend pas fin quand l'outil qui l'a consigné est retiré. Exportez le journal de consentement de l'ancienne plateforme avant la fin du contrat, et notez la date à laquelle la nouvelle plateforme a pris le relais. Ce que contient un enregistrement de consentement exploitable est expliqué ici.

Comment savoir si c'est déjà arrivé chez vous ?

Si vous avez changé de plateforme par le passé sans jamais faire l'étape six, deux vérifications vous diront où vous en êtes.

Dans le conteneur, cherchez le nom du fournisseur précédent. Tout ce qui ressort est un reste. Toute exception construite sur une variable qui lit un cookie qu'aucune plateforme n'écrit plus bloque sa balise en ce moment même. Et ce, depuis le jour où l'ancien outil a été retiré.

Dans les données, prenez votre conversion la plus importante et regardez sa tendance sur douze mois plutôt que sur trente jours. Un blocage silencieux ne ressemble pas à un déclin. Il prend la forme d'une marche nette, presque jusqu'à zéro, à une date précise, puis d'un plateau : une forme qu'aucune évolution d'audience ou de marché ne produit. Comparez cette date avec celle du changement de plateforme. Les autres causes d'une chute du jour au lendemain sont ici ; celle-ci est la plus lente à être repérée, car les balises dont la condition a cassé ne sont qu'une partie du total, et le total baisse sans disparaître.

Velo est souvent la plateforme vers laquelle on migre : ce conseil n'est donc pas désintéressé. C'est pourtant le bon conseil : les restes appartiennent à l'outil que vous quittez, et aucune nouvelle bannière ne peut les nettoyer à votre place. Prévoyez un budget pour le travail sur le conteneur, pas seulement pour l'installation.