replay-ux-research

重放 UX 研究

分析 sentry.io 真实外部用户的会话重放，发掘特定产品领域的 UX 模式、痛点和代表性用户旅程。此研究使用 Sentry 自己的内部试用组织。

输入

$ARGUMENTS 是要研究的产品领域（例如，“issues”、“traces”、“dashboards”、“replays”、“monitors”、“releases”、“alerts”）。

如果 $ARGUMENTS 为空，请询问用户要研究哪个产品领域。

前置条件

此技能要求已连接 Sentry MCP 服务。将使用以下工具：

• search_events — 搜索会话重放
• get_replay_details — 获取重放详细信息
• search_issues — 查找错误问题
• get_sentry_resource — 从 URL 获取问题详细信息

如果这些工具不可用，请让用户先连接 Sentry MCP 服务，再继续操作。

第 1 步：将产品领域映射到 URL 模式

阅读 references/product-areas.md，并查找所请求领域对应的 URL 模式。

如果列表中没有该产品领域，请根据领域名称推断 URL 模式。大多数 Sentry 产品领域在 URL 路径中都遵循 /<area-name>/ 模式。参考文件可能未涵盖较新的产品领域；如果不确定，请向用户确认你的推断。

第 2 步：搜索重放

搜索外部（非 Sentry 员工）用户的重放。25 条重放是不错的起点；如果产品领域较复杂、早期模式不明确，或者用户想要更全面的结果，则应进一步深入搜索。

从过去 24 小时开始搜索；如果需要达到目标数量，可扩展到 48 小时或 7 天。必要时调用多次 search_events。每次调用使用 limit: 50。

如果找不到足够的重放（即使搜索范围扩展到 7 天仍少于 10 条），请告知用户找到的结果，并请他们协助调整搜索条件——他们可以建议更宽泛的 URL 模式、不同的时间范围，或纳入相关产品领域。

查询构造：

使用自然语言查询，例如：

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

关键筛选条件：

• 时间范围：过去 24 小时（必要时扩展）
• URL 模式：匹配第 1 步中该产品领域的路径
• 排除员工：-user.email:*@sentry.io -user.email:*@getsentry.com
• 环境：prod

不要传入 projectSlug 筛选条件——重放涵盖整个组织。

第 3 步：获取重放详细信息

对第 2 步找到的每条重放调用 get_replay_details。为提高速度，请分批并行调用。

对于每条重放，记录：

• 用户：仅记录电子邮件域名（API 返回完整电子邮件地址——输出中绝不能包含这些地址）
• 用户旅程：按顺序列出访问过的页面（根据 URL 和活动面包屑）
• 时长：会话总时长
• 重放类型：session（从常规浏览中随机抽样）与 buffer（由事件触发，例如错误、手动刷新，或提交反馈、完成结账等特定用户操作）。分析时请注明这一区别，因为 buffer 重放偏向于错误或操作发生时的片段，并不代表典型浏览行为。
• 进入来源：第一个 URL 能说明用户如何到达此页面——查找查询参数中的来源信号，例如 referrer=slack、notification_uuid、alert_rule_id（Slack 通知）、电子邮件链接模式，或不带参数的 URL（书签/直接导航）
• 参与度信号：错误数、愤怒点击、无效点击、警告数
• 浏览器/操作系统/设备：用于了解设备分布
• 活动面包屑：页面浏览、导航模式、关键交互

第 4 步：调查重大错误

收集回放详情后，找出在多条回放中出现，或可能影响用户体验的错误。对于每个重大错误：

1. 按频率排序：如果同一个问题 ID（例如 JAVASCRIPT-33RM）出现在 3 条或更多回放中，就值得调查。
2. 在 Sentry 中查看问题：使用 search_issues 查找问题，或使用回放详情中的问题 URL 调用 get_sentry_resource。了解：
   • 错误是什么？（消息、堆栈跟踪上下文）
   • 总共有多少用户／事件受到影响？（不只是当前回放样本）
   • 是否已分配负责人或正在处理？
3. 根据行为信号推断对用户的影响：我们无法通过回放元数据查看页面的渲染内容——只能在浏览器中观看回放。应根据用户在错误发生后的行为推断影响：
   • 重试相同操作 → 他们很可能看到了失败，并尝试再次操作
   • 立即离开当前页面 → 他们可能受阻或放弃了
   • 正常继续操作流程 → 错误可能没有显示出来，或只是视觉问题
   • 随后疯狂点击或点击无响应 → 界面可能已无响应
   • 随后在页面上停留很长时间 → 他们可能在阅读错误消息或感到困惑
   • 行为完全没有变化 → 错误很可能对用户不可见
4. 根据这些证据对每个错误分类：
   • 可能阻断操作：发生错误后，用户重试、离开或无法继续。对用户影响的判断可信度较高。
   • 可能造成体验下降：发生错误后，用户仍继续操作，但行为异常。判断可信度中等。
   • 可能无感知：错误触发了，但用户行为未受影响。对用户影响的判断可信度较低。
   • 不明确：行为信号不足，无法判断。标记为需要人工查看回放。

始终注明置信度，并建议观看特定回放以确认。对于每个分类后的错误，直接链接到回放 URL。

将此分类纳入“摩擦与痛点”部分。不要将可能无感知的错误报告为痛点——请在单独的“后台错误（可能无感知）”小节中列出，以供完整参考。

第 5 步：分析模式

从以下 UX 研究视角查看回放：

行为模式

1. 常见路径：用户会经过哪些导航路径？典型流程是什么？
2. 入口点：用户如何进入？分类为：提醒通知（Slack／电子邮件）、直接使用书签、从其他页面自然导航。第一个 URL 的查询参数可以揭示这些信息。
3. 任务完成情况：用户看起来是否达成了目标，还是在页面间来回浏览／放弃了？完成的迹象：导航到详情视图后离开。放弃的迹象：会话很短、来回导航、从进入时所在的同一页面离开。
4. 任务耗时：用户在执行操作前，会在关键页面上停留多久？

摩擦与功能发现

1. 摩擦信号：疯狂点击、点击无响应、错误；此外还包括_犹豫_（反复访问同一页面）、来回折腾（在页面间快速往返）和_重试循环_（重复相同的操作序列）。
2. 功能发现：用户是否找到了子功能（筛选、搜索、排序、批量操作），还是只使用了主要视图？查看 URL 查询参数和面包屑，寻找使用这些功能的证据。
3. 用户意图信号：从 URL 查询参数中提取用户设置的搜索词、筛选值、排序方式和日期范围。这些最接近用户的原话——它们会揭示用户用自己的话在寻找什么。（例如，query=is%3Aunresolved+assigned%3Ame 表明用户正在处理分配给自己的问题。）
4. 变通方式：是否存在暗示功能缺失或流程令人困惑的意外导航模式？（例如，在任务过程中前往设置，或依次打开多个本可合并为一个视图的页面）
5. 错误恢复：用户遇到错误时，会恢复操作并继续，还是放弃？

背景

1. 回放触发方式：session（随机抽样）和 buffer（事件触发）分别占多少比例？buffer 回放展示了发生重要事件（错误、提交反馈、结账等）的时刻——这些回放有助于分析使用阻碍，但并不代表典型的浏览行为。得出结论时，请指出这一偏差。
2. 回访用户：是否有多个回放中的邮箱域名相同？回访用户表明用户有固定的使用习惯——他们的使用旅程可能揭示高级用户的使用模式，或他们已学会绕过的持续性痛点。
3. 用户多样性：回放来自许多不同的组织或公司，还是集中于少数组织或公司？不同组织的用户行为是否存在差异？
4. 设备和浏览器分布：用户主要使用哪些设备和浏览器？
5. 流失点：用户在哪些位置离开或跳转离开？

第 6 步：撰写报告

使用 references/output-template.md 中的模板。请具体说明，并引用单个回放作为每种模式的证据。附上回放 URL，方便读者自行观看。

隐私：报告中绝不包含完整的用户邮箱地址。请使用匿名标识，例如“来自[公司域名]的用户”或“用户 A、B、C”。