umami.track('scroll_75', { page: location.pathname }) — cette seule ligne, une fois l’instance auto-hébergée en place, remplace tout un tunnel de mesure habituellement confié à Google Analytics ou Plausible. Une coopérative éditoriale qui héberge déjà son propre Umami sur son infrastructure voulait savoir à quel point ses lecteurs descendaient dans ses longs articles, sans ajouter un second outil de mesure.
Le choix d’Umami plutôt que Plausible tenait à une contrainte simple : l’équipe voulait tout héberger elle-même, base de données comprise, sans dépendre d’un service cloud tiers même respectueux de la vie privée. Umami, écrit en Node.js avec une base PostgreSQL ou MySQL, correspond à ce cahier des charges — à condition de bien câbler l’événement de scroll depuis le bloc concerné.
Où placer la mesure : le bloc, pas le thème
Mesurer le scroll globalement, sur toutes les pages, donne des chiffres peu exploitables : un lecteur qui descend jusqu’en bas d’une page d’accueil courte n’a pas le même comportement qu’un lecteur qui abandonne à 20 % d’un article de fond. L’équipe a donc choisi de rattacher la mesure à un bloc spécifique, cooperative/article-long, inséré uniquement dans le gabarit des articles longs et exposant un viewScript dédié.
Le block.json du bloc déclare ce script au niveau du front uniquement :
{
"name": "cooperative/article-long",
"viewScript": "file:./view.js",
"supports": { "interactivity": false }
}Pas besoin de l’Interactivity API ici : le comportement est purement déclaratif au chargement de la page, un IntersectionObserver classique suffit et reste plus léger.
Calculer les seuils de scroll sans librairie
Le script observe la position du bloc dans la fenêtre et déclenche un événement Umami à chaque seuil franchi — 25, 50, 75 et 100 % — une seule fois par seuil et par visite, pour éviter de saturer les statistiques :
document.querySelectorAll('.wp-block-cooperative-article-long').forEach((bloc) => {
const seuils = [25, 50, 75, 100];
const franchis = new Set();
const hauteur = bloc.offsetHeight;
window.addEventListener('scroll', () => {
const rect = bloc.getBoundingClientRect();
const visible = Math.max(0, window.innerHeight - rect.top);
const pourcentage = Math.min(100, Math.round((visible / hauteur) * 100));
seuils.forEach((seuil) => {
if (pourcentage >= seuil && !franchis.has(seuil)) {
franchis.add(seuil);
if (window.umami) {
window.umami.track(`scroll_${seuil}`, { page: location.pathname });
}
}
});
}, { passive: true });
});Le test if (window.umami) évite une erreur JavaScript si le script de suivi n’a pas encore fini de se charger — ou s’il est bloqué par un bloqueur de contenu, ce qui reste rare pour un outil auto-hébergé mais pas impossible.
Pourquoi aucun cookie n’est nécessaire
Umami ne pose pas de cookie et ne génère pas d’identifiant persistant par visiteur : chaque session est recalculée à partir d’un hash journalier combinant l’adresse IP, le user-agent et un sel de configuration, sans jamais stocker cette valeur côté client. Le tracking de scroll décrit ici hérite donc de cette conformité par construction — aucune case à cocher supplémentaire à ajouter dans une politique de consentement, puisque aucune donnée identifiante n’est déposée dans le navigateur.
Un événement personnalisé Umami vaut ce que vaut son nom : mieux vaut un nom stable dès le départ,
scroll_75, que de le renommer trois mois plus tard et perdre la continuité des courbes.
Lire les résultats côté tableau de bord
Umami expose ces événements personnalisés dans l’onglet dédié de son interface, avec un comptage par nom d’événement et par période. Sur le premier mois de mesure, la coopérative a constaté que 61 % des lecteurs franchissaient le seuil de 50 %, mais seulement 19 % atteignaient 100 % — un chiffre qui a directement motivé une refonte de la mise en page des articles les plus longs, en insérant des intertitres supplémentaires.
Limites de cette approche
Ce dispositif mesure une profondeur de défilement, pas un temps de lecture réel : un visiteur peut faire défiler rapidement jusqu’en bas sans avoir lu une ligne. Umami ne propose pas non plus de segmentation avancée par défaut — pour croiser la profondeur de scroll avec la source de trafic, il faut exploiter l’API de requête d’Umami en dehors de son tableau de bord standard, ce qui dépasse le cadre d’un simple bloc de mesure.
En résumé
Brancher un événement Umami sur un bloc de défilement tient en quelques lignes de JavaScript vanille et un viewScript ciblé : pas de librairie de scroll-tracking, pas de cookie, pas de dépendance à un service cloud. Pour une équipe qui a déjà fait le choix d’auto-héberger ses statistiques, c’est la suite logique plutôt qu’un outil de mesure supplémentaire à intégrer.
