Un modèle de données d'abonnement SaaS

Le SaaS (Software as a Service) est l'un des trois principaux composants du Cloud computing. Habituellement, les applications SaaS sont basées sur le Web et peuvent gérer plusieurs utilisateurs différents en même temps. Les solutions par abonnement sont des offres SaaS très populaires. Certains produits SaaS bien connus incluent Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe et (bien sûr) Vertabelo ! Aujourd'hui, nous allons examiner un modèle de données qui nous permettrait de gérer les abonnements SaaS.

L'idée

Les produits SaaS peuvent être très différents. Certains facturent leurs services sur une base régulière, par ex. mensuel ou annuel; d'autres ne facturent que le temps ou les ressources utilisées (ou une combinaison des deux). Pour simplifier les choses dans cet article, je me concentrerai uniquement sur les abonnements mensuels payants.

Supposons que nous ayons quelques solutions SaaS différentes et que nous devions suivre tous nos abonnés dans une seule base de données. Cela peut être le cas lorsque nous fournissons des solutions de base de données (par exemple, Amazon DynamoDB), des outils d'analyse (par exemple, Amazon Athena) ou des applications robotiques (par exemple, AWS RoboMaker). En fait, si nous regardons Amazon, nous pouvons voir qu'il existe de nombreuses applications différentes disponibles. Nous ne choisirions que ceux dont nous avons vraiment besoin.

Modèle de données

Le modèle se compose de trois domaines :

Users & groups
Software & plans
Subscriptions, plans & payments.

Nous décrirons chacun de ces domaines dans l'ordre dans lequel ils sont répertoriés.

Section 1 :Utilisateurs et groupes

Les Users & groups Le domaine stocke des informations sur tous les utilisateurs de notre application. Nous supposerons que les utilisateurs peuvent être regroupés, par ex. lorsqu'une entreprise veut acheter des licences pour plusieurs employés. Nous créerons un groupe même si un seul utilisateur en fait partie. Cela nous donnera la possibilité d'ajouter ultérieurement de nouveaux membres à ce groupe.

Le tableau le plus important ici est le user_account table. Nous l'utiliserons pour stocker tous les détails liés aux comptes d'utilisateurs. Ce sont :

first_name & last_name – Le prénom et le nom de l'utilisateur. Veuillez noter que chaque utilisateur enregistré ici est un particulier.
user_name – Un nom d'utilisateur (choisi par l'utilisateur).
password – Une valeur de hachage du mot de passe de l'utilisateur. (Les utilisateurs définissent leurs propres mots de passe.)
email – L'adresse e-mail de l'utilisateur, définie lors du processus d'inscription.
confirmation_code – Le code utilisé lors du processus de confirmation par e-mail.
confirmation_time – Lorsque l'inscription/la confirmation a été effectuée.
insert_ts – L'horodatage auquel cet enregistrement a été initialement inséré.

Les utilisateurs peuvent créer des groupes; les groupes ont des types prédéfinis. Une liste de tous les types de groupes possibles est stockée dans le user_group_type table. Chaque type est UNIQUEMENT défini par son type_name . Nous définirons également le nombre minimum et maximum de membres de groupe autorisés pour chaque type de groupe. Cette plage est définie avec deux valeurs - members_min (la limite inférieure) et members_max (la limite supérieure).

Lors de la création d'un nouveau compte, les utilisateurs sélectionneront également leur groupe d'utilisateurs. Cela créera un nouvel enregistrement dans le user_group table référençant le type de groupe sélectionné et stockant l'horodatage (insert_ts ) lors de l'insertion de cet enregistrement. Les customer_invoice_data L'attribut est une description textuelle de ce que nous imprimerons sur la facture pour ce groupe d'utilisateurs.

Le dernier tableau de ce domaine est le in_group table. Pour chaque groupe, nous stockerons une liste de tous ses membres. Outre les références au groupe d'utilisateurs (user_group_id ) et compte utilisateur (user_account_id ), nous stockerons également l'horodatage lorsqu'un utilisateur a été ajouté au groupe (time_added ) ou supprimé du groupe (time_removed , qui ne contiendra une valeur que si l'utilisateur a été supprimé). Nous aurons également un indicateur pour indiquer si l'utilisateur est le group_admin ou pas. Les administrateurs de groupe peuvent mettre à jour les membres du groupe et ajouter de nouveaux membres.

Section 2 :Logiciels et forfaits

Ensuite, nous devons définir tout ce que nous offrirons à nos clients (potentiels). Nous ne proposons peut-être qu'un seul type de logiciel, mais il est fort possible que nous ayons plusieurs offres différentes. Un exemple courant de ce cas est d'avoir un outil SaaS distinct de son application d'analyse, par ex. Stripe et Stripe Sigma. Nous couvrirons ces cas dans notre modèle de données.

Nous allons commencer par le software table. Dans ce dictionnaire, nous stockerons une liste de toutes nos offres SaaS. Pour chacun, nous stockerons :

software_name – Un nom de logiciel UNIQUE.
details – Tous les détails décrivant ce logiciel.
access_link – Un emplacement ou un lien où nous pouvons accéder à ce logiciel.

Nous devrions être en mesure d'offrir nos solutions SaaS dans un ou plusieurs forfaits différents. Chaque plan contient diverses options. Par exemple, nous pourrions avoir un plan premium qui comprend toutes les options que nous proposons et un plan de base qui ne comprend que l'essentiel. Nous stockerons tous les plans distincts dans le plan table. Pour chaque plan, nous définirons :

plan_name – Le nom que nous avons choisi pour ce plan. Avec la référence au logiciel (software_id ), cela forme la clé alternative/UNIQUE de cette table.
user_group_type_id – Une référence indiquant le type de groupe pouvant utiliser ce plan. Il peut s'agir d'un groupe d'utilisateurs uniques ou d'un groupe standard. Cette référence définit également le nombre maximum de membres du groupe pour ce plan - par ex. si notre plan autorise cinq comptes différents sur un seul abonnement, nous devons référencer le user_group_type approprié .
current_price – Le prix actuel de ce forfait.
insert_ts – L'horodatage auquel cet enregistrement a été inséré.
active – Un indicateur indiquant si ce plan est actif ou non.

Nous avons déjà mentionné que les plans pour le même logiciel viendront avec différentes options. Une liste de toutes les options distinctes est stockée dans l'option dictionnaire. Chaque option est UNIQUEMENT définie par son option_name .

Pour attribuer des options à différents plans, nous utiliserons le option_included table. Il stocke les références au plan associé (plan_id ) et l'option (option_id ). Cette paire, ainsi que la date_added attribut, forme la clé UNIQUE de cette table. Le date_removed L'attribut contiendra une valeur uniquement si nous avons décidé de supprimer une certaine option d'un plan. Cela peut arriver lorsque nous construisons une nouvelle option pour remplacer l'ancienne ou que nous décidons de ne plus avoir une option donnée car peu de personnes l'utilisent.

La dernière partie de ce domaine concerne les offres spéciales ou promotionnelles. En général, ces offres offrent aux clients plus de services pour moins d'argent et durent pendant une certaine période de temps. Ils peuvent viser à acquérir de nouveaux clients ou à vendre des mises à niveau de plan (ou une gamme plus large de services) aux clients existants.

Toutes nos offres promotionnelles sont stockées dans le offer table. Pour chaque offre, nous devrons définir :

offer_name – Un nom UNIQUE que nous avons sélectionné pour cette offre.
offer_start_date et offer_end_date – La période pendant laquelle cette offre est disponible.
description – Une description textuelle détaillée de l'offre.
Remises :nous avons besoin de la flexibilité d'avoir deux types de remises :une remise basée sur un montant fixe (par exemple, obtenez 50 $ de réduction) et une remise en pourcentage (par exemple, économisez 25 %). Si nous offrons une remise fixe, nous insérerons cette valeur dans le discount_amount attribut; si nous offrons un pourcentage de remise, nous insérerons ce pourcentage dans le discount_percentage attribut.
Durée :nous utiliserons ici la même logique que celle que nous avons utilisée pour les remises. Dans certains cas, les offres dureront un nombre défini de mois (par exemple pendant 24 mois après l'inscription des clients) ; dans ces cas, nous définirons la duration_months valeur. Les autres offres seront valables jusqu'à une certaine date fixe (par exemple jusqu'au 31 décembre 2019); pour ceux-ci, nous définirons la date et la stockerons dans le duration_end_date attribut.

Nous utiliserons les deux tableaux restants dans ce domaine pour définir le contenu de chaque offre et les conditions préalables dont elle dispose. Pour cela, nous utiliserons deux tables :include et prerequisite . Ils partagent la même structure et contiennent la même paire UNIQUE de offer_id – plan_id . Certaines offres peuvent ne pas avoir de prérequis, tandis que d'autres peuvent - par ex. si nous offrons une remise pour la mise à niveau vers un plan avec plus d'utilisateurs ou un abonnement logiciel pour les utilisateurs d'un autre logiciel.

Les offres peuvent être complexes, je vais donc vous donner quelques exemples.

Si nous utilisons actuellement le plan A et avons une offre de mise à niveau vers le plan B, c'est simple.
Si nous avons deux offres, "Le plan A passe au plan B" et "Le plan B passe au plan C", nous devons en créer une autre :"Le plan A passe directement au plan C". Cela permet aux utilisateurs de mettre à niveau leurs forfaits en une seule étape plutôt qu'en deux. Un exemple d'une telle mise à niveau consiste à changer un abonnement qui autorise actuellement cinq utilisateurs par groupe à un qui autorise 20 utilisateurs par groupe sans s'arrêter à un plan intermédiaire de dix utilisateurs par groupe en cours de route.
Si un groupe utilise le Produit A, nous pourrions avoir une offre spéciale pour s'abonner aux Produits B et C à un prix promotionnel. Nous pourrions également avoir deux offres distinctes pour souscrire uniquement au produit B et uniquement au produit C.

En général, nous devrions avoir une offre qui changera le plan actuel en plan souhaité sans aucune étape intermédiaire et une seule offre pour souscrire à un ou plusieurs nouveaux produits.

Section 3 :Abonnements, forfaits et paiements

Le dernier domaine relie les deux domaines mentionnés précédemment et constitue le véritable cœur de ce modèle.

Tous les abonnements sont stockés dans le subscription table. Nous traiterons chaque forfait différent comme un abonnement distinct, même si ces abonnements/forfaits sont le résultat de la même offre. La raison en est que nous pourrons gérer les abonnements séparément - par ex. les annuler séparément si nous le voulions. Nous devrons définir un certain nombre de détails ici :

user_group_id – L'identifiant du groupe souscrivant à ce plan. Ceci est important car les utilisateurs ne seront pas abonnés individuellement ; ils sont souscrits indirectement, dans le cadre du groupe.
trial_period_start_date et trial_period_end_date – Les limites inférieure et supérieure de la période d'essai (le cas échéant) pour cet abonnement.
subscribe_after_trial – Un indicateur indiquant si l'abonnement sera automatiquement renouvelé après la fin de la période d'essai (le cas échéant).
current_plan_id – Le plan actuel pour cet abonnement. Si l'abonnement n'est plus actif, cet attribut contiendra la valeur du dernier plan actif.
offer_id – Une référence à l'offre à laquelle cet abonnement est lié. Cet attribut contiendra une valeur uniquement si cet abonnement était le résultat d'une certaine offre.
offer_start_date et offer_end_date – La limite inférieure et supérieure de la période pendant laquelle cette offre a été active. Ces attributs ne seront définis que si cet abonnement était le résultat d'une certaine offre.
date_subscribed – Lorsque ce groupe s'est abonné à cet abonnement.
valid_to – La dernière date de validité de cet abonnement. Dans le cas d'un abonnement mensuel, on peut s'attendre à ce que valid_to sera fixé à la fin du mois en cours. Si un client se désabonne à tout moment au cours d'un mois, il pourra toujours utiliser son logiciel jusqu'à la fin de ce mois.
date_unsubscribed – La date à laquelle ce groupe s'est désabonné de cet abonnement. Nous pouvons nous attendre à ce que cette date soit définie manuellement par l'administrateur du groupe lorsque le groupe décide de ne plus utiliser le service. Cependant, il pourrait également être défini automatiquement, selon des critères prédéfinis - par ex. désabonner automatiquement un groupe de son service s'il y a au moins deux factures impayées.
insert_ts – L'horodatage auquel cet enregistrement a été inséré.

Les plans d'abonnement changent souvent avec le temps. Pour conserver un historique complet de tous nos plans, nous stockerons toutes les modifications de plan dans le plan_history table. Pour chaque enregistrement ici, nous aurons besoin d'un :

subscription_id – L'ID de l'abonnement associé.
plan_id – L'ID du plan associé.
date_start et date_end – La période pendant laquelle ce plan était actif.
insert_ts – L'horodatage auquel cet enregistrement a été inséré.

La dernière table de notre modèle stockera nos invoices . Pour chaque facture, nous conserverons les détails suivants :

customer_invoice_data – Une description du client facturé pour cette facture. Ce seront les données de user_group.customer_invoice_data au moment où la facture a été générée.
subscription_id – L'ID de l'abonnement associé.
plan_history_id – L'identifiant du plan actif pendant cette période de facturation.
invoice_period_start_date et invoice_period_end_date – La période (par exemple, du 1er janvier 2019 au 31 janvier 2019) couverte par cette facture.
invoice_description – Une brève description textuelle de la facture.
invoice_amount – Le montant du paiement dû pour cette facture.
invoice_created_ts – Quand cette facture a été générée et insérée dans le tableau.
invoice_due_ts – Quand cette facture est due.
invoice_paid_ts – L'horodatage du paiement de cette facture.

Dites-nous ce que vous pensez du modèle de données SaaS

Je suppose que la plupart d'entre vous ont rencontré le SaaS, soit en tant que développeur, soit en tant qu'utilisateur. J'attends avec impatience votre point de vue à ce sujet et sur ce modèle de données. N'hésitez pas à partager vos expériences et suggestions dans les commentaires ci-dessous.