コホート維持率電卓
顧客コホート分析用の維持曲線を作成します。コホートの初期サイズと、1日目、7日目、30日目(または独自のカスタム期間)の「アクティブユーザー数」を入力します。各チェックポイントでの維持率、期間ごとの離脱率、コホートの半減期、スマイル曲線/PMF平坦化検出器、業界クォータイルベンチマーク、ヒートマップ付きアニメーション維持曲線、および定常状態の維持フロアを外挿するベキ乗則フィッティングを取得できます。
広告ブロッカーにより広告が表示できません
MiniWebtool は広告収益で無料提供しています。このツールが役に立ったら、Premium(広告なし+高速)をご利用いただくか、MiniWebtool.com を許可リストに追加して再読み込みしてください。
- または Premium(広告なし)にアップグレード
- MiniWebtool.com の広告を許可してから再読み込みしてください
コホート維持率電卓
維持率コホート電卓は、コホートの規模とアクティブユーザー数のリストを、完全な維持率の図へと変換します。すべてのチェックポイントでの維持率、アニメーション付き維持曲線、色分けされた期間ごとの減少ヒートマップ、コホートの半減期、スマイル曲線 / プロダクトマーケットフィット平坦化検出機能、定常状態の外挿を伴うべき乗則のフィッティング、そしてSaaS、モバイル、コンシューマーサブスクリプション、eコマース、フィンテックのコホートにおける公開業界ベンチマークに対する四分位数分類が含まれます。単一の割合しか出せないチャーン電卓とは異なり、コホート維持曲線は減少の形状を捉えます。そして、単一の数値ではなくその形状こそが、プロダクトが定着しているかどうかを教えてくれるのです。
使い方
- コホートの規模を入力します — これは同じ期間(登録週、有料転換月、インストール日など)に獲得したユーザーの数です。
- 測定単位を選択します。モバイルアプリは通常「日」、B2Cサブスクリプションは「週」、B2B SaaSは「月」で測定します。
- チェックポイントの期間をカンマ区切りのリストで入力します。デフォルトの
1, 7, 14, 30, 60, 90は古典的なモバイルアプリのスケジュールです。B2B SaaSの場合は1, 2, 3, 6, 9, 12ヶ月をお試しください。 - 各チェックポイントのアクティブユーザー数を同じ順序で入力します。各値は、元のコホートのうちそのチェックポイントでまだアクティブなユーザーの数です。分母を決して再基準化しないでください。
- 最も近い業界ベンチマーク(B2B SaaS、SMB SaaS、コンシューマー向けサブスクリプション、モバイルアプリ、eコマース、またはフィンテック)を選択します。
- 維持曲線を構築をクリックすると、各チェックポイントでの維持率、アニメーション曲線、減少ヒートマップ、半減期、スマイル曲線の判定、べき乗則のフィッティング、および四分位数分類が表示されます。
使用されている計算式
期間 t における維持率: R(t) = 期間 t におけるアクティブユーザー数 ÷ コホートの規模
期間ごとの減少 (pp): drop(t) = R(t−1) − R(t) (パーセンテージポイント単位)
コホートの半減期: R(t) = 0.5 となる期間。チェックポイント間の線形補間によって算出されます。
スマイル曲線 / 平坦化テスト: 過去3つの維持率チェックポイントの広がりが2pp以下 ⇒ 強力な平坦化(PMFシグナル)、平均減少が1.5pp以下で5pp以下 ⇒ 緩やかな平坦化、それ以外はまだ減少中
べき乗則のフィッティング: R(t) ≈ a · t^(−k)。両対数変換に対する最小二乗法によって log R = log a − k · log t を解きます。
定常状態の予測: 適合された a と k を t = 3 × 最後に観測された期間(最大365)に適用します。
業界四分位数分類: 最も近い一致のチェックポイントを、選択された業界セグメントの公開されている P25 / P50 / P75 維持率バンドと比較します。
このコホート電卓が他と違う理由
- 単一の数値ではなく、曲線を表示。 ほとんどの「維持率電卓」は単一の割合を計算するだけです。この電卓は、ユーザーが定義した最大10個のチェックポイントで完全な維持曲線を構築します。この形状こそが、コホートが底に達しているのか、それとも流出し続けているのかを明らかにします。
- スマイル曲線 / PMF平坦化検出機能。 過去3つのチェックポイントを対象とした組み込みテストにより、コホートを「強力な平坦化」(古典的な Sean Ellis の PMF シグナル)、「緩やかな平坦化」、または「まだ減少中」に分類します。
- 補間によるコホート半減期。 チェックポイント間の線形補間により、単にそのラインを越えたかどうかだけでなく、コホートの50%がチャーンした正確な期間の推定値を提供します。
- べき乗則のフィッティングと定常状態の予測。 両対数変換に対する最小二乗法(OLS)が
R(t) = a · t^(−k)をフィッティングし、R²を報告し、フィッティングが良好な場合は最後に観測された期間のおよそ3倍の期間まで維持率を予測します。 - 減少ヒートマップ。 期間ごとの減少が緑(2pp以下)から深紅(50pp超)まで色分けされるため、最も影響の大きい流出箇所が一目でわかります。
- 業界四分位数ベンチマーク。 6つのセグメント別ベンチマーク(B2B SaaS、SMB SaaS、コンシューマーサブスクリプション、モバイルアプリ、eコマース、フィンテック)が、自社の1日目、7日目、30日目相当の数値を公開されている P25 / P50 / P75 バンドに対して分類します。
- アニメーション付きSVG曲線。 線が描かれ、領域が塗りつぶされ、数値ラベルが順番にポップアップするため、単なる静的なプロットではなく、減少が視覚的に明らかになります。
- 日、週、月単位の選択。 プロダクトの自然なサイクルに一致する時間軸を選択します。モバイルアプリは「日」単位、B2Bは「月」単位で動きます。
- 送信前のライブプレビュー。 数値を入力すると、ミニバーのプレビュー、パーセンテージ、PMFバッジが即座に更新されます。ページ全体をリロードする必要はありません。
- ステップバイステップの数学。 すべての計算が一行ずつ分解されているため、結果を検証、記録、または学習することができます。
そもそもコホートとは何ですか?
コホートとは、同じ時間枠内に獲得イベントを共有したユーザーのグループのことです。最も一般的なのは、登録、インストール、または最初の購入を行った週、日、または月です。コホート分析は、その後の期間にわたってその同一の固定グループを追跡するため、分母が変化することはありません。これにより、コホート維持率は、獲得の成長の影に加速するチャーンを隠してしまう可能性のある「総ユーザー数で割った月間アクティブユーザー数」よりも、厳密に誠実な指標となります。
維持率 vs チャーン率
維持率とチャーン率は、任意の期間において互いに逆の関係にあります:維持率 = 1 − チャーン率。チームがどちらか一方を選択する理由は、数学的というよりも心理的なものです。数値を「5%のチャーン」ではなく「95%の維持」と表現する方が、損失の防止から防衛の祝福へと注意を向ける傾向があります。維持率のコホート版は、期間チャーンよりも有益です。なぜなら、時間の経過とともに同じユーザーを追跡し、どこに流出があるかを明らかにするからです。1日目に50%のチャーンがあった後に完全に平坦な維持率が続くコホートは、緩やかで永続的な減衰が続くコホートとは根本的に異なり、より優れたコホートと言えます。
維持曲線の形状の読み方
- 初期の急激な低下、その後の平坦なテール(「スマイル」)。 獲得したほとんどのユーザーは適合しませんでしたが、安定したコア層がプロダクトを不可欠なものとして捉えています。これは教科書的なプロダクトマーケットフィットの形状であり、その底の広さは、獲得したセグメント内における真の獲得可能最大市場(TAM)の規模を表します。
- 緩やかで一定の減衰。 低頻度プロダクト(年一回購入のアイテム、税務ツール、結婚式計画アプリなど)によく見られる形状です。必ずしも悪いわけではありませんが、ユニットエコノミクスは水準ではなく、その傾きに依存します。
- 初期は平坦で、その後突然の低下。 ほぼ間違いなく強制解約イベントです — トライアルの終了、決済の失敗、年間契約の非更新など。ユーザーの行動による原因ではなく、構造的な原因を探してください。
カテゴリー別の維持率ベンチマーク
| セグメント | 1日目 (P50) | 7日目 (P50) | 30日目 (P50) | 備考 |
|---|---|---|---|---|
| B2B SaaS | 80% | 60% | 45% | 年間契約のバイアスによりD30が膨らみます。有効年間維持率を確認してください。 |
| SMB SaaS | 65% | 45% | 30% | プロダクトの適合性ではなく、ビジネスのボラティリティによってベースチャーンが高くなります。 |
| コンシューマーサブスクリプション | 55% | 35% | 20% | エンゲージメントが底を支えます。習慣性の高いプロダクトが優位に立ちます。 |
| モバイルアプリ | 35% | 18% | 9% | 初日の低下が支配的です。D1 → D7 が最もレバレッジの高いコホートです。 |
| eコマース / DTC | 45% | 22% | 12% | 「一回試してみる」という行動が、初期の高いチャーンを引き起こします。 |
| フィンテックアプリ | 50% | 30% | 18% | アクティベーションがKYCや入金によって制限されることが多く、最初のセッションが遅くなります。 |
AppsFlyer、Mixpanel、Amplitude、OpenView、RJMetrics の公開レポートから推測された四分位数です。業界標準ではなく、大まかな方向性として扱ってください。
コホート分析のよくある落とし穴
- 分母の再基準化。 すべてのチェックポイントにおいて、常に元のコホート規模で割るようにしてください。「前の期間にまだアクティブだったユーザー」で割ると、ステップごとに維持率が過大に評価され、流出が見えなくなります。
- 「アクティブ」の定義の混同。 30日目の維持率は、ログイン、意味のあるアクション、または課金ステータスのどれで測定されましたか?それぞれ異なる曲線を描きます。1つを選択し、一貫して報告してください。
- コホート維持率と売上維持率の混同。 コホートのロゴ(ユーザー数)維持率はすべてのユーザーを等しく扱います。ネット売上維持率(NRR)は金額で重み付けします。価格帯が幅広いプロダクトでは、これらは激しく乖離します。
- 不十分なコホート規模。 ユーザー数が約500人未満のコホートは、長い時間軸において維持曲線の信頼区間が広くなり、個々のユーザーの再アクティブ化によって曲線が目に見えて変動する可能性があります。小さなコホートを過剰に解釈するのではなく、隣接するいくつかの獲得週を合算してください。
- まだ減少しているテールを底として読み取ってしまう。 3つのポイントがほぼ平坦に並ぶことが、PMF平坦化の最低限のシグナルです。平坦に見える1つのポイントは、ノイズの可能性があります。
- 曲線の形状の無視。 急激な低下+平坦なテールによる30%の30日目維持率は、緩やかで一定の減衰による30%とは根本的に異なります。数値は同じでも、意味合いは真逆です。
- 強制解約によるノイズ。 トライアルの終了、決済の失敗、年間契約の更新は、予測可能な期間において人為的な低下を生み出します。それらに注記を入れ、プロダクト起因のチャーンとして読み取らないようにしてください。
維持率が顧客生涯価値を向上させる仕組み
維持率が高くなると、顧客の寿命が長くなり、顧客生涯価値(CLV)が直接的に増加します。最も単純なCLVの計算式は、CLV = (月間ARPU × 売上総利益率) ÷ 月次チャーン率 です。同等に、CLV = (月間ARPU × 売上総利益率) × 月単位の平均顧客寿命 となります。寿命はチャーンの逆数であるため、5%の月次チャーンベースにおいて維持率が1パーセンテージポイント向上すると、寿命は20ヶ月から25ヶ月へと延び、同一のARPUでCLVが25%向上することになります。プロダクトが緩やかな規模に達した後は、通常、維持率への投資が同じ金額レベルの獲得への投資を上回る成果を出すのはこれが理由です。
維持率を改善するために最初に確認すべき場所
- 最初の期間のアクティベーション。 ほとんどの曲線で最も急激に低下するのは、0日目と1日目の間(または0週目 → 1週目)です。オンボーディングの明確さ、最初の価値を実感するまでの時間(time-to-first-value)、およびプロアクティブなアクティベーションへのアプローチが、通常最も高いレバレッジを持ちます。
- 強制解約の瞬間。 トライアルの終了や更新の瞬間は、予測可能な期間にチャーンを集中させます。プロダクトへのエンゲージメントを責める前に、これらの構造的な瞬間に対してコホートの低下をマッピングしてください。
- 決済失敗のリカバリー。 「チャーン」の驚くべき割合は、単なるクレジットカードの有効期限切れです。カード更新ツールや督促(ダニング)シーケンスは、ほとんどのB2C SaaSにおいて月次チャーンの5〜15%を回収します。
- パワーユーザーの特定。 最後のチェックポイントでまだアクティブなコホートメンバーは、最も定着性の高いセグメントです。彼らが共有しているもの(機能の使用状況、インテグレーションの採用、チームの規模など)を確認し、類似のユーザーを獲得ターゲットに設定してください。
- コホートのセグメンテーション。 コホート全体が平坦化しない場合は、セグメントに分割してください。多くの場合、全体としては凡庸な曲線の中に、1つの獲得ソースや1つのペルソナがPMFを達成しているケースが隠れています。
FAQ
コホート維持率とは何ですか?
コホート維持率とは、単一の獲得コホートのうち、後のある時点でまだアクティブなユーザーの割合のことです。チェックポイントにおけるアクティブユーザー数を元のコホート規模で割ったものに等しく、パーセンテージで表されます。コホートの分母は固定されているため、維持率は単調に減少します — すべてのチャーンが維持率を下げ、再アクティブ化によって維持率が膨らむことはありません。
コホート維持率は月次維持率とどう違うのですか?
月次維持率は通常、月間アクティブユーザー数を総登録ユーザー数で割ります。この数値は、新規の獲得が穴を埋めるため、獲得したコホートが流出していても横ばいまたは成長する可能性があります。コホート維持率は時間の経過とともに固定されたグループを追跡するため、獲得の成長によって隠されることはありません。プロダクトの定着性を評価するにはコホート維持率の方が厳密に誠実であり、トップラインの成長報告には月次維持率の方が有用です。
どのチェックポイントを使用すべきですか?
古典的なモバイルアプリのスケジュールは、1日目、7日目、14日目、30日目、60日目、90日目です — 初期の流出を捉えるのに十分短く、底が形成されるのを確認するのに十分な長さです。B2Cサブスクリプションの場合は週次のチェックポイントを、B2B SaaSの場合は月次のチェックポイントをお試しください。電卓は、2〜10個の厳密に昇順の整数値をサポートしています。
コホート分析におけるスマイル曲線とは何ですか?
スマイル曲線とは、初期に急激に低下し、その後安定した底へと平坦化する維持曲線のことです。この平坦化は、プロダクトマーケットフィット(PMF)を示す Sean Ellis の古典的なシグナルです。獲得したユーザーの安定した割合が、プロダクトを本当に不可欠なものであると感じていることを示しています。減衰し続ける曲線はスマイルに達することはなく、そのセグメントにおいてプロダクトがまだ定着するユースケースを見つけていないことを示します。
30日目の良好な維持率とはどれくらいですか?
30日目の良好な維持率は、プロダクトのカテゴリーに大きく依存します。B2B SaaSの上位四分位のコホートは、30日目で65%以上を維持します。SMB SaaSの上位四分位は約45%です。コンシューマーサブスクリプションは通常、中央値で20%です。モバイルアプリは通常、中央値で9%、上位四分位で18%です。電卓は、選択したセグメントの適切なベンチマークに対して、あなたの30日目の数値を位置づけます。
半減期の計算はどのように行われるのですか?
半減期とは、維持率が50%をまたぐ期間のことです。電卓はチェックポイントをスキャンして、維持率50%を挟む最初のペアを見つけ、それらの間で線形補間を行います。観察ウィンドウ内で維持率が50%を下回らなかった場合、半減期は「データ範囲外」となり、強力な定着性の指標となります。
べき乗則のフィッティングは何を教えてくれるのですか?
ほとんどのコホート維持曲線は、べき乗則 R(t) = a · t^(−k) に近似します。電卓は、両対数変換に対する最小二乗法を用いてチェックポイントにこのモデルを適合させ、適合度(R²)を報告します。R²が90%を超える場合、べき乗則は曲線をよく要約しており、最後に観測された期間のおよそ3倍の期間までのモデルの外挿は、維持率がどこに向かっているのかを示す意味のある予測となります。R²が低い場合は、通常、滑らかなべき乗則モデルでは捉えきれない構造的な変曲(トライアル終了、更新イベント)を示しています。
これをユーザー維持率ではなく、売上維持率に使用することはできますか?
はい — 獲得時のコホートの総売上をコホートの規模として入力し、各チェックポイントでそのコホートからまだ回収されている売上を入力します。電卓はユーザーが入力されたのかドルが入力されたのかを区別しないため、数学的にはまったく同じように機能します。これにより、売上総維持率(GRR)が得られます。拡張(エクスパンション)を含めたネット売上維持率(NRR)を計算するには、分子に拡張売上を加える必要がありますが、電卓はこれを直接行うことはしません。
数値が意味を持つためには、何人のコホートメンバーが必要ですか?
大まかな規則として、500ユーザー未満のコホートは長い時間軸においてノイズの多い維持曲線になりやすく、個々のユーザーの再アクティブ化によって曲線が目に見える量だけシフトすることがあります。統計的な堅牢性を高めるには、隣接する獲得期間を合算するか(複数週の登録ユーザーを1つのコホートにまとめる)、各維持率のポイントを単一の数値ではなく信頼区間として扱ってください。
このコンテンツ、ページ、またはツールを引用する場合は、次のようにしてください:
"コホート維持率電卓"(https://MiniWebtool.com/ja//) MiniWebtool からの引用、https://MiniWebtool.com/
miniwebtool チーム作成。更新日: 2026-05-18