Objectif
Comprendre comment utiliser le workflow de test des tags, conditions et variables dans Adobe Launch.
Le “worfklow” de test d’Adobe Launch correspond au flux de publication des balises / tags dans l’interface d’Adobe Launch. C’est le processus qui sert à créer des bibliothèques de tags et éléments à tester avant de les pousser en production.
Dans Google Tag Manager, ça correspondrait à un “workspace” avec l’ensemble des balises, déclencheurs et variables dédiés à une thématique donnée, qu’on testerait en preview.
Prérequis
Pour une question de simplicité, ce contenu et le suivant présenteront le workflow et le test pour un site web et non une application mobile.
Afin de lancer un workflow de test, il faut avoir créé un tag au préalable, avec l’ensemble des conditions, events et eVars ou props associées. Vous pouvez vous référer à ce guide :
Comment déclarer des eVars et events dans Adobe Launch
Il faut aussi avoir différents environnements (sites web) accessibles pour les tests :
- au moins un de test / staging / preprod
- et un de prod
Adobe Launch propose ainsi un script JS à intégrer dans chaque environnement (sites web) selon le nombre disponibles et définis pour votre projet :
- development
- staging
- production
Un script d’environnement, qu’on trouve dans l’onglet dédié “environments”, ressemble à ceci :
Il arrive que certains projets n’aient qu’un environnement de prod. Il faut alors procéder différemment dans les processus de tests avec des tags dupliqués envoyant à une report de suite de test puis publier les tags finaux mais nous ne verrons pas cette méthode ici.
Etapes détaillées d’implémentation
Fonctionnement des environnements et permissions
Contrairement à d’autres TMS qui ont un fonctionnement avec “preview + publication” ou 3 états “dév / preprod / prod”, Adobe Launch propose 4 étapes dans le workflow de publication :
- development
- submitted
- approved
- published
Le premier intérêt de cette séparation est que des modifications peuvent être ajoutées dans la version de développement et que celle-ci reste dans la colonne “submitted” tant qu’elle n’a pas été testée. Une fois testée et approuvée, celle-ci est transférée dans la colonne “approved” en attente d’une publication ou bien renvoyée pour modification dans la colonne “development”.
Le deuxième intérêt est qu’il permet de visualiser dans l’interface quelles versions ont été testées ou non. Et cela permet de publier en prod juste une version ou plusieurs en parallèle.
Le dernier intérêt concerne un aspect de Data Governance pour la gestion des permissions. En effet, des droits différents peuvent être attribués aux utilisateurs dans Adobe Launch :
- develop
- approve
- publish
Ça donne la structure suivante :
- Les utilisateurs avec un accès “develop” peuvent n’avoir accès qu’aux phases “development” et “submitted” pour une première phase de test
- Les utilisateurs avec un accès “approve” font une deuxième session QA pour pouvoir utiliser la fonctionnalité “approved” du workflow
- La publication finale sur la phase “published” serait réservée aux utilisateurs avec un accès “publish”, pour mettre en prod à un moment bien précis en réalisant un contrôle de non-régression par exemple.
Le worfklow de publication d’Adobe Launch répond aux besoins de Data Quality et Data Governance souvent en place dans de grandes entreprises, où les tests sont parfois réalisés par plusieurs personnes ou équipes avant validation et publication.
Création d’une librairie
Lorsqu’on veut pousser des modifications en test, on va créer ce qu’on appelle un “build” :
- Aller dans l’onglet “Publishing Flow”
- Cliquer sur “Add library”
c. Nommer la librairie avec un nom compréhensible par l’utilisateur (possible d’ajouter les initiales de la personne qui a créé la librairie pour une vue plus rapide des interventions de chaque personne)
d. Cliquer sur “Add a resource” pour choisir les tags, data elements et extensions voulues ou sur “add all changed resources” si l’on n’a travaillé que sur les éléments qui seront publiés
e. Choisir l’environnement de build, qui sera forcément “development” pour une 1ère étape
f. Cliquer sur “Save & Build to Development”
Une fois le build enregistré, celui-ci apparaît dans la colonne “development” de votre publishing flow. L’étape suivante est donc de tester vos tags !
Dans un article suivant, nous verrons comment tester les tags sur un site web de preprod ou de prod selon que votre build se trouve dans la colonne “submitted”, “approved” ou “published”.
Ressources complémentaires
Cet article vous a plus ? Nous vous invitons à le partager sur Linkedin ou vos réseaux sociaux !
L’auteur : Diane Couprie
Consultante Senior Tracking chez unnest
Experte Tracking et Analytics avec une spécialité Adobe.
Précédemment Consultante Data Marketing chez Capgemini, Diane a une expertise data marketing et tracking multi-outils et multi-sectorielle .
✉️ Me contacter : diane.couprie@unnest.co