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. Quelqu'un peut rebondir immédiatement, laisser l'onglet ouvert ou faire 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 peut être erroné car 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.