Aller au contenu

Témoignage – Incidents liés à la gestion de tags

J'étais précédemment responsable process & qualité analytics dans une grande agence web internationale.

Voici les pires soucis auxquels j'ai été confronté. J'espère que mon témoignage évitera à certains des mes lecteurs de connaitre les mêmes horreurs.

Un grand site e-commerce qui tombe à cause d'un tag tiers

Les faits :

Un jour, un grand site e-commerce rencontrait des problèmes de stabilité. La charge sur le serveur était anormalement élevée. Par chance, un développeur a remarqué que les pages se chargeaient indéfiniment.

Chaque page s'appellait dans une iframe qui s'appelait dans une iframe qui s'appelait dans une iframe...

J'ai essayé de reproduire le problème. Ce serait un peu comme si quelqu'un avait posé ce type de tag.

(function(){
var ifr = document.createElement('iframe');
ifr.src=top.location.href;
document.body.appendChild(ifr);
})();

Par chance également, le développeur a suspecté que le problème venait du gestionnaire de tag et nous a contacté.
Il a désactivé temporairement le gestionnaire de tags le temps de notre audit.

Aucune publication n'avait été faite sur le gestionnaire de tags depuis très longtemps. Mes collègues tag specialists n'étaient en aucun cas coupable du problème que rencontrait le client. Le problème venait visiblement d'un tag tiers.

Certains tags sont eux-même en quelques sortes des conteneurs à tags. Je trouve personnellement cela très sale / risqué. A mes yeux, c'est un peu comme si nous avions prêté une clé à des amis qui l'avaient prêté à leurs amis qui l'avait prêté à leurs amis. Que nous n'avions pas la capacité de savoir qui avait eu accès aux clés. Que l'appartement avait été saccagé, mais que nous ne savions pas par qui.

Le problème s'est résolu de lui-même par "magie" sans aucune publication de notre côté avant que nous avions pu mettre la main sur le tag en question.

Le client a perdu de l'argent, les équipes techniques ont du intervenir en urgence, et les coupables n'ont peut-être même pas été informé de l'incident.

Mes conseils :

  • éviter les tags tiers qui appellent des tags tiers dont vous ne contrôlez pas le contenu
  • historiser les javascripts tiers qui sont personnalisés et les tags tiers de petite solution émergeante (en toute transparence, je ne l'ai en réalité jamais fait)
  • rendre systématiquement possible la suppression des tags. Le site ne doit en aucun cas être dépendant d'un javascript tiers. Dans le code source du site par exemple, vous ne devez en aucun cas bloquer la prise en compte d'un clic sur un CTA dans l'attente d'un retour de Google Analytics. Sans cela, vous ne pourrez couper un tag en urgence
  • mettre en place avec les équipes une méthode / un document leur permettant de tester facilement si un tag présent dans le gestionnaire de tags est responsable d'un incident, d'une régression.

Un tag entraîne une régression fonctionnelle

Les faits :

Une régression fonctionnelle était apparue sur un grand site e-commerce. Encore une fois, un membre de l'équipe technique, suite à son analyse a suspecté que le problème venait d'un tag tiers.

Suite à l'analyse, il s'est avéré qu'effectivement, un tag tiers était bien le responsable. Le Tag Specialist avait respecté la demande à la lettre.

Le tag qui avait été écrit par l'éditeur changeait accidentellement la valeur d'une variable qui avait été utilisée par les développeurs du site.

Le tag a cette fois-ci était identifiée. J'ai corrigé le code source et je l'ai envoyé à la solution en expliquant l'incident.

Je n'ai eu droit qu'à un "merci pour votre retour" (il n'est pas impossible qu'il y ait eu une discussion d'une autre nature entre l'éditeur et les responsables du site).

Mes conseils :

  • dans le cas ou une solution émergente / peu courante doit être installée, toujours auditer le code source qui doit être posé.
  • dans le cas de la pose de javascript dans un TMS, toujours intégrer le code dans une fonction anonyme et faites attention à la portée des variables (sauf si le TMS fait cela pour vous).

Tags incompatibles entre eux

Les faits :

Une régression fonctionnelle est apparue sur le site. Un développeur a identifié que c'était suite à la pose d'un tag tiers. En effet, un service était proposé par un autre tag tiers qui déclarait un variable du même nom que le tag marketing.

Mes conseils :

  • Dans le cas ou un tag peu courant doit être installé, ne pas l'installer à proximité / pendant une période critique (solde), ni la veille de jours non ouvrés, et procéder à une recette du site. La recette peut ne pas être réalisée par un Tag Specialist. A noter: Un gestionnaire de tags perd beaucoup de son intérêt dans ce cas.

Tags analytics installé par une solution tierce

Il m'est arrivé à deux reprises de trouver du code Google analytics dans une solution tierce. Ce code analytics pourrait éventuellement être toléré s'il était
bien posé, mais dans les deux cas précédents, le code pouvait générer des incidents.

Ces tags étaient des tags Universal Analytics alors que mes clients utilisaient la version asynchrone. L'éditeur n'avait même pas pris soin de renommer les cookies / de renommer le marqueur. Le code était bien déclenché dans la page du site et non dans une iframe tierce.

Ces pratiques peuvent éventuellement poser des problèmes juridiques. Vous n'êtes pas censé savoir que l'utilisation d'un service va entraîner le chargement de
tag analytics. Et l'internaute n'aura peut-être pas donné son consentement.

Mes conseils :

  • Dans le cas où une solution émergente / peu courante doit être installée, toujours auditer le code source qui doit être posé. Si vous auditez ce code, il peut-être préférable si cela est possible de l'hébergez vous même. Vous contrôlerez ainsi les mises à jours.

Remarques générales

  • ne jamais embriquer des gestionnaires de tags / des conteneurs (exemple : Eulerian dans GTM, GTM dans GTM). J'ai déjà vu à plusieurs reprises ce genre de pratique. Cela fait perdre en précision, et par ailleurs, en cas d'incident, cela peut complexifier vos analyses / vos interventions en urgence (ou celle d'une équipe technique).
  • un tag tiers, même asynchrone, peut ralentir un site. Des accidents sont déjà arrivé chez Facebook, OVH.... Il est intéressant de monitorer la vitesse de chargements des scripts tiers. Et éventuellement de les suspendre si des délais trop long sont détectés. Certaines solutions de tag management propose un time out sur le chargement des scripts tiers (Tag Commander). Tag Commander vous permet d'ailleurs de délivrer vous même les différentes ressources Javascript sur votre propre architecture, ce qui peut potentiellement réduire les risques.
  • si un tag tiers est retiré, le site doit pouvoir continuer à fonctionner sans erreur (même la solution d'analytics / même le gestionnaire de tags).
  • ne travaillez pas de façon trop isolée des équipes techniques. Il faut qu'elles puissent détecter que le soucis puisse venir du gestionnaire de tags, savoir qui contacter et éventuellement comment intervenir en urgence.
  • activez l'authentification à double facteur si possible sur votre gestionnaire de tags. En tout cas, protégez l'accès à votre compte.

N'hésitez surtout pas à me transmettre vos remarques en commentaires ou vos suggestion d'outils.

Publié le

A propos de Antoine Tissier

Diplômé ingénieur en informatique par l'Ecole Centrale de Lille, Antoine a travaillé plus de 10 ans au sein l'agence web altima° ou il a occupé différentes fonctions : ingénieur d'étude, chef de projet technique, ingénieur d'exploitation et Consultant Analytics pendant plus de 6 ans. Il a eu l'occasion de travailler pour de nombreux clients : Petit Bateau, le groupe SEB, le groupe L'Oréal, 3 suisses International, Axa, Cofidis Belglique, ING Direct... sur des missions d'implémentation, d'analyses, d'audit, et de dashboarding / reporting.

1 thought on “Témoignage – Incidents liés à la gestion de tags

  1. François Langrand

    Très bon article sur la réalité souvent méconnue des tags qui évoluent sans qu'on le sache !
    Je rajouterais la possibilité de réaliser 2 actions:
    1. Réaliser un suivi des tags de second niveau (aka piggybacking)
    2. Positionner des tags en server-to-server si leur présence n'est pas nécessaire côté client : cette action permet de supprimer l'empreinte d'un tag sur une page puisqu'il ne s'y exécute plus par définition
    La suite Commanders Act permet de réaliser ces actions.

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *