finding-sessions-to-watch

視聴するセッションを見つける

多くの人は「登録が減っているのはなぜ？」といった目的を持ってセッションリプレイを開きますが、何千件もの録画のうち、どれを見ればよいのか分かりません。絞り込みのない生の一覧は、考えられる限り最悪の答えです。有用なセッションがノイズに埋もれてしまいます。あなたの役割は、ユーザーの意図を絞り込まれたフィルターに変換し、有用な録画を少数提示して、そのうちの1件を詳しく調べることを提案することです。

以下の出発点は、製品で「フィルターテンプレート」として表示されるものと同じです。これらは、ユーザーがリプレイで実際に行う作業を反映しています。手順書ではなく、選択肢として扱ってください。

ルールは1つ

絞り込みのない録画一覧を決してそのまま表示しないでください。 必ず、（a）目的に基づくフィルターを適用するか、（b）シグナル（アクティビティ、エラー）で並べ替えて、最初の数行にクリックする価値がある録画が表示されるようにしてください。ユーザーの目的が不明確な場合は、クエリを実行する前に短い質問を1つするか、選択肢を提示してください。

利用可能なツール

ツール	目的
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. 次のステップを提案する

• 「どれか1つを一緒に確認しましょうか？」→ investigating-replay。
• 「これらを引き続き見られるようにしますか？」→ session-recording-playlist-create を使って、保存済みフィルタービューとして保存します（type: 'filters' — フィルタービューです。手動で選定した録画用で、フィルターを保持できない 'collection' ではありません）。

出発点 → フィルター

ほぼすべてのケースを、次の2種類のフィルターでカバーできます。

• ページに到達した → 記録指標 visited_page（{ "type": "recording", "key": "visited_page", "operator": "icontains", "value": "/pricing" }）。
• 特定のイベントを実行した（サインアップ、検索、レイジクリック、機能の使用）→ 録画クエリにはイベント名のフィルターがないため、まず execute-sql でセッション ID を収集し、それを session_ids に渡します（以下の2段階のパターンを参照）。

ユーザーの目的	方法
サインアップ／オンボーディング／料金ページ／チェックアウト時の問題	関連するパスに対して visited_page icontains を指定します（まず実際のパスを確認してください）。start_time、または問題のあるものを見つけるには console_error_count で並べ替えます。
特定の機能	2段階で実行します。機能イベントが発生した $session_id を execute-sql で取得し、その後 session_ids を指定します。機能が1つのページにある場合は、visited_page と組み合わせます。
レイジクリック／フラストレーション	$rageclick イベントを使った2段階の方法で 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 フィルター（ID を取得するには cohorts-list）を使います。
モバイル／レスポンシブの問題	{ "type": "event", "key": "$device_type", "operator": "exact", "value": ["Mobile"] }、または { "type": "event", "key": "$screen_width", "operator": "lt", "value": 600 } を指定します。
最もアクティブなユーザー／「良いものだけを表示」	フィルターは指定せず、order: "activity_score" を指定します。ユーザーに具体的な目的がない場合の、信頼できるデフォルトです。
最もアクティブなページ	execute-sql で $pageview を URL ごとに順位付けし、最も多いページの visited_page で録画をフィルタリングします。

2段階のパターン：「イベント 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'）として保存します。

ヒント

• フィルターは数多く使うより、適切なものを1つ使うことを優先してください。フィルターをかけすぎると何も返されず、「データなし」と解釈されます。
• クエリで録画が1件も返されない場合、結論を出す前に日付範囲を広げるか、フィルターを緩めてください。それでも空の場合は、そのフローの録画が取得されていない可能性があります（ユーザーに diagnosing-missing-recordings を案内してください）。
• より明確なシグナルがない場合、activity_score は「見る価値がある」録画を選ぶための確かなデフォルト指標です。ただし、単純なインタラクション数が多いほど高く評価されるため、目的に基づくフィルター（エラーや重要なページ）が使える場合は、そちらを優先してください。
• 候補は少数に絞ってください。価値があるのは、候補の山をそのまま渡すことではなく、ユーザーに代わって選ぶことです。

関連スキル

• investigating-replay — 候補に挙がったセッションを1つ選び、詳しく分析します
• diagnosing-missing-recordings — クエリが何度も空の結果を返し、録画自体が取得されているか疑わしい場合に使います
• creating-replay-vision-scanners — 繰り返し作成する候補リストを、スケジュール実行される Replay Vision スキャナーにします