finding-replay-for-issue

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Finding the best replay for an error tracking issue

为错误追踪问题寻找最佳回放

When a user says "show me a replay for this error" or "find a recording for issue X", the goal isn't just any linked session — it's the one that best shows what led to the error. Popular issues can have hundreds of linked sessions, and most are crash-only fragments or duplicate occurrences. This skill picks the most useful one.

当用户说“给我展示这个错误的回放”或“为问题X查找录制内容”时，目标并非任意一个关联会话——而是最能清晰展示错误诱因的那个。热门问题可能关联数百个会话，其中大多数只是仅包含崩溃片段的内容或重复出现的情况。本Skill会挑选出最有用的那个会话。

Available tools

可用工具

Tool	Purpose
`posthog:query-error-tracking-issue`	Get issue details (fingerprint, status, volume)
`posthog:execute-sql`	Query exception events to find linked sessions
`posthog:query-session-recordings-list`	Fetch recording metadata for candidate sessions
`posthog:session-recording-get`	Get full details for the selected recording
`posthog:session-recording-summarize`	AI summary of the selected recording (optional, slow)

工具名称	用途
`posthog:query-error-tracking-issue`	获取问题详情（指纹、状态、数量）
`posthog:execute-sql`	查询异常事件以找到关联会话
`posthog:query-session-recordings-list`	获取候选会话的录制元数据
`posthog:session-recording-get`	获取所选录制内容的完整详情
`posthog:session-recording-summarize`	所选录制内容的AI总结（可选，速度较慢）

Workflow

工作流程

Step 1 — Get the issue details

步骤1 — 获取问题详情

Fetch the error tracking issue to understand what you're looking for:

json

posthog:query-error-tracking-issue
{
  "issueId": "<issue_id>"
}

Note the issue's

fingerprint

name

, and

description

— you'll need the fingerprint to find linked sessions.

获取错误追踪问题的信息，明确查找目标：

json

posthog:query-error-tracking-issue
{
  "issueId": "<issue_id>"
}

记录问题的

fingerprint

、

name

和

description

——你需要用指纹来查找关联会话。

Step 2 — Find sessions with this error

步骤2 — 查找出现该错误的会话

Query exception events to get session IDs where this error occurred. Order by recency and include basic context:

sql

posthog:execute-sql
SELECT
    $session_id AS session_id,
    count() AS occurrences,
    min(timestamp) AS first_seen,
    max(timestamp) AS last_seen,
    any(properties.$current_url) AS url
FROM events
WHERE event = '$exception'
    AND properties.$exception_fingerprint = '<fingerprint>'
    AND $session_id IS NOT NULL
    AND timestamp > now() - INTERVAL 30 DAY
GROUP BY session_id
ORDER BY last_seen DESC
LIMIT 20

This gives you up to 20 candidate sessions. More candidates means better selection.

查询异常事件以获取发生该错误的会话ID。按时效性排序并包含基本上下文：

sql

posthog:execute-sql
SELECT
    $session_id AS session_id,
    count() AS occurrences,
    min(timestamp) AS first_seen,
    max(timestamp) AS last_seen,
    any(properties.$current_url) AS url
FROM events
WHERE event = '$exception'
    AND properties.$exception_fingerprint = '<fingerprint>'
    AND $session_id IS NOT NULL
    AND timestamp > now() - INTERVAL 30 DAY
GROUP BY session_id
ORDER BY last_seen DESC
LIMIT 20

这会为你提供最多20个候选会话。候选会话越多，选择效果越好。

Step 3 — Rank the candidates

步骤3 — 对候选会话排序

Fetch recording metadata for the candidate sessions to rank them:

json

posthog:query-session-recordings-list
{
  "session_ids": ["<id1>", "<id2>", "<id3>", ...],
  "date_from": "-30d"
}

Pick the best recording by filtering out bad candidates, then ranking what's left:

Filter out:

Sessions under 10 seconds (crash-only fragments, no pre-error context)
Sessions over 1 hour (too much data to load, error is a needle in a haystack)

Rank by:

Sweet-spot duration — 2-15 minutes is ideal. Long enough to show the user's journey before the error, short enough to be practical to watch or summarize.
Active time ratio — compare
```
active_seconds
```
to
```
recording_duration
```
. A 20-minute recording with 10 seconds of activity is mostly idle tabs — the user walked away. Prefer sessions where
```
active_seconds / recording_duration
```
is above 0.3 (30%).
Activity score — higher
```
activity_score
```
means the user was actively interacting, not idle. More interesting to watch.
Recency — more recent sessions reflect current app behavior.

获取候选会话的录制元数据并进行排序：

json

posthog:query-session-recordings-list
{
  "session_ids": ["<id1>", "<id2>", "<id3>", ...],
  "date_from": "-30d"
}

先过滤掉不合格的候选会话，再对剩余会话排序，挑选最佳录制内容：

过滤掉以下会话：

时长不足10秒的会话（仅包含崩溃片段，无错误发生前的上下文）
时长超过1小时的会话（数据量过大，错误如同大海捞针）

排序依据：

理想时长区间——2-15分钟为最佳。足够长以展示用户在错误发生前的操作流程，同时又足够短，便于查看或总结。
活跃时间占比——对比
```
active_seconds
```
和
```
recording_duration
```
。一个20分钟的录制内容若仅包含10秒活跃时间，大多是用户离开后的闲置标签页。优先选择
```
active_seconds / recording_duration
```
占比超过0.3（30%）的会话。
活动评分——
```
activity_score
```
越高，说明用户在积极交互而非闲置。这类会话更具查看价值。
时效性——较新的会话更能反映应用当前的行为状态。

Step 4 — Present the finding

步骤4 — 呈现结果

Fetch full details for the selected recording:

json

posthog:session-recording-get
{
  "id": "<best_recording_id>"
}

Present to the user:

The recording with a link to watch it
Why this one — briefly explain the selection ("longest session with the error, user was browsing 3 pages before hitting it")
Pre-error context — what pages the user visited and key actions before the exception, derived from the events query in step 2 (the
```
url
```
and
```
first_seen
```
columns)
Error frequency — how many times the error occurred in this session

获取所选录制内容的完整详情：

json

posthog:session-recording-get
{
  "id": "<best_recording_id>"
}

向用户呈现以下内容：

录制内容：附带查看链接
选择理由：简要说明选择依据（例如“出现该错误的最长会话，用户在触发错误前浏览了3个页面”）
错误前上下文：用户在异常发生前访问的页面和关键操作，来自步骤2中的事件查询（
```
url
```
和
```
first_seen
```
列）
错误频率：该会话中错误发生的次数

Optional: AI summary

可选：AI总结

If the user wants a narrative summary without watching:

json

posthog:session-recording-summarize
{
  "session_ids": ["<best_recording_id>"],
  "focus_area": "<error description or type>"
}

Warn that this takes ~5 minutes for first-time summaries.

如果用户希望无需查看即可获得叙事性总结：

json

posthog:session-recording-summarize
{
  "session_ids": ["<best_recording_id>"],
  "focus_area": "<error description or type>"
}

需提醒用户，首次总结大约需要5分钟。

Tips

提示

If all candidate sessions are very short (<10 seconds), the error likely crashes the page immediately. Note this — it's useful context even without a long replay.
When the issue has very few linked sessions (<3), skip the ranking and just present what's available with a note about the small sample.
If
```
$session_id
```
is null on many exception events, session replay may not be enabled for the affected users. Mention this as a possible gap.
The
```
focus_area
```
parameter on
```
session-recording-summarize
```
is powerful here — pass the exception type or message so the summary focuses on the error context rather than the entire session.

如果所有候选会话都非常短（<10秒），说明错误可能会立即导致页面崩溃。请记录这一点——即使没有长回放，这也是有用的上下文信息。
当问题关联的会话极少（<3个）时，跳过排序步骤，直接呈现现有内容，并注明样本量较小。
如果许多异常事件的
```
$session_id
```
为空，说明受影响用户可能未启用会话回放功能。请提及这一可能存在的缺口。
```
session-recording-summarize
```
的
```
focus_area
```
参数在此处非常实用——传入异常类型或消息，让总结聚焦于错误上下文而非整个会话。