Les évolutions de la collecte de données, de l’analyse des logs jusqu’au server-side (3)
Partager l'article sur :

Page 3/3

Comment les données sont-elles envoyées à la solution de digital analytics ?

Une fois les données récoltées par le tag, il ne reste plus qu’à les envoyer aux serveurs de la solution de mesure d’audience.

L’exécution de la fonction d’envoi (pour Google Analytics, la fonction « send ») contenue dans le tag transmet l’ensemble des données récoltées sur le visiteur et sur sa visite. Ces données sont récoltées via différentes sources : la première, celle présentée ci-dessus, par l’intermédiaire des variables présentes dans le tag, la seconde par l’intermédiaire des cookies (fichiers textes propres au navigateur Web) qui permettent de stocker des informations spécifiques sur le visiteur, et enfin la troisième par l’intermédiaire du navigateur qui détient un certain nombre d’information sur le visiteur (résolution d’écran, navigateur utilisé etc.).

Les données sont transmises via une requête composée de plusieurs paramètres contenant chacun une ou plusieurs données sur le visiteur et sur sa visite.

La requête est envoyée en utilisant la méthode d’envoi GET (en utilisant le protocole HTTP ou HTTPS en fonction du protocole utilisé par la page Web où est exécuté le tag).

Voici un extrait de requête faite par la solution Google Analytics :

extrait requete Google Analytics

Extrait de requête de la solution Google Analytics (visualisée grâce à la console du navigateur Google Chrome)

On constate par exemple que le paramètre tid prend la valeur du numéro de compte Google Analytics défini dans le tag (voir le code du tag plus haut).

Il est possible de visualiser les requêtes effectuées vers l’ensemble des solutions en utilisant le debugger du navigateur (exemples : sur Firefox, le plugin Firebug est souvent utilisé et sur Chrome, le Chrome Developer Tools). Les données sur le visiteur et sur sa visite sont en général envoyées grâce à la méthode GET sous forme de paramètre via l’appel d’une image transparente d’1×1 pixel. Une fois reçues par les serveurs de la solution de mesure d’audience, les données sont enregistrées et traitées.

Cliquez pour agrandir l’image

Chrome Developer Tools

Capture d’écran de Chrome Developer Tools (raccourci : CTRL + MAJ + i) 

Les noms des paramètres utilisés par les solutions dans les requêtes qui sont envoyées à leurs serveurs sont différents des noms des variables utilisées dans le tag à cause de la limite de taille des requêtes envoyées. Cette limite est variable d’un navigateur à l’autre mais est en moyenne de 3000 caractères (pour les requêtes réalisées en utilisant la méthode GET). Si la requête envoyée dépasse cette limite, elle est coupée par le navigateur et le serveur de la solution ne reçoit alors qu’une partie des données. C’est pour cela que les noms des paramètres utilisés par les solutions dans leurs requêtes sont souvent très courts.

Cette différence entre noms des paramètres des requêtes et variables utilisées dans le tag rend fastidieux la vérification des données envoyées.

C’est la raison pour laquelle les solutions fournissent en général un tableau descriptif de chaque paramètre permettant de s’assurer de la valeur de chacun d’entre eux (exemple : tableau descriptif des paramètres Google Analytics).

Si l’implémentation de la solution a bien été réalisée, une requête est faite par page vue étant donné que le tag de la solution aura été soigneusement inséré sur toutes les pages. Si l’annonceur souhaite mesurer un ou plusieurs éléments précis contenus dans la page (ex. : le nombre de téléchargement d’un fichier, le nombre de lecture d’une vidéo etc.), autant de requêtes supplémentaires qu’il y a d’éléments précis mesurés seront envoyées aux serveurs de la solution.

Conclusion sur la méthode de récolte des données via les tags

La méthode de récolte des données via l’utilisation des tags JavaScript permet de quasiment tout mesurer, des transactions e-commerce jusqu’au nombre de clics effectués sur n’importe quel élément de la page.

La mesure du nombre de visiteur unique reste cependant approximative et devrait plutôt être appelée navigateur unique (terme utilisé dans la solution ComScore Digital Analytix, racheté par Adobe en novembre 2015). En effet, les solutions créent et utilisent un cookie (propre au navigateur du visiteur et stocké dans celui-ci) pour identifier spécifiquement chaque visiteur. Il suffit alors qu’un visiteur se rende sur le même site avec son PC puis son téléphone pour que la solution de digital analytics comptabilise 2 nouveaux visiteurs au lieu d’un seul… C’est là qu’intervient la fameuse réconciliation « cross-device » !

La méthode de récolte des données via les tags est cependant victime de son succès, il n’est pas rare de voir des sites avec plusieurs dizaines de tag qui s’exécutent sur chaque page.

Cela alourdit le temps de chargement de la page, nuit à l’expérience utilisateur et diminue les taux de conversion.

Aussi, un des enjeux des annonceurs est d’être en conformité avec la législation sur le respect de la vie privée des internautes et de maitriser l’envoi de leurs données à leurs partenaires pour éviter toute fuite de données. Or il est malheureusement courant que des tags embarquent eux-mêmes d’autres tags, appelés tags de second niveau, derrière lesquels se cachent des solutions / usages dont l’annonceur n’a pas connaissance.

Le futur : le server-side

Nous devrions assister de 2016 à 2018 à l’émergence d’une nouvelle forme de collecte de données : le server-side.

Le server-side, après la collecte de données via l’analyse des logs puis via les tags JavaScript, devrait être la troisième génération de collecte de données.

L’idée est de ne plus envoyer plusieurs fois les mêmes données à plusieurs solutions mais de n’envoyer les données qu’une seule fois à sa solution de Tag Management System (TMS) qui se chargera de les envoyer ensuite à l’ensemble des solutions souhaitées.

A chaque génération de page / écran, le site / l’application génère un appel vers le TMS avec les données du datalayer qu’il souhaite transmettre à ses partenaires. C’est ensuite le TMS qui déclenche, en fonction des règles définies par l’annonceur, les tags des partenaires :

Cliquez pour agrandir l’image

Schema Server side

Voici les points forts du server-side :

  • Augmentation des taux de conversion en diminuant le temps de chargement des pages (il n’y a plus qu’un tag qui est appelé contre plusieurs dizaines aujourd’hui)
  • Meilleure prise de décision grâce à des données plus fiables : le déclenchement des tags ne dépend plus de l’interaction de l’utilisateur avec la page (ex : fermeture de la page de conversion avant que celle-ci ait fini de charger et donc que les tags aient été exécutés). Les taux de transmission approchent les 100%, là où le taux de transmission de la technologie tag varie fortement
  • Reprise du contrôle sur les données transmises aux partenaires : l’exécution des tags coté client favorise la fuite de données (« data leakage »), en effet, ceux-ci peuvent récupérer des données sans avertir l’annonceur et les envoyer à des partenaires tiers (via les tags de second niveau). L’approche server-side permet de contrôler l’envoi de ces données.

L’adoption du server-side est ralentie par le manque de compatibilité des solutions avec ce mode de fonctionnement. Cependant, de plus en plus d’annonceurs sont conscients des avantages et poussent pour que l’ensemble des solutions qu’ils utilisent deviennent compatibles.

1/2/3

Article suivant

A lire aussi…

Avant et après l’arrivée des Tag Management System (TMS)

Etre conforme avec la loi sur les cookies, une option ?

Le digital analytics et l’évolution des technologies de stockage de données

Les communautés qui gravitent autour du digital analytics

Les grandes tendances du digital analytics en 2016

Les grandes évolutions du digital analytics de 1993 à nos jours

Présentation du marché des solutions majeures de digital analytics

Les principales différences entre les solutions de digital analytics gratuites et payantes


Partager l'article sur :
Vous aimerez aussi