Compliant with GDPR, CCPA, COPPA, LGPD, PECR, PDPA, PIPEDA, and more.
Google Tag Gateway (GTG) est une fonctionnalité d'infrastructure Google qui sert les tags Google — y compris gtag.js, Google Tag Manager et Google Analytics — depuis un domaine propriétaire (first-party) plutôt que depuis les serveurs de Google. Au lieu que le navigateur récupère les scripts depuis googletagmanager.com ou google-analytics.com, les requêtes sont dirigées vers un chemin first-party sur votre domaine, par exemple votre-domaine.com/gtg/js. Un CDN (Cloudflare, Akamai ou Fastly) ou un répartiteur de charge redirige ces requêtes vers Google de manière transparente.
Pour la documentation officielle, consultez la documentation Google Tag Gateway.
Il existe deux méthodes de déploiement :
Le fournisseur CDN (par ex. Cloudflare) injecte les tags de mesure directement dans l'élément head de la page via le CDN. Cela supprime votre contrôle sur l'ordre de chargement. Le CDN décide quand et comment les URL des tags Google sont réécrites, et vous ne pouvez pas contrôler la position de ces scripts par rapport au snippet CMP.
Comme les tags GTG se chargent en tant que scripts first-party (depuis votre propre domaine plutôt que depuis le domaine de Google), le blocage en mode de consentement basique qui recherche les scripts chargés depuis le domaine de Google Tag Manager devient inefficace. Les tags apparaissent comme des ressources first-party et ne sont pas interceptés par les règles de blocage basées sur le domaine.
Vous ajoutez manuellement le chemin du script first-party dans le code source de la page et contrôlez son emplacement par rapport aux autres scripts. Cela vous donne un contrôle total sur l'ordre de chargement. La configuration manuelle est le déploiement recommandé lorsque le timing du consentement est critique.
Pour les instructions de configuration, consultez Configurer Google Tag Gateway.
Lorsque GTG n'est pas actif, les tags Google se chargent depuis des domaines tiers. Le flux de consentement est prévisible : votre CMP se charge en premier, définit les paramètres de consentement par défaut, et les tags Google respectent ces paramètres lors de leur exécution.
Lorsque GTG est actif, en particulier via l'injection CDN en un clic, les tags Google peuvent se charger plus rapidement car ils sont servis depuis un domaine first-party. Si la CMP n'a pas encore défini les paramètres de consentement par défaut au moment où le tag Google s'exécute, le tag fonctionne sans signaux de consentement. On parle alors de signal de consentement « tardif ».
denied) ne sont pas appliqués lors de l'exécution initiale du tagPour garantir le maintien des mesures sans violer le consentement, vous devez définir un bloc de refus par défaut afin que les tags Google démarrent dans un état refusé. La CMP se charge ensuite et réautorise explicitement le consentement pour les domaines où l'utilisateur a déjà accepté. Les événements sont mis en file d'attente et rejoués une fois le consentement accordé.
Si vous utilisez Google Tag Manager, vous pouvez définir un état de refus par défaut directement dans GTM :
Cela injecte un bloc de code de refus par défaut avant le chargement des tags Google via le CDN. Vous pouvez également utiliser les contrôles de transmission des données pour empêcher l'envoi de données de mesure comportementale et de configuration à Google lorsque le consentement est refusé.
Pour en savoir plus sur l'implémentation du consentement et le dépannage, consultez la documentation Google sur Consent Mode.
Vous pouvez vérifier si un tag est inscrit à Google Tag Gateway via les paramètres de votre tag Google. Consultez Accéder aux paramètres de votre tag Google pour les instructions détaillées sur la vérification du statut d'inscription GTG.
Pour vérifier si un tag est inscrit à GTG, utilisez https://tagassistant.google.com/ pour trouver l'ID du conteneur (GTM-XXXXX) ou l'ID du tag sur la page. Allez sur https://tagassistant.google.com/, cliquez sur « Add domain » et entrez l'URL de votre site web. Vous verrez alors les IDs de tags Google tels que GTM-XXXXX, AW-XXXXX ou G-XXXXXXXX.
Cliquez sur Résumé, puis vérifiez les « Détails du conteneur » ou « Détails du tag » de chaque conteneur ou ID de tag. Sous « Détails du conteneur » ou « Détails du tag », il y a un libellé « source ». Si une icône est présente, survolez-la — elle affiche « Tag was loaded by Google tag gateway » si le tag est inscrit à GTG.
Ces tags sont chargés depuis www.googletagmanager.com par défaut si GTG n'est pas inscrit.
Lorsque GTG est inscrit, ils sont chargés depuis une URL first-party (/xxxxx/) et chargent les tags depuis un chemin first-party (/xxxxx/yyyyyy) sur votre propre domaine.
| Préfixe | Produit | Données envoyées à |
|---|---|---|
| G- | Google Analytics 4 (GA4) | www.google-analytics.com (+ region1.google-analytics.com, *.analytics.google.com) |
| GT- | Google tag (gtag.js) | Le « Google tag » unifié — un tag, plusieurs destinations |
| AW- | Google Ads (anciennement AdWords) | www.googleadservices.com, googleads.g.doubleclick.net, www.google.com (+ chaque TLD de pays) |
| DC- | Floodlight (Campaign Manager 360 / Display & Video 360) | *.fls.doubleclick.net, ad.doubleclick.net |
| GTM- | Google Tag Manager | Aucune donnée propre — c'est un répartiteur qui déclenche les tags qu'il contient |
G-XXXXXXXXX)./RANDOM_STRING/ ou des chemins first-party similaires qui chargent des scripts depuis /RANDOM_STRING/LONG_RANDOM_STRING et envoient des données vers les domaines de produits Google mentionnés ci-dessus ou vers des chemins de produits Google comme pagead/conversion, /collect, etc. Si vous observez ces patterns, le tag pourrait être inscrit à GTG.Consultez le guide de configuration de Google Tag Gateway pour plus de détails sur l'inscription et la configuration.
Si les tags Google reçoivent des signaux de consentement en retard (après l'exécution initiale) et que l'inscription GTG est vérifiée, voici les options disponibles.
Si vous pouvez configurer GTG manuellement en contrôlant l'ordre de chargement des scripts, placez le tag de statut par défaut du Consent Mode avant la référence au script GTG dans le code source de votre page. L'Advanced Consent Mode est le mécanisme recommandé pour les tags compatibles GTG, car il est compatible avec la configuration manuelle de GTG.
Si vous ne pouvez pas contrôler l'ordre de chargement des scripts avec une configuration d'injection CDN en un clic, vous pouvez migrer tous les tags dans un conteneur Google Tag Manager et déployer GTM via GTG, ce qui centralise le contrôle de l'ordre de chargement afin que les vérifications de consentement intégrées de GTM s'appliquent à tous les tags du conteneur.
Vous pouvez également activer les contrôles de transmission des données pour restreindre les données que les tags Google peuvent transmettre en fonction de l'état du consentement selon vos besoins.
Définit les paramètres de consentement par défaut avant le déclenchement de tout tag. Le snippet d'initialisation du consentement UniConsent s'exécute de manière synchrone dans le <head> de la page, définissant tous les types de consentement sur denied par défaut avant l'exécution des tags Google, qu'ils se chargent depuis les serveurs de Google ou via GTG.
Compatible avec GTG manuel. Lorsque vous contrôlez l'ordre de chargement des scripts (GTG manuel), placer le snippet UniConsent avant le chemin du script GTG garantit que les paramètres de consentement par défaut sont toujours définis en premier.
Active la modélisation des conversions. Lorsque le consentement est refusé, les tags Google envoient toujours des pings sans cookies qui alimentent la modélisation des conversions, permettant de récupérer une part significative des données de conversion.
Placez le tag de statut par défaut du Consent Mode dans le <head> de la page. Il doit apparaître avant tout script de tags Google, y compris les chemins GTG. Exemple d'ordre :
<head>
<!-- 1. Consent mode defaults, same as stubgcm.min.js -->
<script src="https://cmp.uniconsent.com/v2/stubgcm.min.js"></script>
<!-- Or: Consent mode defaults inline on page, same content as stubgcm.min.js -->
<script>
(function() {
if(!window['gtag']) {
window['dataLayer'] = window['dataLayer'] || [];
window['gtag'] = function(){window['dataLayer'].push(arguments);}
}
window['gtag']('set', 'developer_id.dZTcxZD', true);
window['gtag']('consent', 'default', {
ad_storage: 'denied',
functionality_storage: 'denied',
personalization_storage: 'denied',
analytics_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
security_storage: 'granted',
wait_for_update: 1000
});
window['gtag']("set", "ads_data_redaction", true);
window['gtag']("set", "url_passthrough", false);
})();
</script>
<!-- 2. UniConsent CMP tag -->
<script async src="https://cmp.uniconsent.com/v2/YOUR_LICENSE_ID/cmp.js"></script>
<!-- 3. Google tags / GTG script path (loads after consent defaults are set) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=YOUR_ID"></script>
</head>
Vérifiez le timing du consentement à l'aide du UniConsent Consent Mode Checker pour confirmer que les paramètres de consentement par défaut sont définis avant l'exécution des tags Google et qu'il n'y a pas d'erreurs.
Surveillez depuis votre tableau de bord UniConsent. Le rapport d'audit d'implémentation signale les signaux de consentement tardifs et les paramètres de consentement par défaut manquants.
Les contrôles de transmission des données de Google restreignent les données envoyées par les tags Google en fonction de l'état de consentement de l'utilisateur. Combinés aux signaux de consentement d'UniConsent, cela crée une approche en couches :
| Contrôle | Fonction | Quand l'utiliser |
|---|---|---|
| Paramètres de consentement par défaut globaux | Définit l'état de consentement initial pour tous les types de consentement avant l'interaction de l'utilisateur | Toujours, garantit que les tags disposent d'une base de consentement au premier chargement de la page |
| Contrôles de transmission des données | Restreint l'envoi de champs de données spécifiques à Google | Lorsque vous avez besoin d'un contrôle granulaire au-delà des bascules de types de consentement |
| Paramètres par défaut par région | Définit des paramètres par défaut différents selon la région géographique | Lorsque vous servez des utilisateurs dans l'EEE/Royaume-Uni et dans d'autres régions |
Bien que vous puissiez techniquement définir les paramètres de consentement par défaut sur denied uniquement dans des régions spécifiques (comme l'EEE), Google recommande fortement de définir un refus par défaut global. Un refus global prévient les problèmes de consentement tardif si vous décidez de modifier le comportement régional de votre bannière ultérieurement. Pour les cas où les balises Google ne peuvent pas être déplacées après les scripts du CMP, Google recommande spécifiquement d'utiliser l'interface Global Consent Defaults dans l'administration de Tag Manager pour définir les états de consentement par défaut.
UniConsent met automatiquement à jour le statut de consentement en fonction de la région détectée de l'utilisateur :
denied). L'utilisateur doit interagir avec la bannière de consentement avant qu'un consentement ne soit accordé.Ce comportement adapté à la région est entièrement configurable dans le tableau de bord UniConsent, vous permettant de définir quelles régions nécessitent un consentement explicite et quelles régions peuvent procéder avec un accord de consentement automatique.
GTG et Google Tag Manager côté serveur (sGTM) sont des solutions différentes qui peuvent fonctionner ensemble :
| Google Tag Gateway | Server-Side GTM | |
|---|---|---|
| Fonction | Sert les scripts de tags Google depuis un domaine first-party | Achemine les requêtes de tags via un conteneur côté serveur |
| Déploiement | Au niveau CDN (Cloudflare, Akamai, Fastly) ou manuel | Nécessite un conteneur GTM côté serveur (Cloud Run, App Engine, etc.) |
| Impact sur le consentement | Modifie l'ordre de chargement des scripts ; peut provoquer des signaux de consentement tardifs | La vérification du consentement se fait côté serveur avant le transfert des données |
| Coût | Pas de coût Google supplémentaire ; nécessite un CDN ou un répartiteur de charge existant | Des frais d'hébergement serveur s'appliquent |
| Idéal pour | Améliorer les taux de livraison des tags, réduire l'impact des bloqueurs de publicités | Contrôle total du flux de données, application du consentement côté serveur |
Les deux peuvent être utilisés ensemble : GTG sert le tag côté client depuis un domaine first-party, tandis que sGTM traite les événements résultants côté serveur avec des vérifications de consentement appliquées avant le transfert à Google.