segment-users

データベーススキーマを読み取り、行動セグメントごとのクエリを生成して、各グループに対して取るべき具体的なアクションを提示します。分析プラットフォームは不要です。

フェーズ 1：スキーマを確認する

コードベースでユーザーモデルを確認します。必要なシグナルは次のとおりです。

• 利用指標 — 何をアクティビティとみなしますか？消費クレジット、API 呼び出し、生成回数、ログイン、作成したコンテンツなどです。該当するフィールドを探してください。
• タイムスタンプ — created_at、last_active_at、last_login_at。ユーザーの日時フィールドを確認します。
• プラン／課金 — 無料か有料か、プラン名、サブスクリプションのステータス。
• ORM — Prisma、Drizzle、Mongoose、生 SQL のいずれですか？コードベースですでに使われているものに合わせて出力します。

3 つのシグナル（利用状況、タイムスタンプ、プラン）のいずれかが欠けている場合は、クエリを生成する前にユーザーに伝えてください。スキーマに存在しないフィールドを捏造してはいけません。

フェーズ 2：セグメントを定義する

利用できるシグナルを使ってください。データがない場合、無理にセグメントを作らないでください。

利用状況ベース（利用指標が必要）

パワーユーザー — 利用状況の上位 10％。製品を気に入っているユーザーです。ほかのユーザーとは異なる対応をしてください。

アクティブ — 過去 7 日間に利用があり、利用状況が中央値を上回っているユーザー。

カジュアル — 過去 30 日間に利用があり、利用状況が中央値を下回っているユーザー。

休眠 — 7～30 日間、利用がないユーザー。猶予は残りわずかです。

離脱 — 30 日以上、利用がないユーザー。呼び戻すのは難しくなりますが、不可能ではありません。

ライフサイクル（created_at が必要）

新規 — 登録から 7 日未満。まだ習慣が身についていません。

オンボーディング中 — 7～14 日が経過しており、「アハ体験」に到達していません（製品に応じた具体的な利用しきい値を定義してください）。

定着 — 14～60 日が経過しており、定期的に利用しています。

ベテラン — 60 日以上が経過し、継続的に利用しています。無料プランのユーザーの中で最も価値の高い層です。

収益（プランデータが必要）

無料プラン — 一度も支払いをしていません。

有料 — 有効なサブスクリプションがあるか、クレジットを購入しています。

離脱リスクあり — 有料ユーザーですが、過去 14 日間に利用が減少しています。最も緊急性の高いセグメントです。

有料プランから離脱 — 以前は有料でしたが、サブスクリプションが終了しています。収益はすでに失われています。

フェーズ 3：クエリを生成する

該当する各セグメントについて、SQL と ORM の両方を生成します。実際のスキーマに合わせ、仮のカラム名は使わないでください。

-- Power Users: top 10% by credits consumed
SELECT *, (initial_credits - credits) AS credits_used
FROM users
ORDER BY credits_used DESC
LIMIT (SELECT COUNT(*) / 10 FROM users);

-- Dormant: was active, silent for 7-30 days
SELECT * FROM users
WHERE last_active_at < NOW() - INTERVAL '7 days'
  AND last_active_at > NOW() - INTERVAL '30 days';

-- At Risk: paying user, usage dropped below half their average
SELECT * FROM users
WHERE plan != 'free'
  AND (initial_credits - credits) < (
    SELECT AVG(initial_credits - credits) * 0.5
    FROM users WHERE plan != 'free'
  );

// Prisma: dormant users
const dormant = await prisma.user.findMany({
  where: {
    lastActiveAt: {
      lt: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000),
      gt: new Date(Date.now() - 30 * 24 * 60 * 60 * 1000),
    },
  },
});

ユーザーが分布全体をすぐに確認できるよう、必ず件数クエリを含めてください。

SELECT 'power_users' AS segment, COUNT(*) AS count FROM users WHERE ...
UNION ALL
SELECT 'active'      AS segment, COUNT(*) AS count FROM users WHERE ...
UNION ALL
SELECT 'dormant'     AS segment, COUNT(*) AS count FROM users WHERE ...
UNION ALL
SELECT 'churned'     AS segment, COUNT(*) AS count FROM users WHERE ...

フェーズ 4：アクションを提案する

セグメントごとに、具体的なアクションを 1 つ提案します。曖昧な内容は避けてください。

パワーユーザー — アップグレードの案内、または限定的な先行アクセスを提案します。すでに製品を支持しています。創業者からの個人的なメールは、自動キャンペーンよりも効果的です。

アクティブ — まだ使っていない機能を紹介します。アプリ内のツールチップ、または具体的な機能を 1 つ紹介するメールを使います。売り込むのではなく、使い方を伝えてください。

カジュアル — 価値を感じてもらえた 1 つのことを軸に再エンゲージメントを促します。うまくいった体験を思い出してもらいます。

休眠 — 呼び戻しのメールを送ります。何が変わったか、新機能は何かなど、具体的なきっかけを 1 つ提示します。「寂しく思っています」ではいけません。

離脱 — 簡単なアンケートを実施してから、インセンティブを提示します。呼び戻そうとする前に、理由を確認してください。

新規 — オンボーディングシーケンスを用意します。「アハ体験」のしきい値を定義し、最初の 3 日間で到達できるように設計してください。

離脱リスクあり — 解約前に個別に連絡します。自動化よりも、人からの直接のメッセージが効果的です。

フェーズ 5：出力形式

分布、クエリ、アクションの順に出力します。

USER SEGMENTS — [project name]
════════════════════════════════════
CURRENT DISTRIBUTION
────────────────────────────────────
Power Users:    [N] users  ([X]%)
Active:         [N] users  ([X]%)
Casual:         [N] users  ([X]%)
Dormant:        [N] users  ([X]%)
Churned:        [N] users  ([X]%)
────────────────────────────────────
Total:          [N] users
════════════════════════════════════

ship-email スキルがインストールされている場合は、クエリの出力後に各セグメント向けのメールテンプレートを生成するか尋ねてください。

検証

[ ] User model read from codebase — no invented fields
[ ] Usage metric identified and defined
[ ] Only segments with available signals generated
[ ] SQL + ORM queries output for each segment
[ ] Count queries included so distribution is visible
[ ] At Risk segment flagged if any paying users exist
[ ] Action recommendation per segment — specific, not generic
[ ] All column names in queries match the actual schema

RFM スコアリング、コホート維持率分析、解約予測のパターンについては、references/guide.md を参照してください。