Un guide pratique de suivi analytique cote serveur

Le suivi analytique côté serveur est utile lorsque l'événement se produit sur votre serveur ou lorsque le suivi client-side n'est pas fiable. Deux exemples courants sont le lectorat et les inscriptions de blogs. Un navigateur peut estimer la progression de l'article et la durée d'activité visible; le serveur peut vous indiquer si un compte a réellement été créé.

La meilleure configuration combine les deux sans collecter de données personnelles inutiles.

Mesurer la lecture réelle d'un blog

Une page vue est une mesure de contenu faible. Les lecteurs rebondissent immédiatement, laissent l'onglet ouvert ou font défiler vers le bas sans lire. Un meilleur événement « lecture » ​​combine :

• Temps d'activité minimum basé sur le nombre de mots.
• Profondeur de défilement dans le conteneur d'articles.
• État de visibilité donc les onglets d'arrière-plan ne comptent pas.
• Un événement unique pour que les actualisations ne dupliquent pas les lectures.

Par exemple, un article de 1 200 mots peut nécessiter au moins 5 minutes de temps actif à environ 220 à 250 mots par minute plus 80 % de défilement de l'article. Ne considérez pas ce chiffre comme universel. Les documents techniques, le contenu juridique et les articles de comparaison sont lus à des vitesses différentes.

Exemple d'événement côté client

const article = document.querySelector('[data-article]');
const words = Number(article?.dataset.words || 0);
const estimatedSeconds = Math.round((words / 230) * 60);
const minSeconds = Math.min(420, Math.max(30, estimatedSeconds * 0.6));
const maxCreditSeconds = Math.min(900, Math.max(90, estimatedSeconds * 1.5));
let activeSeconds = 0;
let articleVisible = false;
let reachedDepth = false;
let sent = false;
 
const deepMarker = document.createElement('span');
deepMarker.setAttribute('aria-hidden', 'true');
deepMarker.style.cssText = 'position:absolute;top:75%;gauche:0;largeur:1px;hauteur:1px;';
si (article) {
  article.style.position ||= 'relatif';
  article.appendChild(deepMarker);
}
 
fonction peut-êtreSendRead() {
  if (envoyé || !article || !reachedDepth || activeSeconds < minSeconds) return;
  envoyé = vrai;
  navigateur.sendBeacon('/analytics/article-read',
    JSON.stringify({
      slug : article.dataset.slug,
      wordCount : mots,
      activeSeconds,
    }));
}
 
const observateur = nouveau IntersectionObserver ((entrées) => {
    pour (entrée const des entrées) {
      if (entry.target === article) articleVisible = Entry.isIntersecting;
      if (entry.target === DeepMarker && Entry.isIntersecting) atteintDepth = true;
    }
    peut-êtreSendRead();
  },
  { seuil : 0 });
 
si (article) {
  observer.observer(article);
  observer.observer(deepMarker);
}
 
setInterval(() => {
  if (envoyé || !articleVisible || document.visibilityState !== 'visible') return;
  activeSeconds = Math.min(activeSeconds + 1, maxCreditSeconds);
  peut-êtreSendRead();
}, 1000);

Cela évite de compter un défilement rapide vers le bas comme une lecture. Il limite également le crédit de temps d'activité, fait une pause lorsque la page est masquée et utilise un marqueur de profondeur au niveau de l'article au lieu de mesurer la profondeur de défilement par rapport à l'ensemble du document.

Suivi des inscriptions côté serveur

Les inscriptions doivent être suivies une fois que le serveur a confirmé le succès, et non lorsque l'utilisateur clique sur Soumettre. Le formulaire côté client soumet un surdécompte, car la validation peut échouer, des demandes en double peuvent se produire et les robots peuvent déclencher des formulaires.

Un événement server-side doit inclure uniquement des champs sécurisés :

• Nom de l'événement : registration_completed.
• Horodatage.
• Visiteur anonyme ou référence de session si disponible et licite.
• Plan ou chemin d'inscription.
• source UTM capturée à l'atterrissage.
• Type de compte ou compartiment de taille d'espace de travail.

Évitez l'e-mail, le nom, l'adresse IP, l'utilisateur brut ID, l'état du mot de passe ou les champs de texte libre dans les analyses. Si vous devez connecter des événements à des comptes en interne, stockez ce mappage dans la base de données de votre produit, et non dans un événement d'analyse third-party.

Déduplication

Utilisez une clé d'idempotence pour les événements du serveur. Un événement d'inscription doit se déclencher une fois par création de compte, même si l'utilisateur actualise la page de réussite ou si un webhook réessaye.

await analytics.track({
  event: 'registration_completed',
  idempotencyKey: `registration:${account.id}`,
  properties: {
    plan: account.plan,
    source: attribution.source,
    campaign: attribution.campaign,
  },
});

Liste de contrôle de confidentialité

• Ne suivez pas la lecture sur les pages sensibles sauf si nécessaire.
• Gardez les événements d'article regroupés dans la mesure du possible.
• Supprimez les paramètres de requête avant de stocker les chemins.
• N'envoyez pas de données personnelles dans les propriétés de l'événement.
• Conservation des documents pour les événements bruts.
• Respecter les exigences de consentement pour le stockage ou les identifiants client-side.

Le suivi côté serveur n’est pas automatiquement respectueux de la vie privée. Il est préférable d'enregistrer les événements commerciaux vérifiés avec des charges utiles minimisées. Utilisez le navigateur pour les signaux que seul le navigateur peut connaître et utilisez le serveur pour les faits que seul le serveur peut confirmer.

Contrôles de la qualité des données

Comparez les événements de lecture d'articles avec les pages vues. Si chaque page vue devient une lecture, le seuil est trop bas ou l'événement se déclenche au chargement. Si presque aucune lecture n’apparaît pour les articles longs avec un fort engagement, le calcul du défilement est erroné : il utilise l’intégralité du document au lieu du conteneur d’articles.

Pour les inscriptions, rapprochez les événements d’analyse avec la base de données de l’application. Un décompte quotidien de registration_completed doit correspondre à la création de compte dans le comportement attendu de nouvelle tentative et de suppression. Si ce n'est pas le cas, corrigez l'événement du serveur avant de l'utiliser pour l'attribution marketing.

Consentement et transparence

Si le suivi utilise uniquement des événements agrégés et aucun stockage sur l'appareil, la charge en matière de confidentialité est moindre. Si vous définissez des identifiants, associez des événements de lecture à des comptes ou utilisez les données à des fins de personnalisation, mettez à jour les avis de consentement et de confidentialité en conséquence. Côté serveur ne signifie pas invisible; les utilisateurs méritent toujours une explication honnête.

Détails de fiabilité qui comptent

Lors de l'envoi d'événements de lecture depuis le navigateur, privilégiez les méthodes de livraison conçues pour les déchargements de pages. La balise API permet au navigateur d'envoyer une petite requête asynchrone sans bloquer la navigation, ce qui est utile pour les événements d'analyse qui se déclenchent vers la fin d'une visite (MDN Beacon API). Gardez les charges utiles petites et non sensibles, car les balises ne sont pas un endroit pour les gros objets de débogage.

Pour les événements d'inscription, concevez l'événement server-side comme une transaction financière :

• Lancez-le uniquement après la validation du compte ou de l'enregistrement d'enregistrement.
• Inclure une clé d'idempotence basée sur le dossier interne.
• Réessayez en toute sécurité si le point de terminaison d'analyse est temporairement indisponible.
• Stockez un court journal d'audit de l'état de livraison.
• Réconcilier les comptes avec la base de données produits.

Si l'attribution est importante, capturez les UTM au moment de l'atterrissage et stockez-les dans un enregistrement d'attribution first-party avec une période de conservation claire. Une fois l'inscription réussie, joignez des champs de campagne sécurisés tels que la source, le support, la campagne et la page de destination. Ne joignez pas l’historique de navigation complet du visiteur.

Pour l'analyse du temps de lecture, soyez prudent avec les onglets laissés ouverts. Comptez le temps d'affichage actif, faites une pause lorsque la page est masquée et envisagez une fenêtre de crédit maximale afin qu'un onglet de pause déjeuner ne devienne pas une « lecture de 40 minutes ». Pour les publications très courtes, utilisez un seuil minimum; pour les articles longs, évitez d'exiger un défilement à 100 %, car les lecteurs peuvent obtenir de la valeur avant la biographie finale de l'auteur ou la section de l'article connexe.

Le meilleur signal n’est pas seulement le « temps passé ». Il est temps de réaliser des progrès significatifs et une action de suivi telle que l'inscription à la newsletter, la visite d'une page produit ou l'inscription.

Lecture et inscription QA

Traitez la lecture de l'article comme un signal de qualité du contenu, et non comme une preuve qu'une personne identifiable a consommé chaque mot. Validez que :

• Un onglet en arrière-plan n'accumule pas de temps.
• Un défilement rapide ne déclenche pas de lecture.
• Les articles longs plafonnent le crédit de temps actif.
• L'événement se déclenche une fois par page vue.
• Les catégories d'articles sensibles utilisent uniquement des rapports agrégés.
• Les événements d'inscription correspondent aux comptes engagés, pas aux clics sur les boutons.

Gardez le signal du navigateur et le fait du serveur séparés. Le navigateur peut estimer une lecture significative. Le serveur peut confirmer l'inscription. Il est utile de les combiner soigneusement; prétendre que l’un ou l’autre est parfait crée des analyses bruyantes.

Questions fréquentes

Pourquoi une page vue sous-compte et sur-compte la lecture en même temps ?

Une page vue se déclenche dès le chargement de la page, elle compte donc un rebond, un onglet laissé ouvert et un défilement rapide jusqu'en bas de la même façon qu'une lecture réelle. La combiner avec un temps actif minimum, la profondeur de défilement et l'état de visibilité sépare la vraie lecture de ces cas. Un événement unique en plus empêche les rechargements de gonfler encore le compteur.

Quelle fourchette de mots par minute utiliser pour le seuil de temps actif ?

L'article utilise environ 220 à 250 mots par minute comme point de départ, ce qui place le temps actif minimum d'un article de 1 200 mots autour de 5 minutes. À traiter comme une base, pas comme un chiffre universel. La documentation technique, le contenu juridique et les articles comparatifs se lisent à des vitesses différentes, donc il faut recalibrer selon le type de contenu.

Pourquoi mesurer la profondeur de défilement par rapport au conteneur de l'article plutôt qu'au document entier ?

Mesurer par rapport au document entier fausse le chiffre dès que l'en-tête, le pied de page ou les articles liés changent la longueur de la page. L'exemple côté client ancre un marqueur de profondeur à 80 pour cent directement dans l'élément article avec un IntersectionObserver, de sorte que le calcul suit l'article et non la mise en page qui l'entoure. C'est aussi la correction à apporter quand presque aucune lecture n'apparaît pour des articles longs pourtant bien suivis.

Faut-il utiliser 100 pour cent de défilement comme seuil de lecture ?

Exiger un défilement complet sur les articles longs peut exclure des lecteurs qui ont déjà obtenu la valeur recherchée avant la bio de l'auteur ou le bloc d'articles liés en fin de page. L'exemple utilise plutôt 80 pour cent de profondeur de défilement. Sur du contenu long, éviter la barre des 100 pour cent garde la métrique plus proche de ce que "lire" signifie vraiment.

Comment empêcher un onglet en arrière-plan de gonfler le temps actif ?

Vérifier document.visibilityState avec un IntersectionObserver qui surveille si l'article est à l'écran. L'intervalle d'une seconde de l'exemple n'incrémente activeSeconds que lorsque l'article est visible et que l'état de visibilité de l'onglet est "visible", donc un onglet laissé en arrière-plan arrête aussitôt d'accumuler du temps.

Quelle limite fixer au crédit de temps actif pour les articles longs ?

L'article plafonne le temps actif crédité pour qu'un onglet laissé ouvert pendant une pause déjeuner ne devienne pas une lecture de 40 minutes. L'implémentation d'exemple borne activeSeconds avec Math.min contre un plafond maxCreditSeconds dérivé du temps de lecture estimé de l'article. Les articles longs gardent une fenêtre généreuse, simplement pas illimitée.

Pourquoi déclencher les événements d'inscription à la confirmation serveur plutôt qu'à l'envoi du formulaire ?

Les envois de formulaire côté client surcomptent parce que la validation peut échouer, des requêtes en double peuvent survenir, et des bots peuvent déclencher des formulaires sans rien créer. Un événement confirmé par le serveur ne se déclenche que lorsque le compte existe réellement, ce qui est justement ce que l'analytics est censé représenter. C'est pour ça que l'article traite l'événement comme une transaction financière, validée d'abord, suivie ensuite.

Quels champs sont sûrs pour un événement registration_completed ?

On s'en tient au nom de l'événement, à l'horodatage, à une référence anonyme de visiteur ou de session quand elle est disponible et licite, au plan ou au parcours d'inscription, à la source UTM capturée à l'atterrissage, et au type de compte ou à la tranche de taille du workspace. On laisse de côté l'email, le nom, l'adresse IP, l'ID utilisateur brut, le statut du mot de passe et les champs de texte libre. Pour relier des événements à des comptes en interne, la correspondance doit vivre dans la base de données produit, pas dans l'événement analytics.

Comment la clé d'idempotence empêche-t-elle les événements d'inscription en double ?

La clé est construite à partir de l'ID du compte lui-même, par exemple registration:${account.id}, ce qui permet à la plateforme analytics de reconnaître un envoi répété comme le même événement plutôt que comme un nouveau. Ça protège contre un utilisateur qui recharge la page de succès ou un webhook qui réessaie après un délai dépassé. L'événement ne se déclenche pourtant qu'une seule fois par compte créé, quel que soit le nombre de déclenchements du trigger.

Comment vérifier que le suivi des inscriptions est vraiment fiable ?

Rapprocher le nombre quotidien d'événements registration_completed de la création de comptes dans la base de données de l'application. Les deux chiffres devraient correspondre dans les limites du comportement attendu de nouvelles tentatives et de suppressions. En cas d'écart, corriger d'abord l'événement côté serveur avant d'utiliser les chiffres pour l'attribution marketing.