finding-sessions-to-watch

查找要观看的会话

大多数人打开会话回放时都有一个目标（“注册量为什么在下降？”），却不知道该看成千上万条录制中的哪一条。未经筛选的原始列表是最糟糕的答案——它会把有用的会话淹没在噪声中。你的工作是将他们的意图转化为聚焦的筛选条件，返回少量高信号的录制，并主动提出深入分析其中一条。

以下起点与产品中显示为“筛选模板”的选项相同——它们体现了人们实际使用回放完成的任务。请将它们视为菜单，而非照本宣科的脚本。

唯一规则

绝不输出未经筛选的录制列表。 始终要么（a）应用基于目标的筛选条件，要么（b）按某种信号（活动、错误）排序，让前几行值得点击。如果用户的目标不明确，请先提出一个简短问题，或在查询前提供菜单。

可用工具

工具	用途
posthog:query-session-recordings-list	查找/筛选录制（主要工具）。每行返回元数据和 id。
posthog:read-data-schema	在筛选前确认实际的事件名称、URL 和属性值。
posthog:execute-sql	收集发生过特定事件的会话的 $session_id。
posthog:cohorts-list	在限定用户群组时，将群组名称解析为 id。
posthog:session-recording-playlist-create	将最终筛选条件保存为已保存的筛选视图（type: 'filters'）。

用户选定某条录制并希望深入了解后，将任务交给 investigating-replay 技能。

工作流

1. 明确目标

将请求对应到以下起点之一。如果请求含糊不清（“给我看看有意思的内容”），请提供 3-4 个选项，而不是猜测；也可以默认选择活动度最高的会话（信号强，无需设置）。

2. 先探索，再筛选

事件名称和 URL 因项目而异——不要假定存在 $pageview 路径、signup_completed 事件或某个人员属性。在将值放入筛选条件前，先用 read-data-schema 确认（event_properties、event_property_values、entity_property_values）。如果所需事件/属性不存在，请说明情况并建议最接近的可用信号。

3. 执行最精简的查询

调用 query-session-recordings-list，只使用与目标相关的筛选条件。建议设置如下：

• 设置 filter_test_accounts: true（该工具默认为 false），以排除内部用户；除非用户正在调试自己的会话。
• 基于目标的搜索将 date_from 设为 -7d 到 -30d；搜索“最近”的内容则设为 -3d。
• 有意选择 order——“有意思”选 activity_score，“出故障”选 console_error_count，“最近”选 start_time。
• limit: 10——你要的是候选短名单，而不是一股脑罗列。

4. 筛选并呈现结果

不要转述原始行。选出最值得关注的 3-5 条，并说明每条值得观看的原因（活跃时长长、错误多、到达关键页面、活动得分高）。将每条链接到 {posthog_base_url}/replay/{id}——绝不要使用 /replay/home?sessionRecordingId={id}。注明匹配总数，让用户了解短名单背后还有多少内容。

5. 提供下一步

• “要我带你看其中一条吗？” → investigating-replay。
• “要继续关注这些内容吗？” → 使用 session-recording-playlist-create 将其保存为已保存的筛选视图（type: 'filters'——这是筛选视图，不是 'collection'；后者用于手动整理录制，且不能包含筛选条件）。

起点 → 筛选条件

两类筛选条件几乎可以涵盖所有情况：

• 访问过某个页面 → 录制指标 visited_page（{ "type": "recording", "key": "visited_page", "operator": "icontains", "value": "/pricing" }）。
• 执行过某个特定事件（注册、搜索、狂点、使用某项功能）→ 录制查询不支持按事件名称筛选，因此请先使用 execute-sql 收集会话 ID，再将其作为 session_ids 传入（参见下方的两步模式）。

用户目标	方法
注册 / 引导流程 / 定价 / 结账时遇到阻碍	对相关路径使用 visited_page icontains（先确认实际路径）。按 start_time 排序，或按 console_error_count 排序以找出出错的录制。
某项特定功能	分两步：使用 execute-sql 找出触发了该功能事件的 $session_id，然后传入 session_ids。如果该功能位于某个页面，可结合 visited_page 使用。
狂点 / 挫败情绪	分两步筛选 $rageclick 事件 → session_ids。
错误 / 功能异常	properties: [{ "type": "recording", "key": "console_error_count", "operator": "gt", "value": 0 }]，按 console_error_count 排序。
A/B 测试 / 功能标记	{ "type": "flag", "key": "<flag-key>", "operator": "flag_evaluates_to", "value": "<variant or true>" }。
某个特定用户 / 用户群组	person_uuid、person 属性筛选条件（例如 email），或 cohort 筛选条件（使用 cohorts-list 获取 ID）。
移动设备 / 响应式问题	{ "type": "event", "key": "$device_type", "operator": "exact", "value": ["Mobile"] }，或 { "type": "event", "key": "$screen_width", "operator": "lt", "value": 600 }。
最活跃的用户 /“只给我看表现良好的用户”	不设置筛选条件；使用 order: "activity_score"。当用户没有具体目标时，这是可靠的默认选项。
最活跃的页面	使用 execute-sql 按 URL 对 $pageview 排名，然后按最热门页面的 visited_page 筛选录制。

两步模式：“发生过事件 X 的会话”

录制查询按事件_属性_筛选，而非事件_名称_。要查找包含某个特定事件的会话，请先收集会话 ID：

posthog:execute-sql
SELECT $session_id
FROM events
WHERE event = '$rageclick'          -- or your signup/search/feature event (confirm via read-data-schema)
    AND timestamp > now() - INTERVAL 7 DAY
    AND $session_id != ''
GROUP BY $session_id
ORDER BY max(timestamp) DESC         -- recent first: UUIDs aren't time-ordered, so the LIMIT must keep the freshest sessions
LIMIT 100

然后获取这些录制（部分会话 ID 没有录制，这是正常情况）。传入与 SQL 步骤相同的 date_from 时间范围——如果只传入 session_ids，查询会回退到默认的 -3d，导致丢弃事件发生时间早于该范围的会话：

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

示例

用户：“为什么大家在定价页面上纷纷离开？给我看看一些会话。”

1. 目标 = 定价页面上的阻碍 → 采用 visited_page 方法。
2. read-data-schema（针对 $pathname 的 event_property_values），确认路径为 /pricing。
3. 查询：

posthog:query-session-recordings-list
{
  "date_from": "-14d",
  "filter_test_accounts": true,
  "order": "activity_score",
  "limit": 10,
  "properties": [
    { "type": "recording", "key": "visited_page", "operator": "icontains", "value": "/pricing" }
  ]
}

4. 列出最活跃的 3～5 个会话，各自以 {base}/replay/{id} 的形式展示，并注明哪些会话停留时间较长或遇到了错误。
5. 提议深入调查最有希望的会话（investigating-replay），或将其保存为已保存的筛选视图（type: 'filters'）。

提示

• 优先使用一个有效筛选条件，而不是许多条件——过度筛选会导致没有结果，看起来就像“没有数据”。
• 如果查询返回零条录制内容，请扩大日期范围或放宽筛选条件，再得出没有内容可看的结论；如果仍然为空，可能是该流程没有录制内容（引导用户使用 diagnosing-missing-recordings）。
• 如果没有更明确的信号，activity_score 是衡量“是否值得观看”的可靠默认指标——但它会奖励原始交互量，因此有明确目标时（例如错误、关键页面），优先使用基于目标的筛选条件。
• 保持候选列表简短。关键在于替用户做选择，而不是把大海捞针的工作交给他们。

相关技能

• investigating-replay — 深入分析候选列表中的某个会话
• diagnosing-missing-recordings — 查询反复返回空结果，且录制是否正常本身存疑时使用
• creating-replay-vision-scanners — 将重复出现的候选列表转为定时运行的 Replay Vision 扫描器