La limite du payload sur Universal Analytics

Qu'est ce que le payload sur Universal Analytics ?

Le script d'Universal Analytics analytics.js envoie les informations aux serveurs de Google en chargeant des images transparentes.

La liste des paramètres transmises à Google Analytics est écrite dans une chaîne de caractères : le payload, qui a cette forme :

v=1&_v=j56&a=818215533&t=pageview&_s=1&dl=http%3A%2F%2Flinuxfr.org%2F&ul=fr&de=UTF-8&dt=Accueil%20-%20LinuxFr.org&sd=24-bit&sr=1600x900&vp=1583x780&je=0&fl=26.0%20r0&_u=SCCAAMIJI~&jid=1856264349&gjid=1156765483&cid=2131200365.1498342667&tid=UA-12345-19&_gid=423688839.1498342667&_r=1&ti=T12345&ta=Google%20Store%20-%20Online&tr=37.39&tt=2.85&ts=5.34&tcc=SUMMER2013&pa=purchase&pr1id=P12345&pr1nm=Android%20Warhol%20T-Shirt&pr1ca=Apparel&pr1br=Google&pr1va=black&pr1pr=29.20&pr1cc=APPARELSALE&pr1qt=1&z=739145618

Si cette chaîne est de petite taille, vous pouvez la trouver dans l'URL de récupération de l'image transparente. Les détails sur les paramètres présents sur la document officielle de Google Analytics.

Quelle est la limite ?

Au delà de 8192 caractères, le hit ne part plus. Cela peut-être catastrophique, car il peut s'agir de la page d'arrivée (perte de la source de trafic...), voire d'une page de confirmation de commande.

Le risque est accru pour les sites en alphabet non-latin

Le risque est surtout important si vous devez traquer de façon avancée un site n'utilisant pas l'alphabet romain (mais du cyrillique, du mandarin...) car les chaines sont url-encodées avant d'être envoyées à Google.

Ainsi, en écriture latine, "dark knight" ne prend que 11 caractères.

En revanche, sa traduction russe : "темный рыцарь" sera traduite par "%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B9%20%D1%80%D1%8B%D1%86%D0%B0%D1%80%D1%8C" ce qui prendra 75 caractères, soit près de sept fois la taille de la version originale.

Le cas du e-commerce amélioré

Sur "enhanced ecommerce", il est possible de traquer la liste des miniatures produits affichées sur une page liste.

Si votre page liste comporte de nombreux produits, que vous ne souhaitez pas uniquement afficher les produits présents au-dessus de la zone de flottaison, que vous ne remontez pas que le nom des produits mais également les catégories, la marque... cela peut représenter énormément d'informations.

La simplicité est la sophistication suprême

Afin d'éviter d'atteindre ces limites, il est intéressant de se limiter volontairement dans la collecte des données.

En effet, inutile de collecter des dimensions personnalisées pour chacune des vignettes produits vues si elles ne seront pas affichées. Inutile également probablement, de remonter les informations de 50 vignettes produits vues si elles sont bien en-dessous de la ligne de flottaison.

Utilisation de flux

Il peut également être envisagé également de remonter une partie des informations (normalement remontées via des dimensions personnalisées notamment) via des flux et non via Javascript.

Cela vous permet de remonter des informations détaillées sans pour autant risquer des pertes dans la collecte.

Utilisation d'un hit dédié au e-commerce amélioré

Afin d'éviter que la limite soit trop facilement atteinte, il est possible de remonter les informations associés au e-commerce amélioré dans un événement distinct. De cette manière, dans tous les cas, les hits de page vues seront envoyés, et les informations de type source de trafic, pages consultées seront convenablement collectées.

Attention, cependant, ce hit supplémentaire sera comptabilisé dans les quotas, et aura donc potentiellement un impact sur l'échantillonnage.  Les chiffres présentés dans Google Analytics dans certaines conditions seront donc moins précis.

Et si vous détectiez la limite automatiquement ?

Il est possible de détecter que cette limite est atteinte, et de réduire automatiquement votre payload en conséquence. Cela doit cependant être considéré comme une protection de dernier recours, et non comme la norme.

Dans le code ci-dessous, dans le cas ou la limite est atteinte, je ne remonte les informations relatives qu'aux neufs premiers produits.

ga(function(tracker) {	
  var originalBuildHitTask = tracker.get('buildHitTask');	
  tracker.set('buildHitTask', function(model) {			
    originalBuildHitTask(model);
    var payload = model.get('hitPayload');
    if (payload.length > 8192) {
      // on doit faire perdre du poids au hit
      var payloadNew ='';
      payload.split('&').forEach(function(part){		
        if ((!/^pr([0-9]{2,})/.test(part))&&(!/^il([0-9]*)pi([0-9]{2,})/.test(part))){
	  if(payloadNew!==''){payloadNew=payloadNew+'&';}
	  payloadNew=payloadNew+part;
 	}
      });			
      model.set('hitPayload', payloadNew, true);
     }				
  });
});

C'est très "bourrin", et uniquement destiné à de la démonstration. N'hésitez pas à l'adapter à votre cas.

Idéalement, si j'étais amené à mettre réellement en place ce type de code, je déclarerais l'incident dans une dimension personnalisée afin de pouvoir suivre ce phénomène, et de pouvoir optimiser au mieux la correction.

Le cas de Google Tag Manager

Dans Google Tag Manager, le dataLayer est normé de sorte qu'il soit possible à un non technicien de poser un tag "enhanced e-commerce".

Le problème, c'est que les besoins de Google Analytics ne sont pas nécessairement les besoins des autres solutions.

Ainsi, il n'est pas aisé de déclarer dans le dataLayer officiel que l'on souhaite uniquement remonter les 3 premiers produits pour "enhanced ecommerce" mais les dix premiers produits pour une autre solution.

Les tags standard Universal Analytics vont donc collecter l'ensemble des informations produits présents dans le dataLayer et les transmettre à Universal Analytics.

Comme évoqué dans mon précédent article, le problème peut également être résolu en redéfinissant la variable "customTask".

Il faut donc créer pour cela une variable dans GTM de type "Custom Javascript". Vous pouvez la nommer "GA buildHitTask payload workaround" par exemple :

function(){
  return function(tracker){
    var originalBuildHitTask = tracker.get('buildHitTask');	
    tracker.set('buildHitTask', function(model) {
      originalBuildHitTask(model);
      var payload = model.get('hitPayload');
      if (payload.length > 8192) {
        // on doit faire perdre du poids au hit
        var payloadNew ='';
        payload.split('&').forEach(function(part){		
   	  if ((!/^pr([0-9]{2,})/.test(part))&&(!/^il([0-9]*)pi([0-9]{2,})/.test(part))){
	    if(payloadNew!==''){payloadNew=payloadNew+'&';}
	    payloadNew=payloadNew+part;
	  }
        });			
       model.set('hitPayload', payloadNew, true);
      }				
    });
  }
}

Une fois la variable crée, vous pouvez modifier la variable de configuration d'Universal Analytics de sorte que customTask soit associé à la fonction précédemment définie dans la variable.

Paramètres analytics pour éviter les problèmes liés à la taille du payload
Paramètrage analytics pour se protéger contre les dépassements de taille de payload

Maintenant, les hits seront dans tous les cas envoyés même si le dataLayer contient de nombreux produits.

Ce que je n'ai pas fait

Il est peut-être possible de faire sauter réellement la limite de 8192 octets via l'API task. Je n'ai pas cherché à le faire pour différentes raisons :

  • éthique / politesse : je ne veux pas contourner les règles que l'éditeur a mis en place
  • fiabilité : rien ne m'indique que même si j'arrive à faire sauter cette limite côté client / javascript, un autre contrôle n'est pas présent côté serveur. Et s'il n'existe pas aujourd'hui, il n'est pas impossible qu'il soit mis en place demain.

 

 

Publié le

A propos de Antoine Tissier

Diplômé ingénieur en informatique par l’Ecole Centrale de Lille, Antoine a travaillé plus de 10 ans au sein l’agence web altima° ou il a occupé différentes fonctions : ingénieur d’étude, chef de projet technique, ingénieur d’exploitation et Consultant Analytics pendant plus de 6 ans. Il a eu l’occasion de travailler pour de nombreux clients : Petit Bateau, le groupe SEB, le groupe L’Oréal, 3 suisses International, Axa, Cofidis Belglique, ING Direct… sur des missions d’implémentation, d’analyses, d’audit, et de dashboarding / reporting.

Laisser un commentaire

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