La couche de données

Écrire cet article est dangereux. Couche de données est deux commerçants à court de devenir un mot à la mode. Cette occasion sera annoncée par des articles tels que “La couche de données est morte”, “Ce développeur a implémenté une couche de données et vous ne devinerez jamais ce qui s’est passé ensuite”, et d’autres exemples du type de génération de contenu dont la propagation devrait être empêchée par l’armée. Obliger. Ce n’est pas un de ces articles, j’espère, mais plutôt un regard honnête sur ce qu’est Data Layer sous plusieurs angles.

Et il y a de nombreuses perspectives, en effet. La terminologie elle-même est difficile à cerner. Dans cet article, je considérerai Couche de données comprendre les définitions suivantes :

• La description des exigences et des objectifs de l’entreprise, alignée dans un format facilement transférable aux spécifications techniques

• Le concept d’une couche discrète d’informations sémantiques, stockées dans un contexte numérique

J’utiliserai également le nom de la variable dataLayer pour désigner la structure de données utilisée par Google Tag Manager pour stocker, traiter et transmettre des données entre le contexte numérique et la solution de gestion des balises. moi aussi je préfère le terme contexte numérique au site Web, par exemple, puisque la couche de données peut être utilisée dans divers contextes, et pas seulement dans un environnement Web accessible au public.

La couche de données la plus explorée dans cet article est celle qui est fermement ancrée dans la DMZ entre les développeurs et les spécialistes du marketing. C’est un concept très technique, puisque son existence est justifiée par les limitations imposées par certaines technologies du web (JavaScript, par exemple) sur la façon dont les navigateurs interagissent avec les applications (Google Tag Manager, par exemple). Dans le même temps, Data Layer est, et devrait être, détenue au moins en partie par des spécialistes du marketing, des analystes, des cadres, des concepteurs et des professionnels de la communication, qui rédigent les exigences et les objectifs commerciaux satisfaits par les méthodes de collecte de données.

En d’autres termes, il est très courant que la gouvernance de Data Layer fasse l’objet de vifs débats entre les différentes parties prenantes de « l’organisation des données » au sein d’une entreprise. Puisque, comme nous l’apprendrons, il s’agit d’un modèle de données générique pouvant être utilisé par toutes les applications qui s’interfacent avec vos données numériques, il est très difficile d’élaborer un modèle de gouvernance qui satisferait toutes les parties. Cela aussi, nous allons l’explorer dans cet article.

À la fin, je partagerai d’excellentes ressources pour en savoir plus sur la couche de données, car cet article ne sera pas une plongée en profondeur (même s’il est verbeux).

Qu’est-ce que la couche de données

Pour résumer, une couche de données est une structure de données qui contient idéalement tout les données que vous souhaitez traiter et transmettre de votre site Web (ou autre contexte numérique) à d’autres applications auxquelles vous avez établi un lien.

La raison pour laquelle nous utilisons une couche de données est qu’il est parfois nécessaire de découpler les informations sémantiques des autres informations stockées dans le contexte numérique. Ceci, à son tour, est dû au fait que si nous réutilisons des informations déjà disponibles, il y a un risque qu’une fois les modifications apportées à la source d’origine, l’intégrité des données soit compromise.

Un exemple très courant est le suivi d’analyse Web. Vous pouvez avoir une couche de données qui alimente votre outil d’analyse en données sur le visiteur. Souvent, ces données ne sont pas disponibles dans la couche de présentation ou dans le balisage. Ces données peuvent être, par exemple, des détails sur le visiteur (état de connexion, ID utilisateur, géolocalisation), des métadonnées sur la page (résolution optimale, droits d’auteur de l’image), ou même des informations déjà présentes dans le balisage, mais auxquelles vous souhaitez accéder dans une manière plus robuste.

Cette duplication est souvent observée dans les données de commerce électronique. Au lieu de “gratter” les détails transactionnels de l’en-tête ou du contenu de la page, il est plus fiable d’utiliser la couche de données pour transporter ces informations, car ce n’est qu’ainsi que les données sont dissociées du site Web proprement dit, ce qui signifie qu’elles sont moins sujettes aux erreurs lorsque le balisage est modifié.

Si, par exemple, vous étiez enclin à utiliser des données stockées dans un en-tête H2 du balisage HTML de la page de remerciement, une seule modification du balisage ou du format des informations de cet élément HTML compromettrait la collecte des données du site vers votre outil de suivi. Si, toutefois, les données ont été stockées dans une couche de données sans lien avec la couche de présentation, il y a un risque beaucoup plus faible que des changements inattendus se produisent (bien que ce ne soit certainement pas impossible).

Donc, en bref, la couche de données est une structure de données pour stocker, traiter et transmettre des informations sur le contexte dans lequel elle existe.

La couche de données : la perspective non technique

Pour le spécialiste du marketing, l’analyste, le cadre, le responsable des communications ou tout autre non-développeur, la couche de données est en fait une liste d’exigences et d’objectifs commerciaux pour chaque sous-ensemble du contexte numérique.

Pour une boutique en ligne, par exemple, les exigences et les objectifs commerciaux peuvent inclure des informations sur les transactions (ce qui a été acheté), des données sur les utilisateurs (qui a effectué l’achat), des détails spatiaux et temporels (où l’achat a-t-il été effectué et à quelle heure) et des informations sur les micro-conversions possibles (l’utilisateur s’est-il abonné aux mises à jour du produit).

Pour une autre partie du même site Web, les exigences et les objectifs commerciaux peuvent inclure simplement des détails sur le canal de médias sociaux qui a amené l’utilisateur sur le site Web ou sur les pages que l’utilisateur a consultées plus d’une fois.

Il ne s’agit pas de spécifications techniques, mais de listes clairement définies d’éléments qui doivent être collectés afin de satisfaire les objectifs commerciaux définis pour chaque domaine d’activité du site Web ou autre contexte numérique.

Idéalement, la couche de données contient des informations qui peuvent être utilisées par autant d’outils / utilisateurs / parties prenantes différents que possible, mais il est très courant que des idiosyncrasies émergent. C’est pourquoi il est extrêmement important de traiter la couche de données comme un modèle vivant et agilepas une entité stagnante, monolithique, singulière.

Comme pour tout aspect de l’analyse numérique, une couche de données doit également être traitée comme quelque chose qui est en constante évolution. Les données qu’il contient doivent être optimisées, élaborées, divisées, jointes, nettoyées, refactorisées et interrogé aussi souvent que de nouvelles exigences commerciales émergent ou lorsque les objectifs précédents n’étaient pas bénéfiques pour l’entreprise.

Couche de données de Google Tag Manager

Puisqu’il n’y a pas de norme existante pour le modèle de données exploré dans cet article (l’effort est en cours, cependant), la couche de données peut avoir de nombreuses formes techniques. La perspective technique que j’ai choisie est celle qui a évolué grâce à Google Tag Manager. C’est parce que je pense, et je ne suis que légèrement biaisé ici, que dataLayer est l’une des implémentations les plus élégantes d’un modèle de données structuré dans l’environnement Web.

dataLayer est un tableau JavaScript, qui contient des données dans des paires clé-valeur. La clé est un nom de variable au format String, et les valeurs peuvent être n’importe quel type JavaScript autorisé. Ceci est un exemple de dataLayer avec différents types de données :

dataLayer = [{      'products': [{              'name': 'Kala Ukulele',             'tuning': 'High-G',             'price': 449.75         },{             'name': 'Fender Stratocaster',             'tuning': 'Drop-C',             'price': 1699     }],     'stores': ['Los Angeles', 'New York'],     'date': Sat Sep 13 2014 17:05:32 GMT+0200 (CEST),     'employee': {'name': 'Reggie'} }]; 

Ici, nous avons des valeurs telles qu’un tableau d’objets (les produits), des valeurs numériques (prix), un tableau de chaînes (magasins), un objet date et un objet imbriqué (le nom de l’employé).

Le point ici est que dataLayer est générique et indépendant de l’outil. Tant qu’il se comporte comme votre tableau JavaScript typique, il ne sera pas limité à un seul outil. Les informations dans le dataLayer l’objet ci-dessus peut être utilisé par tout application qui a accès à l’espace de noms global de cette page.

La manière dont les données de ce tableau sont traitées est donc laissée à l’outil. Dans Google Tag Manager, par exemple, un objet d’assistance intermédiaire est utilisé pour traiter les données dans dataLayer, qui est ensuite stocké dans un modèle de données abstrait interne au sein de l’outil lui-même. Cela garantit que dataLayer peut rester générique et indépendant de l’outil, mais les données qu’il contient sont traitées pour se conformer aux fonctionnalités idiosyncratiques de Google Tag Manager.

L’objet d’assistance utilisé par Google Tag Manager possède un certain nombre de fonctionnalités intéressantes, telles que :

• Un auditeur qui écoute les poussées vers dataLayer. Si un push se produit, les variables du push sont évaluées.

• Obtenir et définir des méthodes qui traitent/manipulent dataLayer en tant que file d’attente (premier entré, premier sorti) et assurez-vous que les valeurs spéciales (objets, tableaux) dans le modèle de données peuvent être mises à jour et ajoutées correctement.

• La possibilité d’accéder aux commandes et aux méthodes des objets stockés dans dataLayeret la possibilité d’exécuter des fonctions personnalisées dans le contexte du modèle de données.

Celles-ci sont toutes transparentes pour les utilisateurs de Google Tag Manager, bien sûr, mais elles expliquent pourquoi, par exemple, la macro de variables de couche de données peut accéder de la même manière aux noms de variables en pointillés (gtm.element) et aux propriétés (gtm.element.id), et aussi pourquoi vous pouvez pousser plusieurs valeurs avec la même clé dans dataLayer mais seule la valeur la plus récemment poussée est disponible pour les balises qui se déclenchent après la poussée.

Étant donné que le modèle de données abstrait de Google Tag Manager ne respecte que la valeur la plus récente de tout nom de variable, l’organisation doit décider où et quand la couche de données en tant que composant métier devient dataLayer la structure du tableau. C’est le sujet du chapitre suivant.

Des objectifs commerciaux à la mise en œuvre technique

L’approche la plus courante, je crois, est que les exigences et les objectifs de l’entreprise sont traduits en un ensemble de paires clé-valeur, qui doivent être rendues/déployées par du code côté serveur, de sorte que dataLayer contient toutes les données nécessaires avant le chargement de l’extrait de conteneur GTM.

Naturellement, vous pouvez le faire avec du code côté client, et ce n’est pas le cas avoir être préremplies, mais les données critiques sont mieux sécurisées si elles sont rendues dans dataLayer le plus tôt possible dans le chargement de la page, afin que la perte de données soit minimisée si l’utilisateur décide de quitter la page avant dataLayer a rendu.

Voici un exemple. Nous avons une page avec les exigences commerciales suivantes que nous souhaitons suivre en tant qu’objectifs commerciaux :

1. Identifiant d’utilisateur – parce que nous voulons suivre l’intégralité du parcours utilisateur, pas seulement session par session ou appareil par appareil

2. Utilisateur interne – parce que nous voulons filtrer le trafic de nos propres employés à partir des données

3. Météo au moment de la visite – parce que nous voulons voir comment la météo affecte le comportement de visite

Il s’agit d’une liste simple, quoique absurde, d’exigences commerciales qui ont un impact direct sur la façon dont nous suivons les objectifs pour cette partie du site Web. Cette liste doit être accompagnée de plus d’informations, telles que ce qui est valeurs d’exemple pour ces variables, quelle est leur portée (appel, session, utilisateur, produit, par exemple), doivent-ils persister (rester allumé d’une page à l’autre), et ainsi de suite. Je ne le ferai pas maintenant, car cela dépend en grande partie de la façon dont votre organisation gère les projets qui s’étendent sur différents départements ou domaines d’activité.

Quoi qu’il en soit, un exemple de dataLayeraffiché avant l’extrait de conteneur, peut ressembler à ceci :

<script>     window.dataLayer = window.dataLayer || [];     dataLayer.push({         'userId' : 'abf5-3245-ffd1-23ed',         'internalUser' : true,         'weather' : 'Cloudy'     }); </script> <!-- GTM Container Snippet Code Here -->

Comme vous pouvez le voir, les données sont rendues avant l’extrait de conteneur GTM, de sorte que toutes les balises qui se déclenchent dès que GTM est chargé peuvent utiliser ces données.

Notez que vous pouvez et utiliserez dataLayer également dans les limites de Google Tag Manager, car vos balises ou d’autres bibliothèques sur la page pourraient bien insérer des données dans la structure après cette séquence de préchargement. Je ne pense pas que ces poussées dynamiques ou échanges de données aient besoin d’être documentés avec autant de soin, puisqu’ils se produisent uniquement dans le domaine de l’outil qui fait les poussées. Ainsi, la documentation et le contrôle de version sont laissés à la sophistication de l’outil lui-même.

La raison pour laquelle vous devez réfléchir longuement au pré-rendu dataLayer C’est parce que chaque nouvelle partie prenante rend la question de la gouvernance un peu plus complexe.

Gouvernance de la couche de données

Trouver un bon modèle de gouvernance est difficile. En trouver un pour une structure de données qui est à la merci d’un certain nombre de parties différentes, toutes avec différents niveaux d’expertise (et d’intérêt général), est encore plus difficile.

Néanmoins, un modèle de gouvernance bien défini, structuré et formalisé est probablement la seule chose qui empêchera votre organisation d’analyse d’imploser en raison d’erreurs de fonctionnement avec une couche de données.

Un modèle de gouvernance, dans ce contexte, est un document (ou une documentation) qui décrit aussi clairement que possible la couche de données, ses parties, les domaines d’activité dans lesquels elle est déployée, ses différents propriétaires, son historique de version, ses variables, comment la gestion des risques est manipulé, etc…

C’est un concept très fluide, et cela dépend vraiment de l’organisation comment elle veut s’organiser autour de ce projet, mais idéalement voici le type de modèle de gouvernance avec lequel je serais heureux de travailler :

Introduction

• Objet du document
• A qui s’adresse ce document
• Table des matières

II Historique des versions

• Ce qui a été révisé
• Quand il a été révisé
• Par qui il a été révisé

III Propriété

• Que signifie propriété
• À qui appartient le processus
• Quels sont les droits et privilèges du propriétaire

IIIa Parties prenantes

• Qui a un intérêt dans Data Layer (outils, plateformes, départements, agences, tiers)
• Quel est leur rôle
• Quels sont leurs droits et privilèges

IIIb Spécifications techniques

• À qui appartient la couche de données techniques (informatique, le plus souvent, ou un spécialiste du marketing très éclairé)
• Quel est leur rôle
• Quels sont leurs droits et privilèges

Gestion IIIc

• Qui est responsable des exigences commerciales (responsable du marketing ou rôle similaire dans l’organisation cliente)
• Quel est leur rôle
• Quels sont leurs droits et privilèges

IV Répartition des processus

• Quelles parties utilisent la couche de données
• Quelles sont leurs exigences particulières
• Comment éviter les conflits entre les différentes parties prenantes

Gestion des risques

• Quels sont les risques
• Quelle est leur gravité
• Quelle est leur probabilité
• Qui détient les risques (et toutes les mesures prises pour les atténuer).

Modèle de gestion de la couche de données VI

• Comment planifier les mises à jour
• Comment implémenter les mises à jour
• Qui déploie les mises à jour
• Qui teste les mises à jour
• Qui doit être informé
• Qui met à jour le document
• Comment éviter les conflits

VII Description technique de la couche de données

• Quelle est la structure de données sous-jacente
• Comment cette structure est-elle traduite dans le modèle de données propre à chaque outil ?
• Existe-t-il des noms de variables réservés ou d’autres sources potentielles de conflit

VIII Variables de la couche de données

• Exigences métier traduites en variables de couche de données
• Trié par domaine d’activité
• Exemples de valeurs, portée, paramètres, types attendus
• D’où viennent les données
• Comment les données sont utilisées
• Etc…

Je sais, ça a l’air horrible. Et probablement inutilisable pour beaucoup. Cependant, avoir un document comme celui-ci qui est également constamment mis à jour vous offre non seulement une certaine sécurité contractuelle, mais il permet également à tout le monde de se tenir au courant de la structure et du format les plus récents de la couche de données.

Ce document doit-il être consulté/mis à jour lorsque vous créez un nouvel extrait de code JavaScript qui calcule le nombre d’images sur la page ?

Probablement pas.

Ce document doit-il être consulté/mis à jour lorsque vous implémentez un pixel de conversion qui utilise également la valeur de transaction ?

Le plus probable.

Ce document doit-il être consulté/mis à jour lorsque vous déployez un eCommerce amélioré ?

Absolument.

Il n’a pas besoin d’être plus grand que nature ou d’être une énorme complication. Avoir juste quelque description concrète de la couche de données disponible à tout moment et, à tout le moins, convenir par écrit de la manière dont la couche de données est mise à jour et par qui. De cette façon, vous éviterez beaucoup de problèmes à long terme, lorsque des changements injustifiés sont sur le point de se produire.

Conclusions et lectures complémentaires

Je pense que Data Layer est un concept très difficile à appréhender. Ce n’est pas seulement parce que pour la plupart, il s’agit d’une chose technique, mais parce que la plupart ne réalisent pas qu’il s’agit également d’une liste d’exigences commerciales.

Traduire les objectifs commerciaux en une couche de données bien formée, allégée et utilisée à 100 % est vraiment difficile. Je pense honnêtement que l’une des plus grandes erreurs est de suivre le modèle en cascade, où un énorme La liste des exigences est notée au début du projet, puis traduite en une couche de données qui apparaît sur chaque page du site, et après ce point, la structure n’est plus jamais touchée.

Cela ne fonctionne pas.

Le modèle de la cascade est défectueux grâce à la faillibilité humaine. Nous ne pouvons tout simplement pas concevoir ou prédire la forme finale de quelque chose d’aussi vaste qu’une couche entière de données sémantiques, qui pourrait couvrir presque tous les aspects de notre contexte numérique. Il doit être agile. Il doit y avoir une compréhension mutuelle que la forme de la couche devient plus claire avec le temps.

Commencez petit et augmentez si vous avez le temps. Si vous êtes pressé, concentrez-vous uniquement sur les exigences critiques de l’entreprise.

Quoi que vous fassiez, assurez-vous qu’il existe un processus en place qui vous permet de suggérer rapidement des modifications à la couche de données. Cela nécessite beaucoup de lubrification, d’éducation et de transfert de connaissances. C’est pourquoi je pense que la chose la plus importante dans tout projet de données est de commencer par éduquer toutes les parties sur ce que les autres parties font dans le projet. Rendez les spécialistes du marketing plus soucieux du développement et les développeurs plus respectueux de vos efforts de marketing.

De cette façon, tout le monde y gagne et vous aurez une belle couche de données en un rien de temps.

Lecture complémentaire :

• Guide de développement de Google Tag Manager par Google

• Améliorez l’analyse avec la gestion des balises et une couche de données par Justin Cutroni

• Déverrouillez la couche de données : un guide pour les non-développeurs de Google Tag Manager par Dorcas Alexander / Bounteous

• La structure dataLayer en JavaScript 101 Pour GTM : Partie 1

PS Si quelqu’un connaît un très bon article sur la gouvernance des données sémantiques, j’aimerais le lire et le lier dans cet article.