Un guide pratique de analytique cote serveur

Ce guide explique analytique cote serveur de manière pratique, avec un accent sur les décisions d'analytics respectueuses de la vie privée.

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.