SaaSサブスクリプションデータモデル

SaaSソリューションを1つ以上の異なるプランで提供できるはずです。各プランにはさまざまなオプションが含まれています。たとえば、提供するすべてのオプションを含むプレミアムプランと、必需品のみを含む基本プランを作成できます。個別のプランはすべてプランに保存します テーブル。プランごとに、以下を定義します。

• plan_name –このプランに選択した名前。ソフトウェアへの参照（ software_id ）、これはこのテーブルの代替/一意キーを形成します。
• user_group_type_id –このプランを使用できるグループのタイプを示す参照。これは、シングルユーザーグループまたは標準グループの場合があります。このリファレンスでは、そのプランのグループメンバーの最大数も定義されています。プランで1つのサブスクリプションで5つの異なるアカウントが許可されている場合は、適切な user_group_typeを参照する必要があります 。
• current_price –このプランの現在の価格。
• insert_ts –このレコードが挿入されたときのタイムスタンプ。
• アクティブ –このプランがアクティブかどうかを示すフラグ。

同じソフトウェアのプランにはさまざまなオプションが付属することはすでに説明しました。すべての個別のオプションのリストは、 optionに保存されます 辞書。各オプションは、その option_nameによって一意に定義されます 。

さまざまなプランにオプションを割り当てるには、 option_includedを使用します テーブル。関連するプラン（ plan_id ）への参照を保存します ）とオプション（ option_id ）。このペアとdate_added 属性は、このテーブルのUNIQUEキーを形成します。 date_removed プランから特定のオプションを削除することを決定した場合にのみ、属性に値が含まれます。これは、古いオプションを置き換える新しいオプションを作成した場合、または使用する人がほとんどいないために特定のオプションを使用しないことにした場合に発生する可能性があります。

この主題分野の最後の部分は、特別オファーまたはプロモーションオファーに関連しています。一般に、そのようなオファーは、より少ないお金でより多くのサービスを顧客に提供し、一定期間持続します。これらは、新規顧客の獲得や、既存の顧客へのプランのアップグレード（またはより幅広いサービス）の販売を目的とする可能性があります。

すべてのプロモーションオファーはオファーに保存されます テーブル。オファーごとに、以下を定義する必要があります。

• offer_name –このオファーに選択した一意の名前。
• offer_start_date およびoffer_end_date –このオファーが利用できる期間。
• 説明 –オファーの詳細なテキストによる説明。
• 割引：固定金額ベースの割引（例：$ 50オフ）とパーセンテージ割引（例：25％割引）の2種類の割引を利用できる柔軟性が必要です。固定割引を提供する場合は、その値を discount_amountに挿入します 属性;パーセンテージ割引を提供する場合は、そのパーセントを discount_percentageに挿入します 属性。
• 期間：ここでは、割引に使用したのと同じロジックを使用します。場合によっては、オファーは定義された月数の間（たとえば、顧客がサインアップしてから24か月間）持続します。このような場合、 duration_monthsを定義します 価値。その他のオファーは、特定の決まった日付まで（たとえば、2019年12月31日まで）有効になります。これらについては、日付を定義して duration_end_dateに保存します 属性。

このサブジェクトエリアの残りの2つの表を使用して、各オファーに含まれるものと、そのオファーに含まれる前提条件を定義します。この目的のために、2つのテーブルを使用します： include および前提条件 。それらは同じ構造を共有し、 offer_idの同じUNIQUEペアを含みます – plan_id 。一部のオファーには前提条件がない場合がありますが、他のオファーには次のようなものがあります。より多くのユーザーがいるプランへのアップグレードの割引、または他のソフトウェアのユーザー向けのソフトウェアサブスクリプションを提供している場合。

オファーは複雑になる可能性があるため、いくつか例を示します。

1. 現在プランAを使用していて、プランBにアップグレードする提案がある場合、これは簡単です。
2. 「プランAからプランBへのアップグレード」と「プランBからプランCへのアップグレード」の2つのオファーがある場合は、もう1つのオファー「プランAからプランCへの直接アップグレード」を作成する必要があります。これにより、ユーザーは2つではなく1つのステップでプランをアップグレードできます。このようなアップグレードの1つの例は、現在グループごとに5人のユーザーを許可するサブスクリプションを、途中でグループごとに10人の中間プランにとどまることなく、グループごとに20人のユーザーを許可するサブスクリプションに変更することです。
3. グループが製品Aを使用している場合、製品BおよびCをプロモーション価格でサブスクライブする特別オファーを用意できます。また、製品Bのみと製品Cのみをサブスクライブする2つの個別のオファーを用意することもできます。

一般に、現在のプランを目的のプランに変更するオファーが1つあり、その間に何のステップもありません。1つ以上の新製品をサブスクライブするオファーは1つだけです。

セクション3：サブスクリプション、プラン、および支払い

最後のサブジェクトエリアは、前述の2つのエリアを接続し、このモデルの真の心臓部です。

すべてのサブスクリプションはサブスクリプションに保存されます テーブル。これらのサブスクリプション/プランが同じオファーの結果である場合でも、それぞれの異なるプランを個別のサブスクリプションとして扱います。この理由は、サブスクリプションを個別に管理できるようにするためです。必要に応じて、個別にキャンセルしてください。ここでいくつかの詳細を定義する必要があります：

• user_group_id –このプランに加入しているグループのID。ユーザーは個別にサブスクライブされないため、これは重要です。グループの一部として、間接的にサブスクライブされます。
• trial_period_start_date およびtrial_period_end_date –このサブスクリプションの試用期間の下限と上限（ある場合）。
• subscribe_after_trial –試用期間（存在する場合）の終了後にサブスクリプションが自動的に更新されるかどうかを示すフラグ。
• current_plan_id –そのサブスクリプションの現在の計画。サブスクリプションがアクティブでなくなった場合、この属性には最後にアクティブなプランの値が含まれます。
• offer_id –このサブスクリプションが関連するオファーへの参照。この属性には、このサブスクリプションが特定のオファーの結果である場合にのみ値が含まれます。
• offer_start_date およびoffer_end_date –このオファーがアクティブだった期間の下限と上限。これらの属性は、このサブスクリプションが特定のオファーの結果である場合にのみ定義されます。
• date_subscribed –このグループがこのサブスクリプションにサブスクライブしたとき。
• valid_to –このサブスクリプションが有効になる最後の日付。月額サブスクリプションの場合、 valid_to 今月末に設定されます。顧客が1か月の間にいつでも登録を解除した場合でも、その月の終わりまでソフトウェアを使用できます。
• date_unsubscribed –そのグループがこのサブスクリプションのサブスクリプションを解除した日付。この日付は、グループがサービスを使用しないことを決定したときに、グループ管理者によって手動で設定されることが期待できます。ただし、事前定義された基準に従って自動的に設定することもできます。未払いの請求書が2つ以上ある場合は、グループのサービスの購読を自動的に解除します。
• insert_ts –このレコードが挿入されたときのタイムスタンプ。

サブスクリプションプランは、時間の経過とともに変更されることがよくあります。すべての計画の完全な履歴を維持するために、すべての計画の変更を plan_historyに保存します テーブル。ここの各レコードには、次のものが必要です。

• subset_id –関連するサブスクリプションのID。
• plan_id –関連するプランのID。
• date_start およびdate_end –この計画が有効だった期間。
• insert_ts –このレコードが挿入されたときのタイムスタンプ。

モデルの最後のテーブルには、請求書が保存されます 。請求書ごとに、次の詳細を保持します：

• customer_invoice_data –この請求書に対して請求された顧客の説明。これは、u ser_group.customer_invoice_dataからのデータになります 請求書が生成された時点。
• subset_id –関連するサブスクリプションのID。
• plan_history_id –この請求期間中にアクティブなプランのID。
• invoice_period_start_date およびinvoice_period_end_date –この請求書の対象となる期間（例：2019年1月1日から2019年1月31日まで）。
• invoice_description –請求書の短いテキストによる説明。
• invoice_amount –この請求書の支払額。
• invoice_created_ts –この請求書が生成されてテーブルに挿入されたとき。
• invoice_due_ts –この請求書の期日。
• invoice_paid_ts –この請求書が支払われたときのタイムスタンプ。

SaaSデータモデルについてのご意見をお聞かせください

あなたのほとんどは、開発者またはユーザーとしてSaaSに出会ったことがあると思います。それとこのデータモデルについてのあなたの意見を楽しみにしています。以下のコメントであなたの経験や提案を自由に共有してください。