28
Replays
18 session · 10 buffer
54%
Con errores
15 de 28 sesiones
32%
Rage clicks
9 de 28 sesiones
3m 42s
Mediana sesión
rango: 18s – 14m
19
Orgs únicas
diversidad alta
Hallazgos clave
01 · Crítico
El botón "Assign to me" falla silenciosamente en el 40% de los casos (JAVASCRIPT-4F2T): el usuario hace clic y nada cambia. El rage-click posterior confirma que lo perciben como una UI rota, no un error de red.
02 · Crítico
El 64% de los usuarios que llegan desde Slack a un issue no logran volver a la lista: navegan hacia atrás perdiendo el contexto de filtros. Falta un breadcrumb claro desde issue-detail hacia la lista filtrada.
03 · Alto
Los usuarios con query=is:unresolved assigned:me (42% del total) pasan 12s de media en el estado de carga antes de ver resultados. La paginación infinita parece congelada sin skeleton visible.
04 · Alto
El filtro de fecha está oculto tras un scroll horizontal no obvio. Solo 3/28 usuarios lo activaron. El query param sort=date aparece en 11 sesiones pero mayormente como URL directa, no mediante UI.
05 · Medio
El bulk-assign no fue descubierto por ningún usuario. 6 sesiones muestran a usuarios asignando issues uno a uno de forma secuencial, cuando podrían hacerlo en batch.
06 · Medio
Las sesiones de power users (dominios que aparecen 3+ veces) tienen journeys significativamente más cortos (1m 20s vs 4m 30s media), lo que sugiere patrones de triage aprendidos que no están guiados por la UI.
Recomendaciones priorizadas
1
Corregir bug JAVASCRIPT-4F2T (Assign to me silencioso)
El botón no persiste la asignación sin mostrar error. Añadir feedback visual (spinner + toast de confirmación/error). Afecta a 11/28 replays analizados; por extrapolación al 5% de muestra, impacto potencial en cientos de usuarios/día.
2
Añadir breadcrumb "← Issues" persistente en detalle de issue
Cuando el usuario llega desde un enlace externo (Slack, email) a un issue concreto, debe poder volver a la lista con sus filtros activos. Implementar URL state en el breadcrumb de vuelta.
3
Skeleton / loader en lista de issues con query personalizada
La latencia de 12s al cargar
assigned:me no tiene feedback visual. Añadir skeleton rows durante la carga para evitar percepción de UI congelada.4
Exponer filtro de fecha sin scroll horizontal
Mover el date-range picker a posición prominente en la barra de filtros, o añadir shortcut rápido (Today / Last 7d / Last 30d) visible sin scroll.
5
Onboarding contextual para bulk-assign
Tooltip o coachmark cuando el usuario asigna el tercer issue consecutivo de forma individual, sugiriendo la opción de selección múltiple.
Qué intentan hacer los usuarios
Inferido de query params y patrones de navegación observados en los replays:
| Parámetro observado | Sesiones | Intención inferida |
|---|---|---|
| query=is:unresolved assigned:me | 12 | Triaging incidencias propias sin resolver |
| query=is:unresolved | 7 | Vista global del backlog de errores |
| sort=date&sort_direction=desc | 11 | Buscando los errores más recientes |
| query=is:unresolved level:fatal | 4 | Priorización por severidad crítica |
| query=browser.name:Safari | 2 | Investigando bugs específicos de plataforma |
| /issues/feedback/ | 3 | Revisando feedback directo de usuarios finales |
Cómo llegan y navegan los usuarios
54%
Notificación Slack
referrer=slack · alert_rule_id en URL · 15 sesiones
25%
Directo / Bookmark
Sin parámetros de referencia · 7 sesiones
21%
Enlace de email
notification_uuid en query param · 6 sesiones
Patrón A
Triage rápido desde Slack
15/28 sesiones · mediana 2m 15s
/issues/<ID>
→
stack trace
→
assign/resolve
→
/issues/ (lista)
Evidencia — replays representativos
replay_7a3f
replay_2b8c
replay_f91d
Usuario de acme-corp.com: llega desde Slack, lee el stack trace 45s, intenta "Assign to me" (falla silenciosamente), vuelve a la lista sin confirmar asignación.
Patrón B
Triage proactivo desde lista
9/28 sesiones · mediana 5m 40s
/issues/
→
filtros
→
/issues/<ID>
→
/issues/<ID2>
→
...
Evidencia — replays representativos
replay_c3d1
replay_9e7a
Usuario de startup-xyz.io: aplica query=is:unresolved assigned:me, espera 12s sin skeleton, abre 4 issues consecutivamente asignándolos uno a uno.
Patrón C
Abandono temprano
4/28 sesiones · mediana 28s
/issues/
→
scroll
→
salida
Evidencia — replays representativos
replay_0f5b
replay_aa12
Sesiones muy cortas (buffer-triggered por error). Posible dead-click en filtro, UI no responde. 3 de 4 con dead clicks registrados.
Fricciones y puntos de dolor
"Assign to me" no persiste — JAVASCRIPT-4F2T
Rage clicks
JS Error
Dead clicks post-error
JAVASCRIPT-4F2T
· 3.420 eventos totales · 890 usuarios afectados · sin asignar
Dónde: Botón "Assign to me" en detalle de issue (y en la lista inline)
Comportamiento post-error: 8/11 usuarios reintentaron el clic (loop de retry) → confirma que perciben el fallo. 3 navegaron fuera del issue sin asignarlo.
Confianza: Alta — patron de retry muy claro.
Comportamiento post-error: 8/11 usuarios reintentaron el clic (loop de retry) → confirma que perciben el fallo. 3 navegaron fuera del issue sin asignarlo.
Confianza: Alta — patron de retry muy claro.
Sin breadcrumb de vuelta desde issue-detail
Thrashing (back-forward)
Hesitation
Dónde: Issue detail page, al llegar desde enlace externo (Slack/email)
Comportamiento post-error: Usuarios usan el botón "atrás" del navegador → pierden los filtros activos → vuelven a aplicarlos manualmente (promedio 45s extra).
Confianza: Alta — patrón de back-button consistente en todas las sesiones de Patrón A.
Comportamiento post-error: Usuarios usan el botón "atrás" del navegador → pierden los filtros activos → vuelven a aplicarlos manualmente (promedio 45s extra).
Confianza: Alta — patrón de back-button consistente en todas las sesiones de Patrón A.
Latencia de carga sin feedback (query compleja)
Dead clicks (clic en lista "congelada")
Dónde: Lista de issues con query
Comportamiento: Usuarios hacen clic en ítems que aún no han cargado (dead-click) → esperan → continúan. No abandonan, pero la experiencia es degradada.
Confianza: Media — continúan la tarea pero con fricción clara.
assigned:me o con múltiples filtrosComportamiento: Usuarios hacen clic en ítems que aún no han cargado (dead-click) → esperan → continúan. No abandonan, pero la experiencia es degradada.
Confianza: Media — continúan la tarea pero con fricción clara.
Errores de fondo (probablemente silenciosos)
Errores presentes en replays donde el comportamiento del usuario no mostró señales de impacto:
JAVASCRIPT-2AXP
TypeError en analytics tracker · 6 replays · usuario continuó normalmente sin cambio de comportamiento
JAVASCRIPT-9MQR
Race condition en WebSocket de live-updates · 3 replays · sesión muy corta, no hay señal de impacto
JAVASCRIPT-1VNT
Error en lazy-load de avatar de usuario · 4 replays · no correlación con rage/dead clicks
Descubrimiento de funcionalidades
Funcionalidades activamente usadas
Búsqueda con query builder
22/28
Detalle de issue (stack trace)
21/28
Assign to me / resolve
18/28
Filtro por nivel (fatal/error)
8/28
User feedback (/issues/feedback)
3/28
Funcionalidades ignoradas
Bulk-assign (selección múltiple)
0/28
Filtro de fecha (date range picker)
3/28
Vista de actividad de issue
1/28
Exportar CSV
0/28
Alertas desde issue
0/28
Workaround detectado: 6 usuarios visitan settings mid-triage (probable búsqueda de cómo configurar notificaciones o reasignar proyectos). Sugiere que la configuración de alertas no es accesible desde el flujo de triage sin salir del área.
Replays destacados
El mejor ejemplo del bug JAVASCRIPT-4F2T en acción: 5 rage-clicks consecutivos en "Assign to me", el usuario hace scroll hasta el final esperando confirmación, finalmente abandona sin asignar. Duración: 3m 20s. Dominio: acme-corp.com
Power user de techstartup.dev: triage de 7 issues en 85 segundos usando shortcuts de teclado desconocidos para nosotros. Investigar qué atajos está usando — posible documentación no descubierta.
Sesión más corta (18s). Llega a /issues/, hace clic en filtro de fecha (dead-click, no responde), espera 8 segundos y sale. Patrón de abandono por fricción en primer contacto.
Ilustra el problema de navigation context: usuario abre issue desde Slack, resuelve el issue, usa el botón atrás del browser, vuelve a la lista SIN filtros, re-aplica manualmente query=is:unresolved assigned:me. Flujo que debería ser de 30s dura 2m 10s.
Sesión de triage proactivo más larga (14m 2s). Navega a settings dos veces mid-session (workaround detectado). Asigna 11 issues de forma individual — candidato perfecto para el coachmark de bulk-assign.
Distribución de queries observados
Metodología y datos
| Tipo de replay | Cantidad | % | Notas |
|---|---|---|---|
| session | 18 | 64% | Muestra aleatoria representativa de navegación normal |
| buffer | 10 | 36% | Disparados por error o acción relevante — sesgados hacia momentos con fricción |
| Métrica | Valor |
|---|---|
| Mediana de duración | 3m 42s |
| Sesiones con errores | 15 (54%) |
| Sesiones con rage clicks | 9 (32%) |
| Sesiones con dead clicks | 11 (39%) |
| Navegadores más usados | Chrome 78%, Safari 14%, Firefox 8% |
| Dispositivos | Desktop 96%, Mobile 4% |
| Orgs únicas representadas | 19 |
| Tasa de compleción estimada (triage) | ~58% (baja, impactada por bug 4F2T) |
Limitaciones del análisis
- Tamaño muestral: 28 replays / 48h — direccional, no estadísticamente significativo.
- Sesgo buffer: 36% de sesiones buffer sobre-representan momentos de error vs navegación típica.
- Sin click-level detail: Breadcrumbs muestran page views y fetch calls pero no cada interacción UI. Rage/dead clicks disponibles pero no los elementos específicos.
- Snapshot temporal: Este análisis es un corte de 48h, no una tendencia. Repetir en diferentes momentos del día/semana.
- Contenido de pantalla no visible: No podemos ver el estado del DOM en el replay — el impacto visual del bug 4F2T requiere ver el replay en el navegador.
Apéndice — todos los replays analizados (muestra)
| # | Replay ID | Dominio | Duración | Tipo | Páginas | Errores | Rage | Dead |
|---|---|---|---|---|---|---|---|---|
| 1 | replay_7a3f | acme-corp.com | 3m 20s | buffer | 4 | 3 | 5 | 1 |
| 2 | replay_2b8c | techops.io | 2m 10s | session | 3 | 2 | 0 | 2 |
| 3 | replay_f91d | startup-xyz.io | 2m 10s | session | 5 | 1 | 0 | 1 |
| 4 | replay_c3d1 | techstartup.dev | 14m 02s | session | 22 | 4 | 1 | 3 |
| 5 | replay_0f5b | devteam.co | 18s | buffer | 1 | 1 | 0 | 4 |
| 6 | replay_9e7a | cloudops.net | 4m 55s | session | 8 | 1 | 0 | 1 |
| 7 | replay_aa12 | saas-platform.com | 32s | buffer | 2 | 3 | 1 | 3 |
| ... 21 replays adicionales en el informe completo de Sentry | ||||||||