リテンションコホート表を読み解くプロンプト
いつ使うか
Mixpanel / Amplitude のコホート表を眺めて「2週目に大きく落ちてるな」とは分かっても、その先の打ち手まで結びつかない時。AI に表全体の傾向と特定セルの異常を同時に分析させる。
プロンプト本文 (コピペして使う)
あなたはプロダクトアナリストです。以下のリテンションコホート表を解釈してください。
## サービス概要
- 種別: <例: 個人向け副業ツール SaaS>
- 計測アクション: <例: アプリの起動>
- コホート粒度: 週次
- 行: 登録週 / 列: 経過週
## コホート表
| 登録週 | サイズ | W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 |
|--------|------|----|----|----|----|----|----|----|----|
| 2026-W10 | 320 | 58% | 32% | 24% | 22% | 20% | 19% | 18% | 18% |
| 2026-W11 | 410 | 62% | 35% | 27% | 24% | 22% | 21% | 20% | - |
| 2026-W12 | 380 | 51% | 24% | 18% | 16% | 14% | 13% | - | - |
| 2026-W13 | 290 | 67% | 41% | 33% | 30% | 28% | - | - | - |
| 2026-W14 | 350 | 64% | 38% | 30% | 27% | - | - | - | - |
## 周辺情報
- 2026-W12 にアプリの大きな UI 変更を実施
- 2026-W13 から新規ユーザーへのオンボーディングメール 3通追加
## 分析の流れ
1. **全体の地形**
- 直近のリテンションは健康か / 悪化か / 改善か
- 落ち込みが激しい経過週 (W1 直後の崖、W4 以降の安定など)
2. **異常コホートの特定**
- 表中で目立つ良いコホートと悪いコホート
- その原因仮説 (周辺情報と結びつけて)
3. **改善施策の効果検証**
- 2026-W13 のオンボーディングメール追加は効いたか
- 効いたと言える数値根拠と、サンプルサイズの十分性
4. **次の打ち手 3つ**
- W1→W2 の崖を埋めるための施策
- 長期 (W4以降) を持ち上げるための施策
5. **追加で見るべきセグメント**
- デバイス別 / 流入元別 / 初週アクション別など、コホートをさらに分解する観点
## 制約
- 数値の差は絶対値とパーセンテージ両方で書く
- サンプルサイズが小さいコホート (例: <100) の数値を過信しない
- 推測と事実を必ず分ける効くポイント
- 周辺情報 (UI変更/施策) を一緒に渡すと、表の凹凸に意味づけができる
- サンプルサイズが小さい時の注意を明示すると、誤った結論を防げる
- W1→W2 と W4 以降を分けて打ち手を聞くと、施策の時間軸が明確になる
よくある質問
- コホート表の数値が手作業集計なので、AI 分析に投げる前に検算したいです
- BI ツール (Mixpanel / Amplitude / Looker) が出す表をそのまま使うのが基本ですが、手作業の場合は「分母 (登録週のユーザー数)」と「分子 (経過週のアクティブユーザー数)」を別カラムで明示しておくと、AI 側で「分母が小さすぎる行は信頼度が低い」と扱いやすくなります。
- 登録ユーザーの行動データそのものを AI に渡すのは大丈夫?
- コホート表自体は集計値なので個人特定リスクは低いですが、生イベントログ (user_id 付き) を AI に渡すなら個人情報保護法・GDPR 観点でハッシュ化やマスキングを推奨します。社外 LLM に送信する場合、契約上の「学習に使われない設定」を選んでいるかも併せて確認してください。
- サンプルサイズが 100 未満のコホートが多くて判断材料にならない
- プロンプト内の制約に「サンプルサイズが小さいコホート (例: <100) の数値を過信しない」が含まれていますが、現実的にはコホート期間を週次→月次に粗くして 1 コホート 300-500 件に揃えるのが安定です。短期間の細かい変動を見たい場合は、コホートではなくセグメント別の絶対数を別途追うほうが向きます。
このプロンプトを実戦で使った所感や改善案があればぜひフィードバックを。姉妹サイト ai-pick.tech では AI x SNS集客の運用ノウハウを公開しています。