Explication pratique - Analytique côté client vs côté serveur

Ce guide explique le sujet Analytique côté client vs côté serveur avec un contexte pratique. Les mesures côté client et l'analytique côté serveur répondent à des questions différentes : elles décrivent la même activité, mais observée depuis deux points distincts.

Les analyses côté serveur et les analyses côté client répondent à différentes questions. Ils décrivent tous deux l’activité autour de votre site Web, mais ils observent cette activité depuis différents endroits. Lorsque les chiffres ne correspondent pas, ce n’est généralement pas un bug. C'est une limite de mesure.

L'analyse côté client s'exécute dans le navigateur du visiteur. Un extrait de code JavaScript enregistre une page vue ou un événement et l'envoie à un point de terminaison d'analyse. L'analyse côté serveur démarre généralement à partir des journaux du serveur Web, des journaux CDN, des journaux du proxy inverse ou des événements d'application générés sur votre infrastructure.

La question pratique n’est pas « qu’est-ce qui est exact ? » C'est "exact pour quelle décision ?"

Ce que l'analyse côté client capture bien

L'analyse côté client est plus efficace lorsque vous devez comprendre l'expérience utilisateur dans le navigateur :

• Vues de la page de destination
• Référents et campagnes UTM
• Clics, démarrages de formulaires, téléchargements et événements personnalisés
• Entonnoirs de conversion
• Contexte du navigateur, de l'appareil et de la fenêtre d'affichage
• Signaux d'engagement tels que la profondeur de défilement ou le temps d'activité

Il peut également capturer les événements qui n'atteignent jamais votre serveur sous forme de requêtes distinctes. Un clic sur un onglet de tarification, une lecture vidéo, un bouton de copie, une extension en accordéon ou un changement d'itinéraire côté client peuvent être invisibles dans les journaux d'accès bruts, à moins que votre application ne l'enregistre explicitement.

Le compromis est que l’analyse côté client dépend du code exécuté dans le navigateur. Il peut être bloqué par des bloqueurs de publicités, des fonctionnalités de confidentialité du navigateur, des choix de consentement, des pannes de réseau, des erreurs de script, des problèmes de politique de sécurité du contenu et des environnements désactivés par JavaScript.

Ce que l'analyse côté serveur capture bien

L'analyse côté serveur observe les requêtes qui touchent l'infrastructure que vous contrôlez. Il est excellent pour :

• Volume total de requêtes HTTP
• Taux d'erreur, codes d'état et latence
• Comportement des robots et des robots d'exploration
• Utilisation de API
• Comportement du cache CDN
• Enquêtes de sécurité
• Téléchargements de fichiers servis directement depuis le serveur

Les journaux du serveur sont particulièrement utiles lorsque les analyses marketing sont sous-estimées car les scripts sont bloqués. Ils peuvent montrer qu'une page a été demandée même lorsqu'aucun événement côté navigateur n'a été envoyé.

Mais les journaux ne constituent pas un indicateur fiable des visites humaines. Le chargement d'une seule page peut générer des requêtes d'appels HTML, CSS, JavaScript, images, polices et API. Les robots, les moniteurs de disponibilité, les dérouleurs de liens, les lecteurs RSS, les préchargeurs et les scanners peuvent tous gonfler les chiffres. Les journaux ont également des difficultés avec la navigation côté client dans les applications à page unique, à moins que l'application n'envoie des événements de serveur explicites.

Pourquoi les chiffres diffèrent

Attendez-vous à ce que les analyses côté client montrent moins de visites que les journaux du serveur. Les raisons courantes incluent :

• Le visiteur a refusé les cookies d'analyse ou le consentement au suivi.
• Le script a été bloqué par une extension de confidentialité.
• Safari, Firefox, Brave ou un autre navigateur limite le comportement de suivi.
• Le point de terminaison d’analyse a été bloqué par le filtrage DNS ou les outils de sécurité de l’entreprise.
• L'utilisateur est parti avant le chargement du script.
• La page chargée à partir du cache ou pré-rendue d'une manière que votre tracker n'a pas comptée.

Attendez-vous à ce que les journaux du serveur affichent plus de bruit. Les raisons courantes incluent :

• Recherchez des robots et des robots d'exploration SEO.
• Robots d'exploration et scrapers IA.
• Outils de surveillance.
• Bots de prévisualisation des réseaux sociaux.
• Les demandes d’actifs sont comptabilisées comme activité de page.
• Réessayez le trafic et les demandes en double.

Les protections de la confidentialité des navigateurs constituent une véritable partie de l’écart. Le WebKit de Safari documente la prévention du suivi en tant que fonctionnalité de plate-forme de longue durée et bloque les cookies tiers par défaut dans les contextes Safari modernes (WebKit). La protection totale des cookies de Firefox isole les cookies par site pour réduire le suivi intersites (Mozilla).

Différences de confidentialité

Aucune des deux approches n’est automatiquement respectueuse de la vie privée. Un journal de serveur contenant les adresses IP complètes, les agents utilisateurs, URL avec des données personnelles et une longue conservation peut être plus sensible qu'un événement d'analyse minimal côté client. Un tracker côté client qui définit des identifiants persistants et partage des données avec des plateformes publicitaires peut être plus invasif que les métriques agrégées du serveur.

Évaluez les deux en utilisant les mêmes questions :

• Quelles données sont collectées ?
• S’agit-il de données personnelles ou peuvent-elles être liées à une personne ou à un foyer ?
• Est-il partagé avec des tiers ?
• Combien de temps est-il conservé ?
• L’objectif commercial peut-il être atteint avec moins de données ?
• Le système s'appuie-t-il sur des cookies, un stockage local, des empreintes digitales ou un IDs intersite ?

En vertu des règles européennes en matière de cookies, les obligations de consentement peuvent s'appliquer aux technologies qui stockent ou accèdent à des informations sur l'appareil d'un utilisateur, sauf si elles sont strictement nécessaires. Les directives UK ICO traitent les cookies analytiques comme non essentiels et indiquent que les utilisateurs doivent contrôler les cookies non essentiels et les technologies similaires (ICO).

Quand utiliser chaque source

Utilisez l'analyse côté client pour les questions de marketing et de produits :

• Quelles campagnes amènent des visiteurs qualifiés ?
• Quelles pages mènent aux inscriptions ?
• Où les utilisateurs abandonnent-ils un entonnoir ?
• Quels types d’appareils convertissent mal ?
• Quels événements d'intégration prédisent l'activation ?

Utilisez les journaux côté serveur pour les questions opérationnelles et de sécurité :

• Quels points de terminaison sont lents ou défaillants ?
• Les robots empruntent-ils des itinéraires coûteux ?
• Quels codes de statut ont augmenté après un déploiement ?
• Une modification de règle CDN a-t-elle réduit le trafic d'origine ?
• Les clients suspects sondent-ils les chemins de connexion ou d’administration ?

Utilisez les deux lorsque la décision concerne le comportement des utilisateurs et l’infrastructure. Par exemple, si les inscriptions ont été interrompues après une version, les analyses côté client peuvent indiquer si moins d'utilisateurs ont atteint le formulaire, tandis que les journaux côté serveur peuvent indiquer si le point de terminaison de soumission a commencé à renvoyer des erreurs.

Comment combler le manque de données

Ne forcez pas les deux systèmes à correspondre. Définissez plutôt un contrat de mesure :

• Nommez la source de vérité pour chaque métrique.
• Excluez le trafic de robots connu des rapports destinés aux humains.
• Gardez les définitions de pages vues cohérentes entre les outils.
• Filtrez les actifs statiques des rapports de trafic côté serveur.
• Suivez les événements importants du produit sur le serveur lorsque cela est possible.
• Utilisez les paramètres UTM de manière cohérente sur les deux systèmes.
• Comparez les tendances, pas seulement les chiffres absolus.

Pour une analyse axée sur la confidentialité, un modèle utile consiste à collecter des événements agrégés côté client sans cookies ni identifiants intersites, puis à utiliser les journaux du serveur pour la surveillance de l'infrastructure avec une minimisation IP et une conservation courte. Cela donne aux équipes marketing des informations exploitables tout en gardant les équipes opérationnelles proches de la couche de demande brute.

L’écart entre l’analyse côté client et côté serveur n’est pas quelque chose à éliminer. Il faut bien comprendre que chaque ensemble de données est utilisé pour le bon travail.

Liste de contrôle de réconciliation

Attribuez chaque métrique à la source qui peut le mieux y répondre. Utilisez des analyses côté client pour le comportement des pages et les questions de campagne, des journaux côté serveur pour les questions d'infrastructure et de sécurité, ainsi que des événements backend pour les achats, les inscriptions et les actions du compte. Examinez l'écart entre les sources comme signal de qualité, puis documentez les raisons attendues : robots, scripts bloqués, refus de consentement, mise en cache, prérendu et requêtes échouées.

Questions fréquentes

Pourquoi les chiffres de l'analyse côté client et côté serveur ne correspondent-ils jamais exactement ?

L'analyse côté client et l'analyse côté serveur observent la même activité depuis des endroits différents. L'analyse côté client s'exécute dans le navigateur et dépend du déclenchement d'un script, tandis que l'analyse côté serveur part de journaux générés sur votre propre infrastructure. Un script bloqué, un consentement refusé ou un bot qui explore le site fait bouger l'un des chiffres sans toucher l'autre.

À quelle source d'analyse dois-je faire confiance comme source de vérité ?

À aucune des deux seule. Attribuez une source de vérité par métrique : l'analyse côté client pour les questions marketing et produit, les journaux serveur pour les questions opérationnelles et de sécurité, et les événements backend pour les achats, inscriptions et actions de compte. Vouloir faire correspondre les deux systèmes sur un total unique fait perdre l'intérêt de mesurer depuis deux endroits.

Les journaux serveur peuvent-ils remplacer entièrement l'analyse côté client ?

Pas pour le marketing ou le produit. Les journaux serveur sont solides pour le volume de requêtes, les taux d'erreur et l'activité des bots, mais ils manquent les événements propres au client, comme un clic sur un onglet de prix ou l'ouverture d'un accordéon, sauf si l'application les enregistre explicitement. Ils peinent aussi avec la navigation des applications à page unique lorsqu'elle ne déclenche aucune nouvelle requête serveur.

Pourquoi Safari bloque-t-il les scripts d'analyse ?

Le moteur WebKit de Safari traite la prévention du suivi comme une fonctionnalité centrale de la plateforme et bloque par défaut les cookies tiers dans les versions récentes de Safari. C'est l'une des raisons pour lesquelles l'analyse côté client sous-compte les visites par rapport aux journaux serveur.

Que fait la Total Cookie Protection de Firefox ?

La Total Cookie Protection isole les cookies par site, de sorte qu'un traceur ne peut pas suivre le même visiteur d'un domaine à l'autre. Cette isolation réduit la portée des traceurs côté client, ce qui explique en partie pourquoi les chiffres du navigateur restent en dessous du trafic brut du serveur.

Les journaux serveur comptent-ils les bots comme des visites ?

Les journaux serveur peuvent compter les bots comme des visites, sauf s'ils sont filtrés. Les robots de recherche, les crawlers et scrapers d'IA, les outils de supervision et les bots d'aperçu des réseaux sociaux génèrent tous des requêtes qui atterrissent dans les journaux serveur, ce qui fait que les chiffres bruts des journaux surestiment le trafic humain tant que l'activité des bots n'est pas exclue.

L'analyse côté serveur est-elle automatiquement plus respectueuse de la vie privée que l'analyse côté client ?

Non. Un journal serveur contenant des adresses IP complètes, des user agents et des URL comportant des données personnelles, conservé longtemps, peut être plus sensible qu'un événement minimal côté client. La confidentialité dépend de ce qui est collecté et de la durée de conservation, pas du côté de la requête où les données sont générées.

Ai-je besoin d'un consentement pour les cookies d'analyse selon les règles britanniques ou européennes ?

Dans la plupart des cas, oui. L'ICO britannique considère les cookies d'analyse comme non essentiels et exige que les utilisateurs gardent le contrôle sur les cookies non essentiels et les technologies similaires, puisque les obligations de consentement s'appliquent aux technologies qui stockent ou accèdent à des informations sur un appareil, sauf si elles sont strictement nécessaires.

Comment réduire l'écart entre les chiffres côté client et côté serveur ?

Définissez un contrat de mesure plutôt que de chercher une correspondance exacte. Excluez le trafic de bots connu des rapports destinés aux humains, filtrez les ressources statiques des rapports côté serveur, gardez des définitions de page vue cohérentes entre les outils, et utilisez les paramètres UTM de la même façon dans les deux systèmes. Comparez les tendances dans le temps plutôt que les chiffres absolus.

Que faut-il vérifier si les inscriptions baissent après une mise en production ?

Regardez les deux sources de données plutôt que d'en choisir une seule. L'analyse côté client peut montrer si moins d'utilisateurs ont seulement atteint le formulaire d'inscription, tandis que les journaux serveur peuvent montrer si le point de terminaison de soumission a commencé à renvoyer des erreurs après le déploiement.