Ce qui distingue vraiment rage clicks vs dead clicks

Quelle est la différence entre rage clicks et dead clicks ?

La différence rage clicks vs dead clicks est une différence de cause : un rage click enregistre un utilisateur qui répète une action, et un dead click enregistre un clic unique auquel la page n'a jamais répondu. L'un est comportemental, l'autre est structurel. Ils se recoupent en permanence, raison pour laquelle les outils les listent côte à côte, mais le correctif diffère pour chacun.

Un rage click te dit qu'une personne a continué d'essayer. Ça arrive quand la cible est lente, quand la réponse est invisible, et aussi quand l'interface invite légitimement à cliquer plusieurs fois. Un dead click te dit qu'un élément a reçu un clic et n'a produit aucun changement. Ça arrive quand l'élément n'est pas branché, quand un handler a levé une exception, et aussi quand le changement était réel mais que le détecteur ne pouvait pas le voir.

Quels seuils chaque éditeur publie-t-il ?

Deux des cinq publient des chiffres. Trois décrivent le comportement en prose et s'arrêtent là.

Éditeur	Règle rage click	Règle dead click
PostHog	$rageclick se déclenche sur "three clicks that are each within 30 pixels and 1 second of the previous one". Configurable via click_count: 3, threshold_px: 30, timeout_ms: 1000	$dead_click est "a click which isn't followed by a change to the page". Aucune fenêtre chiffrée publiée
Hotjar	"when a user clicks on the same element five times within 500ms of one another"	Le filtre dead click trouve les sessions où les utilisateurs "clicked on a button, link, or a specific element of your site but didn't get any reaction". Aucun chiffre
FullStory	"clicking or tapping multiple times, rapidly, in the same area". Aucun chiffre	"If nothing on the page changes within a few seconds of a click or tap, it will get marked as a Dead Click". Aucun chiffre
LogRocket	"a series of rapid, repeated clicks on the same element". Aucun chiffre	"a click that did not result in a DOM change". Aucun chiffre
Microsoft Clarity	"the user clicks multiple times in a clustered area in rapid succession". Aucun chiffre	"a user clicks on an element but gets no feedback in a reasonable amount of time... the visual status doesn't change, and there's no navigation away from the page". Aucun chiffre

Les deux règles publiées ne s'accordent pas, et elles ne sont même pas proches. PostHog a besoin de trois clics dans une fenêtre d'une seconde et laisse le pointeur vagabonder de 30 pixels entre eux. Hotjar a besoin de cinq clics dans 500 millisecondes et les exige sur le même élément. Un utilisateur qui clique trois fois en 800 millisecondes enrage dans PostHog et reste invisible dans Hotjar. Un utilisateur qui clique cinq fois en quatre secondes sur un bouton n'enrage dans aucun des deux.

Ça compte plus que les chiffres eux-mêmes. Les comptes de rage clicks ne sont pas comparables d'un outil à l'autre, et une migration d'un éditeur à l'autre change le chiffre sans que rien ne change sur ton site.

Qu'est-ce qui compte comme changement de page pour un dead click ?

Aucun éditeur ne s'engage publiquement sur une réponse, ce qui est le point le plus faible de tout le signal.

LogRocket est le plus précis, et il s'agit encore d'une catégorie plutôt que d'un seuil : un dead click est "a click that did not result in a DOM change". Clarity ajoute deux conditions en prose, que le statut visuel ne change pas et qu'il n'y a pas de navigation hors de la page, sans dire combien de temps il attend. FullStory dit "within a few seconds". PostHog dit seulement "a change to the page".

Tout ce qui est ambigu tombe dans cet écart :

• Un clic qui déclenche une requête réseau dont la réponse arrive après la fenêtre de détection.
• Un clic qui modifie un canvas, une scène WebGL ou un élément vidéo, dont aucun ne mute le DOM.
• Un clic qui ouvre une boîte de dialogue native, déclenche un téléchargement, ou copie dans le presse-papiers.
• Un clic qui bascule une classe CSS sans effet visible au breakpoint courant.

Chacun de ces cas produit un dead click dans au moins un outil et rien dans un autre. Traite un compte brut de dead clicks comme un index de recherche sur les sessions plutôt que comme un compte de défauts, et confirme chaque cluster contre le replay avant qu'il ne devienne un ticket. Le workflow pratique est celui décrit dans l'analyse des dead clicks.

Pourquoi les rage clicks se déclenchent-ils sur des interfaces qui fonctionnent ?

Parce que le détecteur mesure la cadence, pas l'intention, et que beaucoup d'interfaces correctes demandent des clics répétés et rapides.

FullStory énonce le problème dans sa propre documentation, sous le titre "Why don't Rage Clicks work for me?" : certains composants d'interface, comme les boutons Suivant et Précédent, invitent naturellement à des clics répétés, ce qui fait sauter l'heuristique alors même que le comportement est voulu. PostHog arrive à la même conclusion et livre des réglages par défaut pour compenser. Avec defaults: '2026-05-30' ou une version ultérieure, PostHog ignore automatiquement les contrôles de navigation dont le texte est du type next, previous, > et <, les incrémenteurs de quantité marqués + et -, et les clics répétés sur des surfaces de sélection de texte comme les inputs, les textareas et les éléments contenteditable, puisque un triple clic pour sélectionner une ligne n'est pas de la rage.

Les deux éditeurs livrent une porte de sortie dans le markup :

Éditeur	Supprimer les rage clicks	Supprimer les dead clicks
PostHog	Classe .ph-no-rageclick, ou rageclick.css_selector_ignorelist	Classe .ph-no-deadclick, ou capture_dead_clicks.css_selector_ignorelist
FullStory	Classe fs-ignore-rage-clicks, ou réglages du compte	Classe fs-ignore-dead-clicks, ou réglages du compte

FullStory ajoute un détail qui mérite d'être anticipé : la suppression ne s'applique qu'aux nouvelles sessions, et les sessions existantes ne sont pas reclassées rétroactivement.

La documentation de PostHog boucle la boucle avec la bonne instruction : confirme les rage clicks contre les session replays avant de les traiter comme un signal de frustration ferme. C'est la même discipline sur laquelle repose l'analyse des rage clicks.

Quelles causes se cachent derrière chaque signal ?

Les deux signaux pointent vers des parties différentes de la stack, ce qui est la raison de les garder séparés plutôt que de les fusionner en un compte unique de frustration.

Les rage clicks viennent de :

• La latence. Le handler fonctionne, la réponse prend deux secondes, l'utilisateur reclique.
• L'absence de retour. Le handler fonctionne instantanément, rien de visible ne le confirme, l'utilisateur reclique.
• La soumission bloquée. La validation côté client échoue en silence et le bouton paraît inerte.
• La répétition légitime. Pagination, incrémenteurs, carrousels, sélection de texte.

Les dead clicks viennent de :

• Les éléments non branchés. Du texte, des icônes et des images stylées pour paraître interactives sans aucun handler.
• Les erreurs de handler. Une exception JavaScript avant le changement d'état. FullStory suit ça séparément sous le nom d'Error Clicks, qui font remonter un clic immédiatement suivi d'une erreur JavaScript ou console côté client.
• Les angles morts de détection. Canvas, vidéo, téléchargements, nouveaux onglets, boîtes de dialogue natives.

Un cluster qui montre les deux signaux sur le même sélecteur est le meilleur dossier que tu obtiendras : l'élément a l'air cliquable, ne fait rien, et les utilisateurs continuent d'essayer. Un cluster de dead clicks sans rage clicks veut généralement dire que l'élément a l'air cliquable pour une machine et pas pour une personne, ce qui est une priorité plus basse.

Comment lire un cluster de clics

Rage clicks et dead clicks sur le même sélecteur

• L'élément paraît cliquable
• Il ne produit aucun changement
• Les utilisateurs continuent d'essayer
• Priorité la plus haute à examiner

Dead clicks seuls, sans rage clicks

• L'élément paraît cliquable pour une machine
• Il ne paraît pas cliquable pour une personne
• Priorité plus basse à examiner

Comment utiliser les deux ensemble ?

Classe par sessions affectées et par position dans l'entonnoir, puis regarde le replay avant d'écrire le ticket.

Aucun des deux comptes n'a de sens isolément. Cent rage clicks sur une flèche de carrousel sont un artefact de détecteur. Douze dead clicks sur un bouton de validation de commande sont un incident de revenu. La différence n'est pas le chiffre, c'est l'endroit où se trouve l'élément et le fait que la session s'en soit remise ensuite.

Un ordre des opérations qui marche :

1. Regroupe par sélecteur CSS ou par ID d'élément stable, jamais par coordonnées brutes.
2. Filtre sur les pages qui portent du poids de conversion.
3. Vérifie si les sessions contenant le cluster ont terminé l'étape.
4. Regarde trois replays du cluster. Confirme l'élément, l'attente et l'échec.
5. Ouvre le ticket seulement ensuite, avec le sélecteur, la page, le nombre de sessions et un lien de replay.

C'est la même logique de classement qui s'applique à tous les autres signaux de la famille des signaux de frustration, et c'est pourquoi le session replay se place sous les deux métriques plutôt qu'à côté d'elles. Les comptes trouvent les candidats. L'enregistrement décide.

Questions fréquentes

Quels éditeurs publient un seuil exact de rage click ?

PostHog et Hotjar. PostHog documente trois clics, chacun à moins de 30 pixels et 1 seconde du précédent, exposés via click_count, threshold_px et timeout_ms. Hotjar documente cinq clics sur le même élément à moins de 500 ms les uns des autres. FullStory, LogRocket et Microsoft Clarity ne publient aucun chiffre pour l'un ou l'autre signal.

Quelqu'un publie-t-il un seuil chiffré de dead click ?

Non. FullStory dit "within a few seconds", Clarity dit "a reasonable amount of time", LogRocket le définit comme un clic sans changement du DOM, et PostHog le définit comme un clic qui n'est pas suivi d'un changement de la page. Aucun des cinq n'énonce de valeur en millisecondes.

Les comptes de rage clicks sont-ils comparables entre outils ?

Non. Avec les réglages par défaut de PostHog, une rafale de trois clics en une seconde compte. Sous la règle de Hotjar, non, parce que Hotjar exige cinq clics en 500 ms sur un seul élément. Toute migration entre les deux change le compte sans aucun changement de comportement utilisateur.

Un clic peut-il être à la fois un rage click et un dead click ?

Oui, et cette combinaison est le cluster le plus rentable à enquêter. L'élément a reçu des clics répétés et n'a produit aucun changement de page, ce qui élimine d'un coup les deux explications habituelles de faux positif.

Comment empêcher un carrousel ou un incrémenteur de produire des rage clicks ?

Ajoute la classe d'exclusion de l'éditeur sur l'élément. PostHog utilise .ph-no-rageclick et accepte aussi rageclick.css_selector_ignorelist. FullStory utilise fs-ignore-rage-clicks. FullStory note que les exclusions s'appliquent aux sessions capturées après le changement, donc les sessions historiques gardent leur classification d'origine.

Un dead click veut-il toujours dire que quelque chose est cassé ?

Non. Les clics sur des éléments canvas, des lecteurs vidéo, des liens de téléchargement, des actions de presse-papiers et des boîtes de dialogue natives produisent tous des réponses réelles qu'un détecteur de mutation du DOM ne peut pas voir. Confirme le cluster dans un replay avant de le traiter comme un défaut.

Que capture le signal Error Click de FullStory ?

FullStory enregistre cela comme un signal distinct appelé Error Clicks, séparé des dead clicks. Il repère un clic survenu juste avant une erreur JavaScript ou console côté client, ce qui relie l'échec à une interaction précise plutôt qu'à une erreur générale de la page. Ce lien se rapproche davantage d'un rapport de bug qu'un dead click ne le pourra jamais, puisqu'un dead click indique seulement que le DOM n'a pas changé.

Quel est le flux de travail recommandé avant de transformer un cluster de clics en ticket ?

Regroupez d'abord par sélecteur CSS ou par identifiant d'élément stable, puis filtrez sur les pages qui pèsent dans la conversion. Vérifiez si les sessions du cluster ont terminé l'étape, puis regardez trois replays pour confirmer l'élément, l'attente et l'échec. C'est seulement après cela que vous ouvrez le ticket, avec le sélecteur, la page, le nombre de sessions et un lien vers le replay.

Qu'est-ce qui provoque un rage click en dehors d'une réponse lente ?

La latence est une cause, mais un rage click se déclenche aussi quand le gestionnaire répond instantanément sans qu'aucun signal visible ne confirme que quelque chose s'est passé. Il se déclenche aussi quand la validation côté client échoue silencieusement et que le bouton paraît simplement inerte, ou quand l'interface invite légitimement à des clics répétés, comme la pagination, les incrémenteurs, les carrousels ou la sélection de texte.

Pourquoi regrouper par sélecteur CSS compte-t-il plus que par coordonnées brutes ?

Le déroulé pratique commence par regrouper les clics par sélecteur CSS ou par identifiant d'élément stable, jamais par coordonnées brutes. Les coordonnées brutes décrivent un point sur l'écran, pas l'élément avec lequel une personne a interagi, donc regrouper par ce biais disperse les clics d'un même bouton dans des groupes différents. Regrouper par sélecteur est ce qui permet de classer les clusters par sessions touchées et par position dans le tunnel.