Suivi côté client VS suivi côté serveur : le pour et le contre

Le marketing digital évolue rapidement et les technologies de web tracking suivent le rythme. Les entreprises se voient freinées dans leur quête de données. En effet, la méthode traditionnelle de collecte des données côté client est limitée par les restrictions des navigateurs et les règlementations sur la protection des données. Il en résulte inévitablement une perte et une dégradation des données. Le suivi côté serveur pourrait aider à résoudre ces problèmes.

 

Dans cet article, nous allons vous présenter le contexte du suivi côté serveur, expliquer en quoi cette technologie consiste et examiner les défis qu’elle pourrait relever, ainsi que son public cible et ses coûts. 

 

Pourquoi le suivi côté serveur revient sous les projecteurs  

La collecte de données par le biais d’outils d’analyse et de publicité a perdu ses lettres de noblesse ces dernières années. En cause, les nombreux scandales (comme celui de Cambridge Analytica et Facebook) et enquêtes menées par des journalistes et lanceurs d’alerte (rappelez-vous Edward Snowden). Résultat : les populations et gouvernements du monde entier ont pris conscience de ce qui était collecté à leur sujet, à leur insu, et de ce qui était fait avec ces données. 

Les législateurs ont dès lors renforcé la protection des données des consommateurs. Le Règlement général sur la protection des données (RGPD) en 2018, la Loi californienne sur la protection de la vie privée des consommateurs (CCPA) en 2020 et bien d’autres règlementations limitent désormais la quantité de données qui peuvent être collectées.  

Des systèmes de protection des données ont été intégrés directement dans les navigateurs. L’Intelligent Tracking Protocol d’Apple, le « strict mode » de Firefox ou encore le mode « Privacy by default » de Brave et DuckDuckGo entravent eux aussi la collecte de données. Sans oublier bien sûr les bloqueurs de publicité installés par les utilisateurs eux-mêmes.  

Enfin, les cookies tiers sont sur le point d’être supprimés définitivement des navigateurs (il ne reste que Google Chrome, qui l’a reporté à la 2e moitié de 2024). L’identification des utilisateurs sera dès lors encore plus compliquée pour l’industrie de la publicité en ligne, et les campagnes vont perdre en efficacité. Le même combat fait rage sur mobile, avec l’introduction par Apple dans l’iOS 14.5 d’une limitation de l’utilisation de l’« IDFA », l’identifiant publicitaire. Android semble emboiter le pas avec l’ajout dès Android 12 d’une fonctionnalité similaire pour son « AdID ». 

Nous assistons ainsi à une détérioration significative des données. Or, la méfiance à l’égard de la qualité des données peut constituer un obstacle majeur pour toute initiative de collecte des données. Alors, comment composer avec toutes ces protections et législations ? Comment redresser le cap et continuer à collecter des données représentatives, tout en respectant à la fois les contraintes légales et la volonté des utilisateurs ?  

C’est ici qu’intervient le suivi côté serveur, une méthode qui répond à toutes ces questions. Mais avant tout, comment fonctionne-t-elle ? 

Qu’est-ce que le suivi côté serveur ?

Une histoire de requête 

Une requête est toujours la base d’un suivi. Dès qu’un utilisateur effectue une action qui est mesurée, une requête (HTTP) est envoyée à un serveur de suivi (terminal) appartenant à un service (Google Analytics, Facebook, Snowflakes). En d’autres termes, cette requête envoyée depuis un navigateur pointe vers une URL qui représente le serveur de suivi d’un service spécifique. 

Ces serveurs de suivi sont configurés de telle sorte qu’ils peuvent lire ces requêtes, plus spécifiquement leur charge utile en tant que paramètres URL. C’est cette charge utile qui contient les données que nous souhaitons collecter. Des données d’identification (provenant des cookies) sont également attachées à la requête afin d’identifier l’expéditeur, ou le navigateur d’une machine donnée. Le serveur de suivi traite ensuite ces données pour ajouter une ligne dans un outil analytique ou un utilisateur dans une liste de remarketing. 

Ces requêtes peuvent être envoyées depuis des sources autres qu’un navigateur web. C’est ici que se manifeste la distinction entre le suivi côté client et le suivi côté serveur. 

 

Le modèle client-vers-fournisseur 

Le suivi côté client – ou client-vers-fournisseur – est le modèle de suivi classique. Un client est le moyen par lequel un utilisateur surfe sur le web, généralement un navigateur web. Les requêtes sont envoyées par ce client vers le ou les serveurs de suivi (fournisseurs), comme Facebook ou Google Analytics. 

Server side tracking 2

Du côté client, un conteneur unique sur le site web envoie des données vers de nombreux fournisseurs

Ce modèle présente toutefois quelques faiblesses

Performances 

Il y a une corrélation directe entre les performances d’une page et son poids. Nous savons qu’un temps de chargement long a un impact négatif sur l’expérience utilisateur et les taux de conversion. 

Pour chaque tiers déployé sur le site web, une bibliothèque JavaScript ou un App SDK (Kit de développement logiciel – une autre bibliothèque, mais pour les applications mobiles) doit être chargé. Cette bibliothèque génère une requête et l’envoie au serveur de suivi du fournisseur. Ces actions entraînent une augmentation des sorties du réseau et peuvent augmenter le poids des pages web. En fin de compte, tout cela nuit au temps de chargement. 

 

Fuites de données 

Des scripts tiers s’exécutent sur le navigateur, sans que nous sachions comment ils opèrent. Plus important, nous n’avons aucun contrôle sur ce qui peut être exécuté ou sur les demandes générées et moins de contrôle encore sur les données envoyées aux fournisseurs. Tout cela nuit à la sécurité des données et peut se traduire par une importante fuite de données personnelles. 

 

Impacté par la protection des données des navigateurs 

De nombreuses méthodes de protection de la vie privée existent pour limiter la collecte de données. Puisque nous ne contrôlons pas ce que décide le navigateur, le suivi côté client dépend fortement des règles appliquées dans le navigateur et des bloqueurs de publicités installés. 

Par conséquent, si le suivi côté client ajoute aux pages un temps de chargement inutile et peut entraîner des violations de la sécurité, il apporte toutefois la transparence nécessaire pour bloquer ou restreindre le suivi. 

En revanche, le suivi côté serveur peut améliorer le contrôle sur les scripts invasifs et gourmands en ressources et la gestion des flux de données entrants et sortants, mais il lui reste à traiter le manque important de transparence auprès des utilisateurs finaux. 

C’est ce modèle que nous allons examiner maintenant. 

Le modèle client-vers-serveur-vers-fournisseur

Ce que nous appelons « suivi côté serveur » n’est en réalité pas simplement du « côté serveur ». C’est-à-dire que la communication des requêtes ne se fait pas, comme on pourrait le croire, de serveur à serveur (fournisseurs), mais bien de client à serveur à fournisseurs. 

Ce modèle de communication a été choisi parce qu’il doit s’appuyer sur ce qui est fait côté client : le stockage des données dans la couche de données et la possibilité de mesurer les interactions de l’utilisateur sur le site. Tous ces éléments sont déjà en place du côté client et orchestrés par un Tag Management System (TMS) comme Tealium, Google Tag Manager ou Adobe Launch. 

Ces outils permettent la collecte de données à l’aide de ce qu’on appelle des tags, déclenchés selon des règles spécifiques. Une fois déclenchés, ces tags sont chargés d’envoyer les données aux fournisseurs. Tout cela se déroule dans le navigateur, côté client. 

Server side tracking 3

Avec le suivi côté serveur – ou client-vers-serveur-vers-fournisseur – la requête n’est pas envoyée aux serveurs de suivi des fournisseurs. À la place, elle est envoyée à un serveur de suivi intermédiaire. 

Server side tracking 4

C’est vous, en tant qu’entreprise, qui possédez ce serveur de suivi. Il est sécurisé et généralement hébergé sur une plateforme cloud. De même que du côté client, un Server-Side Tag Management System (SSTMS) est installé dans ce serveur pour gérer la réception et le traitement des requêtes. 

En bref, le SSTMS traite chaque requête entrante avec toutes ses données associées, puis les filtre, les enrichit ou les transforme avant de transmettre les résultats aux fournisseurs

Principaux avantages du suivi côté serveur

De meilleures performances 

Le principal avantage du suivi côté serveur, c’est la simplification des flux de données. Au lieu d’envoyer autant de requêtes qu’il y a de fournisseurs, une requête unique est envoyée au SSTM, qui se charge ensuite d’envoyer les données aux autres fournisseurs. 

Puisque c’est le SSTMS qui assume cette distribution de requêtes au lieu du TMS exécuté sur le navigateur, les ressources nécessaires au suivi sont fortement réduites : moins de requêtes à envoyer et moins de scripts à charger. L’optimisation du temps de chargement qui en résulte bénéficiera également au SEO. En effet, ces actions vont inévitablement entraîner des améliorations des signaux web essentiels et nous savons que ces indicateurs sont importants, puisque Google a annoncé que les données seront intégrées comme facteur de classement depuis une mise à jour déployée le 15 juin 2021. 

Mais cela n’est vrai que si tout est déplacé du côté serveur. En réalité, il reste quelques contraintes technologiques, ainsi qu’un certain non-sens. Par exemple, Facebook qui demande de maintenir le suivi côté client afin de continuer à collecter le plus de données possible et de placer des cookies tiers pour son algorithme « LookaLike Retargeting ». 

 

Récupérer le contrôle sur les données 

En plus de réduire les risques de violations associées au chargement de scripts tiers dans le navigateur, les fournisseurs n’auront accès qu’aux données que le SSTMS choisit d’envoyer. Ils ne pourront plus se servir comme dans un buffet à volonté des données disponibles dans le navigateur. 

Par ailleurs, comme tout le traitement s’effectue sur le serveur de suivi, de réelles tâches d’anonymisation et d’obscurcissement peuvent être effectuées. Grâce à cette technique, connue sous le nom de « Proxyfication », nous pouvons répondre plus efficacement aux problèmes associés à la protection des données. Nous pouvons réellement protéger les utilisateurs, car nous choisissons ce qui est envoyé, à qui et sous quel format. Mais la mise en place du suivi côté serveur ne nous permet pas de contourner la loi de quelque manière que ce soit, car le consentement reste requis. Et pourtant, la mise en place d’une véritable anonymisation (la suppression de tout élément permettant d’identifier directement ou indirectement un utilisateur) permettrait de nous affranchir de la nécessité de consentement. Néanmoins, en raison de l’importante détérioration des données que cela génère, nous conseillons d’utiliser des outils de mesure dédiés à l’analyse de données agrégées.  

En outre, avec l’approche côté serveur, il est possible de contourner les bloqueurs de publicités. De fait, la requête est envoyée à votre serveur de suivi et non aux fournisseurs, et elle n’est dès lors pas détectable par les plug-ins. Cela représente pour l’instant une aubaine pour le suivi, mais nous vous conseillons toutefois de ne pas chercher à le contourner si les plug-ins devaient s’adapter à ce nouveau mode de suivi. Car nous plaidons en faveur du respect de la volonté des utilisateurs et nous donnerons toujours la priorité à la protection maximale des données utilisateurs. 

Enfin, il est également possible de faire communiquer le serveur de suivi avec d’autres services externes (API) comme un CRM ou un PIM, et donc d’enrichir les données. Cela vous permettrait par exemple de collecter des données produits depuis les bases de données et ainsi d’alléger la couche de données en front-end. 

Si vous souhaitez découvrir d’autres avantages et inconvénients du suivi côté serveur, nous vous recommandons de lire cet article exhaustif de Simo Ahava. 

À qui le suivi côté serveur peut-il profiter ?

La technologie côté serveur est une technologie complexe qui peut résoudre de nombreux problèmes. Elle peut s’avérer particulièrement intéressante dans des environnements analytiques avancés. Parmi ce que nous qualifierions d’environnement analytique avancé, citons par exemple : 

  • Les sites e-commerce 

  • Les écosystèmes numériques répartis sur différentes plateformes 

  • Les stratégies d’acquisition avancées impliquant plusieurs sources de trafic et nécessitant l’intégration de nombreux systèmes de suivi 

  • Les départements juridiques et IT dotés d’exigences de sécurité élevées 

  • Le besoin de communiquer des données dans un écosystème complexe (CRM, CDP, outils d’automatisation marketing, etc.) 

Enfin, les entreprises intéressées par la précision des données, la confidentialité des utilisateurs et les performances de leur site seraient bien inspirées de passer au suivi côté serveur. C’est également devenu une exigence pour certaines plateformes, comme les réseaux d’affiliation. 

Mais nous allons le voir, passer au suivi côté serveur implique un investissement (humain et financier) qui peut s’avérer substantiel. 

 

Un investissement de taille  

La mise en place d’une infrastructure de suivi côté serveur ne doit pas être sous-estimée. C’est plus difficile à mettre en place et à maintenir qu’une infrastructure côté client. 

Le premier élément qui peut entraîner des coûts, c’est le transfert vers le côté serveur de ce qui se fait côté client. Certains éléments, comme Hotjar, sont étroitement liés au côté client et ne peuvent pas être transférés du côté serveur. Pour le reste, il est nécessaire d’évaluer le nombre de fournisseurs qui disposent d’API accessibles, ce qui n’est pas toujours le cas. Il sera ensuite question de définir s’il existe des modèles de tag/clients pour ces fournisseurs dans le SSTMS, ce qui n’est pas très fréquent non plus pour le moment. En fait, moins il y a de fournisseurs avec des modèles tout prêts dans le SSTMS, plus la création de tags qui transmettront les données demandera du travail. Et pour tous ceux qui n’ont pas d’API accessibles, vous perdrez une partie de l’avantage du suivi côté serveur, puisque vous devrez conserver le pixel côté client. 

Il y a ensuite les coûts associés à la configuration et aux testings. Il est plus difficile de s’attaquer au débogage côté serveur que côté client, justement en raison du manque de transparence du suivi côté serveur. Par conséquent, la validation de l’assurance qualité prendra plus de temps. 

Enfin, il y a la location du serveur. Sur Google Cloud avec App Engine, la location revient à environ 150 $ par mois. Cela peut sembler coûteux, mais c’est relativement bon marché compte tenu de tout ce que cette solution apporte en fin de compte. 

Que choisir ?

Pour résumer, à ce stade, le côté serveur présente des avantages indéniables et des possibilités presque infinies, mais au coût d’un investissement initial important. Le côté serveur nous dote de nombreux outils pour optimiser la gouvernance de nos données, mais cet avantage peut se voir réduit à néant selon l’utilisation qu’on en fait. 

Nous pensons que le meilleur point de départ pour mettre en place un suivi côté serveur consiste à commencer de zéro. Que ce soit à l’occasion d’une migration ou d’un remaniement de votre site web, les analyses devront être repensées et adaptées. Vous pourriez saisir cette occasion pour intégrer à votre réflexion le suivi côté serveur. 

Sinon, si vous pensez que la solution côté serveur peut apporter un réel avantage à votre infrastructure d’analyse, n’hésitez pas à vous lancer. Voici deux conseils avant que vous ne commenciez : 

  • Dépenser plusieurs centaines de billets pour la migration et encore 150 $ de plus par mois juste pour le CAPI (API de conversion) de Facebook, ça ne se fait pas à la légère. Le besoin de passer au côté serveur doit être réel, ne vous laissez pas abuser par la pression imposée par ces fournisseurs et prenez un peu de recul. 

  • Un point important avant de passer au suivi côté serveur : documentez parfaitement votre infrastructure d’analyse actuelle pour pouvoir décider de ce que vous devriez transférer côté serveur et comment, et de ce qui devrait rester côté client. Cela vous aidera également à estimer les coûts de migration. 

Si vous souhaitez discuter plus en détail du suivi côté serveur, notre équipe de web analytics sera ravie de répondre à toutes vos questions. 

VOUS SOUHAITEZ ÉCHANGER AVEC UN EXPERT ?

Contactez-nous