← Tracking & MesureTracking & Mesure

Tracking server-side : pourquoi et comment le mettre en place

Le tracking server-side déplace la collecte des données côté serveur pour contourner les bloqueurs de publicités et la disparition des cookies tiers. Principes, avantages et mise en place.

Par Kenoby10 min de lecture

En bref — Le tracking server-side (ou server-side tagging) consiste à déplacer une partie de la collecte des données de l'navigateur vers un serveur intermédiaire que vous contrôlez. Il contourne les bloqueurs de publicités, étend la durée de vie des cookies first-party et améliore les performances du site. C'est la réponse technique à la fin des cookies tiers et à la montée des adblockers.

Pourquoi le tracking client-side atteint ses limites

Le tracking traditionnel (client-side) repose sur des scripts JavaScript chargés dans le navigateur de l'utilisateur. Ces scripts envoient des données directement aux plateformes (Google, Meta, etc.) depuis le navigateur.

Problème 1 : les bloqueurs de publicités uBlock Origin, AdGuard, Brave et les DNS filtrants (Pi-hole) bloquent les domaines publicitaires connus. Selon les études, 25 à 40 % des internautes bloquent au moins partiellement les trackers. Pour un site B2B tech, ce taux peut dépasser 60 %.

Problème 2 : l'Intelligent Tracking Prevention (ITP) de Safari Safari (iOS, macOS) limite la durée de vie des cookies tiers à 7 jours (voire 1 jour dans certains cas). Pour une fenêtre de conversion de 30 jours, les conversions Safari sont sous-comptées.

Problème 3 : la fin des cookies tiers Chrome bloque les cookies tiers par défaut depuis 2025 (avec le Privacy Sandbox). Le remarketing et l'attribution cross-site reposant sur les cookies tiers sont impactés.

Conséquence mesurée : selon différentes études, les entreprises en tracking client-side uniquement sous-comptent 20 à 40 % de leurs conversions réelles.

Comment fonctionne le tracking server-side

Le tracking server-side ajoute un serveur intermédiaire (un "endpoint" que vous contrôlez) entre le navigateur et les plateformes publicitaires.

Architecture client-side (avant) :

Navigateur → [bloqueurs ?] → Google Analytics / Google Ads / Meta Pixel

Architecture server-side (après) :

Navigateur → Votre serveur (GTM server-side) → Google Analytics / Google Ads
                                              → Meta CAPI (Conversions API)
                                              → TikTok Events API

Le navigateur envoie les données à votre propre domaine (ex. tracking.votre-site.fr). Votre serveur reçoit ces données, les traite, et les redistribue aux plateformes. Les bloqueurs ne peuvent pas bloquer votre propre domaine sans bloquer tout votre site.

Les composants d'une infrastructure server-side

GTM Server-Side

Google Tag Manager propose une version server-side : un conteneur GTM qui tourne sur un serveur (Cloud Run, GCP, AWS, Stape.io…). Il reçoit les événements du client (via un "web container" GTM classique) et les redistribue aux destinations.

Conteneur Web (navigateur) → Conteneur Serveur (votre serveur) → Destinations

Le conteneur serveur contient les mêmes concepts que GTM classique : balises, déclencheurs, variables — mais côté serveur.

Meta Conversions API (CAPI)

Meta propose son propre protocole server-side : l'API Conversions. Plutôt que le Pixel (client-side), vous envoyez les événements de conversion directement depuis votre serveur vers Meta via leur API.

Avantages CAPI :

  • Pas bloquable par les adblockers
  • Pas limité par ITP
  • Meilleure attribution (Meta peut matcher via email/téléphone hashé)
  • Peut combiner Pixel + CAPI pour une couverture maximale (Event Match Quality)

Autres APIs server-side

  • Google Ads Enhanced Conversions : enrichit les conversions côté serveur avec des données first-party (email hashé)
  • TikTok Events API : équivalent du CAPI pour TikTok
  • Snapchat Conversions API : idem pour Snapchat

Avantages concrets du server-side

| Problème client-side | Solution server-side | |---------------------|---------------------| | Bloqué par adblockers | Requêtes vers votre domaine, non bloquables | | Cookies limités à 7j (ITP) | Cookies first-party posés côté serveur (durée jusqu'à 2 ans) | | Données third-party limitées | Cookies first-party, données de session enrichies | | Performances dégradées par les scripts | Moins de JS dans le navigateur, Core Web Vitals améliorés | | Dépendance aux cookies tiers | Fonctionne avec données first-party uniquement | | Données brutes envoyées aux plateformes | Possibilité de filtrer/anonymiser avant envoi |

Comment mettre en place le server-side tracking

Option 1 : GTM Server-Side via Stape.io (recommandé PME)

Stape.io est un SaaS qui héberge votre conteneur GTM server-side sans configuration infrastructure. C'est la solution la plus accessible pour les PME.

Étapes :

  1. Créez un compte Stape.io (~30 €/mois)
  2. Stape génère votre conteneur GTM server-side et un endpoint (ex. votre-compte.stape.io)
  3. Configurez votre DNS pour pointer tracking.votre-site.fr vers cet endpoint
  4. Dans votre conteneur GTM Web, remplacez le domaine de collecte GA4 par votre endpoint
  5. Dans le conteneur serveur, ajoutez les balises de destination (GA4, Google Ads, Meta CAPI)

Option 2 : Google Cloud Run (auto-hébergé)

Pour les entreprises avec compétences techniques en interne, déployez GTM server-side sur Google Cloud Run.

Coût : quelques euros par mois pour les volumes PME (facturation à la requête).

Documentation officielle : disponible sur developers.google.com/tag-platform/tag-manager/server-side

Option 3 : Meta CAPI seule (démarrage rapide)

Si votre priorité est Meta Ads, implémentez Meta Conversions API directement :

  1. Via le plugin officiel (WordPress/Shopify)
  2. Via l'intégration GTM Server-Side (plugin Meta CAPI disponible dans Stape)
  3. Via développement direct de l'API

Déduplication : si vous utilisez Pixel + CAPI simultanément, assurez-vous d'envoyer le même event_id dans les deux pour que Meta déduplication les événements et évite le double comptage.

Limites et précautions

Complexité accrue : le server-side ajoute une couche d'infrastructure à maintenir. Une erreur de configuration peut couper tout le tracking.

Coût : comptez 30-100 €/mois pour une infrastructure hébergée, plus le temps de configuration (2-5 jours pour un intégrateur expérimenté).

RGPD : le server-side ne vous exempte pas du Consent Mode et du RGPD. Les données que vous collectez et redistribuez restent soumises aux obligations légales. Configurez le Consent Mode v2 en parallèle.

Prérequis : maîtriser d'abord le tracking client-side classique (GTM + GA4 + Consent Mode) avant de passer au server-side.

Quand passer au server-side ?

Le server-side est recommandé quand :

  • Votre audience est très technique (taux d'adblocking > 30 %)
  • Vos fenêtres de conversion dépassent 7 jours (impact ITP important)
  • Vous investissez > 5 000 €/mois en publicité (ROI du server-side justifié)
  • Vous avez besoin de la Meta CAPI pour améliorer l'Event Match Quality
  • Vous souhaitez enrichir les données envoyées aux plateformes avec des données CRM

Pour les budgets < 2 000 €/mois, le Consent Mode v2 bien configuré offre un meilleur ROI que le server-side.

FAQ tracking server-side

Le tracking server-side est-il légal au regard du RGPD ?

Oui, à condition de respecter les obligations RGPD : consentement de l'utilisateur, finalités définies, transferts internationaux documentés (si les données transitent hors UE). Le server-side ne vous exempte pas du RGPD — il change l'architecture technique, pas les obligations légales.

Meta Pixel ou Meta CAPI : lequel choisir ?

Les deux sont complémentaires. Le Pixel collecte les signaux navigateur (clics, pages vues), la CAPI collecte les événements côté serveur (notamment les conversions). La combinaison Pixel + CAPI donne le meilleur Event Match Quality et donc la meilleure attribution Meta.

Le server-side améliore-t-il les Core Web Vitals ?

Oui, indirectement. En déplaçant certains scripts côté serveur, vous réduisez le JavaScript chargé dans le navigateur. GTM Server-Side peut remplacer 3-5 scripts client-side par un seul appel vers votre endpoint, réduisant le Total Blocking Time.

Faut-il reconfigurer GTM entièrement pour passer au server-side ?

Non. Votre conteneur GTM Web existant continue de fonctionner. Vous ajoutez un conteneur GTM Server-Side en parallèle. Les deux conteneurs coexistent — le web envoie les événements au serveur, le serveur les redistribue aux plateformes.

Kenoby met en place les infrastructures de tracking server-side pour les annonceurs qui veulent fiabiliser leur mesure face aux bloqueurs et à la fin des cookies tiers.