[🛠] Remettre de l’ordre dans le tableau de statistiques du blog

✨ Résumé de GPT-5.5 　

Retour sur la correction d’une page publique de statistiques où visites et vues se mélangeaient, en séparant les visites par sessions de 30 minutes des vues par ouverture de page dans un tableau lisible aussi sur mobile.

Juste après avoir créé la page publique de statistiques du blog, quelque chose me gênait déjà.

Les chiffres étaient là.

Mais leurs noms se mélangeaient trop facilement.

Visiteurs, visites, vues, sessions, page views. Sur l’écran d’un blog, ces mots se ressemblent. Dans le modèle de comptage, ils ne veulent pas dire la même chose. Si un compteur public brouille cette frontière, les chiffres deviennent difficiles à croire même s’ils s’affichent correctement.

Au début, des libellés comme « vues aujourd’hui », « vues ce mois-ci » et « vues totales » semblaient suffisants. Mais ce que je voulais dans la barre latérale était plus proche du nombre de visites du blog aujourd’hui que du nombre d’ouvertures d’articles.

J’ai donc séparé à nouveau le modèle.

Visites
-> sessions avec 30 minutes d'inactivité

Vues
-> nombre d'ouvertures de pages ou d'articles

4943 n’était pas un nombre de visites

La première chose à corriger était le sens du baseline.

La valeur 4943 importée depuis Google Analytics était screenPageViews. Autrement dit, des vues de page. L’afficher comme un total de visiteurs ou de visites aurait été faux.

J’ai donc corrigé le Worker et la documentation ensemble.

totalPageViews
-> GA screenPageViews baseline + D1 page views

totalSessions
-> GA sessions baseline + D1 sessions

Les visites et les vues ne peuvent pas reposer sur le même baseline. J’ai ajouté une route séparée pour initialiser le baseline des sessions.

/admin/seed-session-baseline

J’ai aussi ajouté cette étape au déploiement du Worker dans GitHub Actions. Si le Worker est déployé mais que le baseline reste vide, le total public des visites peut sembler cassé.

Utiliser immédiatement la réponse de /track

La première structure faisait un détour.

Le client envoyait /track pour compter, puis relisait /analytics pour remplir l’écran. Avec le cache et l’ordre des requêtes, la visite tout juste comptée pouvait ne pas apparaître tout de suite.

Désormais, /track renvoie aussi le payload analytics le plus récent.

Chargement de page
-> POST /track
-> le Worker met à jour session/vues
-> la même réponse contient les analytics frais
-> le client rend la barre latérale et la vue de la page courante

Les rafraîchissements périodiques continuent de lire /analytics.

Le premier affichage utilise la valeur fraîchement mise à jour. Ensuite, l’API de lecture maintient l’interface à jour.

Une session ne doit pas augmenter à chaque changement de page

Les vues peuvent augmenter lorsqu’un lecteur passe d’un article à un autre.

Les visites sont différentes. Si une personne lit trois articles dans la même session du blog, cela ne doit pas devenir trois visites. J’ai ajouté une table sessions au Worker et relié les sessions par visitor hash et dernier moment d’activité.

La limite est de 30 minutes.

Moins de 30 minutes depuis la dernière activité
-> même session

Plus de 30 minutes
-> nouvelle session

Ainsi les visites du jour/mois/total dans la barre latérale bougent moins que les page views. Les vues par article continuent d’utiliser le page path.

Les pages multilingues suivent la même règle.

/daily-review/.../ et /en/daily-review/.../ sont deux versions linguistiques du même article. La clé de vue utilise le canonical path, et changer de langue dans la même session ne crée pas une nouvelle visite.

Rendre le tableau plus proche d’une vraie table

La première page de statistiques reposait sur des cartes KPI et des listes à barres.

Ce n’était pas mauvais, mais dès que visites et vues sont apparues ensemble, la structure est devenue ambiguë. Plus de cartes allongeaient l’écran mobile, et il devenait difficile de lire quel chiffre était une visite et lequel était une vue pour chaque période.

J’ai donc transformé la zone de comparaison du haut en quelque chose de plus proche d’une table.

Période          Visites     Vues
Période choisie  n           n
Aujourd'hui      n           n
Ce mois-ci       n           n
Total            n           n

Le total avait aussi besoin de deux lignes.

Total
-> suivi direct depuis 2026/06/09

Total
-> inclut les statistiques avant 2026/06/09

Ces deux lignes n’ont pas le même sens.

Le suivi direct est la valeur soutenue par les dimensions D1 depuis le début de la collecte publique. Le total avec historique ajoute le baseline GA. Les mélanger sur une seule ligne rend le nombre plus gros, mais il ne correspond plus aux dimensions détaillées.

J’ai donc séparé aussi le texte d’explication.

Visites : exclut les retours dans les 30 min. Vues : ouvertures de page.
Le suivi direct commence le 2026/06/09.

Rendre la saisie de dates moins pénible

Sur une page de statistiques, on change souvent les dates.

Au début je pensais que range=today, range=month, range=total et range=custom suffisaient. Mais les périodes directes demandent de modifier début et fin encore et encore.

J’ai donc rendu les champs plus proches d’un petit outil.

format YYYY/MM/DD
date picker caché
sélection du segment année/mois/jour
ajustement avec ArrowUp / ArrowDown
ajustement avec la molette
clamp entre date de début et date de fin

Visuellement, ce sont toujours deux petits champs, mais changer les dates est devenu beaucoup moins pénible.

J’ai aussi arrêté de cacher les dates jusqu’au choix du mode custom. Les champs restent visibles, et les presets déplacent simplement les dates vers la bonne période.

C’est plus prévisible.

Séparer les dimensions détaillées en onglets

Afficher toutes les dimensions à la fois rendait la page confuse.

Pages, environnement visiteur, source de trafic, région et langue sont utiles, mais tout ouvrir sur un seul écran se lit mal. Je les ai regroupés en onglets.

Pages
Environnement visiteur
Trafic
Région/langue

Les paths peuvent être longs, donc les libellés ont reçu un title et le CSS a été ajusté pour que le retour à la ligne et la troncature ne cassent pas la mise en page. Les valeurs de page commençant par / sont devenues des liens.

Le but n’était pas de faire un dashboard spectaculaire.

Je voulais pouvoir l’ouvrir sur téléphone et voir vite quels articles étaient lus, combien de visites il y avait aujourd’hui, et combien de vues avaient été comptées.

Aligner aussi les libellés multilingues

La page de statistiques n’existe pas seulement en coréen.

Il y a aussi /en/analytics/, /ja/analytics/, /zh-Hans/analytics/ et les autres locales actives. Les libellés comme « visites », « vues », « sessions de 30 minutes » et « vues GA + D1 » devaient être ajustés dans le front matter de chaque locale.

Si on oublie cela, la structure change mais les anciennes phrases restent dans les autres langues.

Sur un blog multilingue, corriger un écran ne veut pas dire corriger une seule page. Le sens des libellés doit suivre.

Ce que j’ai vérifié

J’ai surtout vérifié le rendu et le sens des métriques.

node --check cloudflare/ga-stats-worker.js
node --check assets/js/custom/analytics-dashboard.js
node --check assets/js/custom/visitor-stats.js
bundle exec jekyll build
Cloudflare Worker deploy
GitHub Pages deploy

Les critères étaient les suivants.

La barre latérale affiche sessions comme visites
Les vues par article restent des page views
Visites totales et vues totales utilisent des baselines différentes
Le total direct et le total incluant GA sont séparés
La saisie de dates ne se heurte pas aux presets today/month/total
La table période/visites/vues ne déborde pas sur mobile

Après ce travail, la page de statistiques est devenue plus calme.

Il y a plus de chiffres, mais ils prêtent moins à confusion. Une visite est une visite, une vue est une vue. Un total reste un total, mais le total direct et le total avec historique ne sont pas la même chose.

L’important n’était pas de faire paraître les chiffres plus grands.

C’était de ne pas cacher ce que chaque chiffre signifie.