Replay UX Research

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

Entrées

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

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

Prérequis

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

search_events — Rechercher des replays de session
get_replay_details — Obtenir des informations détaillées sur le replay
search_issues — Rechercher des problèmes d'erreur
get_sentry_resource — Récupérer les détails des problèmes à partir des URL

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 modèles d'URL

Lisez references/product-areas.md et trouvez les modèles d'URL pour la zone demandée.

Si la zone produit n'est pas répertoriée, déduisez un modèle d'URL à partir du nom de la zone. La plupart des zones produit Sentry suivent le modèle /<area-name>/ dans le chemin d'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 ce n'est pas clair.

Étape 2 : Rechercher des replays

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

Commencez par les 24 dernières heures — étendez à 48h ou 7j 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 à itérer — il peut suggérer des modèles d'URL plus larges, une autre plage horaire, ou une zone produit connexe à inclure.

Construction des requêtes :

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 horaire : 24 dernières heures (étendez si nécessaire)
Modèle d'URL : faire correspondre les 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 de filtre projectSlug — les replays s'étendent sur l'ensemble de 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 lots parallèles pour la vitesse.

Pour chaque replay, capturez :

Utilisateur : domaine de courriel uniquement (l'API retourne les courriels complets — ne les incluez jamais dans la sortie)
Parcours : liste ordonnée des pages visitées (à partir des URL et des breadcrumbs d'activité)
Durée : longueur totale de la session
Type de replay : session (échantillon aléatoire de navigation normale) vs buffer (déclenché par un événement — erreur, vidage manuel, ou action utilisateur spécifique comme soumettre des commentaires ou passer par la caisse). Notez cette distinction dans votre analyse car les replays buffer sont biaisés vers les moments d'erreur/action, pas la navigation typique.
Contexte d'entrée : la première URL indique comment ils sont arrivés — cherchez les signaux de référent comme referrer=slack, notification_uuid, alert_rule_id dans les paramètres de requête (notification Slack), modèles de lien électronique, ou URL simples (signet/navigation directe)
Signaux d'engagement : nombre d'erreurs, rage clicks, dead clicks, nombre d'avertissements
Navigateur/OS/Appareil : pour le contexte de distribution des appareils
Breadcrumbs d'activité : vues de page, modèles de navigation, interactions clés

Étape 4 : Enquêter sur les erreurs significatives

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

Trier par fréquence : Si le même ID de problème (par ex., JAVASCRIPT-33RM) apparaît dans 3+ replays, cela vaut le coup d'être investigué.
Vérifier le problème dans Sentry : Utilisez search_issues pour trouver le problème, ou get_sentry_resource avec l'URL du problème à partir des détails du replay. Comprenez :
- Qu'est-ce que l'erreur ? (message, contexte de pile)
- Combien d'utilisateurs/événements totaux cela affecte-t-il ? (au-delà de cet exemple de replay)
- Est-ce assigné ou en cours de traitement ?
Déduire l'impact visible pour l'utilisateur à partir des signaux comportementaux : Nous ne pouvons pas voir le contenu de page rendu par les métadonnées de replay — uniquement en regardant le replay en navigateur. À la place, déduisez l'impact de ce que les utilisateurs ont fait après l'erreur :
- Ont réessayé la même action → ils ont probablement vu une défaillance et ont réessayé
- Ont navigué immédiatement → ils ont été bloqués ou ont abandonné
- Ont continué leur flux normalement → l'erreur peut être silencieuse/cosmétique
- Ont cliqué en rage ou dead-cliqué après → l'UI peut être devenue non-réactive
- Ont passé longtemps sur la page après → ils lisent peut-être un message d'erreur ou sont confus
- Aucun changement comportemental du tout → l'erreur était probablement invisible pour l'utilisateur
Classez chaque erreur en fonction de cette preuve :
- Probablement bloquante : Erreur + utilisateur a réessayé/est parti/n'a pas pu continuer. Confiance élevée en l'impact utilisateur.
- Probablement dégradante : Erreur + utilisateur a continué mais avec comportement inhabituel. Confiance modérée.
- Probablement silencieuse : Erreur déclenchée mais comportement utilisateur inaffecté. Confiance faible en l'impact utilisateur.
- Incertaine : Pas assez de signal comportemental pour juger. Marquer pour examen manuel du replay.
Notez toujours le niveau de confiance et recommandez de regarder des replays spécifiques pour confirmer. Créez un lien direct vers l'URL du replay pour chaque erreur classée.

Incluez cette classification dans la section Friction & Pain Points. Ne signalez pas les erreurs probablement silencieuses comme des pain points — répertoriez-les dans une sous-section « Background Errors (likely silent) » distincte pour la complétude.

Étape 5 : Analyser les modèles

Regardez les replays à travers ces lentilles de recherche UX :

Modèles comportementaux

Parcours courants : Quels chemins de navigation les utilisateurs empruntent-ils ? Quel est le flux typique ?
Points d'entrée : Comment les utilisateurs arrivent-ils ? Catégorisez : notification d'alerte (Slack/courrier), signet direct, navigation organique à partir d'une autre page. Les paramètres de requête de la première URL révèlent cela.
Accomplissement des tâches : L'utilisateur semble-t-il avoir atteint un objectif, ou a-t-il erré/abandonné ? Signes d'accomplissement : navigation vers une vue détail puis départ. Signes d'abandon : session courte, navigation alterne, départ de la même page d'entrée.
Temps sur tâche : Combien de temps les utilisateurs passent-ils sur les pages clés avant d'agir ?

Friction et découverte

Signaux de friction : Rage clicks, dead clicks, erreurs — mais aussi hésitation (visite répétée de la même page), thrashing (alterne rapide entre les pages), et boucles de retry (répétition de la même séquence d'action).
Découverte de fonctionnalité : Les utilisateurs trouvent-ils des sous-fonctionnalités (filtres, recherche, tri, actions en masse) ou utilisent-ils uniquement la vue principale ? Regardez les paramètres de requête d'URL et les breadcrumbs pour preuve d'utilisation de fonctionnalité.
Signaux d'intention utilisateur : Exploitez les paramètres de requête d'URL pour les termes de recherche, valeurs de filtre, ordres de tri et plages de dates définis par les utilisateurs. Ce sont les choses les plus proches de « citations » mot pour mot de l'utilisateur — elles révèlent ce que les utilisateurs recherchent avec leurs propres mots. (par ex., query=is%3Aunresolved+assigned%3Ame vous dit que l'utilisateur trie ses propres problèmes assignés.)
Contournements : Des modèles de navigation inattendus qui suggèrent une fonctionnalité manquante ou un flux déroutant ? (par ex., aller aux paramètres au milieu d'une tâche, ouvrir plusieurs pages en séquence qui pourraient être une vue)
Récupération d'erreur : Quand les utilisateurs rencontrent des erreurs, se rétablissent-ils et continuent-ils ou abandonnent-ils ?

Contexte

Mélange de déclenchements de replay : Quelle proportion sont session (échantillon aléatoire) vs buffer (déclenchées par événement) ? Les replays buffer montrent les moments où quelque chose de notable s'est produit (erreur, soumission de commentaires, caisse, etc.) — ils sont précieux pour l'analyse de friction mais ne sont pas représentatifs de la navigation typique. Signalez ce biais lors de la formulation de conclusions.
Visiteurs récurrents : Y a-t-il des domaines de courrier qui apparaissent dans plusieurs replays ? Les visiteurs récurrents suggèrent une utilisation habituelle — leurs parcours peuvent révéler des modèles de power-user ou des pain points persistants qu'ils ont appris à contourner.
Diversité des utilisateurs : Les replays proviennent-ils de nombreuses organisations/entreprises différentes ou sont-ils concentrés ? Y a-t-il des différences de comportement par organisation ?
Distribution navigateur/appareil : Qu'utilisent principalement les utilisateurs ?
Points d'abandon : Où les utilisateurs partent-ils ou navigent-ils ?

Étape 6 : Rédiger le rapport

Utilisez le modèle dans references/output-template.md. Soyez spécifique — citez des replays individuels comme preuve pour chaque modèle. Créez un lien vers les URL de replay afin que le lecteur puisse regarder le replay lui-même.

Confidentialité : Ne jamais inclure les adresses de courrier électronique complètes des utilisateurs dans le rapport. Utilisez des identifiants anonymisés comme « utilisateur du domaine [company domain] » ou « Utilisateur A, B, C ».