/replay-ux-research

name: replay-ux-research
description: Analyze Sentry session replays to surface UX patterns, pain points, and user journeys for a given product area. Use when asked to "show me how users use", "day in the life", "UX research", "replay research", "how do customers use", "what's the user experience like for", "watch replays of", "analyze replays for", "user behavior on", or "replay UX audit" for any Sentry product surface.
argument-hint: '<product-area>'

Replay UX Research

Analyze session replays from real external users of sentry.io to surface UX patterns, pain points, and representative journeys for a given product area. This uses Sentry's own dogfooding org.

Inputs

`$ARGUMENTS` is the product area to research (e.g., "issues", "traces", "dashboards", "replays", "monitors", "releases", "alerts").

If `$ARGUMENTS` is empty, ask the user which product area to research.

Prerequisites

This skill requires the Sentry MCP server to be connected. The following tools are used:

• `search_events` — Search for session replays
• `get_replay_details` — Get detailed replay information
• `search_issues` — Look up error issues
• `get_sentry_resource` — Fetch issue details from URLs

If these tools are not available, ask the user to connect the Sentry MCP server before proceeding.

Step 1: Map product area to URL patterns

Read `references/product-areas.md` and find the URL patterns for the requested area.

If the product area is not listed, infer a URL pattern from the area name. Most Sentry product areas follow the pattern `/<area-name>/` in the URL path. The reference file may not cover newer product areas — confirm your assumption with the user if unclear.

Step 2: Search for replays

Search for replays from external (non-Sentry-employee) users. 25 replays is a good starting point — go deeper if the product area is complex, if early patterns are ambiguous, or if the user wants a more comprehensive picture.

Start with last 24 hours — extend to 48h or 7d if needed to reach your target count. Run multiple `search_events` calls if needed. Use `limit: 50` per call.

**If you can't find enough replays** (fewer than 10 even at 7 days), tell the user what you found and ask them to help iterate — they may suggest broader URL patterns, a different time range, or a related product area to include.

**Query construction:**

Use natural language queries like:

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

Key filters:

• **Time range**: last 24 hours (extend if needed)
• **URL pattern**: match the product area paths from Step 1
• **Exclude employees**: `-user.email:*@sentry.io -user.email:*@getsentry.com`
• **Environment**: prod

Do NOT pass a `projectSlug` filter — replays span the whole org.

Step 3: Get replay details

Call `get_replay_details` for each replay found in Step 2. Run these calls in parallel batches for speed.

For each replay, capture:

• **User**: email domain only (the API returns full emails — never include these in output)
• **Journey**: ordered list of pages visited (from URLs and activity breadcrumbs)
• **Duration**: total session length
• **Replay type**: `session` (randomly sampled from normal browsing) vs `buffer` (triggered by an event — error, manual flush, or specific user action like submitting feedback or going through checkout). Note this distinction in your analysis since buffer replays are biased toward error/action moments, not typical browsing.
• **Entry context**: first URL tells you how they arrived — look for referrer signals like `referrer=slack`, `notification_uuid`, `alert_rule_id` in query params (Slack notification), email link patterns, or bare URLs (bookmark/direct nav)
• **Engagement signals**: error count, rage clicks, dead clicks, warning count
• **Browser/OS/Device**: for device distribution context
• **Activity breadcrumbs**: page views, navigation patterns, key interactions

Step 4: Investigate significant errors

After collecting replay details, identify errors that appear in multiple replays or seem likely to affect the user experience. For each significant error:

1. **Triage by frequency**: If the same issue ID (e.g., `JAVASCRIPT-33RM`) appears in 3+ replays, it's worth investigating. 2. **Check the issue in Sentry**: Use `search_issues` to find the issue, or `get_sentry_resource` with the issue URL from the replay details. Understand:

• What is the error? (message, stack trace context)
• How many total users/events does it affect? (beyond just this replay sample)
• Is it assigned or being worked on?

3. **Infer user-facing impact from behavioral signals**: We cannot see the rendered page content through replay metadata — only by watching the replay in-browser. Instead, infer impact from what users did _after_ the error:

• **Retried the same action** → they likely saw a failure and tried again
• **Navigated away immediately** → they were blocked or gave up
• **Continued their flow normally** → the error may be silent/cosmetic
• **Rage-clicked or dead-clicked after** → the UI may have become unresponsive
• **Spent a long time on the page after** → they may be reading an error message or confused
• **No behavioral change at all** → error was likely invisible to the user

4. **Classify each error** based on this evidence:

• **Likely blocking**: Error + user retried/left/couldn't continue. High confidence of user impact.
• **Likely degrading**: Error + user continued but with unusual behavior. Moderate confidence.
• **Likely silent**: Error fired but user behavior was unaffected. Low confidence of user impact.
• **Unclear**: Not enough behavioral signal to judge. Flag for manual replay review.

Always note the confidence level and recommend watching specific replays to confirm. Link directly to the replay URL for each classified error.

Include this classification in the Friction & Pain Points section.