Google Tag Gateway: quoi, pourquoi et quand l'utiliser

Au cours des derniers mois, Google Tag Gateway (également appelé GTG) est passé d'un déploiement discret à un sujet de discussion régulier. Je pense que cela s'explique par le fait que Google a commencé à le mettre en avant lors des appels et par une demande croissante en matière de suivi first-party.

Je suis Manisha Mistry, Technical Lead chez MeasureU. J'aime expliquer des sujets comme le suivi côté serveur, ce qui m'a amenée à recevoir de plus en plus de questions sur Google Tag Gateway. Plus précisément, au cours des derniers mois, on m'a posé les quatre questions suivantes à plusieurs reprises.

• Qu'est-ce que Google Tag Gateway?
• Dois-je l'utiliser?
• Quelle est la différence avec le suivi côté serveur?
• En ai-je besoin si j'utilise déjà le suivi côté serveur?

Dans cet article de blog, mon objectif est de répondre à ces quatre questions. Comme toujours, je commencerai par les bases, puis j'expliquerai en détail le fonctionnement de Google Tag Gateway et ses différences avec le suivi côté serveur. Je terminerai par un cadre de décision auquel vous pourrez revenir de temps à autre pour déterminer quelle solution de suivi vous convient, à vous et à votre client.

Une petite précision avant de commencer: cet article est basé sur ma propre configuration et mes propres tests de GTG au moment de sa rédaction. Google fait constamment évoluer GTM, GTG, sGTM et l'écosystème plus large du taggage. Certains éléments peuvent donc changer au fil des améliorations apportées au produit. Les concepts fondamentaux resteront les mêmes, mais les chemins exacts, les options et les écrans peuvent évoluer.

Toute configuration Analytics commence par le suivi côté client.

Il s'agit généralement d'installer GA4 sur votre site, soit avec Google Tag Manager (mon option préférée), soit via une intégration au site. Dans les deux cas, les scripts s'exécutent dans le navigateur du visiteur et les domaines utilisés pour ces scripts sont généralement ceux de Google.

Par exemple, il peut s'agir de...

• www.googletagmanager.com (pour le script du conteneur GTM)
• www.google-analytics.com (pour les événements de collecte GA4)
• googleads.g.doubleclick.net (pour les conversions Google Ads)

Le point essentiel à retenir est que les noms d'hôte sont des domaines Google et non le domaine de votre site. Du point de vue du navigateur du visiteur, il s'agit donc de requêtes third-party, et non de requêtes first-party.

Les requêtes third-party ne posent pas de problème, jusqu'à ce que vous commenciez à perdre des données à cause des bloqueurs de publicité, de Safari Intelligent Tracking Prevention (ITP) et de tout ce qui peut les bloquer.

Lorsque vous débutez dans le suivi ou que votre site génère peu de trafic et de dépenses publicitaires, le suivi côté client est un excellent point de départ et peut suffire. Cela dit, à mesure que le trafic augmente et que les budgets marketing progressent, vous (ou votre client) commencez vraiment à vous intéresser à l'écart entre « ce qui s'est déclenché » et « ce qui a réellement été enregistré ». C'est à ce moment-là que le suivi first-party entre en jeu.

Avant d'aborder Google Tag Gateway en particulier, prenons un moment pour comprendre ce qu'est réellement une gateway et comment elle fonctionne.

La véritable définition technique d'une gateway est celle d'un reverse proxy. Elle se place entre vos visiteurs et le point de terminaison d'un fournisseur, puis présente à nouveau la requête comme si elle provenait de votre domaine. Le contenu de la requête ne change PAS DU TOUT: seul le carrier, c'est-à-dire le nom d'hôte, change.

Les gateways sont aujourd'hui partout. Par exemple, Meta propose la Conversions API Gateway, TikTok propose la Events API Gateway, et de nombreuses autres plateformes développent également leurs propres gateways. Elles sont populaires car tous les fournisseurs rencontrent le même problème: leur script s'exécute dans le navigateur, est bloqué et nous perdons des signaux. Mettre en place une gateway est le moyen le plus rapide de faire passer les requêtes de third-party à first-party.

Comme toujours, j'aime les analogies. Pour m'aider à comprendre les gateways et à les expliquer à mes clients, j'en utilise une qui semble particulièrement bien fonctionner.

Nous sommes tous allés à l'école à un moment de notre vie ou avons aujourd'hui des enfants scolarisés. Parfois, pour célébrer quelque chose, un enseignant commandait une pizza pour sa classe et la faisait livrer à l'école.

Là où je vis, les écoles ne laissent pas un livreur entrer par la porte principale, parcourir le couloir et se rendre directement dans une salle de classe. C'est parce que le livreur est un tiers pour l'école. Il n'a pas fait l'objet d'une vérification des antécédents et ne possède pas de badge de l'école.

Le rôle de l'école est d'empêcher les tiers comme ce livreur d'entrer dans les couloirs pendant la journée afin de protéger les élèves.

À la place, le livreur ne porte pas directement la pizza jusqu'à la classe. Il doit se rendre à l'école, entrer dans l'accueil, remettre la pizza à un membre de l'administration, puis celui-ci apporte la pizza jusqu'à la salle de classe.

La pizza qui arrive dans la classe est exactement la même que celle apportée par le livreur à l'école. C'est toujours une pizza au pepperoni, toujours chaude et toujours dans la même boîte. Ce qui change, c'est la personne qui la transporte dans le couloir. Au lieu d'être portée par un livreur tiers, elle l'est par un membre de l'administration de l'école qui a effectué toutes les vérifications nécessaires et qui est autorisé à circuler dans les couloirs. La classe reçoit exactement la même pizza, mais du point de vue de l'école, le transfert est complètement différent.

En termes simples, c'est ça, une gateway.

Le contenu de la requête n'a pas changé. C'était toujours une pizza, mais la personne qui la transportait a changé. Tous ceux qui voyaient la pizza traverser le couloir n'avaient aucun problème avec cela, car le membre de l'administration faisait partie de l'école. Il y travaillait et était autorisé à s'y trouver.

À l'inverse, si le livreur avait traversé l'école, cela aurait posé problème. Il aurait très probablement été empêché d'entrer ou arrêté en chemin, car il n'est pas autorisé à circuler dans l'école.

Maintenant que nous comprenons ce qu'est une gateway, intéressons-nous à Google Tag Gateway (GTG).

Voici la définition donnée par Google, directement issue de sa page d'aide:

En termes simples, GTG est un reverse proxy qui remplace le nom d'hôte de vos requêtes GA4 et Google Ads: au lieu des domaines Google, elles utilisent le domaine de votre site. Le contenu des requêtes, comme les événements, les paramètres, les cookies et l'état du consentement, ne change pas ; seul le carrier change. Pensez à l'analogie de la pizza: la pizza reste la même, seul le transporteur change.

Avant d'aller plus loin avec GTG, vous devez connaître quelques détails importants...

• GTG est limité à Google - GTG est conçu uniquement pour présenter à nouveau les scripts Google tels que GA4 et Google Ads depuis votre domaine. Cela signifie que Meta Pixel, LinkedIn Insight et toutes les autres requêtes resteront des requêtes third-party.
• Les cookies restent des cookies JavaScript - GTG ne modifie pas la manière dont les cookies sont définis. Le navigateur exécute toujours le script client GA4 et les cookies sont toujours écrits via JavaScript. Vous pouvez donc toujours être limité par la durée maximale de 7 jours des cookies JavaScript imposée par Safari ITP.
• GTG ne transforme ni ne supprime les données à lui seul - GTG ne permet pas d'ajuster ou de modifier les données de la requête elle-même. Il ne fait qu'ajuster l'en-tête ; le corps de la requête (son contenu) reste exactement le même.

Il est essentiel de comprendre ces trois points lorsque vous comparez Google Tag Gateway vs suivi côté serveur.

La page de documentation de Google présente trois options d'implémentation de GTG. Chacune déplace une partie différente de votre suivi de third-party vers first-party et implique un niveau de complexité différent. J'ai configuré les trois options sur mon propre site de démonstration, datadrivenuniversity.com, afin que vous puissiez voir pour chacune une image réelle avant/après montrant comment le suivi a changé.

Une chose que je tiens à préciser avant de commencer. Google présente ces trois possibilités comme des options distinctes, mais après avoir configuré chacune d'elles, je ne les considère pas de cette façon. Je considère plutôt que chaque option s'appuie sur la précédente. C'est mon opinion personnelle, fondée sur mon expérience. Maintenant que c'est dit, passons à chaque option.

C'est la version la plus simple de GTG, car vous n'avez pas besoin de modifier votre configuration existante et cela ne prend que quelques clics.

Ce qui change: les collectes GA4 et les conversions Google Ads sont envoyées depuis your-domain.com au lieu de google-analytics.com / googleads.g.doubleclick.net. Elles deviennent des requêtes first-party.

Ce qui ne change pas: le script du conteneur GTM lui-même est toujours chargé depuis googletagmanager.com. Je l'ai confirmé dans ma propre configuration. Le contenu de vos requêtes GA4 et GAds reste également exactement le même.

Pour vous montrer cela en pratique, j'ai configuré Google Tag Gateway avec Cloudflare sur mon site de test datadrivenuniversity.com. Voici à quoi ressemblaient mes requêtes GA4 avant l'activation de Google Tag Gateway.

J'ai ensuite configuré GTG avec Cloudflare et GTM. L'ensemble de la configuration a pris environ trois clics. Après cela, vous pouvez voir que le même hit GA4 passe désormais par mon propre domaine datadrivenuniversity.com/bppc.

Note: vous remarquerez que les hits GA4 commencent maintenant par c? au lieu de collect?, en raison de GTG.

Avec cette implémentation, j'ai fait passer mes requêtes GA4 de third-party à first-party. Elles passent désormais par datadrivenuniversity.com/bppc au lieu de google-analytics.com. Il en va de même pour mes conversions Google Ads, qui passent de googleads.g.doubleclick.net au même chemin first-party.

Lors de mes tests de l'Option 1, j'ai remarqué que mes requêtes Google Ads et GA4 étaient passées en first-party, mais que le script de mon conteneur Google Tag Manager était toujours chargé depuis googletagmanager.com. GTM restait donc une requête third-party. C'est là qu'intervient l'Option 2 et la comparaison Google Tag Gateway vs Google Tag Manager devient particulièrement pertinente.

Ce qui change: gtm.js est désormais chargé depuis votre propre domaine, par exemple datadrivenuniversity.com/metrics/custom-path, au lieu de googletagmanager.com. Votre GTM, GA4 et Google Ads sont alors tous des hits first-party du point de vue du navigateur du visiteur.

J'ai mis cette configuration en place avec un conteneur sGTM, en utilisant un client Google Tag Manager: web container qui me permet de charger le conteneur GTM web depuis le conteneur serveur et de définir un chemin personnalisé. Il existe d'autres façons de rendre GTM first-party, mais sGTM est celle que j'ai testée.

Ce qui ne change pas: vos hits non Google, comme Meta Pixel, TikTok Pixel, LinkedIn Insight et tout autre tag non Google, restent des requêtes third-party.

Pour vous montrer cela en pratique, voici à quoi ressemblait le script de mon conteneur GTM web dans DevTools avant que j'ajoute le conteneur sGTM et que je lui fasse charger mon conteneur web.

Après avoir mis en place un serveur et le conteneur sGTM, où j'ai configuré un client et défini le chemin de diffusion des tags, voici à quoi ressemble maintenant la requête avec mon domaine et mon chemin personnalisé.

À ce stade, mes requêtes GA4 et Google Ads passent par Cloudflare en first-party, et mon conteneur sGTM charge également mon conteneur GTM web depuis un domaine first-party. Toutes les autres plateformes restent third-party.

L'Option 3 est l'implémentation de GTG recommandée par Google et, honnêtement, c'est celle qui a été la plus difficile à configurer et à comprendre. Elle a également changé ma façon de voir Google Tag Gateway côté serveur par rapport au suivi côté serveur, mais je garderai cette conclusion pour la fin afin qu'elle ait plus de sens après avoir vu toute la configuration.

Petit récapitulatif de la situation:

• Dans l'Option 1, nous avons fait passer nos requêtes GA4/Google Ads de third-party à first-party via la gateway (par exemple Cloudflare). Cela signifie que les requêtes des scripts et de la collecte de données GA4/GAds (Google uniquement) sont passées en first-party.
• Dans l'Option 2, nous avons fait passer le script de notre conteneur GTM de third-party à first-party via un conteneur serveur ; notre collecte de données pour le suivi Google uniquement continuait à utiliser la gateway.
• Dans l'Option 3, nos scripts continuent à se charger exactement de la même manière (scripts GA4 via la gateway, GTM via le conteneur sGTM). Ce qui change, c'est que la collecte de données passe par le serveur, ce qui vous permet de la transformer avant son acheminement vers les plateformes en aval.

Ce qui change: au lieu que nos données d'événements passent par le CDN sous forme de hits first-party directement acheminés vers Google, elles passent désormais par notre conteneur sGTM. Le conteneur sGTM reçoit les événements et nous pouvons ensuite transformer, enrichir ou supprimer certaines données avant qu'elles ne soient transmises en aval. En pratique, le suivi côté serveur fonctionne en parallèle de GTG. Nous utilisons les deux en même temps.

Cette configuration ouvre également la possibilité de faire passer les tags non Google, comme Facebook, LinkedIn et TikTok, en first-party. Cela nécessite toutefois de configurer ces tags dans notre conteneur sGTM et de réaliser une implémentation complète du suivi côté serveur. Une fois cette configuration terminée dans le conteneur sGTM, ces hits passent eux aussi par le serveur et deviennent des hits first-party.

Ce qui ne change pas: le script de notre conteneur GTM est toujours servi depuis notre serveur sGTM (repris de l'Option 2). Les appels de configuration GA4 sont toujours servis depuis notre CDN (repris de l'Option 1).

Pour vous montrer cela en pratique, voici à quoi ressemblaient mes hits de collecte GA4 dans l'Option 2, lorsqu'ils passaient par mon chemin Cloudflare.

Après avoir défini l'URL du conteneur serveur dans ma balise de configuration du conteneur GTM web et configuré un client et une balise GA4 dans mon conteneur sGTM, mes collectes passent désormais par le serveur sGTM.

Avec cette implémentation, la collecte de mes événements GA4 passe désormais par mon conteneur sGTM, où je peux acheminer, enrichir ou supprimer les données avant qu'elles ne soient transmises en aval. La même approche peut être appliquée à toute autre plateforme, y compris aux plateformes non Google, à condition de configurer les tags et les déclencheurs requis dans mon conteneur web/serveur.

Maintenant que nous comprenons ce qu'est Google Tag Gateway et les trois façons de l'implémenter, la question suivante, que l'on me pose toujours, est naturellement: quelle est la différence entre Google Tag Gateway et le suivi côté serveur?

À mon avis, ce ne sont pas des produits concurrents.

Google Tag Gateway, et plus précisément l'Option 1, consiste à acheminer vos événements afin qu'ils passent de third-party à first-party au niveau de l'en-tête de la requête. Le suivi côté serveur vise le contrôle: avoir davantage de contrôle sur vos données et, par conséquent, passer au suivi first-party. Vous pouvez le voir dans la propre documentation de Google: dans l'Option 3 présentée plus haut, pour obtenir davantage de contrôle sur vos données, vous devez introduire un conteneur serveur et faire passer vos événements par ce conteneur.

Pour expliquer la différence entre les deux, voici un tableau comparatif rapide:

En résumé, Google Tag Gateway et le suivi côté serveur ne sont pas des produits concurrents. L'un vous fait passer rapidement au suivi first-party, uniquement du point de vue des requêtes. L'autre vous donne un contrôle total sur vos données. Vous pouvez commencer par l'un et passer à l'autre lorsque vos besoins évoluent, et c'est précisément là qu'intervient le cadre de décision.

Pour la comparaison Google Tag Gateway vs côté serveur, le point essentiel est de comprendre que vous pouvez choisir entre Google Tag Gateway, le suivi côté serveur ou même rester sur le suivi côté client. C'est l'une des questions que l'on me pose le plus souvent, aussi bien chez MeasureU que dans la communauté LinkedIn. C'est également l'une des premières choses que les clients demandent lorsque nous commençons un projet d'implémentation. C'est pourquoi j'ai créé un cadre de décision pour vous aider à faire ce choix.

L'essentiel est de comprendre que ce cadre n'est pas conçu pour être utilisé une seule fois. Vous le parcourez une première fois, puis vous y revenez régulièrement à mesure que votre parcours de mesure évolue. Vous pouvez commencer par le suivi côté client, passer à GTG, puis adopter plus tard le suivi côté serveur lorsque vos besoins changent.

Parcourez le cadre aujourd'hui pour déterminer où vous en êtes dans votre parcours. Puis, après quelques semaines ou quelques mois de travail, revenez-y et refaites-le. Utilisez-le comme guide pour savoir quand améliorer votre mesure, pour votre site ou celui de votre client.

À mon avis, après avoir essayé et testé Google Tag Gateway, c'est un excellent gain rapide pour le suivi Google uniquement. Si vous choisissez simplement l'Option 1, vos requêtes GA4 et Google Ads passent de third-party à first-party en environ trois clics.

Cela dit, comme nous l'avons vu dans la propre documentation de Google, dès que vous voulez davantage de contrôle sur vos données, vous devez passer à l'Option 3. Cela signifie mettre en place un serveur et un conteneur serveur, puis faire passer votre collecte de données par le conteneur sGTM. Chaque organisation dispose de sa propre stack de mesure, d'un niveau de trafic différent et de besoins spécifiques en matière de contrôle des données. C'est exactement le rôle du cadre de décision et la raison pour laquelle je l'ai conçu pour être utilisé plusieurs fois.

En tant que personne ayant fait les deux, je dirais que Google Tag Gateway, et plus précisément l'Option 1, est un excellent gain rapide pour le suivi Google uniquement. Cela dit, à mon avis, si vous voulez réellement contrôler vos données sur toutes les plateformes, l'Option 3 demande en réalité plus de travail que de passer directement au suivi côté serveur, car vous effectueriez de toute façon la majeure partie de ce travail. Si c'est votre objectif, je vous recommande de passer directement au suivi côté serveur. Vous pouvez déployer votre propre serveur et conteneur ici.