Comment contourner un datalayer mal renseigné ?

Dans le cadre d’une reprise d’un compte Analytics existant, ou dans certains cas particuliers, il peut arriver que les informations présentes dans un datalayer soient obsolètes ou inutilisable en l’état sur Google Tag Manager (GTM), soit par manque de disponibilité ou de compétences du service IT, soit par décision stratégique du propriétaire du site.

Par exemple, un grand groupe possédant des sites équivalents mais différents, peut imposer un même datalayer partout, sans tenir compte des spécificités. Un service informatique peut n’avoir aucune ressource à fournir pour une mise à jour ou un processus de refonte du tracking.

Programmer ou mettre à jour une configuration Analytics peut, alors, devenir particulièrement complexe. L’absence d’un datalayer contraint à le recréer, de manière virtuelle, pour exploiter les données indispensables au bon fonctionnement d’une vue Analytics.

Google Tag Manager propose, comme les autres Tag Manager System (TMS), la possibilité d’utiliser le code source d’une page, pour tenter d’en récupérer les éléments.

En effet, en cas d’absence d’un datalayer, la plupart des éléments utiles à la configuration, du moins standard, d’Analytics, peuvent se récupérer directement dans le code source.

Les TMS offrent généralement de nombreuses possibilités pour atteindre un élément particulier d’une page, soit pour permettre l’activation d’un déclencheur, soit par l’utilisation de fonctions javascript, de remonter le contenu d’un champ, d’un texte, d’un lien.

L’analyse et la déconstruction de l’url peut alors fournir des informations précises sur l’arborescence du site, le nom du produit, peut-être même son identifiant. En utilisant javascript, combiné à des tableaux de conversion, l’on peut reconstruire une partie des éléments indispensables à la bonne dénomination des pages d’un site.

De même, la plupart des TMS offrent la possibilité de se fonder sur les liens ou éléments cliquables, en se basant sur certaines variables très utiles ; nom, id, class, url de redirection, texte cliquable…

Si un déclencheur peut s’attacher au texte d’un lien (comme « ajouter au panier »), ce même texte peut être remonté en variable.

Les formulaires peuvent également faire l’objet de récupération selon ce même principe, par l’url de destination, l’id, le nom, le texte…

Mais certaines informations ne sont disponibles ni en lien, ni en formulaire. Pour pointer dessus, l’utilisation de javascript, se fondant sur le code source, peut récupérer un bloc programmé et le déconstruire, pour supprimer le code et transformer le texte utile en variable indispensable (par exemple, une page de confirmation affichant les données de la commande est intégralement récupérable, même sans datalayer).

L’utilisation de tableaux de conversion, dans le cas d’éléments incomplets restaurés, peut aussi permettre de corriger la partialité des données, en convertissant celles provisoires, par celles que l’on souhaite afficher.

Javascript est aussi d’une précieuse aide, lorsqu’il n’est possible que de récupérer un code brut. La présentation du contenu des variables sur Analytics doit être le plus clair possible tant pour éviter une réinterprétation d’un code ou d’un caractère, qui en perturberait la lecture. Par ce langage, il devient aussi possible de normer l’affichage des données.

Ainsi, la reconstruction virtuelle d’un datalayer est réalisable, à la seule condition que le code source soit exploitable et fournisse les informations indispensables au fonctionnement d’un compte Analytics.

Car rien ne contraint un site Internet à récapituler le contenu d’une commande, sur une page de confirmation. Dans ce cas, une vue e-commerce ne fonctionnera pas, puisqu’il sera impossible de retrouver les informations sur les produits achetés et donc renseigner l’onglet sur la performance des ventes, rendant l’entonnoir de conversion inutilisable.

Mais cette solution de secours présente une très grosse limite. Le code source a bien plus de chance d’être modifié sans avertissement qu’un datalayer. Autrement dit, une restauration appuyant son tracking sur les class de balises, peut devenir inopérable, si les appels à la feuille de style sont soudainement modifiés. Les appels ou fonctions sur GTM ne pourraient plus se faire, faute d’être conforme aux règles d’exécution ou de déclenchement.

La meilleure solution reste l’implémentation et la modification d’un datalayer conforme aux attentes, lorsque la fiabilité de solutions de secours, pour contourner les blocages constatés, nécessite une vérification régulière de la conformité des statistiques Analytics, pour s’assurer qu’aucune modification ne vienne perturber le bon fonctionnement du tracking.

Et à la moindre alerte, il faut modifier son paramétrage GTM ou TMS, retrouver un moyen fiable d’atteindre un élément, jusqu’à la prochaine modification non attendue.