Le suivi de la frustration met en évidence trois interactions à fort signal qui trahissent presque toujours un problème d'UX : les rage clicks, les dead clicks et les error clicks. Utilisez-le comme raccourci de triage vers les pages et les éléments qui bloquent ou perturbent vos visiteurs réels.
Ce qui est suivi
Trois schémas de clic sont capturés automatiquement dès que le feature flag est activé.
| Type | Définition |
|---|---|
| Rage click | 3 clics ou plus en moins de 600 ms sur le même élément ou dans une zone de 30×30 px. L'utilisateur appuie sur quelque chose qui paraît cliquable mais qui ne réagit pas. |
| Dead click | Un clic sur un élément non interactif sans aucune modification du DOM en une seconde. Ça ressemble à un bouton, ce n'en est pas un. |
| Error click | Un clic qui a déclenché une erreur JavaScript dans les 100 ms qui suivent. Le clic a cassé quelque chose. |
Ces trois types de clics constituent la série complète que le tracker capture aujourd'hui. Il n'y a pas de configuration supplémentaire : lorsque le feature flag est activé, le tracker surveille automatiquement tous les trois.
Garanties de confidentialité
Les événements de frustration ne stockent que des signaux de diagnostic sur l'élément cliqué — jamais le contenu de la page autour.
Ce qui est capturé :
- Le sélecteur CSS de l'élément et un court chemin DOM (par ex.
main > section > button.checkout-confirm) - Le label ou texte visible de l'élément, plafonné à 100 caractères (par ex. le mot « Valider » sur un bouton)
- Le rôle ARIA et l'aria-label de l'élément, s'ils sont présents
- Le style
cursorcalculé de l'élément (utilisé pour signaler les incohérences « semble cliquable mais ne l'est pas ») - Les coordonnées de clic relatives au viewport
- L'URL et le titre de la page
- Le type de frustration et l'horodatage
- Les ID de session et de visiteur déjà utilisés par le reste de votre analytique
Ce qui n'est pas capturé : les valeurs de formulaire, le contenu de fichiers, le contenu des autres éléments de la page ou toute autre donnée personnelle. Toutes les chaînes sont bornées par défaut. Si un visiteur a activé Global Privacy Control, le suivi de la frustration est ignoré — comme le reste du traitement comportemental.
Activation pour un site
- Ouvrez Paramètres → Avancé pour le site à suivre.
- Faites défiler jusqu'à Feature Flags et activez Frustration Tracking.
- Rechargez une page du site pour que le tracker prenne en compte le nouveau flag (il se rafraîchit automatiquement en ~5 minutes).
L'option est réservée au plan Pro et au-delà.
Où le consulter
Ouvrez l'onglet Errors du tableau de bord, puis basculez sur le sous-onglet Frustration.
Trois panneaux apparaissent :
- Spotlight — une carte mise en avant en haut qui sélectionne automatiquement l'incident avec la priorité la plus élevée, en fonction du nombre d'événements, du nombre d'utilisateurs uniques touchés, de la récence et du fait qu'il soit apparu après votre dernier déploiement. La carte ouvre sur une phrase Ce qui s'est passé en langage clair (« Un visiteur a cliqué sur l'élément intitulé 'Valider' sur /checkout, mais rien ne s'est produit »), une cause probable, un bouton Copier le sélecteur en un clic, un extrait Reproduire dans les DevTools prêt à être collé, et un bouton Copier pour le ticket qui regroupe tout pour le passer à un développeur.
- Tendance de frustration — trois cartes sparkline (Rage / Dead / Error), une par type, avec le nombre d'événements sur la plage choisie. Basculez vers un graphique linéaire combiné via le commutateur Cards / Lines en haut à droite.
- Top hotspots — une worklist triable où chaque ligne représente un seul élément cassé sur une seule page. Chaque ligne affiche le sélecteur, le chemin de la page, le label visible de l'élément et les compteurs par type. Cliquez sur une ligne pour la déplier : la même phrase en langage clair, copie du sélecteur, événements récents et (pour les error clicks) l'erreur JS associée en ligne. Les clics sur les conteneurs d'arrière-plan (clics ayant remonté à
<main>,<body>ou<html>depuis un espace vide) sont signalés par un badge Background discret, pour que vous puissiez les ignorer en un coup d'œil.
Vous pouvez filtrer par type (Rage / Dead / Error), préfixe d'URL et plage de temps (1h / 24h / 7j / 30j).
Lire le tableau de bord
Le tableau « Top hotspots » est votre worklist. Chaque ligne représente un seul élément cassé sur une seule page — triable par priorité.
La carte Spotlight et chaque ligne dépliée partagent la même mise en forme de triage :
- Une phrase Ce qui s'est passé en langage clair — lisible par toute personne de votre équipe, sans connaissance technique.
- Un diagnostic Cause probable ajusté au type de clic et aux signaux visibles de l'élément. Le tableau de bord lit le style
cursorde l'élément et son nom de tag pour identifier les cas évidents (« le CSS dit cliquable, mais le tag n'est pas un bouton — transformez-le en vrai<button>ou<a>», ou « état de chargement bloqué — le handler peut lever une exception silencieuse »), plutôt que de vous afficher une définition générique. - Un extrait Reproduire dans les DevTools — collez-le dans la console de la page et chaque élément correspondant reçoit un contour rouge et une ligne de log
[zenovay] match, ce qui permet de localiser l'élément cassé en un instant. - Un bouton Copier le sélecteur (pour le coller dans l'inspecteur d'éléments des DevTools) et un bouton Copier pour le ticket (pour transmettre tout le contexte — page, élément, type, compteurs, correction suggérée — en un seul collage à un développeur).
- Pour les error clicks : le message d'erreur JavaScript associé et un bouton Copier l'empreinte pour pivoter vers l'onglet Errors.
- Les derniers événements sur le même élément avec les coordonnées de viewport et les ID de session.
La carte Spotlight sélectionne automatiquement l'incident le plus prioritaire selon :
priority = (rage × 3 + dead × 1.5 + error × 5) × ln(unique_users + 1) × recency_boost
Le boost de récence est de 1.5× pour les 24 dernières heures. Les clics sur les conteneurs d'arrière-plan sont fortement déprioritisés, ils ne se retrouvent jamais en Spotlight. Si un hotspot est apparu après votre dernier déploiement GitHub, la ligne reçoit un badge NEW ambre — c'est presque toujours une régression.
Conseils de triage
- Commencez par le Spotlight. Lisez la phrase en langage clair, parcourez le diagnostic de cause probable, copiez l'extrait DevTools, collez-le dans la console de la page — l'élément cassé sera entouré.
- Transmettez en un seul collage à un développeur. Si vous êtes PM ou fondateur·trice et repérez un problème, le bouton Copier pour le ticket réunit page, élément, type de clic, compteurs et correction suggérée dans un seul message à coller dans Linear, Jira ou Slack.
- Surveillez le badge NEW. Les hotspots marqués comme nouveaux depuis votre dernier déploiement sont presque toujours des régressions à corriger en priorité.
- Associez rage et error. Des rage clicks sur le même sélecteur qu'un error click pointent vers une vraie exception — corrigez l'erreur JS et la rage disparaît généralement avec.
- Les dead clicks révèlent des attentes. Une page où de nombreux visiteurs cliquent en vain sur le même div vous dit ce qu'ils croyaient cliquable. Soit rendez-le interactif, soit retirez l'indice visuel (par ex.
cursor: pointer). - Ignorez les lignes Background. Les lignes étiquetées Background sont des clics tombés dans un espace vide qui ont remonté jusqu'à un conteneur ; elles indiquent très rarement un vrai bug.
Limites
- Les événements de frustration sont conservés pendant environ 90 jours, puis purgés automatiquement. Ce sont des signaux de triage, pas une archive permanente — enquêtez sur les hotspots pendant qu'ils sont encore frais.
- La capture est limitée côté tracker pour éviter des compteurs incontrôlés sur les pages cassées — vous voyez un échantillon représentatif, pas tous les clics.
- Les hotspots agrègent l'ensemble des données stockées ; le graphique respecte la plage choisie.