In Tribune expert

Les données digitales

La transformation digitale représente un enjeu pour de nombreuses entreprises : il est donc essentiel de collecter et d’analyser efficacement les données de navigation au travers d’un tracking performant. De nombreux outils de web analytics permettent d’analyser les données de performance sur un site web ou une application.

Cependant, pour exploiter pleinement ces données, il est important de pouvoir les croiser avec des données transactionnelles, comportementales ou CRM, voire de les intégrer dans des modèles de machine learning. Les données exportées des outils de web analytic se présentent sous forme de fichiers plats, où chaque ligne correspond à un hit : ces données sont très clairsemées (nombreuses données manquantes) et difficiles à exploiter.

Pour faciliter leur exploitation, utiliser un modèle de données hiérarchique peut se révéler utile.

Les modèles hiérarchiques, c’est quoi au juste ?

Le modèle hiérarchique est un type de base de données apparu au cours des années 70. Cette modélisation fut très utilisée dans de nombreux systèmes mainframes, comme par exemple la base de registre Windows. Les données sont représentées sous forme d’arbre, où chaque enregistrement, appelé nœud, a une relation père-fils avec les autres nœuds. Ce type de modèle permet de traiter les relations one-to-many, et la recherche y est simple, dès lors que le parent est connu.

En quoi un modèle de type hiérarchique peut-il faciliter l’exploitation des données digitales ?

On identifie quatre grands ensembles sur les données digitales :

  • Les visiteurs, identifiés par un id de cookie
  • Les visites réalisées par chaque visiteur
  • Les pages vues lors de chaque visite
  • Les événements survenus sur chacune des pages visitées

Il serait tout à fait possible de constituer un modèle relationnel classique, avec 4 tables distinctes pour chacun de ces ensembles. Cependant, cela nécessiterait de construire des identifiants, notamment au niveau pages et évènements, ceux-ci n’étant pas générés par les outils de web analytics, pour affecter les bons évènements aux bonnes pages vues. De plus, de nombreuses jointures seraient nécessaires pour requêter les données, ce qui ne serait pas optimal au vu de la volumétrie produite : il n’est pas rare que les données digitales approchent les 30 à 40 Go par jour !

L’autre approche est de définir une hiérarchie des données. Cela tombe bien, puisque c’est exactement la forme que prennent les données digitales 😉

Ainsi, on peut hiérarchiser la donnée de la manière suivante :

Pour chaque typologie, on pourra alors définir les attributs qui lui sont propres ainsi que précalculer un certain nombre de KPI. Par exemple pour une visite :

  • L’identifiant de la session
  • La date de début de la session
  • La durée de sessions
  • Le nombre de pages vues
  • Le nombre de pages produits vues
  • Un booleen indiquant si la session a été initialisée via une campagne
  • Et la liste des pages vues

De même, pour chacune des pages vues, on pourra définir :

  • L’URL de la page
  • L’URL referrer
  • Le type de page
  • Le temps passé sur la page
  • Le nombre de clics réalisé sur cette page lors de la session
  • Et la liste des events survenus sur cette page…

Et ainsi de suite.

Et concrètement, ça se présente comment ?

Nous avons eu l’occasion d’intervenir chez l’un de nos clients sur un projet relativement similaire. La solution de tracking à partir de laquelle les données sont collectées est le TMS Tealium. Etant donné la volumétrie collectée chaque jour, la solution a été développée sur Spark à partir d’un traitement développé en Scala, et le modèle stocké en format parquet dans un datalake hébergé sous HDFS.

Le modèle développé n’est pas proprement un modèle hiérarchique « classique », mais s’en inspire fortement.

Dans notre contexte client, il a été décidé de ne pas inclure les visiteurs dans le modèle hiérarchique, mais dans une vue séparée, dans laquelle les identifiants de visiteurs sont matchés avec les identifiants clients. 3 classes ont donc été implémentées en Scala :

  • Une classe Session
  • Une classe Pages
  • Une page Events

Un enregistrement dans la table exposée correspond donc à une session, comportant un champ de type array pour lister les pages vues et leurs attributs ; cet array de pages comportant lui-même un array de d’events listant les différents événements survenus sur chacune des pages.

Rien de tel qu’un exemple pour illustrer ce type de « modèle ».

Le modèle hiérarchique présentera la forme suivante:

Conclusion

Les modèles hiérarchiques sont donc tout indiqués pour exploiter les données digitales. Les avantages sont multiples :

  • pas de redondance au niveau du stockage ce qui permet de limiter la volumétrie
  • des KPI précalculés à chaque niveau, permettant de ne pas avoir à requêter le niveau de détail le plus fin en fonction des besoins
  • des jointures « implicites » permettant de minimiser le temps de requêtage

Bien entendu, il est nécessaire de réaliser un travail de qualité en amont au niveau du plan de taggage, et de bien définir les règles de gestion des données et des KPI.

Recent Posts
AVISIA