GTM Server Side – L’évolution naturelle pour votre tagging ?

Article Analytics 11.09.2020
Par Converteo

En bêta privée depuis le début d’année accessible aux Partners Google, la version Server-Side de Google Tag Manager (GTM) est sortie en beta publique en Août 2020.
Nous évoquions déjà, dans un billet de 2017, l’intérêt des solutions de Tag Management Server-Side – dont certaines sont déjà bien en place, comme TagCommander Server-Side, Tealium, Segment, Addingwell

Pour compléter votre lecture, vous pouvez revoir notre webinar : GTM Server-Side : vers un tracking hybride client-serveur.

Nous vous proposons d’expliquer et analyser l’architecture et la philosophie de la dernière évolution majeure du TMS de Google à travers cet article et pourquoi un Tag Management System est indispensable pour simplifier et optimiser la gestion des tags tiers sur un site web ou mobile.

Quelles différences entre GTM Server-Side & Client-Side ?

Pour bien comprendre l’apport de GTM Server-Side, notamment par rapport à la version standard client-side, nous nous intéressons ici à l’architecture proposée.

En version standard

Dans la version classique de Google Tag Manager, les tags (Google Analytics, Floodlight, Facebook …) sont installés directement dans un conteneur Web qui est appelé au sein de votre site. Ces tags, en s’appuyant sur les informations de la page en cours (dataLayer par exemple) envoient des requêtes depuis le navigateur du client aux serveurs des solutions concernées.

En version Serveur

Dans la version Server-Side, Google Tag Manager introduit un nouveau type de conteneur « Serveur » qui viendra s’installer directement dans une instance Google Cloud (App Engine) dont vous êtes propriétaire.
L’intérêt est de pouvoir gérer une couche intermédiaire – un endpoint HTTP, qui va servir de proxy – entre des requêtes génériques émises par le navigateur du client ou par n’importe quel autre serveur, et les solutions.
Comme l’indique le schéma ci-dessous, les tags sont désormais posés côté serveur : il est possible avec une requête du côté du navigateur du client, qui est ensuite retraitée et consolidée, d’alimenter plusieurs tags de solutions.

Il est à noter que cet Endpoint HTTP peut être mappé sur un sous-domaine propriétaire, permettant ainsi d’évoluer dans un univers first-party.

Pour plus de détails techniques sur l’architecture Google Tag Manager Server-Side, vous pouvez consulter le blog de Simo Ahava qui a fait un article très complet à ce sujet. Celui-ci explique notamment la nouvelle notion de « client » qu’introduit GTM Server-Side, un nouvel élément responsable de la manipulation des données dans le conteneur Server-Side, qui est à distinguer du « client » qui habituellement désigne plutôt le navigateur web (!!).

On espère que Google trouvera rapidement une astuce pour résoudre cette confusion sémantique !

The Filter : Data Privacy Framework : Quelles conséquences pour les entreprises européennes ?

Quels avantages à utiliser GTM Server Side ?

Nous avons listé ici 4 avantages majeurs :

  • Amélioration de la performance du site grâce à la réduction de la charge côté client / navigateur web

GTM Server-Side permet de déplacer la logique de construction et de dispatch des hits vers les solutions du navigateur vers le serveur. Un site qui déclenche 10 tags depuis le navigateur du client pourrait en théorie ne générer qu’une seule requête depuis celui-ci, qui serait ensuite traitée, mappée, et dispatchée dans 10 tags installés dans le container Serveur.

Quand on connaît les impacts potentiels sur la performance que peut avoir les tags contenu dans un containeur GTM Web, la promesse est donc très intéressante.

  • Meilleur contrôle sur les données

Les scripts third party appelés sur un site de façon standard peuvent être malicieux : exécution de scripts non désirés, envoi d’adresses IP clients à des tiers et plus globalement Data Leakage… Avec GTM Server-Side, vu que tous les hits sont reconstruits depuis le serveur, le contrôle sur la donnée transmise est complet. La confiance est ainsi déplacée des scripts des éditeurs vers soi-même.

  • Amélioration de la qualité des données collectées

Premièrement, GTM Server Side est… sur un serveur. On peut donc tout à fait imaginer des schémas où les données de transactions d’un site ecommerce sont envoyées directement depuis le serveur de transaction au container GTM pour être redispatchées à Google Analytics, et avoir ainsi un écart entre le back-office et sa solution Analytics proche de 0. Globalement cela gomme une bonne partie des inconvénients liés au déclenchement d’un tag de conversion sur la page de confirmation, dans la mesure de ces mêmes conversions.

Deuxièmement, le déplacement du traitement des hits sur un serveur peut par exemple permettre de limiter le spam dans l’envoi des données aux solutions éditeurs : les tags peuvent désormais contenir une clé qui transitera uniquement entre les serveurs, et qui ne sera pas exposée dans le navigateur du client.

Enfin, GTM Server Side permet de créer un environnement first-party ce qui va avoir plusieurs avantages :

  • Réduire l’impact de certains Ad-blockers

Certains Ad-Blockers fonctionnent sur un système de liste noire : ils vont bloquer les requêtes destinées à des serveurs connus, au hasard google-analytics.com. Avec GTM Server Side, la requête qui va contenir les informations de tracking Analytics est envoyée vers votre sous-domaine, avant d’être dispatchée vers google-analytics.com. Votre sous-domaine n’étant pas sur liste noire, le tracking ne sera pas bloqué dans ce cas.

  • Contournement à ITP / ETP

Avec GTM Server-Side, il est possible de créer ses cookies first-party depuis votre serveur. Ainsi, les cookies ne sont plus exposés à l’Intelligent Tracking Prevention d’Apple car ne sont plus générés par du JavaScript côté navigateur. En effet les requêtes entre le site et GTM restants localisées sur le même nom de domaine, les cookies associés sont considérés comme étant légitimes face à ITP.

  • Intégration à toute la suite GCP

Pour le moment, GTM Server Side est déployé via AppEngine sur Google Cloud Platform. Les possibilités sont encore limitées, mais il est probable que dans le futur GTM puisse être déployé avec d’autres modules type Cloud Run et que la solution s’intègre à tout l’environnement GCP… Avant d’être déployable dans d’autres environnement cloud (AWS ? Azure ?).

Quelles limites actuelles ?

Google Tag Manager Server Side présente de nombreux avantages, mais n’est pas la réponse à tout et présente des limites à avoir en tête :

  • En Production, Google Tag Manager Server Side est payant

Dans le schéma actuel, le container Server-Side est déployé dans une instance App Engine sur Google Cloud Platform. Il est actuellement possible de déployer GTM Server-Side gratuitement sur un environnement standard App Engine. Ceci sera suffisant pour mener vos premiers tests. En revanche, en production, et pour faire transiter tous les hits de votre trafic, il est vivement recommandé de passer sur un environnement Flexible avec un minimum de 3 serveurs.

Pour vous donner un exemple et un ordre de grandeur, on peut compter en moyenne 100€ / mois pour faire tourner 3 serveurs App Engine pour un trafic modéré.

Les coûts du Cloud étant à la baisse, et au regard des avantages sur le contrôle de la donnée, l’investissement est cependant rapidement amorti.

  • Cela nécessite un travail de migration des tags

Basculer certains de ses tags dans une logique server-side représente un travail conséquent , avec une logique nouvelle propre à un environnement cloud.

  • L’architecture Server-Side n’est pas valable pour tous les tags

De nombreux éditeurs permettent de recevoir des données directement depuis un serveur (Google Analytics, Facebook) mais ce n’est pas le cas de tous. Par exemple : il n’est pour l’heure pas possible d’utiliser GTM Server Side pour une application trackée sous Firebase.

Prenons également l’exemple des tags d’UX Analytics : Hotjar collecte tous les déplacements de souris qui sont envoyés directement à la solution via le navigateur du client – et cette solution n’est pas prête pour du server-side, pour le moment.

  • L’architecture Server-Side n’est pas valable pour tous les sites

Les sites qui ont une architecture qui visent à minimiser le nombre d’appels serveur – comme les Progressive Web Apps (PWA) par exemple – ne semblent pas être les meilleurs candidats pour être des early adopters de la solution !

  • C’est en Beta

La solution étant encore en Beta, elle est encore potentiellement instable et surtout en construction. Par exemple, la gallery de tags disponibles pour GTM Server Side en est encore à ses débuts.

De plus, l’environnement actuel étant en plein mouvement sur les questions de législation, privacy et de sécurité des navigateurs, il convient à notre sens de ne pas se jeter à corps perdu dans la solution mais plutôt de commencer à s’y préparer.

En définitive, quoi penser de GTM Server Side ?

GTM Server Side représente une évolution majeure dans le stack Google.

Cette évolution est portée par 2 dynamiques importantes sur le marché :

  • La démocratisation du cloud notamment au travers de Google Cloud Platform (GCP)
  • La nécessité de mieux contrôler et maîtriser les flux de données – notamment publicitaires – et leur qualité

Pour ces raisons : il est important de commencer à s’intéresser à la solution dès maintenant. La complexité apparente de cette nouvelle architecture peut effrayer mais il faut considérer la sortie de GTM Server-Side comme une opportunité de mettre un pied dans l’apprentissage de GCP.

Toutefois, la solution ne va certainement pas remplacer la logique côté client web : c’est une solution de tagging côté serveur, et non de tracking. Et on se dirige probablement dans le futur vers un modèle hybride de tracking Client-Side / Server-side pour essayer d’atteindre l’optimum entre respect de la privacy / performances / qualité & contrôle des données.

A suivre donc !

Vous pouvez accéder ici à la documentation officielle de Google.

Par Converteo

Nos ressources associées

1 / 1