行動データと事業価値から施策可能な顧客セグメントを設計するPrompt

顧客データから、説明用の属性グループではなく、施策を変えられる顧客セグメントを設計してください。

データ条件：
分析単位（ユーザー／ドメイン／企業等）：ユーザー単位（アカウントID）。同一企業から複数アカウントがあるが、企業単位への名寄せはまだできていない。
データ期間・対象環境・母集団：2025-10-01 〜 2026-09-30 の12か月。対象は日本国内の有料プラン契約アカウントのみ（無料トライアルのみで終了したアカウントは除外）。母集団 4,820 アカウント。
利用可能な行動・属性・購買・利用変数：
- 月次ログイン日数（中央値 8 日 / 四分位 3・8・17）
- 主要機能Aの月間実行回数（中央値 12 回 / 上位10%は 90 回以上 / 0 回のアカウントが全体の 21%）
- 主要機能Bの月間実行回数（中央値 2 回 / 0 回が全体の 58%）
- 契約プラン（Light 2,980円 = 61% / Standard 9,800円 = 32% / Business 29,800円 = 7%）
- 契約継続月数（中央値 7 か月 / 12か月以上が 24%）
- 直近3か月の課金停止申請フラグ（全体の 6.1%）
- サポート問い合わせ件数（12か月合計。0件が 72%、5件以上が 4%）
- 登録時に自己申告した業種（12分類。ただし未回答が 38%）
- 登録時に自己申告した従業員規模（5分類。未回答が 41%）
- 請求先の都道府県（未回答なし）
達成したい成果指標：12か月後の継続率。現状 61%。副次的に Standard 以上へのアップグレード率（現状 年間 8%）。
到達可能なチャネル：アプリ内メッセージ、登録メールアドレスへのメール、カスタマーサクセス担当による個別連絡（月あたり最大 120 アカウントまで）。
最小セグメント規模・運用制約：1セグメント 200 アカウント以上。運用できるセグメント数は同時に最大 5 つ。施策の内製リソースは月 1 人分。
同意・人権・利用禁止変数：性別・年齢・国籍・信条・健康に関する情報は保持しておらず、取得もしない。請求先都道府県は保持しているが、地域による価格差や提供内容の差をつける目的では使わない。登録時の自己申告項目は「サービス改善のため」という同意文で取得しており、外部への提供はしていない。
既存セグメント：現在は「プラン別」（Light / Standard / Business）でしか分けておらず、それ以外の切り口は運用していない。

手順：
- 欠損、外れ値、重複、リーケージ、期間差、分析単位の混在を点検する。
- 成果と施策に関係する変数だけを選び、人口属性だけに依存しない。
- データ量と目的に応じ、ルールベース/統計的クラスタリングの適否を選ぶ。
- セグメントをMeasurable、Accessible、Substantial、Differentiable、Actionable、Stableで評価する。
- 別期間または保留データで再現性と成果差を確認する。
- 各セグメントを配信条件・オファー・KPIへ接続する。

出力：
1. データ品質診断
2. 採用/除外変数と理由
3. 分析方法と再現手順
4. セグメント定義表（条件、規模、行動、価値、到達手段）
5. 妥当性・安定性評価
6. 優先順位と施策設計
7. GA4等へ実装する場合の包含/除外条件
8. 更新頻度とモニタリング
9. 未確定事項

集計値や生データが無い場合、クラスタ結果を作らず分析仕様だけを返してください。

生データがないため、実在するクラスタや成果差は作らず、**「分析仕様＋本番で採用する候補セグメント設計」**としてまとめます。今回の条件なら、K-meansのような説明用クラスタより、成果指標に紐づく制約付き決定木＋運用ルールが適しています。

編集
1. データ品質診断
結論

現状のデータだけで「12か月後継続率が高い／低いセグメント」を確定することはできない。

最大の理由は、分析期間が2025-10-01〜2026-09-30の12か月しかなく、行動を観測する期間と、その後12か月の継続結果を分離できないためである。

たとえば2026年6月時点の利用行動から12か月後継続を予測しようとしても、結果は2027年6月まで必要になる。

したがって現時点では、

セグメント設計

集計仕様

ルール候補

検証方法

までを確定し、12か月成果差については追加期間取得後に判定する。

データ品質上の主要論点
論点	診断	対応
分析単位	アカウント単位で統一されている	基本分析単位として採用
同一企業複数アカウント	企業内で施策効果が波及する可能性あり	将来企業IDを作成。現時点では制約として明示
業種欠損	38%	主セグメント条件には使わない
従業員規模欠損	41%	主セグメント条件には使わない
都道府県	欠損なし	分析・品質確認のみ。価格・提供差には使用しない
A実行回数	強い右裾。上位10%が90回以上	モデル分析時はlog1p変換も併用
B実行回数	58%が0回	「利用有無」と「利用量」を分離する
サポート問い合わせ	72%が0件、5件以上は4%	0/1以上＋回数の2変数化を検討
契約継続月数	成果と強く関係する可能性	スナップショット時点までの値のみ使用
課金停止申請	継続と極めて近い情報	分析モデルと運用トリガーを分離
月次利用量	契約月数の違いで観測量が異なる	「直近90日」等の固定lookbackに統一
部分月	新規契約月・解約月で利用機会が少ない	日数補正または部分月除外

特に注意すべきなのがリーケージである。

たとえば2026年6月を判定日とする場合、

2026年3〜5月の行動 → 2026年6月時点でセグメント判定 → その後の継続を見る

という時間方向にする。

2026年6月以降の問い合わせ回数や停止申請を説明変数に混ぜてはいけない。

2. 採用／除外変数と理由
本番セグメント候補として採用
変数	採否	用途
直近90日ログイン日数	◎	利用習慣・休眠判定
直近90日A実行回数	◎	コア価値到達判定
直近90日B実行回数	○	利用深度・用途幅の判定
契約プラン	◎	アップグレード可能性・価値
判定日時点の契約月数	◎	初期定着と長期利用を分離
直近90/180日問い合わせ	○	利用摩擦の検出
課金停止申請	◎※	「救済施策」のトリガーとして使用

※課金停止申請は通常セグメントの説明変数ではなく、最優先の「Saveトリガー」として別扱いする。

主セグメントには使わない
変数	理由
業種	欠損38%かつ自己申告。まずプロファイリング用途
従業員規模	欠損41%。同一企業複数アカウント問題もある
都道府県	施策差をつけない方針。セグメント条件に不要
12か月問い合わせ総数	判定日より未来の情報が混入する可能性
12か月平均利用量	新規/長期ユーザー間で比較条件が揃わない

業種・従業員規模は捨てるのではなく、作成した行動セグメントについて

「どんな企業属性が多いか」

を後から説明する用途に限定する。

3. 分析方法と再現手順
推奨方式

教師あり・制約付き決定木によるセグメンテーションを第一選択とする。

K-meansなどの統計クラスタリングを第一選択にしない理由は、今回の目的が

「似た顧客をまとめること」

ではなく、

「継続率・アップグレード率が異なり、施策を変えられる集団を作ること」

だからである。

分析フロー
STEP 1：月末スナップショットを作る

各アカウントについて判定日を設定し、そこから過去90日を説明変数期間とする。

例：

snapshot_date

login_days_90d

feature_A_count_90d

feature_B_count_90d

support_count_90d

plan_at_snapshot

tenure_months

stop_request_before_snapshot

を1行にする。

STEP 2：成果を定義する

主KPI：

retained_12m

= snapshotから365日後も有料契約が継続していれば1。

アップグレードKPI：

upgraded_12m

= snapshot時点Lightのユーザーが12か月以内にStandardまたはBusinessへ移行した場合1。

一時的なアップグレード後すぐダウングレードしたケースをどう扱うかは事前定義する。

STEP 3：課金停止申請者を分離

停止申請済みアカウントは通常モデルから外し、

Saveセグメント

として独立させる。

全体の6.1%なので、概算約294アカウントとなり、200アカウント以上という運用条件も満たす可能性が高い。

STEP 4：残りを制約付き決定木で分割

推奨制約：

max_leaf_nodes：4

max_depth：3程度

min_samples_leaf：200

説明変数は事前確定したもののみ

剪定あり

Saveセグメントを合わせて最大5セグメントにする。

STEP 5：アップグレード差を確認

継続率ベースでできた各leafについてLightユーザーだけ抽出し、

12か月アップグレード率

Standard移行率

Business移行率

を比較する。

高利用Lightに明確なアップグレードliftが見つかった場合のみ、1leafを「Expansion」に置換する。

4. セグメント定義表

以下は採用候補となる運用設計であり、人数・成果差は生データ検証後に確定する。

セグメント	暫定包含条件	規模	行動状態	顧客価値/課題	主な到達手段
S1 Save	直近3か月停止申請=1	約294※	解約意思表明済み	最も即時性の高い継続課題	CS＋メール
S2 Activate	Stop=0 AND 低ログイン AND A未利用/低利用	未確定	価値体験前	初期定着の失敗	メール＋アプリ内
S3 Deepen	Stop=0 AND A利用あり AND 利用幅/頻度が中程度	未確定	一部価値は実感	習慣化・B等への利用拡張余地	アプリ内中心
S4 Expand	Stop=0 AND Light AND 高頻度利用	未確定	プランに対して利用強度が高い	Standardへのアップグレード候補	アプリ内＋メール
S5 Maintain	Stop=0 AND 高利用・安定利用、S4以外	未確定	定着済み	継続維持・ロイヤルティ	低コスト自動接点

※6.1%×4,820の概算。

閾値について

以下のように最初から固定しない。

たとえば、

ログイン3日以下

ログイン17日以上

A=0

A>=90

は候補境界として有用だが、分位点だからという理由だけでセグメント条件にはしない。

実データ上、

「ログイン3日以下で継続率が急落する」

と確認できれば採用する。

決定木による候補閾値と、業務上理解可能な数字の両方を比較して最終決定する。

5. 妥当性・安定性評価

各セグメントを以下で採点する。

評価軸	判定方法
Measurable	GA4/DB/CDP上で毎月同条件で計算できる
Accessible	メール・アプリ内・CSのいずれかで接触可能
Substantial	200アカウント以上
Differentiable	継続率またはアップグレード率に意味のある差が存在
Actionable	セグメント間で実施施策が異なる
Stable	月を変えても極端に構成が崩れない
推奨採用基準

候補セグメントは最低限、

n >= 200

期間を変えても同方向の成果差

施策が具体的に変わる

単なるプラン別説明になっていない

ことを満たす。

安定性確認では、

月別セグメント構成比

セグメント移動率

継続率

アップグレード率

特徴量分布

を追跡する。

保留データ検証

ランダム分割より時間分割を優先する。

例：

Training
→古いeligible snapshot

Validation
→その次の期間

Final holdout
→最も新しい12か月結果確定済みsnapshot

とする。

同一アカウントが学習・テスト双方に何度も登場すると過大評価しやすいため、アカウント単位の重複にも注意する。

6. 優先順位と施策設計
優先順位1：S1 Save

停止申請者は全体6.1%、概算294件。

CS対応可能数が月120件なので、全員を人手対応するのではなく、

CS対象120件＋自動対応残り

にする。

CS優先度は、

Standard / Business

利用頻度が高かったのに急減

長期契約

直近問い合わせあり

等からスコアリングする。

オファーは単純値引きではなく、

解約理由確認

利用方法改善

設定サポート

適切なプラン提案

を優先する。

KPI：

停止申請撤回率

30/90日有料継続率

最終的な12か月継続率

優先順位2：S2 Activate

主な対象は、

「契約しているがAという中心価値まで到達していない」

ユーザー。

A=0は全体21%あるため、母集団として十分大きい。

アプリに来ないユーザーも多いと考えられるため、

メールを主、アプリ内を従

とする。

施策：

最短でAを1回成功させる導線

初回設定チェック

具体的利用例

1クリックで再開できる導線

KPI：

14日以内A初回実行率

30日ログイン復帰率

90日継続率

12か月継続率

優先順位3：S4 Expand

Lightは全体61%と最大なので、アップグレード改善の中心となる。

ただし、

「Lightだからアップセルする」

では現在のプラン別セグメントと変わらない。

対象は、

Lightの中で利用強度が明らかに高いアカウント

に絞る。

施策：

「Standardがおすすめです」

ではなく、

「現在の利用状況ならStandardにすると何が改善するか」

を具体的に提示する。

KPI：

Standard以上への30/90日移行率

年間アップグレード率

アップグレード後90日継続率

優先順位4：S3 Deepen

Aは使っているが、

Bを使っていない

ログイン習慣が弱い

一用途だけ

などのユーザー。

ただしB=0が58%あるため、

B未利用そのものを問題扱いしてはいけない。

B利用者の方が本当に継続しやすいのかを検証した上で施策対象にする。

優先順位5：S5 Maintain

高定着ユーザー。

人手CSを大量投入せず、

新機能案内

活用事例

フィードバック依頼

アップデート通知

など低コストの自動施策を基本とする。

この層に大量の人的リソースを使わないこと自体が、セグメンテーションの価値になる。

7. GA4等へ実装する場合の包含／除外条件

最も安全なのは、GA4内部で複雑なロジックを再現するのではなく、

バックエンドでsegment_idを計算し、GA4へuser propertyとして渡す方法。

例：

customer_segment

save

activate

deepen

expand

maintain

とする。

メールアドレス、会社名などの個人識別情報はGA4へ送らない。

概念的な判定順
IF stop_request = 1
    => SAVE

ELSE IF low_engagement AND low_A_usage
    => ACTIVATE

ELSE IF plan = LIGHT AND high_usage
    => EXPAND

ELSE IF partial_adoption
    => DEEPEN

ELSE
    => MAINTAIN

順番は重要である。

たとえば高利用Lightでも停止申請中なら、

ExpandではなくSave

として扱う。

除外条件

共通除外：

無料トライアルのみ

海外アカウント

無効/テストアカウント

社内アカウント

データ不足期間

判定前に解約済み

月途中契約で十分な観測期間がない場合は、

segment = insufficient_history

として一時的に分析対象から外す方法も推奨する。

8. 更新頻度とモニタリング
セグメント更新

月1回

を推奨する。

毎日更新すると、一時的な利用変動でセグメントが頻繁に変わりすぎる。

ただし停止申請だけはイベント発生時に即時Saveへ変更する。

つまり、

通常セグメント：月次更新

Saveトリガー：リアルタイム

とする。

月次モニタリング

見る指標：

各セグメント人数

構成比

前月からの移動

ログイン量

A/B利用

施策配信率

開封/クリック等の中間KPI

30/90日継続

12か月継続

アップグレード率

「成果だけ」ではなく、

各セグメントに想定した行動特徴が残っているか

も監視する。

9. 未確定事項

分析開始前に以下を確定する必要がある。

12か月継続の定義

365日後時点で契約中なら継続か

途中で一度解約→再契約は継続扱いか

支払失敗は解約扱いか

一時休止制度がある場合どう扱うか

アップグレードの定義

Light→Standardのみ対象か

Light→Businessも同じ1件か

Standard→Businessも含めるか

一時的なアップグレードも成功扱いか

利用変数の粒度

現在提示されている中央値等ではなく、

アカウント×月

の行データが必要。

最低限必要なのは、

account_id
month
plan
paid_status
login_days
feature_A_count
feature_B_count
support_count
stop_request
contract_start_date
plan_change_date
cancel_date

である。

観測期間

最終的に12か月後継続を検証するため、

説明変数期間＋12か月後結果

を確保する。

直近90日を説明変数にするなら、少なくとも15か月以上、実務上は24か月程度の履歴が望ましい。

最終提案

今回の4,820アカウントでは、

「似ている顧客を5群に分類する」アプローチは採らない。

目指す構造は、

Save → Activate → Deepen → Expand → Maintain

の最大5状態である。

このうち、

Saveは明確な業務ルール、

残り4つは12か月継続率を目的変数とした制約付き決定木

から閾値を決める。

これにより、

「40代・東京・IT企業」

のような説明だけの分類ではなく、

誰に、何を、どのチャネルで、何のKPIを改善するかまで変えられるセグメント

になる。

なお現状の12か月データだけでは、これらのセグメント別12か月継続率や最適閾値を確定できないため、人数・成果差・クラスタ結果については未算出とする。

この設計なら、次にアカウント×月のCSVが用意できれば、「どこで切れば継続率が何ポイント変わるか」「実際に各セグメントが何人になるか」まで機械的に確定できる形になっています。