Utilisez l’analyse des clics morts pour trouver les affordances cassées

En analytics produit, l'analyse des clics morts pour trouver les vrais problèmes consiste à repérer les clics sans effet visible et à décider lesquels comptent.

Un clic mort se produit lorsqu'un utilisateur clique sur quelque chose et que rien ne répond. Aucune navigation, aucun changement d'état, aucun appel réseau, aucun retour d'aucune sorte. L'élément semblait cliquable, l'utilisateur l'a donc essayé, et l'interface n'a rien fait.

La plupart des outils détectent les clics morts avec une règle simple : un clic atterrit sur un élément et aucun changement mesurable ne suit dans une courte fenêtre. Le signal est peu coûteux à calculer et souvent utile. Il est aussi bruyant, car « rien n'a changé » et « rien n'a changé que nous ayons pu observer » ne sont pas la même chose.

Pourquoi les clics morts comptent

Un clic mort est le symptôme de l'une de quelques causes sous-jacentes.

• Une affordance cassée, où un texte, une icône ou une carte semble cliquable mais n'a jamais été relié à quoi que ce soit.
• Un écart de latence, où un gestionnaire existe mais la réponse est assez lente pour que le clic paraisse mort.
• Une erreur JavaScript, où une exception a arrêté le gestionnaire avant qu'il ne puisse s'exécuter.
• Une cible masquée ou désactivée, où une surcouche, un état obsolète ou un chargement échoué a bloqué le vrai contrôle.

Chacune de ces causes érode la confiance dans l'interface. Lorsqu'un utilisateur clique et n'obtient aucune réponse, l'hypothèse la plus prudente qu'il fait est que le produit est cassé, et beaucoup d'entre eux partent.

Commencez par ce qui aurait dû se produire

La question la plus utile est de savoir ce que l'interface était censée faire après le clic.

• Un élément qui n'a jamais été interactif suggère une affordance trompeuse ou un problème de conception.
• Un gestionnaire qui existe mais a échoué suggère une erreur de script ou une requête bloquée.
• Une réponse qui a fini par arriver suggère de la latence plutôt qu'une véritable impasse.
• Un contrôle correctement inerte, comme un texte de corps sur lequel un utilisateur a cliqué par accident, ne suggère aucun problème.

Replay fournit l'état environnant. Les erreurs de console et la télémétrie réseau peuvent fournir une cause. Les données d'entonnoir et d'objectif montrent si le clic mort a modifié le résultat.

Un classement utile

Gestionnaire manquant

L'élément semble cliquable mais n'a jamais été relié à un comportement. Un div stylisé, une icône décorative ou un libellé qui ressemble à un lien. Il s'agit d'un problème de conception ou de balisage.

Échec silencieux

Un gestionnaire existe mais a levé une erreur ou touché une requête ayant échoué, de sorte que le clic n'a rien produit de visible pour l'utilisateur. Le contexte de la console et du réseau révèle la cause.

Latence prise pour un clic mort

Le clic a fonctionné, mais la réponse était assez lente pour que l'utilisateur ne perçoive aucun résultat. Un retour de chargement ou un état optimiste résout le comportement sans changer la logique.

Cible bloquée

Une surcouche, un reste de modale, un composant obsolète ou une page partiellement chargée a masqué le contrôle visé. L'utilisateur a cliqué au bon endroit, mais le clic n'a jamais atteint sa cible.

Raté inoffensif

L'utilisateur a cliqué par accident sur un contenu non interactif, comme un espace vide, une image ou un paragraphe. Rien n'était censé se produire. Excluez ou minimisez ces surfaces.

Regroupez avant de prioriser

Un tableau de bord avec 1 200 événements de clics morts individuels n'est pas une liste de travail. Regroupez les signaux par itinéraire, élément, état de l'interface, version, périphérique et résultat observé.

Classez ensuite les clusters en utilisant :

• Utilisateurs et sessions concernés uniques.
• Changement par rapport à la ligne de base normale.
• Proximité d'un entonnoir ou d'un objectif.
• Abandon après le clic mort.
• Importance des revenus ou du compte.
• Nouvelle concentration après une version.
• Erreurs à l'appui, requêtes ayant échoué ou retards de performance.

Un petit cluster sur un élément de paiement qui ne mène nulle part mérite peut-être bien plus d'attention qu'un gros cluster sur un graphique décoratif de pied de page.

Clics morts et clics de rage

Les deux signaux sont liés mais décrivent des comportements différents, et les confondre conduit au mauvais correctif.

• Un clic mort est un clic unique qui ne produit aucun résultat. Il reflète souvent un utilisateur qui a essayé une fois puis a abandonné.
• Un clic de rage est une rafale rapide de clics au même endroit, reflétant un utilisateur qui a essayé à plusieurs reprises par frustration.

Ils apparaissent souvent ensemble. Une cible morte qu'un utilisateur déterminé martèle devient un cluster de clics de rage sur le même élément, tandis qu'un utilisateur résigné ne laisse qu'un clic mort. L'analyse des clics morts tend à capter les échecs silencieux que les clics de rage manquent, car tout le monde ne clique pas deux fois. Traitez les deux comme des entrées, et laissez la cause sous-jacente, et non le nombre de clics, guider la priorité.

Comment l'IA aide

La détection basée sur des règles trouve le candidat. L'IA peut inspecter le résultat visuel, confirmer si quelque chose a réellement changé, lire le contexte de la console et du réseau, comparer des enregistrements similaires et séparer les clusters qui partagent un sélecteur mais ont des causes différentes.

Elle ne devrait pas simplement étiqueter chaque clic mort « cassé ». Un résultat utile indique ce que l'utilisateur a tenté de cliquer, ce que le produit n'a pas fait, à quelle fréquence cela s'est produit, près de quel entonnoir ou objectif il se situe et où se trouvent les preuves de relecture.

Flowsery regroupe les clics morts en problèmes classés reliés aux entonnoirs et aux objectifs, de sorte que les clusters qui bloquent la conversion s'élèvent au-dessus des ratés inoffensifs au lieu de rester dans une liste plate.

Liste de contrôle d'enquête

Ouvrez trois à cinq enregistrements représentatifs du même cluster et demandez :

1. Le même élément et le même état sont-ils impliqués ?
2. L'élément était-il censé être interactif ?
3. Un gestionnaire s'est-il exécuté, et a-t-il levé une erreur ?
4. Une requête a-t-elle échoué ou est-elle arrivée trop lentement pour paraître réactive ?
5. La vraie cible était-elle masquée ou désactivée au moment du clic ?
6. L'utilisateur a-t-il récupéré, converti ou quitté ?
7. Le comportement est-il limité à un navigateur, un appareil, une variante de page ou une version ?

Ne créez un ticket que lorsque le cluster est cohérent. Incluez un horodatage de relecture directe, le nombre de personnes concernées, la répartition de l'environnement, la cause probable et le résultat attendu.

Prévenir la détection bruyante

Excluez les surfaces non interactives connues afin que les clics accidentels sur les images et le texte du corps n'inondent pas le rapport. Tenez compte de la latence en élargissant la fenêtre d'observation avant qu'un clic ne soit déclaré mort. Supprimez les signaux en double au cours d'une seule session. Conservez des lignes de base par itinéraire et par composant plutôt que d'appliquer un seuil à l'ensemble du produit.

Examinez les faux positifs chaque semaine pendant le déploiement. Une équipe qui rejette chaque jour le même élément décoratif devrait corriger la règle, et non continuer à former les gens à ignorer les alertes.

Questions fréquemment posées

Qu'est-ce qu'un clic mort exactement ?

Un clic sur un élément qui ne produit aucune réponse visible ou technique, comme aucune navigation, aucun changement d'état et aucune activité réseau. L'élément semblait généralement cliquable, c'est pourquoi l'utilisateur l'a essayé.

Quelles sont les causes des clics morts ?

Les causes courantes sont les gestionnaires de clic manquants, les affordances trompeuses, les erreurs JavaScript, les requêtes ayant échoué, les cibles masquées ou désactivées, et une latence assez grave pour que la réponse paraisse absente.

En quoi les clics morts diffèrent-ils des clics de rage ?

Un clic mort est un clic unique qui ne mène nulle part. Un clic de rage est une rafale rapide de clics motivée par la frustration. Les clics morts captent les utilisateurs qui abandonnent après un seul essai, ils révèlent donc des échecs silencieux que les clics de rage peuvent manquer.

Tous les clics morts valent-ils la peine d'être corrigés ?

Non. Beaucoup sont des clics inoffensifs sur du contenu non interactif. Priorisez les clusters qui se situent près d'un entonnoir ou d'un objectif, affectent de nombreux utilisateurs ou ont augmenté après une version.

Que doit contenir un ticket de clic mort ?

Incluez l'élément et l'état affectés, ce que l'utilisateur attendait et la cause probable comme un gestionnaire manquant ou une erreur de script. Ajoutez la fréquence, le segment concerné, la preuve de relecture directe et toute erreur de console ou requête ayant échoué à proximité.

Transformez les preuves de session en problèmes prioritaires avec Flowsery - commencez gratuitement et examinez les sessions importantes.

Comment regrouper les événements de clics morts avant de les prioriser ?

Regroupez les signaux par route, élément, état de l'interface, version, appareil et résultat observé, plutôt que d'examiner chaque événement un par un. Un tableau de bord avec des centaines d'événements individuels n'est pas une liste de tâches, mais des clusters regroupés le sont. Une fois regroupés, classez les clusters selon les utilisateurs affectés, la proximité du tunnel et l'abandon, plutôt que selon le nombre brut.

Quels facteurs déterminent quel cluster de clics morts corriger en premier ?

Classez les clusters selon les utilisateurs et sessions uniques affectés, l'écart par rapport à la référence, la proximité d'un tunnel ou d'un objectif et l'abandon après le clic. Pesez ensuite l'importance en revenu ou en compte, la nouvelle concentration après une version, et les erreurs ou ralentissements de performance qui l'accompagnent. Un petit cluster sur un élément de paiement peut peser plus lourd qu'un cluster bien plus grand sur un graphique décoratif de pied de page. La cause compte plus que le nombre de clics.

Comment les équipes peuvent-elles réduire les faux positifs dans la détection des clics morts ?

Excluez les surfaces non interactives connues pour que les clics accidentels sur les images et le texte n'encombrent pas le rapport. Élargissez la fenêtre d'observation avant de qualifier un clic de mort afin de tenir compte de la latence. Supprimez les signaux dupliqués au sein d'une même session et conservez des références par route et par composant plutôt qu'un seuil unique pour tout le produit. Passez en revue les faux positifs chaque semaine pendant le déploiement pour améliorer la règle de détection, plutôt que d'habituer les utilisateurs à ignorer les alertes.

Comment l'IA aide-t-elle à analyser les clusters de clics morts ?

L'IA peut inspecter le résultat visuel d'un clic, confirmer si quelque chose a réellement changé et lire le contexte de la console et du réseau. L'IA compare aussi des enregistrements similaires et sépare des clusters qui partagent un sélecteur mais ont des causes différentes. Elle ne devrait pas se contenter d'étiqueter chaque clic mort comme « cassé ». Flowsery regroupe les clics morts en tickets classés et liés aux tunnels et aux objectifs, afin que les clusters qui bloquent la conversion ressortent des ratés inoffensifs.

Que vérifier avant d'ouvrir un ticket pour un cluster de clics morts ?

Ouvrez trois à cinq enregistrements représentatifs du même cluster et vérifiez si le même élément et le même état sont concernés. Regardez si l'élément était censé être interactif, si un gestionnaire s'est exécuté ou a échoué, et si l'utilisateur s'est rattrapé, a converti ou est parti. Ne créez un ticket que lorsque le cluster est cohérent, et incluez un horodatage de relecture, le nombre affecté, la répartition par environnement, la cause probable et le résultat attendu.