Le suivi multi-propriétés est une problématique incontournable sur Google Analytics. S'il existe diverses raisons pouvant justifier de transmettre, sur une même page ou un même écran, des données à deux propriétés Google Analytics distinctes, les plus courantes demeurent la mesure des actions utilisateur au lendemain d'une refonte et la mise en oeuvre d'un plan de marquage sur l'ensemble des sites appartenant à une même entité, tout en préservant autant que possible les quotas de collecte octroyés par Google Analytics sur certaines propriétés. Dans de tels cas de figure, quel est le mode de paramétrage le plus efficace afin de mettre en oeuvre un suivi multi-propriétés ?
Les possibilités offertes par la bibliothèque JavaScript analytics.js
En dépit de l'introduction de la bibliothèque gtag.js en 2017, analytics.js demeure l'outil dédié à la collecte de données Google Analytics actuellement maintenu à jour le plus utilisé pour transmettre des informations à Google Analytics. Il n'est donc pas inutile de s'intéresser aux possibilités de paramétrage qu'il propose en terme de suivi multi-propriétés, d'autant plus qu'une telle fonctionnalité existait déjà sur l'ancienne bibliothèque JavaScript ga.js. Les développeurs de Google ont donc pu capitaliser sur le système historique des traceurs, à la fois simple et ingénieux, afin de proposer aux intégrateurs de multiples possibilités de paramétrage.
Tout traceur créé peut se voir assigner un nom. Si une telle démarche demeure optionnelle lorsque la page n'abrite qu'un unique traceur, elle devient incontournable lorsqu'il est question de mettre en oeuvre un suivi multi-propriétés. En effet, toute demande de création d'un nouveau traceur, dont le nom serait identique à un traceur existant, est systématiquement rejetée par la bibliothèque analytics.js. Or, chaque traceur ne peut transmettre des données qu'à une unique propriété. Par conséquent, donner un nom à tous les traceurs créés après que le premier ait été initialisé sur la page s'avère indispensable dans une telle configuration.
Bien qu'il puisse sembler logique, à première vue, de transmettre par défaut des données à l'ensemble des traceurs présents sur la page et d'offrir la possibilité en cas de besoin de ne le faire qu'à un ou plusieurs d'entre eux, les développeurs de Google ont pris le parti inverse. Par conséquent, un intégrateur devra impérativement exécuter trois commandes de type "send", chacune préfixée du nom du traceur approprié, s'il désire envoyer des données à différentes propriétés. Un tel exemple démontre que si assigner des noms à chaque traceur facilite leur identification, ainsi que les sessions de test, elle rend beaucoup plus ardue l'utilisation au quotidien de l'outil. Afin de contourner le problème, l'intégrateur peut recourir à trois approches distinctes.
La première consiste à créer une fonction javascript personnalisée, qui se chargera de transmettre aux différents traceurs les paramètres fournis lors de son appel. Simple à mettre en oeuvre, cette approche a pour défaut essentiel de nécessiter de devoir opter pour un mode de déclaration des paramètres de la fonction ga reposant sur l'usage systématique d'un objet, sous peine de devenir gérer les différents cas de figure liés au recours aux différents types d'appels Google Analytics, tels que les pages vues et les événements, et du nombre variable de paramètres qui en découle.
La deuxième approche tire parti de la fonction getAll proposée de façon standard par analytics.js et qui permet d'itérer sur les différents marqueurs présents de sorte à leur transmettre à chacun une commande selon leur nom ou tout autre paramètre les constituants. A moins que le plan de marquage ne soit mis à jour par des utilisateurs disposant d'un profil technique, la plupart du temps, le recours à cette fonction sera masqué aux utilisateurs en étant directement intégrée au sein d'une fonction intermédiaire de traitement, comme cela était le cas dans la première méthode décrite.
La troisième et dernière approche n'a vu le jour que très récemment avec l'introduction des tâches personnalisées, qui permettent de manipuler les données calculées par le kit de programmation JavaScript de Google avant leur envoi au point de collecte de Google Analytics. En initialisant une tâche personnalisée chargée de dupliquer les paramètres à transmettre à Google Analytics, après avoir changé l'identifiant de la propriété, il devient possible d'offrir une méthode de suivi multi-propriétés totalement transparente pour l'utilisateur final qui peut se contenter d'appeler une unique commande, rendant inutile la création de différents traceurs. Une fois encore cependant, la méthode présente des inconvénients. En effet, il s'avère extrêmement difficile de rédiger la tâche personnalisée de sorte à transmettre certains appels, mais pas d'autres, à une ou plusieurs propriétés clairement identifiées.
Les méthodes natives et personnalisées ne donnant pas pleinement satisfaction, Google a revu sa copie lors de l'introduction de la bibliothèque gtag.js.
Les possibilités offertes par la bibliothèque JavaScript gtag.js
Contrairement à analytics.js, gtag.js ne repose pas sur des traceurs, identifiés par des noms, pour transmettre des données au point de collecte Google Analytics. Le système de gtag.js repose sur les identifiants des propriété en tant que tels, spécifiés dans un objet de configuration, afin de gérer la transmission des données à une propriété donnée. L'usage d'un identifiant pour cibler une propriété, bien que pouvant sembler moins commode de prime abord, s'avère à l'usage limiter considérablement les risques d'erreur en rappelant constamment la destination des données transmises.
Autre point différenciant majeur, gtag.js est conçu pour transmettre par défaut des informations à l'ensemble des propriétés Google Analytics ayant été initialisées. C'est un renversement complet de paradigme, en comparaison d'analytics.js, le suivi multi-propriété devenant de fait la norme et la transmission de données de façon différenciée l'exception.
Pour finir, les équipes de Google ont rendu possible la définition de groupes de propriété. La bibliothèque offre ainsi la possibilité de transmettre tout aussi simplement des données à l'ensemble des propriétés déclarées, à un groupe plus restreint de propriétés, ou au contrainte à une seule d'entre elles, selon le bon vouloir de l'intégrateur.
En conclusion
Les possibilités nouvelles offertes par gtag.js en terme de suivi multi-propriétés, en comparaison du vieillissant analytics.js, rendent son utilisation incontournable à toutes les organisations ayant recours de façon intensive à la transmission simultanée de données vers plusieurs propriétés Google Analytics.