GTM Server-Side : Le guide complet

Mis à jour : samedi 20 janvier 2024

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 server-side est pertinente pour votre entreprise et également les étapes à suivre pour l’implémenter.




Vous pourriez être intéressé par un guide plus spécifique :

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 tiers dans le navigateur pour identifier un même visiteur à travers plusieurs visites et/ou relier un visiteur à 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. utilise des cookies tiers qui seront “normalement” retirés en 2024
  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 des utilisateurs collectées automatiquement, fingerprinting, etc.)
  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 avec 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. le fingerprinting devient impossible avec le tracking server-side
  4. vous êtes moins sujet aux ad blockers car les librairies javascript de GTM et GA4 notamment peuvent être téléchargées depuis votre serveur

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)

Questions fréquentes


Est-ce que ma configuration client-side est à mettre à la poubelle si je passe en server-side ?

Non. Votre implémentation client-side pourra être réduite à un seul type de balise (par exemple GA4) qui va envoyer les données à votre serveur, ceci réduira le temps de chargement de votre site web car vous aurez moins de balises. Tous vos déclencheurs seront toujours utiles. Si vous avez mis en place une Data Layer, ceci n’est pas à mettre à la poubelle non plus, le conteneur client va continuer de l’utiliser.

Est-ce que je dois changer mon plan de taggage ou ma stratégie de mesure si je passe en server-side ?

Vous pouvez mettre à jour votre plan de taggage côté client si vous retirez certains tags. Vous pouvez aussi créer un plan de taggage pour la partie server-side. En revanche, les événements que vous mesurez resteront les mêmes, le passage en server-side modifie d’un point de vue technique la façon dont les données sont remontées aux plateformes marketing mais ne modifie en rien votre stratégie de mesure.

Est-ce que je dois toujours obtenir le consentement de mes visiteurs en server-side ?

Oui. GTM server-side est juste une implémentation technique différente mais ceci ne change rien à la législation en vigueur.

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.

Menu de création du conteneur serveur dans GTM
Menu de création du conteneur serveur dans GTM

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.

Provisionnement automatique du serveur de taggage
Provisionnement automatique du serveur de taggage

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.

Sélection du compte de facturation
Sélection du compte de facturation

La création du serveur va prendre quelques minutes…

Serveur de taggage créé
Serveur de taggage créé

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.



Sélectionnez Cloud Run dans le menu de Google Cloud Platform
Sélectionnez Cloud Run dans le menu de Google Cloud Platform

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 :

Services Cloud Run après l'approvisionnement automatique
Services Cloud Run après l'approvisionnement automatique

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

Onglet intégration dans Cloud Run
Onglet intégration dans Cloud Run

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

Intégration domaines personnalisés dans Cloud Run
Intégration domaines personnalisés dans Cloud Run

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

Configuration du domaine personnalisé dans Cloud Run
Configuration du domaine personnalisé dans Cloud Run

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.

Enregistrement DNS à configurer
Enregistrement DNS à configurer

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.

Configuration de l'enregistrement DNS dans Cloudflare
Configuration de l'enregistrement DNS dans Cloudflare


Attente de la liaison du nom de domaine et de la génération certificat SSL
Attente de la liaison du nom de domaine et de la génération du certificat SSL

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.

Domaine lié et certificat SSL actif
Domaine lié et certificat SSL 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.

Changement de l'URL du serveur dans les paramètres du conteneur sur GTM
Changement de l'URL du serveur dans les paramètres du conteneur sur GTM

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

Bouton d'activation du mode de prévisualisation sur le conteneur serveur
Bouton d'activation du mode de prévisualisation sur le conteneur serveur

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.

Test d'envoi d'une requête au serveur
Test d'envoi d'une requête au serveur

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.

Requête reçue par le serveur
Requête reçue par le serveur

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.

Backends dans la section équilibrage de charge sur Google Cloud Platform
Backends dans la section équilibrage de charge sur Google Cloud Platform

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

Modification du service backend qui correspond à votre serveur
Modification du service backend qui correspond à votre serveur

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

Configuration de la journalisation sur le service backend
Configuration de la journalisation sur le service backend

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 :

Réglages par défaut de l'autoscaling
Réglages par défaut de l'autoscaling

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.

Réglages en production
Réglages en production

Cliquez ensuite sur Déployer.


Déléguer la gestion du Cloud

Voici 3 services qui vous proposent de gérer de A à Z toute la partie infrastructure/cloud de l’implémentation Server-Side :