Comment mettre en place un plan de marquage universel ?

Lors du déploiement d’un outil de Web Analytics sur un site web, l’élaboration du plan de marquage est une étape essentielle. Il représente le lien entre les besoins marketing et les spécifications techniques en précisant la manière de structurer l’information et de l’envoyer à l’outil. C’est un document de travail fort utile puisqu’il correspond au langage commun que doivent avoir le service Marketing et le service de développement informatique.

Pour que ce document facilite au maximum le travail de chacun, il doit suivre les points suivants :

  • Etre facile à communiquer (il peut être utilisé par n’importe qui)
  • Répondre aux besoins de données du Marketing
  • Etre relativement rapide à mettre en place (besoins techniques)
  • Etre facile à maintenir et à faire évoluer (besoins techniques)

 

Pour répondre au mieux à ces différents points, la mise en place d’un plan de marquage universel est conseillé. Un plan de marquage universel est associé à un data layer interne regroupant toutes les données qui peuvent être utiles, où chaque outil l’utilise pour prendre ce dont il a besoin.

 

DATA LAYER INTERNE : Regroupement dans un objet DOM

 

Le Plan de marquage universel passe par un Data Layer interne qui correspond à la structure hiérarchique des informations. Sur chaque page du site toutes les informations sont regroupées dans un objet DOM unique, cet objet DOM pouvant contenir de multiples niveaux, sous-niveaux, etc (structure en arbre JSON).

L’intérêt de tout regrouper dans un objet DOM est d’accéder et de lire les informations disponibles plus facilement. Cet objet DOM permet également de symboliser le tracking (en choisissant notamment le nom à donner), ce qui prémunit de certaines erreurs de développement quand les données sont mises dans des objets partagés, non réservés exclusivement au Web Analytics.

L’objectif de cet obet DOM est de regrouper toutes les informations qui seront utiles aux différents plans de marquage (des différents outils),. Mais chaque plan de marquage n’utilise pas forcément toutes les informations contenues dans l’objet DOM.

Il est important de bien structurer l’information, pour arriver à une granularité la plus fine possible afin de faire en sorte que l’objet DOM puisse répondre à tous les besoins avec le minimum d’objets et variables. Ceci facilite la lecture de l’objet DOM et sa maintenance. Avec un niveau de granularité très fin, il est possible de faire face à plusieurs cas en passant par des concaténations des morceaux d’information. Par exemple, pour un nom de page avec des chapitres. un outil peut nécessiter un format spécifique où tout est mis dans une seule variable  (« Chapitre-SousChapitre-NomPage »), alors qu’un autre outil demandera de mettre dans une variable le nom de la page et dans une autre variable distincte les chapitres.

Exemple de construction du Data Layer dans le HTML (via JSON) :

On créé un objet « Page » dans lequel on créé des sous-objets pour chaque « morceau » d’information.

<script>
dataLayerInterne = [{
Page :{
Chapitre1 : « Chapitre »,
Chapitre2 : « Sous-chapitre »,
NomPage : « page »}
}];
</script>

 

Utilisation d’un fichier JS interne pour chaque outil : Sélection des données et envoi

 

Une fois l’objet DOM créé, rempli et structuré, un fichier JS est à développer pour chaque outil afin de définir le process correspondant pour sélectionner les données nécessaires au plan de marquage, les formater, puis les envoyer à l’outil.

Le fichier JS peut comprendre différentes parties :

  • Récupération dans le DataLayer interne des données nécessaires pour l’outil
  • Formatage des données : Définition de librairies de fonction pour mettre au bon format les données (par exemple : enlever les accents, les espaces, etc)
  • Formatage des données : Création des tables de correspondance pour obtenir un identifiant à partir d’un libellé (si la configuration de l’outil l’exige). Utile pour n’avoir qu’une seule fois l’information dans le data layer et pouvoir gérer les spécificités de chaque outil (libellés différents pour une même information)
  • Validation des données : Test de validation et Utilisation de callbacks pour s’assurer que toutes les informations ont pu être récupérées
  • Attribution des données aux variables de l’outil : plan de marquage de l’outil
  • Envoi des données : Appel au fichier JS de l’outil (ou autre process défini par l’outil)

 

Ce fichier JS doit être appelé sur toutes les pages du site. Pour cela, il est conseillé d’inclure les appels aux fichiers JS spécifiques à chaque outil dans un fichier JS commun.

L’appel à ce fichier JS commun doit être intégré sur toutes les pages du site. Ainsi, lorsqu’un nouvel outil doit être intégré sur tout le site, il suffit simplement de créer le fichier JS spécifique à l’outil et d’ajouter son appel dans le fichier JS commun. Si l’outil ne doit pas être appelé sur certaines pages ou catégories du site, la règle peut être spécifiée dans le fichier JS commun. De préférence, cette tâche doit être réalisée côté serveur, et non côté client (ce qui est le cas quand la tâche est faite avec le JS). Cela permet de gagner en temps d’exécution en évitant notamment le chargement du fichier JS commun. La contre-partie est de perdre en visibilité pour cette étape, en tant que chef de projet web analytics, puisque le code correspondant est rangé plus en profondeur dans le code du site.

A noter également, concernant le tracking des événements, il est recommandé dans le cadre d’un plan de marquage universel de demander au développement informatique de « pousser » les évènements dans l’objet DOM du Data Layer interne (tant que l’événement n’a pas lieu lors du chargement de la page ou qu’il n’y a pas fermeture de la page juste après l’événement). Ainsi pour chaque outil, il suffit simplement d’ajouter dans le JS de l’outil un gestionnaire d’évènement (à l’aide de listeners sur l’objet DOM du Data Layer interne) pour détecter l’évènement et envoyer les informations correspondantes à l’outil. Pour chaque nouvel outil, il n’y a donc pas besoin de faire de multiples modifications à différents endroits dans le code du site (ce qui facilite la maintenance). Le développement ne pousse l’évènement au Data Layer qu’une seule fois.

Au global, le principe du Data Layer interne peut être résumé avec le schéma suivant (l’étape 1 et 2 peuvent être fusionnées en faisant le travail  côté serveur et non côté client) :

Avec ce schéma, on pourrait confondre le principe du Data layer interne à celui d’un outil de Tag Management. Les deux sont similaires et peuvent comprendre ces différentes étapes. Cependant le principe du Data Layer interne se distingue par le fait qu’il met le plan de marquage à disposition des autres outils plus tôt que l’outil de Tag Management. Il n’y a pas besoin d’attendre l’appel au fichier JS de l’outil de Tag Management et l’envoi des données pour que les autres outils aient accès aux données. Avec le principe du Data Layer interne, les autres outils ont accès aux données en même temps que l’outil de Tag Management. Le seul inconvénient est qu’il nécessite le développement d’un fichier JS  spécifique. C’est pour cela qu’en dehors d’outils de web Analytics, de testing ou de première importance (pour lesquels il faut éviter de prendre le risque de dépendre d’un autre outil comme celui du Tag Management), les autres outils doivent être intégrés sur le site via un outil de Tag Management pour permettre au développement de se concentrer uniquement sur le développement des fichiers JS Commun et ceux spécifiques aux outils les plus importants en s’appuyant sur le Data Layer interne.

 

Avantages d’un plan de marquage universel

 

L’utilisation d’un plan de marquage universel présente de nombreux avantages :

  • Toutes les informations sont présentes au même endroit, ce qui facilite la maintenance
  • Les informations du plan de marquage sont structurées hiérarchiquement, ce qui facilite leur lecture (que ce soit pour le Marketing ou le service de developpement informatique). Le plan de marquage peut également être rendu accessible au Marketing via un bout de code JS à mettre en favori dans le navigateur web : le code JS ouvre une fenetre « alert » avec les infos du plan de marquage présentées de manière pertinente (pour des personnes sans compétences techniques).
  • La même information est partagée avec tous les outils : pas de décalage de périmètre
  • Le plan de marquage est sécurisé grâce à l’utilisation d’objets et fichiers dédiés uniquement à cette cause : ce qui permet d’éviter des effets de bord, des effets secondaires de modifications de fichiers partagés
  • Le déploiement d’un outil sur tout le site peut se faire rapidement (potentiellement en quelques heures en créant simplement le fichier JS spécifique à l’outil)
  • Le plan de marquage universel n’est pas dépendant d’un outil. Et l’outil n’est pas pour autant dépendant du plan de marquage universel pour son évolution (grâce au JS spécifique à l’outil). Ceci a notamment pour bénéfice de pouvoir rapidement changer d’outil (par exemple changer d’outil de Tag Management)

 

Comparaison avec le projet W3C de Data Layer standard

 

Le Data layer interne se distingue du Data Layer standard qui est en train d’être défini par le W3C (pdf : http://www.w3.org/2013/12/ceddl-201312.pdf). Le standard W3C définit la structure à mettre en place, ainsi que les noms à donner aux objets. En suivant ces règles, les outils qui respectent le standard W3C peuvent alors s’appuyer sur le Data Layer standard et se déployer plus rapidement (pas besoin de faire un nouveau plan de marquage).

L’intérêt du data layer standard est l’absence de surcouche JS. Seul l’appel au fichier JS de l’outil est nécessaire, le fichier JS pouvant s’appuyer directement sur le data layer standard. Ce qui permet d’envoyer les données plus rapidement lors du chargement de la page. Cependant il peut présenter quelques inconvénient pour des variables d’outils personnalisables ou « libres » qui ne peuvent pas être définies dans le standard W3C : le risque est de rajouter au fur et à mesure dans le Data Layer ces variables « libres » en fonction des règles de chaque outil, ce qui risque de créer des doublons (même information demandée, mais avec un format différent) et d’alourdir le data layer. A moins de mettre en place une surcouche JS pour formater les données, ce qui reviendrait à mettre en place le principe du data layer interne …

Un point intéressant est également abordé dans le standart W3C : la confidentialité des données. Un standard est défini pour sécuriser des données sensibles présentes dans le Data Layer qui ne doivent pas être partagées avec n’importe quel outil. La structure hiérarchique du Data Layer (structure en arbre) est donc utile pour mettre en place des règles simples de droits d’accès faciles à maintenir (en permettant de l’appliquer à un objet qui en regroupe plusieurs, au lieu de l’attribuer à une liste d’objets).

 

0.00 avg. rating (0% score) - 0 votes

Laissez un commentaire

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