Des données produit structurées, c'est une information produit rangée dans un attribut typé, ave…
Server-side tracking en e-commerce : retrouver une mesure complète
Le server-side tracking déplace l'envoi des événements analytics et de conversion du navigateur de vos visiteurs vers un serveur que vous contrôlez. Les événements atteignent ainsi GA4, Meta, TikTok ou votre data warehouse, même lorsque des adblockers, des restrictions de navigateur ou des scripts interrompus les auraient fait disparaître. Il ne remplace pas le consentement : une mesure complète signifie que chaque événement que vous avez le droit de mesurer arrive bien à destination.
Pourquoi la mesure côté client laisse des trous
Le tracking classique repose sur des tags JavaScript dans le navigateur. Chaque tag se charge, lit des cookies et envoie des données directement vers un domaine tiers. Ce modèle cède à quatre endroits :
- Les adblockers et extensions de confidentialité filtrent les requêtes vers les domaines de tracking connus. L'événement ne quitte jamais le navigateur, et vos rapports n'en savent rien.
- Les restrictions des navigateurs raccourcissent la durée de vie des données côté client. Safari bloque par défaut les cookies intersites depuis 2020, et WebKit supprime le stockage accessible en écriture par script d'un site après sept jours d'utilisation de Safari sans interaction avec ce site. Les clients fidèles ressemblent alors à de nouveaux visiteurs, et l'attribution se brise.
- Les refus de consentement sont une lacune légitime. Qui refuse reste en dehors de la mesure. C'est normal, et aucune architecture n'y change rien.
- Le poids et le timing des scripts coûtent aussi des données. Les tags chargés tardivement ratent des événements quand un visiteur repart vite, et chaque script supplémentaire dispute le main thread à votre storefront.
Selon le Web Almanac 2025 de HTTP Archive, au moins 90 % des pages intègrent un ou plusieurs tiers. Chacun représente un petit risque pour la qualité des données et pour la vitesse.
Ce qu'est le server-side tracking, et ce qu'il n'est pas
Ce qu'il apporte
Au lieu d'une douzaine de tags, la storefront envoie ses événements vers un point de collecte first-party unique, idéalement sur votre propre sous-domaine. Un serveur les reçoit, les valide, les enrichit et les transmet aux destinations : GA4, la Meta Conversions API, la TikTok Events API ou un data warehouse. Google résume sobrement l'intérêt de son server-side tagging : moins de tags de mesure sur le site, c'est moins de code exécuté côté client. Sur un domaine personnalisé, le serveur de tagging peut en outre poser des cookies HttpOnly que les scripts de la page ne peuvent pas lire.
Ce qu'il n'apporte pas
Le server-side tracking n'est pas un moyen de contourner le consentement. Les règles européennes de consentement portent sur l'accès aux informations stockées dans le terminal et sur la finalité du traitement, pas sur l'endroit où s'exécute un tag. Les lignes directrices de l'EDPB sur le champ d'application technique de la directive ePrivacy, adoptées en 2024, couvrent explicitement des techniques comme les pixels de suivi et le tracking par URL. En pratique, un setup propre transmet le statut de consentement avec chaque événement, et le serveur n'alimente que les destinations acceptées par le visiteur. Le consent mode de Google pour le server-side tagging transmet lui aussi le statut de consentement au conteneur serveur. Cet article ne constitue pas un conseil juridique : la base légale relève de votre délégué à la protection des données.
Trois architectures possibles
Les trois approches courantes résolvent le même problème avec des priorités différentes.
Google Tag Manager Server-Side
Un conteneur serveur tourne dans votre propre environnement cloud, par exemple sur Google Cloud Run, et répond sur un sous-domaine dédié. Beaucoup d'équipes connaissent déjà sa logique de tags et de déclencheurs grâce au conteneur web. La contrepartie : vous exploitez l'infrastructure et continuez à maintenir les tags. Nous avons expliqué pourquoi le tagging no-code ne lève pas à lui seul le goulot d'étranglement du frontend dans notre article sur Google Tag Manager et le fossé du tracking.
Pipeline CDP avec RudderStack
Un pipeline de données client comme RudderStack collecte les événements de façon centralisée, les transforme et les distribue vers un grand nombre de destinations. RudderStack annonce plus de 200 intégrations prêtes à l'emploi et adopte une approche warehouse-native. Cela convient aux équipes pour qui le data warehouse est la source de vérité.
Edge avec Cloudflare Zaraz
Cloudflare Zaraz charge les outils tiers côté serveur, à l'edge : leur code ne s'exécute donc pas dans le navigateur. Zaraz intègre sa propre gestion du consentement. C'est la variante qui demande le moins d'infrastructure propre.
Qualité des données : schéma d'événements et déduplication
Côté serveur ne veut pas dire automatiquement propre. Deux disciplines décident de la fiabilité de vos chiffres.
Un schéma d'événements commun. Définissez chaque événement une seule fois : nom, paramètres obligatoires, devise, identifiants produit et contexte de consentement. Si "add_to_cart" porte trois noms différents, un serveur ne fera que propager le désordre plus vite. Pourquoi cette définition a sa place dans les composants de la storefront plutôt que dans des règles de tags, c'est le sujet de notre article sur le server-side tracking dans le schéma de composants.
La déduplication entre navigateur et serveur. Meta recommande d'utiliser la Conversions API en complément du Meta Pixel. Pour qu'un même achat ne soit pas compté deux fois, les deux événements doivent avoir le même nom d'événement et le même identifiant d'événement. Meta déduplique dans les 48 heures suivant la réception du premier événement portant cet identifiant. TikTok fonctionne de la même manière : paramètres event et event_id identiques, déduplication dans une fenêtre de 48 heures.
Une courte checklist pour démarrer :
- Générez dans le frontend un identifiant d'événement unique par interaction.
- Envoyez cet identifiant avec l'événement navigateur et avec l'événement serveur.
- Transmettez le statut de consentement avec chaque événement et filtrez les destinations côté serveur.
- Comparez le volume d'événements par destination pendant deux semaines avant de retirer les tags client.
- Retirez systématiquement les tags navigateur remplacés, sinon le gain de performance ne se matérialise jamais.
Performance : moins de JavaScript tiers dans le navigateur
Chaque tag qui passe côté serveur, c'est du code que le navigateur n'a plus à télécharger, analyser et exécuter. Le main thread respire, ce qui profite surtout aux métriques d'interaction comme l'INP. Un seul projet, deux effets : des données plus stables et un frontend plus rapide. Pour le volet plateforme, consultez Performance et Core Web Vitals.
Comment Laioutr aborde le server-side tracking
Laioutr est une Frontend Management Platform (FMP) qui se place au-dessus de votre backend commerce existant. Dans une Composable Storefront, le tracking est séparé en deux niveaux :
- Socle de tracking, inclus : la collecte des événements de base passe par le schéma de composants. Comme la plateforme connaît chaque composant, les interactions telles que clics, changements d'onglet et vues sont captées comme événements, sans tagging manuel.
- Server Side Tracking, add-on : ces événements sont transmis côté serveur, les tags marketing ne tournent donc plus dans le navigateur. La mesure devient plus robuste face aux adblockers, et la transmission reste first-party et pilotée par le consentement. Parmi les destinations : GA4, Meta, TikTok, votre data warehouse et RudderStack. Côté fournisseur, vous choisissez entre Cloudflare Zaraz, GTM Server-Side ou un autre setup.
Socle inclus, transmission côté serveur en add-on. Tous les détails sur la page Tracking & Analytics.
FAQ
Le server-side tracking est-il conforme au RGPD ?
Le server-side tracking est une architecture, pas un statut juridique. Il aide parce que vous contrôlez quelles données atteignent quelle destination, mais les obligations de consentement s'appliquent toujours. La base légale est à valider avec votre délégué à la protection des données.
Le server-side tracking contourne-t-il les adblockers ?
Il rend la mesure plus robuste face aux adblockers, car les événements partent vers un point de collecte first-party plutôt que vers des domaines de tracking connus. La limite reste le consentement : les visiteurs qui ont refusé ne sont pas suivis.
Faut-il encore des tags navigateur après la migration ?
Il reste souvent un composant client léger qui transmet les événements au serveur. Meta recommande un setup redondant navigateur et serveur, ce qui rend la déduplication par identifiant d'événement obligatoire.
GTM Server-Side, RudderStack ou Cloudflare Zaraz : lequel choisir ?
GTM Server-Side convient aux équipes qui maîtrisent GTM et exploitent leur propre cloud. RudderStack convient aux stratégies de données centrées sur le warehouse. Zaraz convient aux équipes qui veulent travailler à l'edge avec le moins d'infrastructure possible.
Prochaines étapes
Commencez par un inventaire : quels tags tournent sur votre storefront, et où les commandes de votre système e-commerce divergent-elles des conversions dans vos analytics ? Cet écart indique ce que le server-side tracking peut récupérer. Pour voir comment collecte d'événements par composants et transmission côté serveur fonctionnent ensemble, réservez une démo avec notre équipe.