Analyse UX Research via Replay

Analysez les session replays d'utilisateurs externes réels de sentry.io pour identifier les patterns UX, les points de friction et les parcours représentatifs d'une zone produit donnée. Cela utilise l'organisation de dogfooding de Sentry.

Entrées

$ARGUMENTS est la zone produit à analyser (par ex. « issues », « traces », « dashboards », « replays », « monitors », « releases », « alerts »).

Si $ARGUMENTS est vide, demandez à l'utilisateur quelle zone produit analyser.

Prérequis

Cette skill nécessite que le serveur Sentry MCP soit connecté. Les outils suivants sont utilisés :

• search_events — Rechercher des session replays
• get_replay_details — Obtenir des informations détaillées sur un replay
• search_issues — Rechercher des issues d'erreur
• get_sentry_resource — Récupérer les détails des issues à partir d'URLs

Si ces outils ne sont pas disponibles, demandez à l'utilisateur de connecter le serveur Sentry MCP avant de continuer.

Étape 1 : Mapper la zone produit aux patterns d'URL

Consultez references/product-areas.md et trouvez les patterns d'URL pour la zone demandée.

Si la zone produit n'est pas listée, déduisez un pattern d'URL à partir du nom de la zone. La plupart des zones produit Sentry suivent le pattern /<area-name>/ dans le chemin URL. Le fichier de référence peut ne pas couvrir les zones produit plus récentes — confirmez votre hypothèse avec l'utilisateur si c'est peu clair.

Étape 2 : Rechercher les replays

Recherchez les replays d'utilisateurs externes (non-employés Sentry). 25 replays est un bon point de départ — allez plus loin si la zone produit est complexe, si les patterns initiaux sont ambigus ou si l'utilisateur veut une vue plus complète.

Commencez par les 24 dernières heures — étendez à 48h ou 7 jours si nécessaire pour atteindre votre cible. Exécutez plusieurs appels search_events si nécessaire. Utilisez limit: 50 par appel.

Si vous ne trouvez pas assez de replays (moins de 10 même sur 7 jours), dites à l'utilisateur ce que vous avez trouvé et demandez-lui de vous aider à affiner — ils peuvent suggérer des patterns d'URL plus larges, une plage de temps différente ou une zone produit connexe à inclure.

Construction de la requête :

Utilisez des requêtes en langage naturel comme :

replays from the last 24 hours where url contains "/<area-path>" excluding user emails ending in @sentry.io and @getsentry.com

Filtres clés :

• Plage de temps : 24 dernières heures (à étendre si nécessaire)
• Pattern d'URL : correspondre aux chemins de zone produit de l'Étape 1
• Exclure les employés : -user.email:*@sentry.io -user.email:*@getsentry.com
• Environnement : prod

Ne passez PAS un filtre projectSlug — les replays couvrent toute l'organisation.

Étape 3 : Obtenir les détails des replays

Appelez get_replay_details pour chaque replay trouvé à l'Étape 2. Exécutez ces appels par batches parallèles pour plus de rapidité.

Pour chaque replay, capturez :

• Utilisateur : domaine de l'email uniquement (l'API retourne les emails complets — ne jamais inclure ceux-ci dans la sortie)
• Parcours : liste ordonnée des pages visitées (à partir des URLs et des breadcrumbs d'activité)
• Durée : longueur totale de la session
• Type de replay : session (échantillonné aléatoirement à partir de la navigation normale) vs buffer (déclenché par un événement — erreur, flush manuel ou action utilisateur spécifique comme soumission de feedback ou passage en checkout). Notez cette distinction dans votre analyse car les buffer replays sont biaisés vers les moments d'erreur/action, non une navigation typique.
• Contexte d'entrée : la première URL vous indique comment ils sont arrivés — cherchez les signaux de referrer comme referrer=slack, notification_uuid, alert_rule_id dans les query params (notification Slack), patterns de lien email ou URLs simples (bookmark/navigation directe)
• Signaux d'engagement : nombre d'erreurs, rage clicks, dead clicks, nombre de warnings
• Navigateur/OS/Appareil : pour le contexte de distribution d'appareils
• Breadcrumbs d'activité : vues de page, patterns de navigation, interactions clés

Étape 4 : Enquêter sur les erreurs significatives

Après avoir collecté les détails des replays, identifiez les erreurs qui apparaissent dans plusieurs replays ou qui semblent susceptibles d'affecter l'expérience utilisateur. Pour chaque erreur significative :

1. Triez par fréquence : Si le même ID d'issue (par ex. JAVASCRIPT-33RM) apparaît dans 3+ replays, cela vaut la peine d'être enquêté.

2. Vérifiez l'issue dans Sentry : Utilisez search_issues pour trouver l'issue, ou get_sentry_resource avec l'URL de l'issue à partir des détails du replay. Comprenez :

   • Qu'est-ce que l'erreur ? (message, contexte de stack trace)
   • Combien d'utilisateurs/événements totaux cela affecte-t-il ? (au-delà de cet échantillon de replay)
   • Est-elle assignée ou en cours de traitement ?

3. Déduisez l'impact côté utilisateur à partir des signaux comportementaux : Nous ne pouvons pas voir le contenu de la page rendue via les métadonnées de replay — seulement en regardant le replay dans le navigateur. Déduisez plutôt l'impact à partir de ce que les utilisateurs ont fait après l'erreur :

   • Ont réessayé la même action → ils ont probablement vu un échec et ont réessayé
   • Ont navigué immédiatement ailleurs → ils étaient bloqués ou ont abandonné
   • Ont continué leur flux normalement → l'erreur est peut-être silencieuse/cosmétique
   • Ont rage-cliqué ou dead-cliqué après → l'UI a peut-être devenu non-réactif
   • Ont passé longtemps sur la page après → ils lisent peut-être un message d'erreur ou sont confus
   • Pas de changement comportemental du tout → l'erreur était probablement invisible pour l'utilisateur

4. Classifiez chaque erreur basé sur cette évidence :

   • Probablement bloquante : Erreur + utilisateur a réessayé/a quitté/n'a pas pu continuer. Confiance élevée d'impact utilisateur.
   • Probablement dégradante : Erreur + utilisateur a continué mais avec comportement inhabituel. Confiance modérée.
   • Probablement silencieuse : Erreur s'est produite mais le comportement utilisateur n'a pas été affecté. Confiance faible d'impact utilisateur.
   • Peu clair : Pas assez de signal comportemental pour juger. À signaler pour examen manuel du replay.

   Notez toujours le niveau de confiance et recommandez de regarder des replays spécifiques pour confirmer. Liez directement à l'URL du replay pour chaque erreur classifiée.

Incluez cette classification dans la section Friction et Points de Friction. Ne rapportez pas les erreurs probablement-silencieuses comme des points de friction — listez-les dans une section séparée « Erreurs de Fond (probablement silencieuses) » pour complétude.

Étape 5 : Analyser les patterns

Regardez les replays à travers ces lentilles de recherche UX :

Patterns comportementaux

1. Parcours communs : Quels chemins de navigation les utilisateurs prennent-ils ? Quel est le flux typique ?
2. Points d'entrée : Comment les utilisateurs arrivent-ils ? Catégorisez : notification d'alerte (Slack/email), bookmark direct, navigation organique depuis une autre page. Les query params de la première URL révèlent cela.
3. Accomplissement de tâche : L'utilisateur semble-t-il avoir accompli un objectif ou a-t-il erré/abandonné ? Signes d'accomplissement : navigation vers une vue de détail puis départ. Signes d'abandon : session courte, navigation d'avant en arrière, départ depuis la même page d'entrée.
4. Temps sur tâche : Combien de temps les utilisateurs passent-ils sur les pages clés avant d'agir ?

Friction et découverte

1. Signaux de friction : Rage clicks, dead clicks, erreurs — mais aussi hésitation (visite de la même page répétée), thrashing (rapide d'avant en arrière entre pages) et boucles de retry (répétition de la même séquence d'actions).
2. Découverte de fonctionnalité : Les utilisateurs trouvent-ils les sous-fonctionnalités (filtres, recherche, tri, actions en masse) ou utilisent-ils seulement la vue principale ? Regardez les query params d'URL et les breadcrumbs pour la preuve d'utilisation de fonctionnalités.
3. Signaux d'intention utilisateur : Explorez les query params d'URL pour les termes de recherche, valeurs de filtre, ordres de tri et plages de dates définis par les utilisateurs. Ceux-ci sont la chose la plus proche de « citations » verbatim utilisateur — ils révèlent ce que les utilisateurs cherchent dans leurs propres mots. (par ex. query=is%3Aunresolved+assigned%3Ame vous dit que l'utilisateur trie ses propres issues assignées.)
4. Contournements : Des patterns de navigation inattendus qui suggèrent une fonctionnalité manquante ou un flux confus ? (par ex. aller aux paramètres au milieu d'une tâche, ouvrir plusieurs pages en séquence qui pourraient être une seule vue)
5. Récupération d'erreur : Quand les utilisateurs rencontrent des erreurs, se rétablissent-ils et continuent ou abandonnent-ils ?

Contexte

1. Mélange de déclencheurs de replay : Quelle proportion sont session (échantillon aléatoire) vs buffer (event-triggered) ? Les replays buffer montrent les moments où quelque chose de notable s'est produit (erreur, soumission de feedback, checkout, etc.) — ils sont précieux pour l'analyse de friction mais ne sont pas représentatifs de la navigation typique. Mettez en évidence ce biais quand vous tirez des conclusions.
2. Visiteurs réguliers : Y a-t-il des domaines d'email qui apparaissent dans plusieurs replays ? Les visiteurs réguliers suggèrent une utilisation habituelle — leurs parcours peuvent révéler des patterns de power-user ou des points de friction persistants auxquels ils ont appris à contourner.
3. Diversité utilisateur : Les replays proviennent-ils de nombreuses orgs/compagnies différentes ou sont-ils concentrés ? Y a-t-il des différences de comportement par org ?
4. Distribution navigateur/appareil : Qu'utilisent principalement les utilisateurs ?
5. Points de départ : Où les utilisateurs se retirent ou naviguent-ils ailleurs ?

Étape 6 : Écrire le rapport

Utilisez le template dans references/output-template.md. Soyez spécifique — citez les replays individuels comme preuve pour chaque pattern. Liez aux URLs des replays afin que le lecteur puisse regarder le replay lui-même.

Confidentialité : N'incluez jamais les adresses email complètes des utilisateurs dans le rapport. Utilisez des identifiants anonymisés comme « utilisateur de [domaine d'entreprise] » ou « Utilisateur A, B, C ».