Google Tag Gateway (GTG) et/ou Addingwell ?
Contexte : pourquoi la collecte se dégrade
Aujourd’hui, la collecte de données est principalement impactée par deux freins : les ad blockers et certaines restrictions navigateurs (dont Safari).
L’utilisation croissante des ad blockers
De plus en plus d’internautes utilisent des ad blockers, qui peuvent empêcher le chargement des scripts Google (Google Tag Manager Web ou Google tag), et parfois bloquer directement les requêtes de mesure.
Si ces fichiers ne se chargent pas, les tags ne s’exécutent pas → baisse directe de la collecte.
Exemple
Un utilisateur visite votre site avec un ad blocker. Si gtm.js ne se charge pas, votre conteneur GTM ne démarre pas, donc vos événements (page_view, add_to_cart, purchase…) ne partent pas.
Les restrictions imposées par Safari
Safari applique des mécanismes de protection de la vie privée (ITP) qui peuvent, dans certains cas, réduire la durée de vie de certains cookies marketing à 7 jours.
Cela se produit notamment quand Safari estime que le cookie est déposé par un “contexte” différent de celui du site (selon l’architecture de tracking utilisée, et notamment la manière dont le tracking est servi/routé).
Résultat : attribution, mesure et analyses dégradées pour les visiteurs Safari.
Exemple
Un utilisateur Safari vient sur votre site, puis revient 10 jours plus tard. Si les cookies ont expiré à 7 jours, il peut être “revu” comme un nouvel utilisateur, ce qui dégrade l’attribution (campagnes), les audiences, et la lecture du parcours.
La solution Google Tag Gateway (GTG)
Résumé de la solution proposée par Google
Dans un setup standard, votre page charge les tags depuis des domaines Google. Quand un tag se déclenche, les requêtes partent directement vers Google.
Avec Google Tag Gateway (GTG), la logique est la même… sauf que :
- le navigateur charge le GTM / Google tag depuis votre propre domaine (au lieu d’un domaine Google),
- et certaines requêtes de mesure passent aussi par votre domaine, avant d’être relayées vers Google.
En pratique, GTG consiste à mettre en place une passerelle (reverse proxy) “first‑party” entre votre site et Google.
Exemple (avant / après)
- Avant : le navigateur charge https://www.googletagmanager.com/gtm.js?id=GTM-XXXX
- Après GTG : le navigateur charge un fichier équivalent depuis votre domaine, par exemple - https://example.com/8kpl/gtm.js?id=GTM-XXXX
Même logique pour certaines requêtes de mesure : elles transitent par example.com/8kpl/… plutôt que d’aller directement vers un domaine Google.
GTG en pratique : reverse proxy + measurement path
GTG repose sur deux éléments.
Le measurement path (chemin dédié)
GTG s’appuie sur un chemin dédié sur votre domaine, par exemple : https://example.com/8kpl/
Ce chemin sert à :
- charger les scripts Google en first‑party,
- transporter les requêtes de mesure.
Pourquoi un chemin dédié ?
Parce que ça permet de distinguer très clairement ce qui relève de la “passerelle GTG” du reste de votre site.
Le reverse proxy (la “passerelle”)
C’est un composant (souvent un CDN comme Cloudflare) qui reçoit une requête sur votre domaine, puis la relaie vers la bonne destination.
On peut le voir comme un “guichet unique” :
- le navigateur parle à example.com,
- l’infrastructure se charge d’aller chercher la ressource au bon endroit (Google, puis retour au navigateur).
Exemple
Vous configurez une règle du type : “Tout ce qui commence par /8kpl/ doit être transmis vers les endpoints GTG / Google.”
Du point de vue de l’utilisateur, tout se passe sur example.com, même si “derrière”, c’est Google qui répond.
Bénéfices et limitations
Réduction partielle de l’impact des ad blockers
Avec GTG, les scripts et certaines requêtes passent par votre propre domaine. Cela réduit surtout les blocages qui reposent uniquement sur le fait que les ressources proviennent d’un domaine Google.
En revanche, ce n’est pas une garantie de bypass à 100% : certains ad blockers bloquent aussi en regardant à quoi ressemble la requête (ex. format d’URL, paramètres, chemin utilisé, type de requête) - même si la requête part de votre domaine.
Safari 16.4+ : GTG ne résout pas le problème ITP
Safari applique des restrictions (ITP) qui limitent à 7 jours la durée de vie des cookies posés via JavaScript (document.cookie), même si le script est chargé depuis votre propre domaine.
Or, les scripts Google (GA4, GTM) posent leurs cookies via JavaScript côté navigateur. Le fait que ces scripts soient servis en first‑party via le reverse proxy GTG ne change pas la manière dont les cookies sont écrits : ils restent posés en JavaScript, et Safari continue de les caper à 7 jours.
GTG ne résout donc pas la limitation Safari/ITP. Pour maintenir les cookies au‑delà de 7 jours sur Safari, il faut que les cookies soient posés côté serveur (via un en‑tête HTTP Set-Cookie), ce que GTG ne fait pas.
Périmètre
GTG concerne les scripts et tags Google (Google tag, GTM, tags Google). Il ne transforme pas vos tags non‑Google (Meta, TikTok, etc.).
Mettre en place GTG
GTG est un produit Google, indépendant d’Addingwell. Sa mise en place se fait directement via les outils et la documentation Google.
Addingwell ne fournit pas de support sur la configuration de GTG. Pour toute question relative à l’installation ou au paramétrage de GTG, référez-vous à la documentation officielle Google ci-dessous.
- Présentation de Google Tag Gateway — vue d’ensemble du produit et de son fonctionnement.
- Guide de mise en place de GTG — guide d’implémentation pas à pas (setup automatique et manuel).
- Configurer GTG avec votre CDN — configuration du reverse proxy via votre CDN.
La solution Addingwell
Résumé de l’approche Addingwell
Addingwell repose sur une architecture où la collecte et l’envoi des événements se font nativement en first‑party, avec une couche server-side complète.
Concrètement, Addingwell apporte :
- du server-side tagging (vos événements sont envoyés vers votre serveur de tracking),
- des optimisations avancées pour les ad blockers (option CDN),
- et une approche de résilience Safari, principalement via un Reverse Proxy (et, si reverse proxy impossible, une option de secours type Cookie Restore).
Exemple (server-side)
Votre site envoie un événement (ex. purchase) vers votre endpoint de tracking (first‑party). Le serveur Addingwell reçoit cet événement et le renvoie ensuite vers GA4, Google Ads, Meta, etc.
Résultat : vous centralisez mieux la collecte et vous maîtrisez davantage la distribution des données.
Addingwell en pratique : ad blockers et Safari
Bypass des ad blockers (option CDN Addingwell)
Addingwell permet un contournement avancé grâce à :
- la proxification avancée de la librairie GTM,
- la proxification avancée de la librairie GA4,
- et la transformation automatique des requêtes GA4 (ex: le endpoint /g/collect n’apparaît plus).
Au lieu d’avoir une requête qui ressemble très clairement à une collecte GA4 (avec /g/collect), la requête est modifiée pour ne plus exposer ce chemin standard. Beaucoup de bloqueurs s’appuient justement sur ces “signatures” faciles à repérer.
Contrairement à GTG, cette approche ne se limite pas à “passer en first‑party” : elle rend les requêtes beaucoup plus difficiles à identifier pour les bloqueurs.
Résilience Safari : cookies posés côté serveur
Contrairement à GTG (où les cookies sont posés en JavaScript par les scripts Google), Addingwell permet de poser les cookies côté serveur (via un en‑tête HTTP Set-Cookie). C’est cette différence fondamentale qui permet de maintenir les cookies au‑delà de 7 jours sur Safari.
Deux options sont disponibles :
- Reverse Proxy DNS (ex. Cloudflare) : le trafic de votre serveur de tracking passe par le même DNS que votre site. Les cookies, posés côté serveur, sont considérés comme first‑party par Safari et conservent une durée de vie de 13 mois.
- Cookie Restore : solution alternative lorsque vous ne pouvez pas mettre en place de reverse proxy. Un “Master Cookie” posé côté serveur permet de restaurer automatiquement les cookies marketing au‑delà de 7 jours.
Bénéfices et points d’attention
Addingwell offre une couverture plus large que GTG :
- résilience Safari effective (cookies posés côté serveur, contrairement à GTG),
- bypass ad blockers plus avancé,
- stack server-side complète,
- multi-destinations et possibilités de gouvernance/enrichissement.
Setup GTG + Addingwell
Il est tout à fait possible de combiner GTG et Addingwell. Les deux solutions ne sont pas incompatibles, car elles ne jouent pas exactement le même rôle :
- GTG fournit surtout une couche “reverse proxy + delivery first‑party” (scripts Google + certaines requêtes via votre domaine)
- Addingwell fournit une couche server-side complète (collecte, traitement, redistribution vers plusieurs destinations)
Autrement dit : GTG peut être la “porte d’entrée first‑party”, et Addingwell peut être le “moteur server-side” derrière.
Quand est-ce que ça a du sens ?
Le combo GTG + Addingwell est pertinent si :
- vous souhaitez activer GTG (recommandation Google, politique IT interne, standardisation), tout en ayant besoin d’une stack server-side complète (multi-destinations, gouvernance, optimisation ad blockers, résilience Safari),
- et/ou vous voulez un reverse proxy basé sur un measurement path conforme aux attentes Google.
Deux façons courantes de les combiner
Option A - GTG pour charger le tag, Addingwell garde son endpoint de collecte (le plus simple)
Ici, vous utilisez GTG principalement pour servir les scripts Google en first‑party (via le measurement path).
Ensuite, quand un événement est déclenché, il part vers l’URL de collecte Addingwell (comme dans un setup Addingwell classique).
Exemple
- Les scripts se chargent via GTG : https://example.com/8kpl/gtm.js?id=GTM-XXXX
- Mais les événements partent vers l’endpoint Addingwell : https://tagging.example.com/… (ou un autre endpoint first‑party déjà en place)
Quand choisir Option A ?
Quand vous voulez un montage simple, avec le moins de changements possibles : GTG s’occupe du “chargement first‑party”, et Addingwell reste votre point d’entrée server-side habituel.
Option B - Measurement path comme point d’entrée unique (le plus “aligné GTG”)
Ici, vous allez plus loin : vous utilisez le measurement path comme porte d’entrée unique pour le tracking.
Le navigateur ne parle qu’à une seule base d’URL, par exemple https://example.com/8kpl/… .
Ensuite, le reverse proxy route :
- certaines requêtes vers Google (pour le fonctionnement GTG),
- et d’autres vers Addingwell (pour la collecte server-side).
Exemple
- Le tag se charge via : https://example.com/8kpl/gtm.js?id=GTM-XXXX
- Et les événements partent aussi via : https://example.com/8kpl/collect → puis le reverse proxy les envoie vers Addingwell.
Pourquoi c’est intéressant ?
vous avez un seul point d’entrée “site” (même domaine + même chemin) pour le tracking, c’est très cohérent avec la logique GTG “measurement path”,
Point d’attention
L’option B demande un routage plus “soigné”, car le reverse proxy doit distinguer ce qui doit aller vers Google vs ce qui doit aller vers Addingwell (souvent via des sous-chemins ou des règles spécifiques).
Parcours d’implémentation (haut niveau)
- Mettre en place GTG et choisir un measurement path (chemin inutilisé) — voir la documentation Google GTG .
- Mettre en place l’environnement Addingwell (serveur + configuration first‑party).
- Choisir l’architecture : Option A (en parallèle) ou Option B (derrière measurement path).
- Tester : chargement du tag, réception des événements côté server-side, puis réception côté plateformes (GA4, Ads, etc.).
Les étapes 1 et 3 ne sont pas supportées par Addingwell. La mise en place de GTG (étape 1) et le choix d’architecture entre les options A et B (étape 3) relèvent de la configuration de votre infrastructure et de GTG. Consultez la documentation officielle Google pour la mise en place de GTG, et votre équipe technique ou votre intégrateur pour le routage reverse proxy.
À retenir
✅ GTG et Addingwell sont compatibles
✅ Addingwell peut être positionné derrière GTG
✅ Addingwell complète GTG en apportant la résilience Safari et le bypass ad blockers avancé
✅ Si vous voulez être complètement aligné avec GTG, vous pouvez utiliser un measurement path comme point d’entrée et router vers Addingwell
Comparaison Google Tag Gateway vs Addingwell
| Critère | GTG | Addingwell | GTG + Addingwell |
|---|---|---|---|
| Scripts Google first-party | ✅ | ✅ | ✅ |
| Réduction ad blockers | ⚠️ (partielle) | ✅ | ⚠️ (partielle) |
| Résilience Safari 16.4+ | ❌ | ✅ | ✅ |
| Server-side tagging complet | ❌ | ✅ | ✅ |
| Multi-destinations | ❌ | ✅ | ✅ |
| Gouvernance & enrichissement | ❌ | ✅ | ✅ |
| Complexité | Faible à moyenne | Moyenne à élevée | Élevée |
Conclusion
- GTG seul : bon premier niveau d’amélioration pour le chargement first‑party des scripts Google, rapide à activer. Cependant : bypass ad blockers partiel, pas de résilience Safari (les cookies restent capés à 7 jours), et centré sur l’écosystème Google uniquement.
- Addingwell seul : stack server-side complète, avec résilience Safari effective (cookies posés côté serveur), optimisation ad blockers avancée, et contrôle multi-destinations.
- GTG + Addingwell : combinaison possible et compatible ; Addingwell peut être positionné derrière GTG (notamment via measurement path) ou utilisé en parallèle selon l’architecture cible. Addingwell apporte la résilience Safari et le bypass ad blockers avancé que GTG seul ne couvre pas.