詳細ガイド
認証MAUコストシミュレーター:ユーザー単位課金の認証と自社運用の認証を比較
業界のエグゼクティブ分析
認証は、すべてのユーザーが触れるのに、価値を感じるユーザーはほとんどいない、製品の中でも珍しい部分です。ホスト型プロバイダーが月間アクティブユーザー単位で課金するのは、その指標が自社のコストに比例するからで、若い製品にとっては公平に感じられます。最初の1万人は無料で、その後は1人あたり数セントというケースも多いでしょう。リスクは、料金がサインインの数に応じて増える一方で、収益は有料ユーザーというごく一部の割合にしか応じて増えないことです。コンシューマー向けアプリ、フリーミアムのツール、マーケットプレイスでは、収入より先にユーザーが増えることがあり、認証の請求額は後者ではなく前者の曲線に沿って増えていきます。
この問題の構造は、コストの要因と収益の要因が食い違っていることです。コストは、無料ユーザー、トライアルアカウント、ボット、放置されたセッションを含め、アクティブなすべての人に課金されます。収益は支払うユーザーからしか入ってこず、その割合は通常、ユーザー全体の1桁台前半のパーセントです。この2つの比率、つまり有料ユーザー1人あたりの認証コストこそ注視すべき数字です。これが数セントから数ドルへと上がっていくと、ベンダーがあらゆるプランからひそかに取り分を得ていることになり、ユーザーが1万人のときに成り立っていたプラン価格は、30万人では通用しなくなります。
ドミノモデルは、お金の流れを5つの段階でたどります。アクティブユーザーに、課金されるボットアカウントを加えたものが課金対象の数を決めます。その数とSMSの量が、有料ユーザー1人あたりの認証コストを決めます。それを売上に対して配分したものが、認証の負担です。ホスティング、サポート、エンジニアリングを差し引いた残りが貢献利益で、固定費を引いた後に月が黒字で終わるかどうかが決まります。ボットによる登録や、テキストメッセージによる本人確認を使うユーザーの割合がわずかに増えるだけで、最後のボックスが変わるよりずっと前に、2つ目のボックスが黄色から赤へ変わることがあります。
氷山は、請求書に表れないものを示します。水面上にあるのは、実在ユーザー分のプロバイダー請求額と、一般的なホスティング費用です。水面下にあるのは、アクティブユーザーとして数えられるボットや偽の登録、メッセージ単位で課金されるSMSコード、サポートチームが対応するログインやロックアウトの問い合わせ、そして連携を維持するために費やされるエンジニアの時間です。自社運用ならユーザー単位の料金はなくなりますが、同じ項目が自社の人件費に移るだけなので、正直な比較とは、時間をかけた総コストの比較です。このシミュレーターで、2本の線が交差するユーザー数を探してみてください。
計算式と方法論の設計図
モデルは月単位で動きます。課金対象ユーザーは、アクティブユーザーに一定割合のボットアカウントを加えたものです。ベンダーは、1万人の無料枠を超えた課金対象ユーザーすべてに単価を課します。売上は、アクティブユーザー数に有料の割合と有料ユーザー1人あたりの売上を掛けたものです。この売上から、固定割合のホスティングとサポート、ベンダーの請求額、SMSコード、ロックアウトに関する問い合わせ、人件費込みの単価で換算したエンジニアの時間、そして月次の固定費を差し引きます。
- 課金対象ユーザー
- B = MAU × (1 + ボットの割合)
- アクティブとして数えられ、実在ユーザーと同じように課金されるボットや偽の登録です。
- ベンダーの請求額
- A = max(0, B − 10,000) × MAU単価
- 無料枠を超えた分のプロバイダー料金で、オプションは含みません。
- SMSとサポート
- S = MAU × 多要素認証の割合 × 2 × SMS単価 + MAU × 0.4% × 問い合わせ単価
- テキストメッセージのコードと、ログインやロックアウトの問い合わせに対応するコストの合計です。
- 有料ユーザー1人あたりの認証コスト
- (A + SMS) ÷ (MAU × 有料の割合)
- 有料顧客1人が毎月負担しなければならない認証の費用です。
- 純利益
- 純利益 = 売上 − ホスティング − A − SMS − サポート − エンジニアリング − 固定費
- 月次の結果です。破綻点は、これがゼロになる点です。
連鎖する弾力性
有料の割合と有料ユーザー1人あたりの売上は、売上の全体に掛かるため、最も感応度の高い入力です。次に大きいのが追加MAUあたりの単価で、ボリュームが大きいと1ユーザーあたり1セントの差も大きな金額になります。エンジニアの時間とSMSの割合は影響が小さい代わりに継続的で、最も減らしやすい項目です。アクティブユーザー数は両方向に働きます。ユーザーが増えれば請求額は増えますが、有料の割合が保たれる限り、売上はそれより速く増えます。
実例に基づく3つのケーススタディ
自己資金で始めるスタートアップ
無料枠に収まる小さなアプリ
若い製品に2万人のアクティブユーザーがいて、6%という健全な割合が有料で、ユーザーの大半が無料枠に収まるため請求額は控えめです。エンジニアの工数も小さく済みます。これを読み込むと、初期にはホスト型認証がいかに快適で、この規模ではベンダー料金がいかに小さな問題かがわかります。
成長中の中堅企業
コンバージョンの高い成長中のプラットフォーム
アクティブユーザーが30万人のプラットフォームで、3.5%が有料に転換し、プラン価格は高めに設定されています。ベンダーの請求額は絶対額では大きいものの、売上で十分に賄えています。これを読み込むと、有料ユーザーがユーザー全体を支えているならユーザー単位の課金でも問題ない理由と、自社運用が意味を持ち始める地点がわかります。
ブラックスワン級の危機
有料ユーザーが少ないまま拡散した無料アプリ
無料ツールが拡散して35万人のユーザーに達しますが、有料なのは1%未満です。半数のユーザーにSMS認証が有効になり、ボットも数に加わり、ベンダーはアカウントを上位のプランへ移します。これを読み込むと、1か月のうちに認証コストが売上を上回る様子がわかります。
業界ベンチマーク一覧
| 指標 | 危険ゾーン | 業界平均 | 上位10%のエリート水準 |
|---|---|---|---|
| 売上に占める認証コストの割合 | 20%超 | 5~12% | 4%未満 |
| 有料ユーザー1人あたりの認証コスト | 月額$3.50超 | $0.50~$1.50 | $0.40未満 |
| アクティブユーザーに占める有料の割合 | 1%未満 | 2~5% | 8%超 |
| 登録のうちボットや偽アカウントの割合 | 15%超 | 3~8% | 2%未満 |
| 認証に費やす月間のエンジニア工数 | 60時間超 | 10~25時間 | 8時間未満 |
変数とレバー
月間アクティブユーザー数
その月にサインインした、またはセッションを保持していた個別の人数です。ベンダーが請求の基準にする数字です。
レバー: 休眠アカウントを整理し、アクティブユーザーの定義をベンダーの基準に合わせましょう。誰も使っていないセッションに料金を払わずに済みます。
有料ユーザーの割合
月間アクティブユーザーのうち有料プランを利用している人の割合です。無料ユーザーは認証コストを発生させますが、収益はもたらしません。
レバー: アクティベーションとアップグレードの案内を改善しましょう。有料にならない無料ユーザーも、認証の請求額を生み出しています。
有料ユーザー1人あたりの売上
割引後の、有料ユーザー1人あたりの月平均売上です。
レバー: 価格を引き上げるか、ヘビーユーザーを上位プランに移して、有料ユーザー1人あたりの売上がユーザー単位のコストに追いつくようにしましょう。
追加MAUあたりの単価
無料枠を超えたアクティブユーザーに対してプロバイダーが課す料金です。多くのプランでは、ボリュームが増えるほど段階が急になります。
レバー: コミット型のボリュームプランを交渉するか、ベンダーを比較しましょう。無料枠を超えたあとは、ユーザー単価が最も大きなレバーです。
SMS多要素認証を使うユーザー
毎月、テキストメッセージでワンタイムコードを受け取るアクティブユーザーの割合です。
レバー: 認証アプリとパスキーを優先して提供し、SMSは予備の手段にとどめましょう。テキストメッセージ1通ごとに直接のコストがかかります。
認証に費やすエンジニアの時間
連携の保守、移行、セッションのバグ対応、セキュリティレビューに毎月費やす時間です。
レバー: ログインフローを1つに統一してカスタムコードを削除しましょう。保守に費やす1時間ごとに、見えない人件費が積み上がります。
このシミュレーターの使い方
- 1分析ツールから、先月のアクティブユーザー数、有料の割合、有料ユーザー1人あたりの売上を入力します。
- 2ベンダーの請求書から追加ユーザーあたりの単価を設定し、SMSとボットの割合を見積もります。
- 35つのボックスを見て、どれが最初に黄色や赤に変わるかを確認します。
- 4「破綻点を探す」を押して、利益がゼロになるまでにユーザー数や単価がどこまで動けるかを確認します。
- 5移行コストを含め、ホスト型と自社運用の認証を24か月にわたって比較します。
避けたい間違い
- 総額ではなく表面上の価格を比べること。自社運用の選択肢は、パッチ適用、オンコール対応、セキュリティレビューをエンジニアの時間単価で数えるまでは無料に見えます。
- すべてのアクティブユーザーを同じ価値とみなすこと。100万件の無料セッションが生む認証コストは、10万人の有料顧客が稼ぐ額を上回ることがあります。
- ボットを無視すること。偽の登録やクレデンシャルスタッフィングの試行も実在ユーザーと同じように課金され、請求額を2桁のパーセントで押し上げることがあります。
- 現在のボリュームだけで計画すること。5万人では問題なく見える料金の段階が、50万人では状況を一変させることがあります。
よくある質問
MAU単位の課金は割に合わないのですか?
それ自体が悪いわけではありません。ユーザー数が少ないうちや、大半のユーザーが有料のうちは安く済みます。無料ユーザーや非アクティブなユーザーが多いと高くつくので、プランを決める前に有料の割合をモデル化してください。
認証を自社運用にすると有利になるのはいつですか?
通常は、ユーザー数が多く有料の割合が低い場合で、しかもエンジニアの時間を割けるときに限られます。ここで両方のシナリオを実行し、移行コストを含めた24か月の比較を確認してください。
なぜボットによる登録がモデルに含まれているのですか?
プロバイダーは通常、その月にサインインしたアカウントをすべてアクティブとして数えます。偽のアカウントも実在のアカウントと同じように課金されるため、ボット対策は費用に見合う可能性があります。
SMSコードは本当に大きなコストになるのですか?
1通あたりは小さな金額ですが、ユーザー数と月数を掛けると積み上がります。認証アプリやパスキーを使えばそのコストの大半がなくなり、一般にテキストメッセージより安全です。
破綻点はどうすれば見つかりますか?
「破綻点を探す」を押してください。ツールが各入力を不利な方向へ動かし、月次利益がゼロになる値を報告します。
この結果はどのくらい正確ですか?
前提を明示した教育目的のモデルであり、財務やセキュリティに関する助言ではありません。入力を実際の請求額と利用実績に置き換え、ベンダーの最新の料金も確認してください。
これは前提条件を明示した、教育目的の計画モデルです。財務、税務、法律に関する助言ではありません。入力値はご自身の数字に置き換え、重要な判断は必ず資格を持つ専門家に確認してください。