Comment mettre en place un processus Assurance Qualité Google Tag Manager ?
L’un des plus gros challenges avec Google Tag Manager est d’équilibrer la gouvernance entre le besoin de mise en oeuvre agile et le respect d’un processus Assurance Qualité (AQ). Cela est particulièrement vrai pour les sites qui sont gérés à partir de plusieurs environnements serveur (production, pré-production, développement…).
Aujourd’hui, la majorité des implémentations Google Tag Manager qui intègrent différents environnements dans leur processus de production sont gérées en général de deux façons.
- 1 conteneur GTM partagé dans chaque environnement du site prod, preprod, dev…
- 1 conteneur GTM dédié par environnement du site prod, preprod, dev.
1 conteneur GTM partagé dans chaque environnement du site.
Pour distinguer les environnements au sein d’un même conteneur GTM, on préfixe le nom des balises en spécifiant l’environnement de déclenchement, comme « prod_ »preprod_ », « dev_ ».
Les règles qui régissent la publication de ces balises sont souvent basées sur le nom de domaine des différents serveurs de production du site. Par exemple, déclencher tag « prod_GA page vue » si {{host name}} == « www.monsite.com ». Idem pour les codes de suivi Google Analytics, en utilisant cette fois une variable « tableau de conversion », par exemple pour conditionner la valeur de la variable « Code de suivi GA », utilisez comme variable entrante (input) {{Page Hostname}} si « www.monsite.com » alors « UA-xxxxxxx1 »; si « preprod.monsite.com » alors « UA-xxxxxxx2 »; si « dev.monsite.com » alors « UA-xxxxxxx3 ».
- L’avantage c’est l’agilité, car tous les composants GTM sont mutualisés entre les différents environnements de production du site.
- L’inconvénient principal, c’est le fait de publier par défaut la même version du conteneur dans chaque environnement. C’est-à-dire de partager la même copie du conteneur sur chaque site de chaque environnement. Par exemple, si une balise, une règle ou une variable n’était pas finalisée, elle serait quand même publiée dans l’environnement « live », en l’état.
1 conteneur GTM dédié par environnement du site.
L’avantage de cloisonner les tags GTM de chaque environnement de production du site Web permet de minimiser les risques dus à la gestion mutualisée et facilite la gouvernance QA. L’environnement de production peut être protégé par un Gardien QA qui n’intègre que les tags préalablement validés dans l’environnement de préproduction.
Dans la pratique, l’approche la plus agile, c’est que le responsable QA GTM intègre et teste les nouveaux tags, règles et variables dans l’environnement preprod avant de les dupliquer, tester et publier dans l’environnement de prod. Une autre approche, le responsable QA GTM maintient les conteneurs GTM prod, preprod et dev identiques et merge périodiquement le conteneur GTM de dev (intégration et test) vers préprod (test), puis de preprod vers prod (test et activation).
L’inconvénient de ce type d’organisation, c’est le manque d’agilité de l’implémentation et de la gestion des tags, notamment dû à l’entretien et merge entre les différents conteneurs Google Tag Manager.
Il faut trouver le juste équilibre entre Agilité d’implémentation et processus Assurance Qualité. La réponse est à trouver dans la fonctionnalité « environnement » de Google Tag Manager que très peu de gestionnaires GTM utilisent à ce jour.
Processus Assurance Qualité avec les environnements Google Tag Manager.
Dans cet article, nous allons voir comment utiliser les environnements Google Tag Manager pour mettre en oeuvre un processus Assurance Qualité la plus agile possible.
Avant de nous plonger dans les environnements Google Tag Manager, il est important de comprendre avant tout, comment fonctionne la gestion des versions de Google Tag Manager.
Les versions dans Google Tag Manager.
En résumé, une version est un instantané d’un container. En créant une nouvelle version, vous enregistrez l’état actuel d’un conteneur. Ce qui est très pratique pour enregistrer et de conserver votre travail, puis si nécessaire, revenir à une version précédente.
Par défaut, il existe 3 types de versions :
- « Live (réel) », qui représente la « Version active », actuellement publiée sur le site
- « Latest (dernier) » ou « Dernière version »,
- « Now Editing (en cours de modification) » ou « Version en cours ».
Exemple : Comment faire si vous devez publier un nouveau tag alors que votre conteneur GTM intègre des tags non finalisés ?
Pour cela c’est très simple, depuis l’onglet « versions » :
- Vous avez une « Version en cours » (ex. n° 11) qui contient des tags en cours de configuration, non testés.
- Au niveau de la « Version active » (ex. n° 10) > « modifier en tant que nouvelle version », cocher « enregistrer la version préliminaire du conteneur avant de la modifier ».
- Intégrer votre tag puis publier la nouvelle « Version en cours » (n° 12), qui devient « Version active » (n° 12).
- Pour finir, au niveau de la version qui intègre les tags non finalisés (n° 11) > « modifier en tant que nouvelle version », mais cette fois décocher « enregistrer la version préliminaire du conteneur avant de la modifier ». Ainsi la nouvelle « Version en cours » (n° 13), correspond à l’instantanée de la version n° 11.
Cet exemple est parfait pour vous présenter la fonctionnalité environnement de Google Tag Manager.
Les environnements Google Tag Manager.
Comme nous l’avons vu, Google Tag Manager permet de publier par défaut, une version de conteneur dans le seul environnement « live ».
Pour répondre au besoin de publication du conteneur dans différents environnements de production (« dev », « preprod », « prod »…), Google Tag Manager a intégré la possibilité de créer des environnements personnalisés. Un environnement personnalisé, c’est un environnement de publication supplémentaire, en plus de l’environnement natif « live », dans lequel vous pouvez publier une version du conteneur donné. C’est la possibilité de diviser un conteneur Google Tag Manager dans des environnements distincts et publier différentes versions de votre conteneur pour chaque environnement.
Donc en résumé, si nous créons les environnements « preprod » et « QA », notre pourrons publier une version du conteneur dans les environnements suivants :
- « Live », représente la version du conteneur active publiée sur le site « live »,
- « preprod », représente la version du conteneur active sur le site « pré-production ».
- « QA », qui représente le conteneur du conteneur active sur le site « QA ».
Comment créer un environnement Google Tag Manager ?
Pour créer un nouvel environnement GTM, c’est très simple, rendez-vous dans l’admin de votre conteneur, puis « environnements », puis cliquez sur le CTA « créer ». Remplissez les champs comme demandé et c’est fini. S’il s’agit d’un environnement de test GTM, cochez l’option « activer le débogage par défaut » pour activer par défaut la fenêtre de débogage GTM.
Une fois l’environnent créé, vous devez créer une nouvelle version à associer au nouvel environnement.
Félicitations, vous venez de créer votre premier environnement de publication Google Tag Manager !
Vous pouvez utiliser chaque environnement de deux manières :
- Avec un lien « Partager l’aperçu » (partager l’aperçu » dans le menu « Actions » de l’environnement).
Les utilisateurs devront cliquer sur le lien pour effectuer leurs tests dans cet environnement. Utile pour partager ponctuellement l’accès à un environnement donné, mais peu pratique au quotidien. Pour activer en permanence l’environnement GTM, il faut modifier le script de GTM des pages de l’environnement. - Avec un extrait de code
Remplacez le script Google Tag Manager au lieu du code existant. Pour obtenir ce script, sélectionnez « Obtenir l’extrait de code » dans le menu « Actions » de l’environnement.
Comment utiliser un environnement Google Tag Manager.
Il est temps de parler de workflow Assurance Qualité avec Google Tag Manager. Imaginons, que le processus d’assurance qualité basé sur 3 environnements « DEV », « PREPROD » et « PROD » (LIVE), les tags sont publiés et validés progressivement dans chaque environnement, idéalement par des « responsables QA » différents. Pour les petites structures ou pour gagner en agilité, vous pouvez planifier le processus sur 2 environnements « QA » et « PROD » par exemple.
| Nom environnent | URL environnent | Equipe | Workflow QA |
| dev | dev.webanalyste.com | GTM – métier (IT et Marketing) | Configuration et publication de nouveaux tags dans une nouvelle version dans l’environnement « DEV ». |
| preprod | preprod.webanalyste.com | GTM – QA DEV | Validation des tags de l’environnement « DEV », puis publication dans l’environnement « PREPROD » |
| life (défaut) | www.webanalyste.com | GTM – QA PREPROD | Validation des tags de l’environnement « PREPROD », puis publication dans l’environnement « PROD » |
Pour finaliser notre workflow QA GTM, il faut remplacer sur les pages des environnements « DEV » et « PREPROD », le script GTM par défaut par celui de l’environnement correspondant. Ainsi le responsable QA aura directement accès à la dernière version publiée. Pour finir, pensez à activer dans la configuration de l’environnement, l’option « activer le débogage par défaut » pour activer par défaut la fenêtre de débogage GTM.
Voilà, l’environnement QA est fonctionnel. Mais est-il agile ? Il me semble qu’on peut mieux faire. 😉
Workflow QA Google Tag Manager agile as is possible.
Maintenant que vous avez compris le principe du workflow QA GTM et l’environnement de publication personnalisé, c’est le moment de penser optimisation pour gagner en agilité.
Les deux principaux leviers sur lesquels nous pouvons influer sont le nombre d’environnements GTM QA et le nombre de tags à considérer dans le workflow QA.
Concernant le nombre d’environnements, deux environnements de publication devraient satisfaire la plupart de besoin QA.
- Environnement GTM par défaut « live », qui correspond à site de production,
- environnement GTM personnalisé « QA », qui correspondrait au serveur de preprod ou stagging.
Dans Google Tag Manager, il y a deux types de balises :
- Les balises intégrées par Google, disponibles sous forme de template prérempli. Leur configuration ne devrait pas affecter directement la stabilité du site Web/APP ou la confidentialité des données. Les seuls risques, c’est qu’elles soient mal configurées et n’envoient pas les informations attendues ou qu’elles ne se déclenchent pas. Pas de quoi défriser un mouton. Exemples de balises intégrés: GA, AdWords, TradeDoubler, Mediaplex…
- Les balises et les variables personnalisées dans lesquelles on peut intégrer librement un script. Très utilisé pour le tracking Analytics et les tags médias qui ne sont pas intégrés par Google. Mais qui dit script libre injecté dans votre site, dit potentiel risque. Les balises HTML, les balises image et les variables JavaScript peuvent affecter la stabilité du site Web/APP ou la confidentialité de vos données. Comme il s’agit d’intégration de script libre, une erreur de codage ou un abus de collecte de données peuvent affecter votre site et votre entreprise.
Pour gagner en agilité, il suffit d’inclure dans le processus QA, uniquement la validation des composants personnalisés (balises et variable).
Nous avons fait le tour de la fonctionnalité environnement et abordé quelques modèles de processus Assurance Qualité, il vous reste à éditer les règles qui régissent votre propre workflow QA.
