Skip to main
← Tous les articles

Server-side tracking : le guide complet (2026)

Ce qu'est le tracking server-side, pourquoi il est devenu indispensable, comment il fonctionne et comment le mettre en place sans sGTM ni ligne de code.

· 9 min de lecture · L'équipe Walityk

Si vous gérez une boutique en ligne, vous avez probablement déjà constaté l’écart : Shopify dit que vous avez fait 100 ventes, Meta Ads en compte 62, Google Ads 71, et personne n’est d’accord. Cet écart porte un nom — la perte de données de tracking — et la réponse moderne s’appelle le server-side tracking.

Ce guide explique ce que c’est, pourquoi c’est devenu incontournable en 2026, comment ça marche réellement, et comment le déployer sans monter une infrastructure complexe.

Le tracking côté navigateur ne suffit plus

Pendant des années, tout reposait sur des pixels client-side : un bout de JavaScript (Pixel Meta, gtag Google, pixel TikTok) chargé dans le navigateur du visiteur, qui envoyait directement les events aux régies.

Ce modèle s’effondre pour quatre raisons :

  • ITP (Intelligent Tracking Prevention) sur Safari plafonne les cookies first-party à 7 jours, et supprime les cookies tiers. Sur iOS, c’est la majorité de votre trafic mobile.
  • Les adblockers bloquent purement et simplement les requêtes vers facebook.com, google-analytics.com, etc. Entre 20 % et 40 % des visiteurs selon votre audience.
  • Les CMP (bannières de consentement) bloquent les scripts tant que le consentement n’est pas donné — et beaucoup de scripts ne se rechargent jamais correctement après.
  • Les navigateurs eux-mêmes (Brave, Firefox, bientôt Chrome) durcissent leurs protections vie privée.

Résultat : une partie significative de vos conversions ne remonte jamais aux algorithmes publicitaires. Et un algorithme qui optimise sur des données partielles brûle votre budget.

Ce qu’est le server-side tracking

Le principe est simple : au lieu d’envoyer les events du navigateur directement vers Meta/Google, on les envoie d’abord vers votre propre serveur (un domaine first-party que vous contrôlez), qui les relaie ensuite aux régies via leurs API serveur :

  • Meta → Conversions API (CAPI)
  • Google Ads → Enhanced Conversions
  • GA4 → Measurement Protocol
  • TikTok → Events API
  • Pinterest / LinkedIn → Conversions API

Le flux devient : Navigateur → votre endpoint first-party → API serveur des régies.

Pourquoi ça change tout

  • Résistant aux adblockers : la requête part vers votre domaine, pas vers facebook.com. Les bloqueurs ne la voient pas.
  • Cookies first-party côté serveur : posés par votre serveur, ils échappent au plafond ITP de 7 jours.
  • Données enrichies : vous pouvez ajouter côté serveur des informations fiables (valeur de commande, e-mail hashé) que le navigateur ne connaît pas toujours.
  • Contrôle et conformité : vous décidez exactement quelles données partent, après hashage et minimisation.

Le hic : c’est compliqué à mettre en place

La méthode classique passe par un server-side Google Tag Manager (sGTM) hébergé sur Google Cloud Run. Concrètement, il faut :

  1. Provisionner un conteneur sGTM sur Cloud Run (et payer l’hébergement).
  2. Configurer un sous-domaine CNAME (metrics.votreboutique.com) avec les bons enregistrements DNS.
  3. Brancher chaque tag serveur (CAPI, Enhanced Conversions, Events API) avec les bons clients et triggers.
  4. Gérer le hashage PII (SHA-256), la déduplication par event_id, les fbp/fbc, les retries.
  5. Câbler le Consent Mode v2 pour rester conforme RGPD.
  6. Faire valider la configuration par un DPO ou un avocat.

C’est plusieurs semaines de travail pour un développeur expérimenté, plus une maintenance continue. La plupart des TPE/PME abandonnent en cours de route.

L’approche sans code

C’est exactement le problème que Walityk résout. Au lieu de monter une infrastructure, vous :

  1. Installez l’app native Shopify (ou le plugin WordPress).
  2. Connectez vos destinations (GA4, Meta, Google Ads, TikTok, Pinterest, LinkedIn) en OAuth ou par simple copier-coller de token.
  3. C’est tout — vos events partent en server-side, dédupliqués et hashés.

Pas de CNAME, pas de DNS, pas de Cloud Run, pas de header HTTP. Le endpoint first-party, la déduplication, le Consent Mode v2 et le hashage PII sont gérés pour vous. Voir l’installation Shopify.

Les bonnes pratiques à connaître

Même avec un outil qui automatise tout, quelques principes restent essentiels :

  • Déduplication : si vous gardez un pixel navigateur en plus du server-side, les deux doivent envoyer le même event_id sinon vous comptez chaque conversion deux fois. (Walityk gère ce pont automatiquement.)
  • Hashage PII : e-mails et téléphones doivent partir hashés en SHA-256 — jamais en clair.
  • Consent Mode v2 : sans signaux de consentement corrects, Google dégrade la modélisation de vos conversions.
  • Qualité de matching : plus vous envoyez de paramètres fiables (e-mail hashé, IP, user agent), meilleur est le taux de correspondance côté régie.

Faut-il s’y mettre ?

Si vous dépensez en publicité Meta, Google ou TikTok et que votre trafic est majoritairement mobile (donc Safari/iOS), la réponse est oui. L’écart entre ce que vous vendez et ce que vos régies voient se traduit directement en budget gaspillé.

La vraie question n’est plus « server-side ou pas », mais « infrastructure maison ou solution gérée ». Si vous n’avez pas une équipe data dédiée, une solution sans code vous fait gagner des semaines.

Pour aller plus loin, consultez notre documentation ou découvrez comment Walityk s’installe en moins de 5 minutes.