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.
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
- relativement simple à mettre en place (la plus grosse complexité réside dans le fait de manipuler la Data Layer)
- la communauté a développé de nombreux modèles de balises et de variables pour vous faciliter la vie
- il existe de nombreux tutoriels sur internet pour vous aider
- 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)
- Google Tag Manager Client-Side est complètement gratuit
Les inconvénients de GTM Client-Side
- utilise des cookies tiers qui seront “normalement” retirés en 2024
- a tendance à augmenter le temps de chargement des pages car vous devez ajouter un code de suivi par plateforme marketing
- 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.)
- 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
- 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)
- vous permet de totalement contrôler les données qui sont transmises aux plateformes marketing car vous serveur jour le rôle d’intermédiaire (si lui qui dicte les données qui passent ou qui ne passent pas)
- le fingerprinting devient impossible avec le tracking server-side
- 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
- l’hébergement cloud de votre serveur est payant
- la gestion d’un serveur dans le cloud demande des compétences supplémentaires (mise en place, monitoring, scaling, etc.)
- 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.

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 :
- Le projet Google Cloud dans lequel se situe votre serveur
- 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 :
- le serveur de taggage
- 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
Voici 3 services qui vous proposent de gérer de A à Z toute la partie infrastructure/cloud de l’implémentation Server-Side :
Déléguer l’implémentation Server-Side
Si vous souhaitez déléguer votre implémentation Server-Side, vous pouvez me contacter sur LinkedIn : https://www.linkedin.com/in/lucasrollin/