Comme toute solution logicielle existant de longue date les codes de collecte Google Adwords, destinés à être utilisés sur le Web ont connu des évolutions significatives au fil du temps, à tel point qu'un intégrateur peut aujourd'hui opter pour près de 5 méthodes distinctes afin de transmettre les données indispensables au bon fonctionnement de la plateforme publicitaire de Google. Les deux raisons principales expliquant l'inflation des modes de collecte disponibles sont l'accroissement du volume d'informations traitées par Google Adwords au fil des années ET la nécessité de répondre à de nouveaux enjeux technologiques. Au programme de ce billet : exposer les caractéristiques des anciennes versions des codes de suivi Google Adwords et apprendre à choisir l'option la plus pertinente parmi celles promues à date par Google.
Chronique rapide de l'apparition des cinq méthodes de mesure
La méthode la plus basique et qui demeure proposée aux utilisateurs ayant désactivé l'exécution de codes JavaScript sur leur navigateur est le recours à un pixel de suivi. Cette méthode a très rapidement montré ses limites ce qui explique qu'un code JavaScript, initialement conçu pour une méthode de chargement synchrone, ait été introduit. A même de collecter des données utiles au remarketing et relatives à la conversion, cette bibliothèque JavaScript a progressivement montré ses limites notamment suite à l'accroissement de l'usage de système de gestion des balises qui en a fortement limité son utilisation du fait d'appels asynchrones aux ressources externes.
C'est afin de répondre à cette problématique de chargement asynchrone et de garantir le bon fonctionnement sur des sites ayant recours de façon prononcée aux requêtes AJAX, qu'a été introduite une version plus moderne de la bibliothèque JavaScript, parfaitement à même de répondre à ces deux enjeux. Parallèlement, l'intégration entre Google Analytics et Google Adwords n'a cessé de s'améliorer. Reposant sur la communication entre les deux produits aux moyen d'une API exécutée côté serveur ET la récupération de la valeur du paramètre gclid côté client, elle n'a cessé de gagner en popularité au fil des années.
L'introduction, en juillet 2017, sur le navigateur Safari, de la technologie dite de Prévention Intelligente du Suivi, limitant considérablement les possibilités d'usage de cookies tiers sur ce navigateur, a conduit Google à systématiser l'usage de cookies propriétaires en parallèle de cookies tiers, afin de contourner les restrictions imposées par cette technologie. Les versions synchrones et asynchrones des codes de suivi n'étant pas déployées systématiquement sur l'ensemble des pages d'un site, rendant par la même difficile le stockage des gclid générés suite au clic sur une annonce, un code complémentaire disponible sur Google Tag Manager et baptisé "connecteur" a été introduit afin de compléter les deux vénérables bibliothèques JavaScript.
Enfin, l'introduction en 2017 du code de suivi global gtag.js, né du désir de Google de proposer une bibliothèque JavaScript mutualisée entre ses produits les plus populaires, a ajouté un dernier membre à cette famille déjà bien fournie. Pleinement compatible avec les méthodes de chargement asynchrones et le stockage d'informations relatives aux annonces dans des cookies propriétaires, il s'agit de l'outil de suivi Google Adwords le plus avancé disponible à date.
Les caractéristiques des trois anciennes méthodes de suivi
La transmission d'informations au moyen d'un pixel a l'avantage d'être fonctionnelle sur l'ensemble des navigateurs, y compris ceux pour lesquels l'exécution de codes JavaScript aurait été désactivée. En revanche, les informations communiquées à Google doivent être assignées manuellement lors de la construction du pixel, ce qui peut rendre complexe la mise en oeuvre de certains paramétrages tels que le remarketing avancé. Par ailleurs, le pixel fournit moins d'informations à Google en comparaison des bibliothèques JavaScript, ce qui a une incidence sur le fonctionnement de certaines fonctionnalités de la plateforme.
La bibliothèque JavaScript conversion.js permet d'effectuer l'ensemble des paramétrages nécessaires à la mise en place du remarketing et du suivi des conversions. Néanmoins, le principal inconvénient de cette bibliothèque réside dans la nécessité de définir les différentes informations à transmettre à l'outil AVANT d'appeler la bibliothèque JavaScript. Cela implique qu'il est impossible de transmettre des informations à posteriori du chargement initial de la bibliothèque JavaScript, sans rappeler le fichier lié. Le suivi du clic sur un bouton, par exemple, nécessitera de rappeler le fichier JavaScript d'ores et déjà téléchargé lors du chargement initial de la page. Autre inconvénient de taille, le fichier s'avère incompatible avec certaines méthodes de chargement asynchrones.
La bibliothèque JavaScript conversion_async.js présente l'avantage, comme son nom l'indique, de pouvoir être chargé sans encombre avec des méthodes asynchrones. La bibliothèque permet au moyen de commandes normalisées de transmettre à tout moment et de façon répétée des informations à Google. Elle s'avère donc parfaitement compatible avec des installations de type Application à Page Unique. Une ombre au tableau toutefois : afin d'être utilisable, les différentes commandes JavaScript requièrent que les codes JavaScript soient totalement chargés. Un comble pour une bibliothèque comportant dans son libellé le terme async.
Enfin, dernier point et non des moindres, aucune de ces trois méthodes ne permet de rendre le suivi des conversions et actions utilisateurs pleinement fonctionnels si un visiteur utilise le navigateur Safari et par extension la Prévention Intelligente du Suivi. La fiabilité des données collectées peut donc s'avérer considérablement altérée, à moins de déployer la balise dite "connecteur" au moyen de Google Tag Manager, qui permet de contourner le problème en cas d'utilisation d'une des anciennes bibliothèques JavaScript. Malheureusement, il n'est pas possible d'obtenir le code JavaScript correspondant à cette balise afin de l'utiliser en dehors de Google Tag Manager.
Pour laquelle des deux méthodes modernes opter ?
A première vue, recourir à la version gtag.js de Google Adwords, pour toute nouvelle implémentation, semble être l'évidence. Proposant une syntaxe simplifiée et une méthode d'intégration extrêmement flexible, elle a tout pour plaire. Par ailleurs, elle gère nativement le suivi des utilisateurs utilisant la Prévention Intelligente du Suivi. Que demander de plus ? Rien si la recherche d'une amélioration des performances en terme de temps de chargement n'est pas prioritaire.
Dans le cas contraire, opter pour Google Analytics s'avère être la meilleure option. En effet, il s'avère possible d'exploiter les données transmises par la solution de mesure d'audience afin de paramétrer l'ensemble des éléments nécessaires au bon fonctionnement de Google Adwords au prix d'un enrichissement minime de la plupart des plans de marquage existants. Sans compter que si l'intégration de la solution de mesure d'audience a été réalisée via gtag.js, il devient possible de bénéficier, pour ainsi dire, du meilleur des deux mondes, tout en réduisant le volume de ressources téléchargées et de requêtes exécutées par le visiteur.
En conclusion
A mesure que les années passent, un véritable millefeuilles logiciel Google Adwords s'est constitué, dans le domaine du suivi des actions utilisateurs sur le Web. Si faire usage de la dernière version de la bibliothèque JavaScript de Google Adwords peut sembler être l'évidence pour toute nouvelle installation, il s'avère que l'intégration avec Google Analytics constitue au final une alternative beaucoup plus intéressante pour tout utilisateur de la solution de mesure d'audiences de Google. Pour l'intégrateur en revanche, qui peut être amené à devoir faire évoluer des plans de marquage plus anciens, une bonne connaissance des caractéristiques et limites des anciennes bibliothèques s'avère indispensable pour juger de la pertinence d'un maintien des codes existants ou au contraire de décider de procéder à une montée de version.