Comment mettre en place un tracking server-side (le guide étape par étape)

Cet article explique comment on installe un tracking server-side. Si vous vous demandez d'abord pourquoi et si ça se justifie chez vous, commencez par le guide à quoi sert le tracking server-side — puis revenez ici pour la mise en œuvre.

Par quoi commence l'installation ?

Par le sous-domaine de collecte, et rien d'autre. Avant de toucher au moindre tag, on crée un sous-domaine de votre domaine principal — par exemple sgtm.votremarque.fr — pointé en CNAME vers votre conteneur serveur. C'est cette entrée DNS qui rend toute la collecte first-party : les cookies posés depuis ce sous-domaine sont vus comme les vôtres, pas comme ceux d'un tiers.

Sauter cette étape, ou utiliser le domaine d'un hébergeur, revient à retomber dans le problème qu'on cherche à résoudre : des cookies traités en tiers, coupés par Safari au bout de 24 heures. Le first-party n'est pas un détail de confort, c'est la fondation.

Les 6 étapes, dans l'ordre

L'ordre n'est pas cosmétique : chaque étape suppose la précédente. Voici la séquence que je suis sur chaque installation.

1. Poser le sous-domaine first-party (CNAME DNS) — la fondation décrite ci-dessus.
2. Déployer le conteneur GTM server-side sur ce sous-domaine. Le choix de l'hébergement (Stape, Cloud Run, Cloudflare) se décide selon votre profil : voir où héberger son GTM server-side.
3. Router les événements du navigateur vers le serveur. Votre GTM web envoie désormais les hits à votre conteneur serveur plutôt qu'aux plateformes, en générant un event_id unique par événement.
4. Brancher les destinations serveur : la CAPI Meta dédupliquée par event_id, les Enhanced Conversions Google Ads (données hachées), et GA4.
5. Piloter par le Consent Mode V2. Denied par défaut, mise à jour au choix de l'utilisateur, et surtout signal de consentement transmis jusqu'au serveur — pas seulement côté navigateur.
6. Recetter. Comparer la couverture d'événements avant/après, vérifier que la déduplication tient, que le gclid est persisté jusqu'à l'achat, et que l'EMQ côté Meta monte.

Quels réglages cassent le plus souvent ?

Une installation qui « tourne » n'est pas une installation qui mesure juste. Quatre réglages concentrent l'essentiel des échecs :

Aucun de ces quatre points n'apparaît dans un tableau de bord : tout a l'air vert. Ils ne se voient qu'en lisant les requêtes réseau et les payloads, un par un. C'est exactement ce que couvre un audit des 13 familles de défauts.

Peut-on le faire sans développeur ?

Pour la base, oui, et c'est une bonne nouvelle. Le conteneur serveur se déploie depuis l'interface GTM, un hébergeur managé comme Stape s'occupe de l'infrastructure, et le sous-domaine se pose avec une entrée DNS que votre hébergeur crée en deux minutes. Dans la majorité des cas, aucune ligne de code sur votre thème.

Ce qui demande de l'expérience, ce n'est pas le déploiement — c'est le réglage fin : dédupliquer proprement, transmettre le consentement au serveur, normaliser et hacher les données utilisateur, reconstruire fbc/fbp. Là, ce n'est pas un développeur qu'il faut, c'est quelqu'un qui a déjà cassé et réparé ces réglages des dizaines de fois. La différence se mesure : couverture d'événements avant, couverture après.

FAQ

Nicolas MalabreMedia buyer senior — 10 ans d'achat média Google Ads & Meta. Je scanne des stacks e-commerce chaque semaine et je répare la couche de mesure des marques qui dépensent en publicité. Profil Malt ↗