Google Tag Gateway vs Server-side GTM : lequel des deux est vraiment nécessaire à votre installation ?

Google Tag Gateway a débarqué en 2024 et a immédiatement divisé les opinions. Certaines équipes l'ont considéré comme la fin de la conversation sur le suivi côté serveur. D'autres l'ont considéré comme une solution de contournement légère.

Ni l'un ni l'autre n'est exact.

En réalité, les deux outils s'attaquent à des problèmes différents, à des niveaux différents de votre installation. GTG modifie l'endroit où les scripts sont chargés. Le GTM côté serveur modifie l'endroit où les données sont traitées et où les cookies sont écrits. Il ne s'agit pas de la même chose, et les confondre conduit à des configurations qui semblent complètes sur le papier, mais qui laissent ouvertes de réelles lacunes en matière de suivi.

Dans cet article, vous découvrirez ce que Google Tag Gateway change dans votre configuration et ce qu'il ne change pas, comment le GTM côté serveur gère différemment le traitement des événements, la durée de vie des cookies et la couverture multiplateforme, une comparaison directe des deux outils sur 7 dimensions, et un cadre clair pour décider quelle configuration (ou quelle combinaison) correspond à votre pile de suivi.

Qu'est-ce que Google Tag Gateway ?

Google Tag Gateway est un proxy géré par Google pour vos balises Google. Au lieu de se charger à partir de googletagmanager.com, votre script GTM provient d'un sous-domaine que vous contrôlez, quelque chose comme gtg.yoursite.com. La collecte des données GA4 se déplace du point de collecte de Google vers ce même sous-domaine.

Le sous-domaine vous appartient. Google en gère l'infrastructure. L'installation consiste principalement en un changement de DNS et une mise à jour du conteneur.

Il y a une contrainte qui mérite d'être mentionnée d'emblée : GTG couvre uniquement les produits Google. GA4, Google Ads, Floodlight et Google Tag sont donc inclus. Si vous utilisez Meta, TikTok, Klaviyo ou tout autre produit extérieur à cet écosystème, GTG ne couvre pas ces événements.

Que corrige le GTG ?

La plupart des bloqueurs de publicité fonctionnent en bloquant les requêtes vers des noms d'hôtes tiers connus. googletagmanager.com figure sur toutes les principales listes de blocage. GTG contourne ce problème en acheminant ces demandes via votre domaine, qui ne figure sur aucune liste.

Il s'agit d'une réelle amélioration. Les données agrégées dans le monde réel situent l'amélioration à environ 1,5 à 2,5 points de pourcentage pour les données Google qui, autrement, seraient abandonnées au niveau des scripts.

Deux choses que le GTM ne règle pas

1. Le problème du chemin

Tout d'abord, GTG ne résout pas le problème du chemin d'accès. GTG modifie la partie "domaine" de l'URL de la requête, mais les chemins d'accès restent les mêmes. Une demande de collecte de données GA4 aboutit toujours à /g/collect sur votre sous-domaine, quelque chose comme gtg.yoursite.com/g/collect/?id=G-12345678 . Les bloqueurs de publicité tels que Ghostery et uBlock Origin ne se basent pas uniquement sur les noms d'hôte. Ils filtrent également sur les signatures de chemin connues, et /g/collect est un modèle bien documenté qui apparaît dans la plupart des grandes listes de blocage. Déplacer la requête vers votre sous-domaine n'y change rien. Des bloqueurs sophistiqués continuent d'intercepter ces demandes, ce qui limite les possibilités de récupération de GTG.

2. Durée de vie des cookies

Les cookies sont toujours définis par le JavaScript exécuté dans le navigateur. Lorsque votre conteneur GTM se déclenche côté client, il écrit des cookies via document.cookie. La prévention intelligente du suivi de Safari limite ces cookies à 7 jours. Le domaine qui a servi le script n'a pas d'importance. L'origine du cookie est l'environnement JavaScript du navigateur. GTG ne modifie pas cette couche.

Pour tout parcours d'attribution de plus d'une semaine, ou pour tout visiteur revenant pour convertir après 7 jours dans Safari, le plafond de 7 jours s'applique toujours. Comme avant. Le chargement des scripts s'est amélioré ; le problème des cookies n'a pas bougé.

Qu'est-ce que le GTM côté serveur ?

Le GTM côté serveur retire entièrement le traitement des événements du navigateur et le place sur un serveur que vous contrôlez.

Votre navigateur envoie un événement à votre serveur. Le serveur le reçoit, le traite et le transmet à chaque plateforme par le biais d'appels API de serveur à serveur. Si vous utilisez le script de suivi amélioré avec votre conteneur de serveur, les bloqueurs de publicité n'ont aucune visibilité sur ces appels. Il n'y a rien à bloquer dans le navigateur.

Comment le GTM côté serveur fonctionne-t-il différemment ?

La situation des cookies change de manière significative. Votre serveur écrit des cookies à l'aide d'en-têtes de réponse HTTP Set-Cookie. La limite de 7 jours imposée par l'ITP vise les cookies écrits par JavaScript. Les cookies définis par le biais d'en-têtes provenant d'une première partie échappent à cette restriction. Un serveur correctement configuré peut écrire des cookies de première partie qui durent 365 jours ou plus.

Pour les sites où les clients mettent des semaines à se décider, cette différence dans la durée de vie des cookies est la différence entre une attribution précise et une attribution incomplète de par sa conception.

La couverture est une autre lacune que le GTM côté serveur comble. Le même conteneur peut acheminer des événements vers GA4, Google Ads Enhanced Conversions, Meta Conversions API, TikTok Events API et la plupart des autres plateformes qui proposent une API côté serveur. Si les campagnes cross-canal perdent du signal et que cela commence à se voir dans vos performances de reciblage(voici comment récupérer la perte de données), un seul pipeline d'événements vers toutes les plateformes est la solution structurelle.

Le compromis ? GTM nécessite un hébergement, une configuration et une connaissance de GTM pour fonctionner correctement. Il ne s'agit pas d'un changement rapide.

Google Tag Gateway vs Server-Side GTM : une comparaison directe

	Passerelle Google Tag	GTM côté serveur
Quels changements	Où les scripts sont chargés	Où se déroule le traitement des événements
Paramétrage des cookies	JavaScript (navigateur)	En-têtes HTTP (serveur)
Impact du PTI	Pas de changement	Les cookies peuvent durer plus de 365 jours (avec une configuration de stockage adéquate).
Contournement des bloqueurs de publicité	Chargement de scripts uniquement	Appels complets de serveur à serveur
Couverture de la plate-forme	Produits Google uniquement	Toute plate-forme dotée d'une API serveur
Complexité de la mise en place	Faible	Moyen à élevé
Augmentation typique des données	4-6%*	14-20%*

Il existe également une distinction technique entre GTG et sGTM qu'il convient de comprendre si vous vous intéressez au comportement du même site par rapport à celui de la même origine. GTG fonctionne à partir d'un sous-domaine comme gtg.yoursite.com. Il s'agit d'un même site, mais pas d'une même origine avec votre domaine principal. Une configuration sGTM complète peut servir des événements à travers un chemin sur votre domaine racine : votresite.com/collect. Même origine. Certains navigateurs et certains mécanismes de suivi les traitent différemment, et l'approche sGTM vous donne plus de contrôle sur ce point.

*Vérifier les données et la comparaison dans GTG ou GTM côté serveur ? Le dilemme du côté serveur par Niek Schlepers

Quelle configuration convient le mieux à votre cas d'utilisation ?

GTG est le bon choix si :

• Votre pile ne comprend que des produits Google (GA4, Google Ads, Floodlight).
• La plupart de vos utilisateurs utilisent Chrome
• Les cycles de conversion sont inférieurs à 7 jours
• Vous souhaitez une amélioration à faible coût avec une configuration minimale.

sGTM est le bon choix si :

• Vous effectuez un suivi sur plusieurs plateformes (Meta, TikTok, Klaviyo, Google).
• Vos clients mettent plus de 7 jours à se convertir
• Vous avez besoin de cookies qui persistent au-delà de la limite ITP de Safari
• Vous voulez que le consentement soit appliqué côté serveur et que les informations nominatives soient contrôlées avant que les données ne quittent votre infrastructure.
• Vous voulez comprendre toute l'étendue de ce que le suivi côté serveur récupère

En voici un exemple.

Vous effectuez un suivi sur plusieurs plates-formes. Une configuration côté serveur Meta dépend de sGTM, pas de GTG. Il en va de même pour TikTok, Klaviyo et tout ce qui ne fait pas partie de l'écosystème de Google.

Vos clients mettent du temps à se convertir. Les voyages de plusieurs semaines dans Safari nécessitent des cookies qui survivent au-delà du 7ème jour. GTG n'offre pas cette possibilité.

Vous voulez voir ce que vous perdez réellement. Il est difficile de se faire une idée complète de ce que le suivi côté serveur permet de récupérer tant que vous n'avez pas exécuté les deux configurations et que vous ne les avez pas comparées.

Vous avez besoin d'un contrôle des données allant au-delà de la récupération des données. sGTM vous permet de décider ce qui est transmis à chaque plateforme, d'appliquer une logique de consentement côté serveur et de supprimer les IIP avant que les données ne quittent votre infrastructure.

La plupart des équipes qui prennent au sérieux le suivi des conversions finissent par atteindre le GTM côté serveur. Le GTM peut être une première étape utile. Il ne résout toutefois pas la question de l'infrastructure.

GTG et Server-Side peuvent-ils fonctionner ensemble ?

Oui, Google Tag Gateway et le serveur Google Tag Manager opèrent à des niveaux différents et peuvent fonctionner l'un à côté de l'autre sans conflit. Il ne s'agit pas d'un choix "soit l'un, soit l'autre".

Avec sGTM déjà en place, votre conteneur côté navigateur continue à charger des scripts et à déclencher des événements. GTG gère la couche de livraison de scripts pour les balises Google en particulier. Le conteneur lui-même peut être servi à partir de votre sous-domaine sGTM ou de votre chemin de domaine. L'ajout de GTG n'interfère pas avec cela.

Un exemple concret : si vous utilisez le TAGGRS Enhanced Tracking Script pour l'écriture de cookies côté serveur, cela résout le problème de la durée de vie des cookies. GTG s'occupe du chargement du script. Deux tâches différentes, même domaine, pas de chevauchement.

Pour la plupart des installations qui ont dépassé la configuration de base, la combinaison pratique est la suivante :

• GTG pour Google tag script delivery
• sGTM pour le pipeline d'événements, la persistance des cookies et le routage multiplateforme.

GTG et sGTM : quelle est la place de TAGGRS ?

Le GTM côté serveur a besoin d'un serveur pour fonctionner. Pour la plupart des équipes, le besoin réel n'est pas la gestion de l'infrastructure. Il s'agit de la performance, de la fiabilité et de la configuration correcte des consentements sans temps dédié à DevOps.

TAGGRS fournit une infrastructure sGTM hébergée avec des connecteurs intégrés pour les principales plateformes publicitaires, l'intégration du mode de consentement et les contrôles de confidentialité. Êtes-vous prêt à dépasser la couche GTG et voulez-vous comprendre à quoi ressemble la récupération des données pour votre configuration spécifique ?

FAQ

Ai-je besoin de Google Tag Gateway ?

Si vous utilisez GA4 et Google Ads sans aucun suivi côté serveur, GTG est une amélioration pratique qui mérite d'être mise en place. Il récupère les données perdues en raison d'un blocage basé sur le nom d'hôte avec très peu de frais généraux d'implémentation. Si vous utilisez déjà sGTM, le gain incrémental de GTG est plus faible. Vos événements se déplacent déjà de serveur à serveur. GTG aide principalement la couche de chargement des scripts, que votre installation sGTM peut déjà gérer en fonction de la façon dont votre conteneur est configuré.

Google Tag Gateway corrige-t-il l'ITP de Safari ?

Non. GTG ne modifie pas la manière dont les cookies sont écrits. L'ITP s'applique aux cookies écrits par JavaScript, quel que soit le domaine qui a servi le script.

Quelle est la différence entre Google Tag Gateway et le balisage côté serveur ?

Google Tag Gateway modifie le lieu de chargement de vos scripts Google. Un sous-domaine que vous contrôlez au lieu du domaine de Google. Les scripts s'exécutent toujours dans le navigateur, les cookies sont toujours écrits par JavaScript et l'ITP s'applique toujours. Les bloqueurs de publicité sophistiqués qui s'appuient sur des modèles de chemin plutôt que sur de simples noms d'hôte peuvent toujours détecter et bloquer les requêtes.

Le marquage côté serveur déplace le traitement des événements du navigateur vers un serveur. Les cookies sont écrits via les en-têtes HTTP, ce qui les place hors de portée de l'ITP. Les événements atteignent les plateformes par le biais d'appels API de serveur à serveur que les bloqueurs de publicité ne peuvent pas toucher. Et contrairement à GTG, sGTM fonctionne sur toutes les plateformes dotées d'une API côté serveur, et pas seulement sur celle de Google.

Ils opèrent à des niveaux différents. GTG améliore la diffusion des scripts pour les balises Google ; sGTM gère le pipeline d'événements, la durée de vie des cookies et l'acheminement des signaux sur plusieurs plates-formes. Pour les configurations où les deux problèmes sont importants, ils fonctionnent ensemble.

Ai-je besoin de GTM côté serveur si j'utilise déjà Google Tag Gateway ?

GTG améliore la livraison de scripts pour les balises Google. Si vous utilisez des plateformes non Google, si vous avez besoin de cookies qui durent plus de 7 jours, ou si vous souhaitez un contournement complet des bloqueurs de publicité pour toutes les plateformes, sGTM comble ces lacunes.