Tracking côté serveur vs côté client, expliqué pour les e-commerçants

Si vous avez cherché des outils d'analyse ou de marketing récemment, on vous a probablement dit qu'il vous fallait du « tracking côté serveur ». C'est présenté comme une solution à tout, généralement sans que personne n'explique ce que c'est ou en quoi cela diffère de ce que vous avez déjà.

Ce guide le fait en termes simples. À la fin, vous comprendrez les deux approches, là où chacune brille et échoue, et la configuration précise qui vous donne le meilleur des deux sans les inconvénients. Aucun jargon que vous n'auriez pas déjà rencontré, et aucune supposition que vous gérez des balises pour gagner votre vie.

Le tracking côté client, en un paragraphe

Le tracking côté client est la façon originelle dont l'analyse fonctionne. Vous placez un petit morceau de JavaScript sur votre site, et quand un acheteur fait quelque chose — voir un produit, ajouter au panier, acheter — ce code s'exécute dans son navigateur et envoie l'événement à Google, Meta ou ailleurs. Le navigateur fait le travail et la remontée.

C'est facile à mettre en place : collez un extrait, et les événements se mettent à circuler. Et comme il vit dans le navigateur, il voit tout ce que voit le navigateur — clics, profondeur de défilement, quelle page précédait quelle autre, combien de temps quelqu'un est resté. Cette richesse est sa véritable force, et c'est pourquoi le tracking côté client ne disparaîtra jamais totalement.

L'ennui, c'est que le navigateur est aussi l'environnement le moins contrôlable d'internet. Vous ne le possédez pas, l'acheteur si, ainsi que chaque extension et paramètre de confidentialité qu'il a installés. C'est la graine de chaque problème dont nous allons parler.

Le tracking côté serveur, en un paragraphe

Le tracking côté serveur déplace la remontée hors du navigateur, vers un serveur. Au lieu que le navigateur de l'acheteur informe Google d'un achat, le back-end de votre boutique — ou un serveur de suivi dédié opéré pour son compte — envoie l'événement directement, de serveur à serveur.

Comme l'événement ne dépend plus de ce que le navigateur termine son travail, il survit aux bloqueurs de publicités, aux réglages de confidentialité, aux onglets fermés et aux connexions mobiles capricieuses. Il garde aussi vos balises et jetons d'accès hors de la page web publique, où n'importe qui pourrait sinon les inspecter. Cette fiabilité et ce contrôle font sa force.

Voyez-le ainsi : le navigateur est la vitrine, pleine de vie et de détails mais exposée aux intempéries ; le serveur est l'arrière-boutique, plus calme et verrouillée, où vous pouvez être sûr que les comptes sont tenus avec exactitude. Vous voulez les deux, chacun utilisé pour ce qu'il fait de mieux.

Les avantages et inconvénients en toute honnêteté

Le côté client est riche, mais il fuit. Il capte un comportement détaillé, mais une part non négligeable des événements n'arrive jamais — bloquée par les bloqueurs de publicités, écourtée par l'ITP d'Apple, ou perdue quand une page se ferme trop tôt. Perdre les événements qui comptent, comme purchase, est courant — un événement bloqué n'arrive tout simplement jamais. Il expose aussi vos balises et jetons au navigateur.

Le côté serveur est fiable mais, à lui seul, aveugle au pur comportement du navigateur. Il ne voit pas le défilement et les clics que le côté client capte si bien, et il demande une véritable infrastructure — un serveur de suivi, un domaine, de la configuration — à moins que quelqu'un n'opère cette partie pour vous. Il est aussi plus difficile à mal configurer sans s'en rendre compte.

Aucune des deux approches n'est complète à elle seule. C'est l'idée clé que la plupart des vendeurs passent sous silence quand ils vous disent de simplement « passer » au côté serveur.

Si vous ne retenez qu'une chose de cet article, que ce soit cette phrase. Quiconque vous vend une décision binaire vous vend une demi-solution, et la moitié manquante est généralement celle qui vous coûte de l'argent en silence, avec le temps.

Pourquoi exécuter les deux, dédupliqués, l'emporte

La bonne réponse pour presque toutes les boutiques est de faire tourner les deux. Utilisez le côté client pour la richesse comportementale et le côté serveur comme filet de sécurité fiable qui garantit que les événements qui comptent — surtout purchase — arrivent réellement.

Le piège, c'est le double comptage : si les deux canaux rapportent la même vente, vos chiffres gonflent, ce qui est sans doute pire que la sous-déclaration, parce que cela se cache en pleine lumière. La déduplication le résout. Les deux événements portent le même event_id, et la plateforme (GA4 ou Meta) les fusionne en un seul, en gardant celui qui a les meilleures données. Les conceptions les plus propres vont un cran plus loin et donnent à chaque événement du quotidien un propriétaire unique — le navigateur porte le comportement, le serveur porte l'argent — pour que la déduplication n'arbitre que le chevauchement délibéré, comme un achat rapporté à la fois par le pixel Meta et par la Conversions API.

Le résultat, c'est la couverture et la richesse sans inflation : vous voyez le comportement depuis le navigateur et vous ne perdez jamais une conversion. Cela ressemble à avoir le beurre et l'argent du beurre, mais c'est simplement utiliser chaque méthode pour la tâche où elle excelle et laisser la déduplication arbitrer le chevauchement.

Notre page côté serveur vs côté client va plus loin, et le glossaire définit chaque terme employé ici.

Une note sur la confidentialité et le contrôle

Faire tourner les deux routes ensemble n'est pas seulement plus précis, c'est plus facile à exploiter de façon responsable. Comme les PII transitent par un serveur que vous contrôlez, les données personnelles comme l'e-mail et le téléphone peuvent être normalisées et hachées en SHA-256 avant même d'atteindre Google ou Meta — les plateformes reçoivent une empreinte irréversible, pas une adresse lisible.

Garder les jetons et la logique de balisage côté serveur réduit aussi votre exposition : il y a moins à lire sur votre page pour un script malveillant ou un concurrent curieux, et vous décidez exactement quels champs quittent votre boutique et lesquels non. Pour beaucoup de marchands, cette combinaison de précision et de contrôle est la vraie raison de franchir le pas.

Ce que les propriétaires de boutiques PrestaShop devraient faire

Vous n'avez pas besoin de devenir un expert en gestion de balises. Vous avez besoin d'une configuration qui enregistre les événements navigateur via votre propre adresse web, rapporte les événements d'argent — purchase et remboursement — depuis votre back-office pour qu'ils ne dépendent jamais du navigateur, et déduplique tout chevauchement délibéré sur un event_id partagé — avec les PII hachées avant de quitter votre boutique.

C'est exactement ce que PrestaSignal installe : un module PrestaShop câblé à un serveur de suivi géré que nous opérons pour vous. Vous n'hébergez rien — le module place un petit connecteur sur l'adresse propre de votre boutique pour les événements navigateur, votre back-office rapporte chaque vente côté serveur, et vos comptes GA4 et Meta existants continuent de fonctionner exactement comme avant, simplement sans les trous.

Voyez comment ça marche pour les spécificités PrestaShop, ou regardez le module pour comprendre ce qui est installé. Si vous préférez que nous regardions simplement votre boutique, réservez un audit.