Google Tag Manager Server-Side : Le guide complet

L’objectif de cet article est de vous donner toutes les clés nécessaires pour déterminer si la mise en place d’une solution GTM server-side est pertinente pour votre entreprise et également les étapes à suivre pour l’implémenter.

Avant d’aller plus loin, vous pourriez être intéressé par un guide plus spécifique :

• Google Ads Server-Side Tracking avec Google Tag Manager
• Tracking Matomo Server-Side avec Google Tag Manager

Qu’est-ce que Google Tag Manager Client-Side ? #

Dans sa version client-side, Google Tag Manager collecte des données sur votre site web et envoie ces données à des plateformes marketing telles que Google Analytics, Google Ads ou Facebook Ads par l’intermédiaire du navigateur.

flowchart LR
    subgraph Navigateur
        A[Votre site web]
        subgraph I[Google Tag Manager]
            F(Code de suivi GA4)
            G(Code de suivi Google Ads)
            H(Pixel Facebook)
        end
    end
    C[Serveur Google Analytics 4]
    D[Serveur Facebook Ads]
    E[Serveur Google Ads]
    A --- I
    Navigateur -- google-analytics.com/collect --> C
    Navigateur -- www.facebook.com/tr --> D
    Navigateur -- googleadsservices.com/pagead/conversion/ --> E

Le navigateur envoie donc directement des requêtes aux plateformes marketing avec lesquelles vous travaillez. Grâce aux codes de suivi, ces plateformes peuvent déposer des cookies first-party ou tiers dans le navigateur pour identifier un même visiteur à travers plusieurs visites et/ou relier un visiteur à un clic sur une publicité.

Les avantages de GTM Client-Side

1. relativement simple à mettre en place (la plus grosse complexité réside dans le fait de manipuler la Data Layer)
2. la communauté a développé de nombreux modèles de balises et de variables pour vous faciliter la vie
3. il existe de nombreux tutoriels sur internet pour vous aider
4. c’est ce qui se fait depuis longtemps donc il est plus facile de trouver ces compétences sur le marché (que ce soit pour recruter ou externaliser)
5. Google Tag Manager Client-Side est complètement gratuit

Les inconvénients de GTM Client-Side

1. permet l’utilisation des cookies tiers qui sont bloqués sur Firefox, Safari et Brave mais pas sur Chrome
2. a tendance à augmenter le temps de chargement des pages car vous devez ajouter un code de suivi par plateforme marketing
3. vous n’avez que très peu de contrôle sur les données que vous envoyez aux plateformes marketing (données collectées automatiquement)
4. les requêtes envoyées aux plateformes marketing peuvent être bloquées par des bloqueurs de publicités

Qu’est-ce que Google Tag Manager Server-Side ? #

Au lieu d’envoyer des requêtes à chaque serveur des plateformes marketing que vous utilisez, vous allez uniquement envoyer des requêtes à votre propre serveur. C’est ensuite votre serveur qui va communiquer avec les plateformes marketing.

flowchart TD
    subgraph Navigateur
        A[Votre site web]
        subgraph I[GTM Client-Side]
            F(Code de suivi GA4)
        end
    end
    subgraph J[Votre serveur]
        subgraph K[GTM Server-Side]
            R[Client GA4]
            L[Balise Google Ads]
            M[Balise Facebook Ads]
            N[Balise Google Analytics]
        end
    end
    R --> L
    R --> M
    R --> N
    Navigateur <-- HTTP --> J
    L -- googleadsservices.com --> O[API Google Ads]
    M -- graph.facebook.com --> P[API Facebook Ads]
    N -- google-analytics.com --> Q[API Google Analytics]

Les avantages de GTM Server-Side

1. permet de réduire le temps de chargement de votre site web (surtout si vous devez envoyer des données à beaucoup de plateformes marketing)
2. vous permet de totalement contrôler les données qui sont transmises aux plateformes marketing car votre serveur joue le rôle d’intermédiaire (c’est lui qui dicte les données qui passent ou qui ne passent pas)
3. vous n’êtes moins sujet aux ad blockers (avec une configuration spécifique) car les librairies javascript de GTM et GA4 notamment peuvent être téléchargées depuis votre serveur avec des chemins uniques

Les inconvénients de GTM Server-Side

1. l’hébergement cloud de votre serveur est payant
2. la gestion d’un serveur dans le cloud demande des compétences supplémentaires (mise en place, monitoring, scaling, etc.)
3. peu de modèles de balises sont actuellement proposés par la communauté

Les compétences Client-Side VS Server-Side #

mindmap
  root[Compétences <br>Client-Side <br>vs Server-Side]
    [Client-Side]
      (Javascript)
        (Variables)
        (Fonctions)
        (JSON)
      (Cookies)
      (Sélecteurs CSS)
      (DOM HTML)


    [Server-Side]
      (HTTP)
        (Requêtes et réponses)
        (Cookies)
        (JSON)
        (Journalisation)
      (Cloud)
        (DNS)
        (Load balancing)
        (Monitoring <br>des ressources)

Créer un conteneur serveur dans GTM avec Cloud Run #

Approvisionner un nouveau conteneur serveur

Dans Google Tag Manager, créez un nouveau conteneur et choisissez Serveur comme plate-forme cible.

Une fois votre conteneur créé, Google Tag Manager va vous demander comment vous souhaitez configurer votre serveur. Vous pouvez le faire soit de façon automatique (ceci va configurer un serveur pour vous dans Google Cloud) soit de façon manuelle (ceci vous offre la possibilité de configurer vous-même votre serveur).

Pour faciliter les choses, on va choisir le provisionnement automatique.

A cette étape, si vous n’avez pas de compte de facturation dans Google Cloud, vous allez devoir en créer un.

Une fois que c’est fait, sélectionnez votre compte de facturation et créez votre serveur.

La création du serveur va prendre quelques minutes…

Une fois le serveur créé, deux informations importantes s’affichent :

1. Le projet Google Cloud dans lequel se situe votre serveur
2. L’URL par défaut pour envoyer des requêtes aux serveur

Lier son nom de domaine au conteneur serveur

Lier votre nom de domaine va permettra de déposer des cookies dans un contexte first-party. Ceci est un des avantages du tracking server-side donc cette étape est importante.

Rendez-vous dans votre projet Google Cloud puis Cloud Run.

Vous arrivez ensuite sur la vue d’ensmble de vos services Cloud Run.

On voit ici qu’il y a deux services :

1. le serveur de taggage
2. le serveur de preview

Avec cette configuration les requêtes de tests seront envoyés au serveur preview et les vraies requêtes seront envoyé au serveur de taggage principal.

Pour lier votre nom de domaine, cliquz sur le service du serveur de taggage principal :

Rendez-vous ensuite dans l’onglet Intégrations.

Cliquez sur Ajouter une intégration puis séclectionnez Domaines personnalisés.

Rentrez ensuite votre sous-domaine puis activez les API nécessaires.

Une fois les API activées, vous pouvez cliquer sur le bouton SUBMIT.

Ajouter votre enregistrement DNS

Dans l’intégration Domaines personnalisés que vous venez de créer, une fenêtre vous indique la configuration à réaliser sur vos enregistrements DNS.

Pour ma part, je vais faire cette configuration sur Cloudflare mais ceci dépend de l’hébergeur de nom de domaine que vous utilisez.

En fonction de votre hébergeur DNS, la liaison du nom de domaine avec votre serveur de taggage dans Cloud Run et la génération du certificat SSL peut prendre entre 10 minutes et 24h.

Une fois ceci terminé, l’état de l’intégration passera à Actif.

Tester le serveur avec votre nom de domaine #

Avant de tester votre nom de domaine, il est nécessaire de modifier la configuration du conteneur serveur pour lui indiquer la nouvelle URL de votre serveur.

Pour cela rendez-vous dans Admin puis Paramètres du conteneur. Ici, changez l’URL du conteneur serveur.

Activez ensuite le mode de prévisualisation dans votre conteneur serveur GTM.

En parallèle, entrez le nom de domaine de votre serveur (ici https://sst.data-marketing-school.com) dans votre navigateur. Vous devriez obtenir une erreur 400.

Même si vous obtenez une erreur à cette étape, ceci veut dire que le serveur a répondu et qu’il fonctionne. On peut le vérifier dans le mode de prévisualisation de GTM Server-Side.

Félicitations, vous avez terminé la configuration Cloud de votre serveur.

Activer la journalisation (logging) #

Sur Google Cloud, rendez-vous dans la section Équilibrage de charge (ou Load balancing) puis cliquez sur l’onglet backends. Ici, vous devriez voir votre serveur.

Cliquez sur le service backend qui correspond à votre serveur puis sur Modifier.

Descendez jusqu’à la section Journalisation puis modifier les réglages comme ceci.

Cliquez ensuite sur le bouton Mettre à jour.

Félicitations, vous avez activé la journalisation.

Déployer le serveur Cloud Run en production #

Une fois que vous êtes satisfait de votre configuration Server-Side, vous devez mettre votre serveur en production avant de lui envoyer du trafic.

Rendez-vous dans les réglages de votre instance Cloud Run et déscendez jusqu’à la section Autoscaling.

Le paramétrages par défaut est le suivant :

Les réglages recommandés par Google pour passer en production sont entre 2 et 10 instances. Des instances de Cloud Run seront ajoutées ou retirées en fonction de la charge de trafic.

Cliquez ensuite sur Déployer.

Déléguer la gestion du Cloud #

Ceci peut paraître paradoxal, mais l’un des avantages principaux qui est vendu avec GTM Server-Side est le contournement des ad-blokers mais ceci n’est pas disponible nativement lorsque vous passez par Google Cloud Platform.

Pour tirer pleinement parti de GTM Server-Side je vous conseille fortement de déléguer votre gestion du Cloud. Je vais vous présenter 3 outils qui gèrent de A à Z toute la partie infrastructure/cloud de l’implémentation Server-Side.

• Configurez votre serveur avec Addingwell (plan gratuit jusqu`à 100,000 requêtes)
• Configurez votre serveur avec Stape (plan gratuit jusqu`à 10,000 requêtes)
• Configurez votre serveur avec Taggrs (plan gratuit jusqu`à 10,000 requêtes)

Envoyer vos données vers le serveur #

Pour envoyer les données à votre serveur, on va utiliser GA4 comme transporteur.

Côté web, vous devez préciser à la balise Google d’envoyer les données vers votre serveur. Pour ceci, vous devez ajouter le paramètre server_container_url dans les paramètres de configuration.

Comme valeur, vous devez renseigner l’URL de votre serveur.

Si certaines balises d’événements se déclenche avant la balise Google, elle vont utiliser la configuration par défaut et envoyer des requêtes directement à GA4 sans passer par votre serveur. Ceci va entraîner des problèmes de remontée de données par la suite.

Pour éviter ceci, il est plus prudent d’ajouter le paramètre server_container_url en paramètre d’événement pour l’ensemble de vos balises d’événement GA4.

Qu’est-ce qu’un client ? #

Un client écoute les requêtes qui arrivent sur votre serveur. S’il reconnait une requête comme étant la sienne (par exemple, le client GA4 reconnait les requêtes en /g/collect) alors il va la “Claim” (je ne connais pas de mot équivalent en français mais en gros il va dire “c’est la mienne”).

Il n’y a qu’un seul client qui peut Claim une requête. Autrement dit, une seule et même requête ne peut pas être Claim par plusieurs clients à la fois.

Un client a une priorité. Le client avec la priorité la plus haute est le plus prioritaire.

Une fois qu’un client a Claim une requête, il va récupérer les informations présentes à l’intérieur pour en extraire un nom d’événement et des données d’événements qui pourront être utilisés par les balises pour transmettre ces données et/ou se déclencher.

Configurer le client GA4 #

Le client GA4 est présent par défaut dans un nouveau conteneur GTM Server-Side.

Default GA4 paths

Cette case est cochée par défaut. Elle permet au client GA4 d’écouter les requêtes /g/collect.

Si vous décochez cette case, le client ne va plus Claim les requêtes d’événement GA4.

Default gtag.js paths for specific IDs

Cette case permet de livrer les fichier gtag.js (par exemple la libraire GA4) depuis votre serveur.

Cookies et client ID

Lorsque vous êtes en Client-Side, le cookie utilisé par GA4 pour identifier un utilisateur est _ga.

Quand vous passez en Server-Side, le cookie utilisé par défaut (configuration initiale du client GA4) pour identifier un utilisateur est FPID pour First-Party IDentifier.

Dans la configuration vous pouvez choisir de continuer d’utiliser le cookie _ga, d’utiliser le cookie FPID ou un mix des deux.

Javascript managed #

Le cookie _ga sera toujours utilisé même si vous êtes en Server-Side.

Server managed #

Le cookie FPID sera utilisé.

Lorsque vous êtes en server-managed, vous pouvez aussi cocher la case Migrate from JavaScript Managed Client ID. Ceci permettra de continuer d’utiliser le cookie _ga pour les utilisateurs existant mais aussi de déposer le FPID pour les nouveaux utilisateurs.

Configurer la balise GA4 #

Étant donné qu’on utilise le standard de données de GA4 pour envoyer les données au serveur, la configuration de la balise GA4 est plutôt simple car elle va faire passe-plat pour envoyer les données à votre propriété GA4.

Pour simplement transmettre les données à GA4, vous pouvez créer la balise et laisser la configuration vide.

Gestion du Consent Mode #

Si vous avez configuré le Consent Mode côté WEB et que vous utilisez le standard de GA4 pour envoyer les données à votre serveur, les balises côté serveur vont automatiquement prendre en compte le Consent Mode.

Les valeurs du consent mode sont transmises dans la requête GA4 via les paramètres gcs et gcd.

Ces valeurs sont ensuite extraite par le client GA4 qui va les proposer dans les données d’événements dans les paramètres x-ga-gcs et x-ga-gcd. On peut aussi retrouver le paramètre gcd dans x-sst-system_properties.gcd.

Ce sont donc ces paramètres qui vont adapter le comportement des balises Google (GA4, Google Ads et Floodlight) côté serveur.

Les onglets de la prévisualisation #

Requêtes

Ici vous pouvez voir quel client a Claim la requête ainsi que les requêtes entrantes et sortantes de votre serveur.

Balises

Comme dans le Tag Assistant côté WEB, vous pouvez voir ici les balises qui ont été déclenchées et celles qui n’ont pas été déclenchées.

Variables

Comme sur GTM WEB, il existe des variables intégrées et aussi des variables définies par l’utilisateur côté serveur.

Pour rappel, les variables intégrées sont des variables déjà existantes que vous pouvez activer ou désactiver dans votre conteneur.

Les variables définies par l’utilisateur sont des variables que vous devez configurer vous-même. Par exemple, la variable de type Données d’événement sera utile côté serveur pour aller chercher un paramètre spécifique dans les données d’événement.

Données d'événement

Les données d’événements sont tous les paramètres qui ont été récupérés de la requête entrante GA4.

Pour rappel, ces données d’événement sont générées par le client GA4.

Console

La console, permet d’afficher des messages envoyés par les balises lorsqu’elles se déclenchent.

Ces messages peuvent être des informations, des avertissements ou des erreurs.

Les transformations #

Avec les transformations, vous pouvez ajouter, modifier ou exclure des paramètres dans les données d’événements.

Dès qu’une transformation est appliqué, les balises devront utiliser les paramètres transformés et non plus les données d’événement d’origine.

FAQ #