cohort-analysis

コホート分析スキル

継続率曲線、LTV の推定、行動セグメンテーション、解約の先行指標、優先順位を付けた施策を網羅する、構造化されたコホート分析を作成します。プロダクト責任者への説明や、グロースチームやデータチームとの共有にそのまま使用できます。

---

必須入力

不足している項目があれば、開始前に確認してください。数値、ベンチマーク、スキーマの詳細を捏造しないでください。

入力項目	不足している場合の確認事項
分析の目的	継続率の改善／LTV モデリング／行動セグメンテーション／解約予測から、主な目的を1つ選んでください
プロダクトまたは機能	何を分析しますか？
コホートの定義	ユーザーをどのようにコホートに分類しますか？（獲得月、登録チャネル、プランの階層、機能の利用開始日など）
観測期間	何期間にわたって追跡しますか？（例：12か月、8週間）
主要指標	コホートごとに何を測定しますか？（継続率、収益、エンゲージメントスコア、機能の利用状況など）
利用可能なデータ	スキーマやテーブル名を貼り付けるか、利用可能な指標を説明してください。推測しないでください
ベースラインまたは目標	比較対象となる既存の継続率ベンチマークや目標はありますか？

実データを提示できない場合は、明確なプレースホルダー（[X%]、[£X]、[N users]）を使ってフレームワークを作成し、実データが必要なセクションを記載してください。

---

手順

以下の手順を順番に実行してください。

1. 入力を確認する — 出力を作成する前に、曖昧な点（コホート定義の矛盾、観測期間の不足など）を明らかにします。
2. コホートを定義する — コホート同士が相互に排他的になるよう、開始イベント、終了条件、除外条件を定めます。
3. 継続率テーブルを作成する — 期間ごとのマトリクスにデータを入力するか、テンプレートを作成し、継続率が安定する期間を特定します。
4. LTV を予測する — 観測済みの継続率データのみを使用し、データが不十分な場合はその旨を示します。
5. 行動別にセグメント化する — 相互に排他的な行動セグメントを作成し、アクティベーションのしきい値を特定します。
6. 解約の先行シグナルを提示する — 観測可能なシグナルを先行期間および対応する施策とともに列挙します。
7. コホートの推移を比較する — プロダクトの変更が新しいコホートに反映されているかを評価します。
8. 推奨事項に優先順位を付ける — すべての推奨事項を、特定のコホートまたはセグメントでの分析結果と結び付けます。
9. SQL の参考例を提示する — 実際のスキーマが提示されている場合は、テンプレートのクエリをそれに合わせて調整します。
10. 品質チェックを実施する — 出力を提出する前に、チェックリストの全項目を確認します。

---

出力テンプレート

以下のセクションを順番に作成してください。対象外であることが明示されている場合に限り、そのセクションを省略し、省略した旨を記載してください。

---

コホート分析：[プロダクト／機能]

分析の目的： [継続率／LTV／行動セグメンテーション／解約予測] コホートの定義： [例：獲得月 — 初回登録の暦月ごとにユーザーを分類] 観測期間： [X か月／週間] 主要指標： [指標名と定義] データソース： [使用したテーブルまたは指標 — 提示されていない情報を捏造しない] 作成日： [日付]

---

1. コホートの定義

コホート	期間	規模	説明
[コホート 1]	[2025年1月]	[N users]	[例：2025年1月にオーガニック検索経由で登録したユーザー]
[コホート 2]	[2025年2月]	[N users]	[説明]

コホートのロジック：

• 開始イベント： [例：初回登録／初回購入／機能の利用開始]
• 終了／解約の定義： [例：継続率の主要イベントに該当するアクティビティが30日間ない]
• 除外条件： [例：社内テストアカウント、データが3日未満のトライアルユーザー、ユーザー数が[N]人未満のコホート — アンチパターンを参照]

注： いずれかのコホートが統計的信頼性を確保するための最小規模のしきい値を下回る場合は、その旨を明示し、傾向の結論から除外してください。

---

2. リテンションカーブ

読み方： 各セルは、期間 N に主要なリテンションイベントを実行したコホートの割合を示します。期間 0 は定義上 100% です。

コホート	P0	P1	P2	P3	P6	P12
[Jan 2025]	100%	[X%]	[X%]	[X%]	[X%]	[X%]
[Feb 2025]	100%	[X%]	[X%]	[X%]	[X%]	[X%]
[前のコホートとの傾向]	—	[↑/↓ X pp]	[↑/↓ X pp]	[↑/↓ X pp]	[↑/↓ X pp]	[↑/↓ X pp]

リテンションのプラトー： [カーブはどの期間で横ばいになりますか？横ばいになる割合は何％ですか？観測期間が短く、プラトーを確認できない場合は、その旨を明記してください。]

主な所見：

• [例：期間ごとの最大の減少は P1 → P2 で、平均 X pp です。ここが対処すべき主な離脱のタイミングです]
• [例：[チャネル] 経由で獲得したコホートは、P6 のリテンションが全体平均より X pp 高くなっています]
• [例：P3 のリテンションは、最も古いコホートの X% から最新コホートの Y% に変化しており、Z pp の変動です]

リテンションチャート — コホートごとに 1 本の線を描き、x 軸に期間を配置します。

{
  "type": "line",
  "title": "Retention by cohort (%)",
  "labels": ["P0", "P1", "P2", "P3", "P6", "P12"],
  "series": [
    { "name": "[Cohort 1]", "data": [100, "[X]", "[X]", "[X]", "[X]", "[X]"] },
    { "name": "[Cohort 2]", "data": [100, "[X]", "[X]", "[X]", "[X]", "[X]"] }
  ]
}

---

3. LTV の予測

収益データがない場合は、このセクションを省略してください。データソースなしに ARPU を推定しないでください。データが不足していることを記載し、データの提供を依頼してください。

期間ごとの ARPU： [アクティブユーザー 1 人あたりの通貨と期間ごとの金額 — 出典：X] 使用したリテンションカーブ： [どのコホート、またはどの加重平均を使用したか、およびその理由]

期間	リテンション率	継続ユーザーあたりの収益	累積 LTV
1 か月目	[X%]	[£X]	[£X]
3 か月目	[X%]	[£X]	[£X]
6 か月目	[X%]	[£X]	[£X]
12 か月目	[X%]	[£X]	[£X]

12 か月時点の加重平均 LTV： [£X — 対象コホートと加重方法を明記]

セグメント別 LTV：

セグメント	LTV（12 か月）	加重平均基準との差	差を生む主な要因
[オーガニック]	[£X]	[+X%]	[例：P6 のリテンションが高い]
[有料]	[£X]	[-X%]	[例：アクティベーション率が低い]
[エンタープライズ]	[£X]	[+X%]	[例：期間あたりの ARPU が高い]

---

4. 行動セグメンテーション

セグメントはユーザーの流入時期ではなく、ユーザーの行動に基づいて定義します。分析対象集団内で、セグメントは相互に排他的であり、全体を網羅している必要があります。

セグメント	定義	コホートに占める割合	リテンション（P6）	LTV（12 か月）
パワーユーザー	[例：最初の 30 日間にコアアクションを週 3 回以上実行]	[X%]	[X%]	[£X]
カジュアルユーザー	[例：最初の 30 日間にコアアクションを週 1～2 回実行]	[X%]	[X%]	[£X]
休眠ユーザー	[例：ログインしたが、コアアクションを一度も実行していない]	[X%]	[X%]	[£X]
未アクティベーション	[例：登録したが、オンボーディングのステップ 1 を一度も完了していない]	[X%]	[X%]	[£X]

アクティベーションの閾値（「アハ・モーメント」）： [最初の X 日以内に行われる、長期リテンションを最も強く予測する具体的なアクションは何ですか？データから特定してください。一般的な回答を想定しないでください。]

---

5. 離脱の先行指標

ユーザーの離脱前に現れるシグナルで、事前の介入を可能にします。記載するシグナルはすべて本番データで観測できる必要があります。理論上のものしかない場合は、その旨を明記してください。

シグナル	離脱までのリードタイム	相関の強さ	推奨される介入
[例：7 日連続でログインがない]	[7 日]	[強い／中程度／弱い]	[例：7 日目に自動的な再利用促進メールを送信]
[例：エスカレーションが未解決のサポートチケット]	[約 14 日]	[中程度]	[例：エスカレーションから 48 時間以内に CSM から連絡]
[例：コア機能の利用が週ごとに 50% 超減少]	[約 10 日]	[強い]	[例：ユースケースのチュートリアルへのリンクを含むアプリ内プロンプト]

データ要件： 相関の強さは観測データに基づいている必要があります。データを利用できない場合は、[仮説 — 未検証] と記載し、確認のための A/B テストまたは生存分析を推奨してください。

---

6. コホート比較：経時的な傾向

新しいコホートで、プロダクトの変更がリテンションの結果に表れているかを評価します。

指標	[最古のコホート]	[最新のコホート]	変化	メモ
P1 リテンション	[X%]	[X%]	[↑/↓ X pp]
P3 リテンション	[X%]	[X%]	[↑/↓ X pp]
アクティベーション率	[X%]	[X%]	[↑/↓ X pp]
初回30日間の平均セッション数	[X]	[X]	[↑/↓]

結論： [最近のコホートの実績は向上していますか、それとも低下していますか？この期間にリリースされた変更のうち、変化の説明になり得るものは何ですか？因果関係を説明できない場合は、その旨を述べてください。説明を捏造してはいけません。]

---

7. 推奨事項

各推奨事項は、上記のセクションに記載された特定のコホート、セグメント、またはシグナルに言及する必要があります。どのプロダクトにも当てはまるような一般的なアドバイスは削除してください。

#	推奨事項	根拠となる所見	対象セグメント	期待される効果	工数	優先度
1	[具体的なアクション]	[セクション X、所見 Y]	[セグメント]	[例：P1 リテンション +X pp — 推定の根拠]	[低 / 中 / 高]	P1
2	[具体的なアクション]	[セクション X、所見 Y]	[セグメント]	[例：P3 リテンション +X pp]	[低 / 中 / 高]	P1
3	[具体的なアクション]	[セクション X、所見 Y]	[セグメント]	[例：12M 時点の LTV +£X]	[低 / 中 / 高]	P2

利用可能なデータから期待される効果を推定できない場合は、その旨を述べてください。増加率を捏造してはいけません。

---

8. SQL リファレンス

ユーザーから実際のスキーマが提示されている場合は、このテンプレートを適合させてください。プレースホルダーのテーブル名とカラム名を置き換え、ユーザーが実行できないクエリを提出してはいけません。

-- Retention cohort query
-- Replace: users, events, created_at, event_date, user_id, event_type, [start_date], [key_retention_event]
SELECT
  DATE_TRUNC('month', u.created_at)    AS cohort_month,
  DATE_TRUNC('month', e.event_date)    AS activity_month,
  DATEDIFF('month', u.created_at, e.event_date) AS period,
  COUNT(DISTINCT e.user_id)            AS retained_users,
  COUNT(DISTINCT c.user_id)            AS cohort_size,
  ROUND(
    COUNT(DISTINCT e.user_id) * 100.0
    / NULLIF(COUNT(DISTINCT c.user_id), 0), 1
  )                                    AS retention_rate
FROM users u
JOIN (
  SELECT user_id, DATE_TRUNC('month', created_at) AS cohort_month
  FROM users
  WHERE created_at >= '[start_date]'
) c ON u.user_id = c.user_id
   AND DATE_TRUNC('month', u.created_at) = c.cohort_month
JOIN events e
  ON u.user_id = e.user_id
 AND e.event_type = '[key_retention_event]'
GROUP BY 1, 2, 3
ORDER BY 1, 3;

使用環境に合わせた調整： BigQuery では DATE_DIFF、Redshift では DATEDIFF、Snowflake では DATEDIFF または TIMESTAMPDIFF を使用します。実行前に SQL の方言を確認してください。

---

評価基準（0～40）

提出前に、このスキルの出力を評価してください。32 点以上が提出品質です。

項目	0	5	10
コホート定義の厳密さ	境界が曖昧で、同じユーザーが複数のコホートに属する可能性がある	相互排他的だが、参加イベントの根拠が弱い	参加イベントと日付境界が明確で、定義に伴うトレードオフも記載されている
プラトーと期間に関する誠実さ	リテンションを判断するには短すぎる期間から読み取っている	プラトーの位置を示さずにプラトーを主張している	プラトーが視認でき、その位置も示されている。または、確認するには期間が短すぎると明記している
LTV の根拠	想定リテンションまたは想定 ARPU から LTV を算出している	実測データを使用しているが、予測方法が明記されていない	実測リテンション × 実測 ARPU から LTV を算出し、予測方法と減衰の仮定を示している
傾向と先行指標による効果	コホートを説明しているだけで、比較していない	コホート間の傾向は示しているが、指標がない	獲得期間をまたぐ傾向を正しく読み取り、解約の検知に結び付く行動上の先行指標も示している

品質チェック

出力を提出する前に、すべてのチェックを実施してください。提示されたデータに照らして事実を確認できない限り、チェックに合格したとしないでください。

• 相互排他性： 同じユーザーが複数のコホートに属さない — 参加イベントと日付境界が明確である
• リテンションのプラトー： 曲線に目視できるプラトーがある。または、確認するには期間が短すぎると分析で明記している
• LTV の根拠： LTV の予測に実測リテンションと実測 ARPU を使用している — 想定値を使用していない
• 行動セグメント： 相互排他的かつ網羅的であり、対象となるすべてのユーザーが必ず1つのセグメントだけに属する
• コホートの最小サイズ： 信頼性のしきい値を下回るコホートにフラグを立て、傾向に関する結論から除外している
• 解約シグナル： 記載した先行指標がすべて本番データで観測可能である。または、仮説として明示している
• 推奨事項の根拠： 各推奨事項が特定の所見に言及している — 根拠のない成長アドバイスがない
• SQL の適合： スキーマが提示されている場合、クエリにユーザーの実際のテーブル名とカラム名を使用している

---

アンチパターン

次の失敗パターンは避けてください。厳密に見えても、信頼できず、行動につなげられない分析になってしまいます。

アンチパターン	失敗する理由	適切な方法
コホートメンバーの重複	コホート間でリテンションの数値を比較できません	明確で曖昧さのない開始イベントを定義します。1人のユーザーは1つのコホートにのみ属します
LTV予測でARPUを仮定する	セグメントごとの差が隠れ、正確そうに見えて実際には正確でない数値が生まれます	リテンションユーザー1人あたりの期間ごとの実測収益を、セグメント別に使用します
規模の小さすぎるコホートから結論を導く	ランダムな変動が有意なシグナルのように見えてしまいます	コホートの最小サイズを明示し、基準を下回るコホートは除外するか、注意書きを添えます
ログインとリテンションを混同する	ログインしても重要なイベントを完了しないユーザーは、定義上、リテンションユーザーではありません	リテンションとは、セッションではなく、定義された重要なリテンションイベントの完了を指します
リフトの推定値を捏造する	データに基づかない影響予測の数値は、優先順位付けの判断を誤らせます	データから影響を推定できない場合は、その旨を伝え、テストを推奨します
一般的な推奨事項	どのSaaS製品にも当てはまる助言では、分析上の価値がありません	すべての推奨事項で、特定のコホート、セグメント、またはシグナルの調査結果に言及します

---

起動フレーズ

このスキルは、次のようなフレーズで起動します。

• 「[product]のコホート分析を実行して」
• 「獲得月別にリテンションを分析して」
• 「[channel]経由のユーザーと[channel]経由のユーザーのLTVはどのくらい？」
• 「次のデータからコホートリテンションモデルを構築して」