Alors que la collecte de données devient de plus en plus difficile — entre les navigateurs qui restreignent les requêtes tierces, les scripts bloqués par les adblockers et la disparition progressive des cookies tiers — assurer le bon déclenchement des balises marketing se révèle plus complexe.
Ces évolutions techniques ont un impact direct sur la mesure des campagnes, la qualité des données et la capacité à suivre les conversions de manière fiable.
Pour répondre à ces nouveaux défis, Google propose une solution : Google Tag Gateway (GTG).
Cette approche permet de charger les balises depuis votre propre domaine, pour contourner les blocages liés aux domaines tiers et rendre la collecte plus résiliente, tout en respectant les exigences actuelles en matière de vie privée.
De quoi s’agit-il concrètement ?
Comment le mettre en place ?
Et surtout, est-ce une vraie réponse durable ou un simple patch de plus ?
On fait le point dans cet article.
Google Tag Gateway, de quoi s’agit-il ?
Un peu de contexte
L’explosion des contrôles réglementaires (RGPD, DMA, etc.) et techniques (ITP, adblockers, etc.), imposent des modifications de plus en plus poussées pour continuer à mesurer correctement le comportement des utilisateurs sur vos sites.
C’est là que Google Tag Gateway (ou “Passerelle de balise Google” sur la documentation officielle de Google) intervient pour reprendre le contrôle sur votre tracking.
Principe de fonctionnement
Techniquement, les balises de tracking sont des scripts qui envoient des informations (hits) vers des serveurs d’outils de mesure ou de publicité. Ces balises peuvent être appelées depuis le domaine du site lui-même (first-party, par exemple resoneo.com) ou depuis un domaine tiers (par exemple google-analytics.com).
Lorsque les balises sont appelées depuis un domaine tiers, les navigateurs les identifient comme provenant d’un acteur externe. Cela peut entraîner des restrictions spécifiques, notamment le blocage des cookies ou des requêtes. Exemple : hotjar.com.
Pour contourner ces limitations, il est possible de faire transiter les requêtes (clics, pages vues, etc.) via un Content Delivery Network (CDN) hébergé sur un sous-domaine du site (first-party, par exemple tracking.resoneo.com). Les données sont ensuite transmises aux partenaires (Google Analytics, Google Ads, etc.).
Résultat : cette approche permet de limiter les risques de blocage par les navigateurs, tout en maintenant une collecte de données fiable et conforme.
Pourquoi c’est utile ?
Google Tag Gateway est une solution efficace pour continuer à collecter vos données de manière plus performante.
Elle offre une meilleure qualité de collecte
Comme nous l’avons vu plus haut, les restrictions imposées par certains navigateurs peuvent bloquer ou limiter le bon fonctionnement des balises de tracking. Lorsqu’un utilisateur clique sur une publicité, des identifiants comme gclid, ou des paramètres UTM sont ajoutés à l’URL. Ces informations ne sont pas stockées automatiquement : elles doivent être lues par les balises, puis enregistrées dans un cookie first-party pour être associées à une conversion ultérieure. Si les balises ne peuvent pas lire ou stocker ces données, la correspondance entre le clic et la conversion est perdue, ce qui altère la qualité de l’attribution.
Grâce à GTG, les balises sont mieux collectées, car considérées comme first-party : vous limitez les pertes de données et améliorez la qualité de la collecte et donc par extension la qualité de la modélisation de vos conversions. Vous donnez ainsi à vos algorithmes plus de signal pour optimiser vos campagnes.
Elle permet une meilleure mesure de la performance
En passant par votre propre domaine, Google Tag Gateway permet de limiter le blocage de vos balises par les navigateurs… Résultat : plus de hits enregistrés dans Google Analytics et dans Google Ads, une couverture plus fiable, et donc une mesure de performance plus complète. C’est une façon efficace d’améliorer la qualité des données sans violer les règles de confidentialité.
Elle renforce la sécurité des données
En hébergeant les flux de données via votre propre structure, par exemple un sous-domaine dédié, vous limitez les appels directs vers des services tiers sur vos pages. Moins d’appels externes signifie un environnement plus sécurisé..
Google Tag Gateway permet ainsi de mieux contrôler les échanges de données, tout en maintenant une capacité de mesure fiable.
Il pourrait être tentant d’assimiler Google Tag Gateway à une solution de tracking Server-Side. En réalité, cette solution reprend certains principes du Server-Side, mais elle fonctionne différemment : elle agit principalement comme un proxy, sans traitement des données côté serveur.
Comment déployer GTG
Google Tag Gateway est une solution proposée par Google qui repose sur un reverse proxy (comme Cloudflare par exemple).
Son déploiement nécessite 3 pré-requis :
- Un accès aux services Google et un compte Google Tag Manager.
- Une gestion du nom de domaine et du sous-domaine appropriée.
- Des outils de débogage et des pratiques de conformité.
L’objectif est de faire en sorte que les fichiers JavaScript et les requêtes de mesure soient chargés depuis votre propre domaine, tout en les relayant vers les serveurs Google en arrière-plan. Cette méthode est plus simple à mettre en place, gratuite et accessible grâce à l’implémentation d’un CDN via CloudFlare. Il est tout à fait possible d’utiliser un CDN différent, mais cela ajoutera les coûts liés à celui-ci.
Pour cela :
- Choisissez votre chemin personnalisé. Par exemple : https://resoneo.com/gtag/. Ce sera l’URL visible dans le code source, utilisée à la place de https://www.googletagmanager.com/gtag/js.
- Configurez une règle de redirection proxi dans le CDN. Dans notre exemple : Redirection automatiquement de toutes les requêtes vers Google : resoneo.com/gtag/js → www.googletagmanager.com/gtag/js et resoneo.com/gtag/collect → www.google-analytics.com/collect
- Modifiez votre script de tracking : <script async src= »https://resoneo.com/gtag/js?id=G-XXXXXXX »></script>
Testez le fonctionnement : par exemple en utilisant l’outil Google Chrome Devtools. Le fichier doit bien se charger depuis le domaine, et les requêtes de mesure doivent bien se lancer.
Pourquoi est-ce différent du Server Side Tracking ?
GTG s’adresse aux projets qui veulent simplifier la mise en place d’un tracking plus fiable
Google Tag Gateway (GTG) s’adresse principalement aux entreprises qui souhaitent améliorer la fiabilité de leur tracking sans déployer une infrastructure Server-Side. Il est particulièrement adapté dans les contextes où :
- les ressources techniques sont limitées,
- le déploiement d’un serveur n’est pas envisageable,
- ou l’objectif est simplement de rendre les requêtes first-party pour contourner les bloqueurs.
GTG et SGTM répondent à des logiques différentes
GTG permet de servir les scripts de tracking depuis un domaine personnalisé, ce qui améliore leur chargement en contournant les blocages côté navigateur. Son rôle reste limité au déclenchement côté client, sans traitement des données.
SGTM, de son côté, repose sur une architecture serveur complète, capable de recevoir, filtrer, enrichir et rediriger les données selon des règles précises. Il s’agit d’une solution plus avancée, adaptée aux besoins de contrôle, de conformité et de qualité des données.
En résumé, GTG optimise le point d’entrée, SGTM maîtrise tout ce qui suit.
(Petit plus) Le cas particulier où GTG peut compléter SGTM
Dans la majorité des cas, SGTM suffit à lui seul. En effet, il fonctionne déjà sur un domaine first-party, ce qui suffit à contourner les principales limitations imposées aux cookies et aux requêtes.
Cependant, il existe un cas d’usage spécifique où GTG peut être utilisé en complément de SGTM :
Lorsqu’un navigateur ou un adblocker bloque le chargement du script gtag.js ou gtm.js avant même qu’un hit ne soit généré et envoyé vers le serveur SGTM.
Dans ce cas, même si SGTM est correctement configuré, le tracking ne démarre jamais… car le script n’a pas pu s’exécuter.
GTG permet alors de servir ce script depuis un domaine personnalisé, en l’hébergeant de façon first-party, ce qui le rend beaucoup moins susceptible d’être bloqué.
Une fois le script chargé, les balises côté client peuvent fonctionner normalement et envoyer les hits vers SGTM, où le traitement complet est assuré.
En conclusion
Google Tag Gateway répond à un besoin clair : fiabiliser le déclenchement des balises dans un environnement de plus en plus contraint. Facile à mettre en place, il permet de contourner les blocages côté navigateur en rendant les appels plus discrets, plus durables. Pour de nombreux projets, c’est une réponse rapide, accessible et efficace à la perte de données côté client.
GTG remplit son rôle : faciliter l’envoi des données dans un contexte client de plus en plus restreint.
Mais lorsqu’il devient nécessaire de structurer, contrôler ou adapter ces données avant qu’elles n’atteignent les plateformes, le Server-Side Tagging offre un cadre plus complet, pensé pour aller plus loin dans la maîtrise de la collecte.
Ajouter le fait que c’est uniquement écosystème google
BONUS : Tableau récapitulatif du déploiement de Google Tag Getaway via CDN vs. SGTM
| CRITÈRE | CDN (CLOUDFLARE,ETC..) | SGTM (SEVER-SIDE GTM) |
| Type de déploiement | Redirection des fichiers et requêtes via proxy | Conteneur serveur complet exécuté sur un hébergement cloud |
| Complexité technique | Moyenne (règles de proxy DNS/CDN) | Élevée (infrastructure cloud, DevOps, configuration GTM serveur) |
| Hébergement requis | Non, le CDN fait tout | Oui (Google Cloud, App Engine, Cloud Run, ou autre plateforme) |
| Personnalisation | Faible à moyenne (peu de logique possible) | Très élevée (filtrage, enrichissement, logique avancée possible) |
| Contrôle des données | Redirection pure (pas de traitement) | Complet : possibilité de modifier, bloquer, anonymiser les données |
| Vie privée/ conformité | Basique : meilleure que le client-side, mais limité | Fort : conformité RGPD, anonymisation IP, gestion avancée du consentement |
| Performance | Très élevée (CDN = rapidité et cache) | Bonne, dépend de l’hébergement (possibilité de latence) |
| Maintenance | Faible (le CDN s’autogère après configuration) | Moyenne à élevée (surveillance, logs, mises à jour serveur) |
| Temps de mise en place | Rapide (1 à 2 heures si CDN déjà en place) | Plus long (1 à 3 jours selon complexité et tests) |
| Coût | Faible voire gratuit (Cloudflare, etc.) | Variable (hébergement cloud, trafic, support technique) |
| Comptabilité outils | Google Analytics, Google Ads, tracking de base | Tous outils Google, CRM, API internes, tracking enrichi |
| Gestion du Mode Propriétaire | Simple relais des scripts et requêtes vers Google | Reconfiguration complète du parcours de données via GTM serveur |