Adobe Launch (Tags) : checklist d'implémentation

La plupart des implémentations Adobe Launch que j’audite n’échouent pas à cause de l’outil. Elles échouent parce que personne n’a écrit ce qu’il fallait collecter, que le data layer arrive après le déclenchement des règles, et que la personne qui a construit la propriété est partie avec l’unique copie de la logique de nommage. Six mois plus tard, plus personne ne fait confiance aux chiffres d’Adobe Analytics, et chaque demande de tag tourne à l’archéologie.

Adobe Launch s’appelle désormais Tags dans Adobe Experience Platform (la documentation d’Adobe dit « formerly known as Adobe Experience Platform Launch ») et se trouve sous Data Collection > Tags. Les briques n’ont guère changé : propriétés, extensions, data elements, règles, bibliothèques, environnements. Ce qui change, c’est le contexte : Web SDK et Edge Network, datastreams, event forwarding, droits de publication plus stricts. Voici la checklist que j’utilise, puis le détail derrière chaque ligne.

La checklist d’implémentation Adobe Launch (Tags)

Avant de commencer : plan de marquage écrit (questions métier, événements, variables, responsables) ; choix de la bibliothèque (extension Analytics avec AppMeasurement, ou extension Web SDK avec l’Edge Network) ; avec le Web SDK, schéma et datastream créés avant de toucher à Tags ; droits Develop, Approve, Publish attribués ; conventions de nommage.
Propriété et environnements : une propriété par groupe de sites aux templates et besoins proches ; tous les domaines listés ; réglages de séquence et de valeur vide décidés dès le premier jour ; code de production en production uniquement ; chargement asynchrone ou synchrone choisi exprès et testé.
Data layer et data elements : data layer alimenté par le site (pas extrait du DOM) ; un data element par variable métier avec valeur par défaut ; code personnalisé toujours terminé par un return.
Règles : déclenchées par des événements du data layer ou des Direct Calls, pas par « Library Loaded » ; ordre simple (1 à 100, 50 par défaut) ; une règle par événement métier.
Publication, QA et gouvernance : tout passe par une bibliothèque (Development, Submitted, Approved, Published) ; test avec le Debugger avant soumission ; vérification dans les rapports ; droits séparés entre qui construit et qui publie ; notes sur chaque règle non évidente ; capacité de republier une bibliothèque précédente.

Avant de commencer : planifier d’abord, cliquer ensuite

Le plan de marquage est le contrat : pour chaque événement, la question métier, l’action de l’utilisateur, les variables et qui les pousse dans le data layer. Si vous ne pouvez pas remplir ce tableau, n’ouvrez pas Tags. Deuxième décision, la bibliothèque : l’extension Adobe Analytics charge AppMeasurement et envoie les hits directement à Analytics ; l’extension Web SDK envoie les données à l’Experience Cloud via l’Edge Network, et un datastream porte la configuration côté serveur (quels services Adobe reçoivent les données). Adobe la décrit comme « typically the recommended path for new Web SDK implementations » : en partant de zéro, évaluez-la en premier.

Troisième décision, les permissions : Develop (créer des bibliothèques, builder en développement), Approve (builder en staging et approuver) et Publish (pousser en production). Adobe est explicite : « these rights are not inclusive ». Donner aux consultants externes le seul droit Develop est une configuration saine, c’est l’exemple du guide de permissions d’Adobe.

Propriété et environnements

Une propriété est le conteneur des règles, data elements, extensions, environnements et bibliothèques, et peut servir plusieurs domaines. Selon Adobe, si les templates HTML sont les mêmes et les données proches, une propriété peut gérer plusieurs sites ; sinon, séparez. Une erreur de la version initiale de cet article : ne nommez pas une propriété « MonSite – Production ». La production est un environnement dans la propriété, pas une propriété.

À la création, deux réglages avancés demandent une décision immédiate, car les changer plus tard modifie le comportement à l’exécution :

Run rule components in sequence : conditions et actions attendent la fin de la précédente. Chacune a alors un timeout (2 000 ms par défaut), et une action en échec ou en timeout retire de la file les actions suivantes de la règle.
Return an empty string for missing data elements : la référence à un data element inexistant renvoie une chaîne vide au lieu de undefined.

Les codes d’intégration concentrent le plus de dégâts. Chaque environnement a le sien, et Adobe prévient que seul celui de production supporte le cache navigateur : « you should not use development or staging embed codes in high-traffic or production contexts ». L’asynchrone utilise une balise script dans le <head>, le synchrone en utilise deux (une dans le <head>, une avant </body>). Si vous changez d’hôte ou le réglage d’archive, le code change et doit être mis à jour à la main dans le HTML.

Data layer et data elements

Les data elements sont les variables de Tags, référencés avec %Nom du Data Element% dans les règles et _satellite.getVar() dans le code. Trois réglages faciles à sauter : la valeur par défaut (Adobe suggère « none » ou « n/a »), la mise en minuscules et le nettoyage du texte, et la durée de stockage (None, Page view, Session, Visitor).

Pour le data layer, Adobe fournit l’extension Adobe Client Data Layer, qui crée par défaut un tableau adobeDataLayer. Le site pousse, Tags écoute :

// Code de page, poussé par le site une fois la donnée connue
window.adobeDataLayer = window.adobeDataLayer || [];
window.adobeDataLayer.push({
  event: "product-view",
  product: {
    id: "SKU-123",
    category: "skincare"
  }
});

Pour un data element en code personnalisé, l’éditeur exige un return : sans lui, la valeur est undefined, puis Tags se rabat sur une valeur stockée, puis sur la valeur par défaut. Cette chaîne explique beaucoup de tickets « pourquoi cette variable garde la valeur de la page précédente ».

Règles

Une règle, c’est « si événements et conditions, alors actions » : plusieurs événements sont reliés par OU, plusieurs conditions par ET, une exception est une condition NON. Une règle peut déclencher plusieurs outils à la fois.

Le piège classique est le timing. Selon Adobe, une règle sur Library Loaded « might execute before your data layer is fully loaded » : préférez des événements Custom Event ou Direct Call déclenchés par le code de page une fois le data layer prêt. Une règle Direct Call écoute un identifiant que la page déclenche :

// Déclenché par le site quand un formulaire est vraiment envoyé (après validation)
if (window._satellite) {
  _satellite.track("form-submit-success");
}

Chaque règle a un numéro d’ordre (50 par défaut, les plus bas passent en premier ; Adobe recommande de rester entre 1 et 100). Les règles démarrent dans l’ordre mais ne finissent pas toujours dans l’ordre si l’une fait quelque chose d’asynchrone.

Extension Adobe Analytics ou Web SDK

Extension Adobe Analytics : report suites séparées pour Development, Staging et Production, pour que le trafic de test n’atterrisse pas en production. Trois actions : Set Variables (qui n’envoie rien : « You cannot send the beacon with the set variables action »), Send Beacon (s.t() compte une page vue, s.tl() non) et Clear Variables, qui évite que les valeurs fuient dans le hit suivant.

Extension Web SDK : l’action principale est Send event, qui « sends event data to the Edge Network ». Le datastream décide ensuite où vont les données. Si Customer Journey Analytics est sur la feuille de route, Adobe « advises against using the Adobe Analytics schema field group » et recommande votre propre schéma avec mapping dans le datastream, ou l’objet de données, pour ne pas vous enfermer dans les props et eVars. Event forwarding exécute règles et data elements sur les serveurs d’Adobe : c’est une fonction payante, vérifiez votre contrat.

Publication : bibliothèques, états et droits

Rien n’atteint le site tant que ce n’est pas dans une bibliothèque buildée, qui passe par quatre états : Development, Submitted, Approved, Published (développement, staging, puis production). Trois règles d’Adobe font gagner du temps : une bibliothèque est approuvée ou rejetée en bloc ; les data elements dépendent des extensions et les règles des deux, donc une dépendance manquante fait échouer le build ; pour retirer quelque chose, on le désactive et on publie l’état désactivé (supprimer une bibliothèque ne retire pas son build).

Comment faire la QA d’une implémentation Tags

L’Adobe Experience Platform Debugger (extension Chrome) montre quelle propriété, quel environnement et quel build tournent sur une page. Trois fonctions que j’utilise à chaque audit : Replace embed codes (remplacer le code de la page par celui de développement, en local seulement), les Logs (« Show Code » affiche le code de condition d’une règle) et le logging console du Web SDK (ajoutez ?alloy_debug=true à une URL pour l’activer sur votre session seulement).

Avec le Web SDK, la vraie question est ce que l’Edge Network a envoyé à Analytics ou Platform : dans le Debugger, Logs, onglet Edge, puis Connect active Edge Trace et une session Assurance. Enfin, vérifiez les rapports : une requête réseau verte ne fait pas un rapport correct.

Les pièges que je vois le plus souvent

Codes d’intégration de développement ou de staging laissés en production : pas de cache navigateur, et le site exécute la bibliothèque de développement.
Règles Library Loaded qui lisent un data layer pas encore là : des valeurs manquantes qui semblent aléatoires.
Passer du synchrone à l’asynchrone sans retester, ou Set Variables sans Send Beacon.
Une seule personne avec tous les droits et sans relecture, ou du code personnalisé partout.

Conclusion

Adobe Launch est devenu Tags, mais une bonne implémentation repose toujours sur trois choses : un data layer dont le site est propriétaire, des règles qui attendent ces données, et un circuit de publication où quelqu’un d’autre regarde avant la mise en ligne. Passez la checklist avant chaque release. Si votre propriété échoue sur plusieurs lignes, commencez par les codes d’intégration et le timing des règles : c’est là que naissent la plupart des mauvaises données.

Sources

Pour aller plus loin, lisez la version complète de l’article (en anglais) : Adobe Launch (Adobe Experience Platform Tags) Implementation Checklist and Guide.

Besoin d’aide sur ce sujet ? Consultant Adobe Analytics.

Adobe Launch (Tags d’Adobe Experience Platform) : checklist et guide d’implémentation