Datový model předplatného SaaS

SaaS (Software as a Service) je jednou ze tří hlavních součástí cloud computingu. Aplikace SaaS jsou obvykle webové a mohou pracovat s mnoha různými uživateli najednou. Řešení založená na předplatném jsou velmi oblíbené nabídky SaaS. Některé známé produkty SaaS zahrnují Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe a (samozřejmě) Vertabelo! Dnes se podíváme na datový model, který by nám umožnil spravovat předplatné SaaS.

Nápad

Produkty SaaS mohou být velmi odlišné. Někteří si své služby účtují pravidelně, např. měsíčně nebo ročně; ostatní účtují pouze množství času nebo použitých zdrojů (nebo kombinaci těchto dvou). Abychom to v tomto článku zjednodušili, zaměřím se pouze na měsíční placené předplatné.

Předpokládejme, že máme několik různých řešení SaaS a potřebujeme sledovat všechny naše předplatitele v jedné databázi. To může být případ, kdy poskytujeme databázová řešení (např. Amazon DynamoDB), analytické nástroje (např. Amazon Athena) nebo robotické aplikace (např. AWS RoboMaker). Ve skutečnosti, když se podíváme na Amazon, můžeme vidět, že je k dispozici mnoho různých aplikací. Vybrali bychom jen ty, které skutečně potřebujeme.

Datový model

Model se skládá ze tří tematických oblastí:

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

Každou z těchto oblastí popíšeme v pořadí, v jakém jsou uvedeny.

Část 1:Uživatelé a skupiny

Users & groups předmětová oblast ukládá informace o všech uživatelích naší aplikace. Budeme předpokládat, že uživatelé mohou být seskupeni, např. když chce společnost koupit licence pro více zaměstnanců. Skupinu vytvoříme, i když do ní bude patřit pouze jeden uživatel. To nám poskytne flexibilitu k pozdějšímu přidávání nových členů do této skupiny.

Nejdůležitější tabulkou je zde user_account stůl. Použijeme jej k uložení všech podrobností souvisejících s uživatelskými účty. Jsou to:

first_name & last_name – Jméno a příjmení uživatele. Upozorňujeme, že každý uživatel zde uložený je soukromá osoba.
user_name – Uživatelské jméno (zvolené uživatelem).
password – Hodnota hash hesla uživatele. (Uživatelé si nastavují svá vlastní hesla.)
email – E-mailová adresa uživatele, nastavená během procesu registrace.
confirmation_code – Kód použitý během potvrzovacího e-mailu.
confirmation_time – Po dokončení registrace/potvrzení.
insert_ts – Časové razítko, kdy byl tento záznam původně vložen.

Uživatelé mohou vytvářet skupiny; skupiny mají předdefinované typy. Seznam všech možných typů skupin je uložen v user_group_type stůl. Každý typ je JEDNOZNAČNĚ definován svým type_name . Definujeme také minimální a maximální počet členů skupiny povolený pro každý typ skupiny. Tento rozsah je definován dvěma hodnotami – members_min (spodní hranice) a members_max (horní hranice).

Při vytváření nového účtu si uživatelé také vyberou svou uživatelskou skupinu. Tím se vytvoří nový záznam ve skupině user_group tabulka odkazující na vybraný typ skupiny a ukládající časové razítko (insert_ts ), kdy byl tento záznam vložen. customer_invoice_data atribut je textový popis toho, co vytiskneme na faktuře pro danou skupinu uživatelů.

Poslední tabulka v této oblasti je in_group stůl. Pro každou skupinu uložíme seznam všech jejích členů. Kromě odkazů na uživatelskou skupinu (user_group_id ) a uživatelský účet (user_account_id ), uložíme také časové razítko, kdy byl uživatel přidán do skupiny (time_added ) nebo odebrán ze skupiny (time_removed , která bude obsahovat hodnotu pouze v případě, že byl uživatel odebrán). Budeme mít také příznak, který označí, zda je uživatel group_admin nebo ne. Správci skupiny mohou aktualizovat členy skupiny a přidávat nové členy.

Část 2:Software a plány

Dále musíme definovat vše, co nabídneme našim (potenciálním) zákazníkům. Můžeme nabízet pouze jeden typ softwaru, ale existuje velká možnost, že budeme mít několik různých nabídek. Běžným příkladem tohoto případu je nástroj SaaS, který je oddělený od jeho analytické aplikace, např. Stripe a Stripe Sigma. Takové případy pokryjeme v našem datovém modelu.

Začneme software stůl. V tomto slovníku uložíme seznam všech našich nabídek SaaS. U každého z nich uložíme:

software_name – UNIKÁTNÍ název softwaru.
details – Všechny podrobnosti popisující tento software.
access_link – Umístění nebo odkaz, kde máme k tomuto softwaru přístup.

Měli bychom být schopni nabízet naše řešení SaaS v jednom nebo více různých plánech. Každý plán obsahuje různé možnosti. Mohli bychom mít například prémiový plán, který zahrnuje všechny možnosti, které nabízíme, a základní plán, který zahrnuje pouze to nejnutnější. Všechny odlišné plány uložíme do plan stůl. Pro každý plán definujeme:

plan_name – Jméno, které jsme vybrali pro tento plán. Spolu s odkazem na software (software_id ), tvoří alternativní/UNIQUE klíč této tabulky.
user_group_type_id – Odkaz označující typ skupiny, která může tento plán používat. Může to být skupina jednoho uživatele nebo standardní skupina. Tento odkaz také definuje maximální počet členů skupiny pro daný plán – např. pokud náš plán umožňuje pět různých účtů na jedno předplatné, měli bychom uvést příslušný user_group_type .
current_price – Aktuální cena za tento plán.
insert_ts – Časové razítko, kdy byl tento záznam vložen.
active – Příznak označující, zda je tento plán aktivní či nikoli.

Již jsme zmínili, že plány pro stejný software budou přicházet s různými možnostmi. Seznam všech různých možností je uložen v option slovník. Každá možnost je JEDNOZNAČNĚ definována svým option_name .

K přiřazení možností k různým plánům použijeme option_included stůl. Ukládá odkazy na související plán (plan_id ) a možnost (option_id ). Tento pár spolu s date_added atribut, tvoří UNIKÁTNÍ klíč této tabulky. date_removed atribut bude obsahovat hodnotu pouze v případě, že jsme se rozhodli odstranit určitou možnost z plánu. To se může stát, když vytvoříme novou možnost, která nahradí starou, nebo se rozhodneme, že danou možnost již nebudeme mít, protože ji používá málo lidí.

Poslední část této oblasti se týká speciálních nebo propagačních nabídek. Obecně platí, že takové nabídky poskytují zákazníkům více služeb za méně peněz a trvají určitou dobu. Mohou být zaměřeny na získávání nových zákazníků nebo prodej upgradů plánu (nebo širšího rozsahu služeb) stávajícím zákazníkům.

Všechny naše akční nabídky jsou uloženy v offer stůl. Pro každou nabídku musíme definovat:

offer_name – JEDINEČNÉ jméno, které jsme pro tuto nabídku vybrali.
offer_start_date a offer_end_date – Časové období, během kterého je tato nabídka dostupná.
description – Podrobný textový popis nabídky.
Slevy:Potřebujeme flexibilitu, abychom měli dva typy slev – slevu s pevnou částkou (např. získáte slevu 50 $) a procentní slevu (např. ušetříte 25 %). Pokud nabízíme pevnou slevu, vložíme tuto hodnotu do discount_amount atribut; pokud nabízíme procentuální slevu, vložíme toto procento do discount_percentage atribut.
Trvání:Použijeme stejnou logiku, jakou jsme použili pro slevy. V některých případech budou nabídky trvat definovaný počet měsíců (např. 24 měsíců poté, co se zákazníci zaregistrují); v těchto případech definujeme duration_months hodnota. Ostatní nabídky budou platné do určitého pevného data (např. do 31. prosince 2019); pro tyto případy definujeme datum a uložíme ho do duration_end_date atribut.

Zbývající dvě tabulky v této tematické oblasti použijeme k definování toho, co každá nabídka obsahuje a jaké má předpoklady. Pro tento účel použijeme dvě tabulky:include a prerequisite . Sdílejí stejnou strukturu a obsahují stejný UNIKÁTNÍ pár offer_id – plan_id . Některé nabídky nemusí mít žádné předpoklady, zatímco jiné mohou – např. pokud nabízíme slevu za upgrade na tarif s více uživateli nebo předplatné softwaru pro uživatele jiného softwaru.

Nabídky mohou být složité, proto uvedu několik příkladů.

Pokud v současnosti používáme plán A a máme nabídku na upgrade na plán B, je to jednoduché.
Pokud máme dvě nabídky, „Upgrade plánu A na plán B“ a „Upgrade plánu B na plán C“, měli bychom vytvořit ještě jednu nabídku:„Upgrade plánu A přímo na plán C“. To umožňuje uživatelům upgradovat své plány v jednom kroku namísto dvou. Jedním z příkladů takového upgradu je změna předplatného, které v současné době umožňuje pět uživatelů na skupinu, na předplatné, které umožňuje 20 uživatelů na skupinu, aniž by se museli zastavit na přechodném plánu deseti uživatelů na skupinu.
Pokud skupina používá produkt A, můžeme mít speciální nabídku k odběru produktů B a C za propagační cenu. Mohli bychom mít také dvě samostatné nabídky na předplatné pouze produktu B a pouze produktu C.

Obecně bychom měli mít jednu nabídku, která změní aktuální plán na požadovaný plán bez jakýchkoli kroků mezi tím, a pouze jednu nabídku k odběru jednoho nebo více nových produktů.

Část 3:Předplatné, plány a platby

Poslední tematická oblast spojuje dvě výše zmíněné oblasti a je skutečným srdcem tohoto modelu.

Všechna předplatná jsou uložena v subscription stůl. S každým jiným plánem budeme zacházet jako se samostatným předplatným, i když jsou tato předplatná/plány výsledkem stejné nabídky. Důvodem je to, že budeme moci spravovat předplatná samostatně – např. zrušit je samostatně, pokud bychom chtěli. Zde budeme muset definovat řadu podrobností:

user_group_id – ID skupiny přihlášené k odběru tohoto plánu. To je důležité, protože uživatelé nebudou předplaceni jednotlivě; jsou přihlášeni nepřímo, jako součást skupiny.
trial_period_start_date a trial_period_end_date – Dolní a horní hranice zkušebního období (pokud existuje) pro toto předplatné.
subscribe_after_trial – Příznak označující, zda bude předplatné automaticky obnoveno po skončení zkušebního období (pokud existuje).
current_plan_id – Aktuální plán pro toto předplatné. Pokud předplatné již není aktivní, bude tento atribut obsahovat hodnotu posledního aktivního plánu.
offer_id – Odkaz na nabídku, ke které se toto předplatné vztahuje. Tento atribut bude obsahovat hodnotu pouze v případě, že toto předplatné bylo výsledkem určité nabídky.
offer_start_date a offer_end_date – Dolní a horní hranice období, během kterého byla tato nabídka aktivní. Tyto atributy budou definovány pouze v případě, že toto předplatné bylo výsledkem určité nabídky.
date_subscribed – Když se tato skupina přihlásila k odběru tohoto odběru.
valid_to – Poslední datum platnosti tohoto předplatného. V případě měsíčního předplatného můžeme očekávat, že valid_to bude nastaven na konec aktuálního měsíce. Pokud se zákazník kdykoli během měsíce odhlásí, bude moci svůj software používat až do konce daného měsíce.
date_unsubscribed – Datum, kdy se daná skupina odhlásila z tohoto předplatného. Můžeme očekávat, že toto datum bude nastaveno manuálně administrátorem skupiny, když se skupina rozhodne již službu nepoužívat. Může být ale také nastaven automaticky, podle předem definovaných kritérií – např. automatické odhlášení skupiny z jejich služby, pokud existují dvě nebo více nezaplacených faktur.
insert_ts – Časové razítko, kdy byl tento záznam vložen.

Plány předplatného se často v průběhu času mění. Abychom zachovali kompletní historii všech našich plánů, uložíme všechny změny plánu do plan_history stůl. Pro každý záznam zde budeme potřebovat:

subscription_id – ID souvisejícího předplatného.
plan_id – ID souvisejícího plánu.
date_start a date_end – Časové období, kdy byl tento plán aktivní.
insert_ts – Časové razítko, kdy byl tento záznam vložen.

V poslední tabulce v našem modelu budou uloženy naše invoices . U každé faktury uchováme následující podrobnosti:

customer_invoice_data – Popis zákazníka fakturovaného za tuto fakturu. Toto budou data z user_group.customer_invoice_data v okamžiku, kdy byla faktura vygenerována.
subscription_id – ID souvisejícího předplatného.
plan_history_id – ID plánu aktivního během tohoto fakturačního období.
invoice_period_start_date a invoice_period_end_date – Časový interval (např. 1. ledna 2019 až 31. ledna 2019), na který se vztahuje tato faktura.
invoice_description – Krátký textový popis faktury.
invoice_amount – Částka splatná za tuto fakturu.
invoice_created_ts – Kdy byla tato faktura vygenerována a vložena do tabulky.
invoice_due_ts – Kdy je tato faktura splatná.
invoice_paid_ts – Časové razítko, kdy byla tato faktura zaplacena.

Řekněte nám, co si myslíte o datovém modelu SaaS

Předpokládám, že většina z vás se setkala se SaaS, ať už jako vývojář nebo jako uživatel. Těším se na váš názor na to a na tento datový model. Neváhejte se podělit o své zkušenosti a návrhy v komentářích níže.