Model danych subskrypcji SaaS

SaaS (Software as a Service) to jeden z trzech głównych elementów przetwarzania w chmurze. Zazwyczaj aplikacje SaaS są oparte na sieci WWW i mogą obsługiwać jednocześnie wielu różnych użytkowników. Rozwiązania oparte na subskrypcji to bardzo popularne oferty SaaS. Niektóre dobrze znane produkty SaaS to Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe i (oczywiście) Vertabelo! Dzisiaj przyjrzymy się modelowi danych, który pozwoli nam zarządzać subskrypcjami SaaS.

Pomysł

Produkty SaaS mogą być bardzo różne. Niektórzy regularnie pobierają opłaty za swoje usługi, m.in. miesięcznie lub rocznie; inni pobierają opłaty tylko za czas lub wykorzystane zasoby (lub za kombinację tych dwóch). Aby uprościć ten artykuł, skupię się tylko na miesięcznych płatnych subskrypcjach.

Załóżmy, że mamy kilka różnych rozwiązań SaaS i musimy śledzić wszystkich naszych subskrybentów w jednej bazie danych. Może tak być, gdy dostarczamy rozwiązania bazodanowe (np. Amazon DynamoDB), narzędzia analityczne (np. Amazon Athena) lub aplikacje do robotyki (np. AWS RoboMaker). W rzeczywistości, jeśli spojrzymy na Amazon, zobaczymy, że dostępnych jest wiele różnych aplikacji. Wybieralibyśmy tylko tych, których naprawdę potrzebujemy.

Model danych

Model składa się z trzech obszarów tematycznych:

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

Opiszemy każdy z tych obszarów tematycznych w kolejności, w jakiej są wymienione.

Sekcja 1:Użytkownicy i grupy

Users & groups obszar tematyczny przechowuje informacje o wszystkich użytkownikach naszej aplikacji. Przyjmiemy, że użytkowników można grupować m.in. gdy firma chce kupić licencje dla kilku pracowników. Stworzymy grupę, nawet jeśli należy do niej tylko jeden użytkownik. Da nam to elastyczność w późniejszym dodawaniu nowych członków do tej grupy.

Najważniejszą tabelą jest tutaj user_account stół. Wykorzystamy go do przechowywania wszystkich szczegółów związanych z kontami użytkowników. Są to:

first_name & last_name – Imię i nazwisko użytkownika. Pamiętaj, że każdy zapisany tutaj użytkownik jest osobą prywatną.
user_name – Nazwa użytkownika (wybrana przez użytkownika).
password – Wartość skrótu hasła użytkownika. (Użytkownicy ustawiają własne hasła.)
email – Adres e-mail użytkownika, ustawiony podczas procesu rejestracji.
confirmation_code – Kod używany podczas procesu potwierdzania wiadomości e-mail.
confirmation_time – Kiedy rejestracja/potwierdzenie zostało zakończone.
insert_ts – Sygnatura czasowa początkowego wstawienia tego rekordu.

Użytkownicy mogą tworzyć grupy; grupy mają predefiniowane typy. Lista wszystkich możliwych typów grup jest przechowywana w user_group_type stół. Każdy typ jest JEDYNIE zdefiniowany przez jego type_name . Zdefiniujemy również minimalną i maksymalną liczbę członków grupy dozwoloną dla każdego typu grupy. Ten zakres jest określony dwiema wartościami – members_min (dolna granica) i members_max (górna granica).

Tworząc nowe konto, użytkownicy wybierają również swoją grupę użytkowników. Spowoduje to utworzenie nowego rekordu w user_group tabela odwołująca się do wybranego typu grupy i przechowująca znacznik czasu (insert_ts ), kiedy ten rekord został wstawiony. customer_invoice_data atrybut to tekstowy opis tego, co wydrukujemy na fakturze dla tej grupy użytkowników.

Ostatnia tabela w tym obszarze tematycznym to in_group stół. Dla każdej grupy będziemy przechowywać listę wszystkich jej członków. Poza odniesieniami do grupy użytkowników (user_group_id ) i konto użytkownika (user_account_id ), będziemy również przechowywać znacznik czasu, kiedy użytkownik został dodany do grupy (time_added ) lub usunięty z grupy (time_removed , który będzie zawierał wartość tylko wtedy, gdy użytkownik został usunięty). Będziemy również mieli flagę, aby wskazać, czy użytkownik jest group_admin albo nie. Administratorzy grup mogą aktualizować członków grupy i dodawać nowych członków.

Sekcja 2:Oprogramowanie i plany

Następnie musimy zdefiniować wszystko, co będziemy oferować naszym (potencjalnym) klientom. Możemy zaoferować tylko jeden rodzaj oprogramowania, ale istnieje duże prawdopodobieństwo, że będziemy mieć kilka różnych ofert. Typowym przykładem tego przypadku jest posiadanie narzędzia SaaS, które jest niezależne od aplikacji analitycznej, np. Paski i Paski Sigma. Omówimy takie przypadki w naszym modelu danych.

Zaczniemy od software stół. W tym słowniku będziemy przechowywać listę wszystkich naszych ofert SaaS. Dla każdego przechowujemy:

software_name – UNIKALNA nazwa oprogramowania.
details – Wszystkie szczegóły opisujące to oprogramowanie.
access_link – Lokalizacja lub link, z którego możemy uzyskać dostęp do tego oprogramowania.

Powinniśmy być w stanie zaoferować nasze rozwiązania SaaS w jednym lub kilku różnych planach. Każdy plan zawiera różne opcje. Na przykład możemy mieć plan premium, który obejmuje wszystkie oferowane przez nas opcje, oraz plan podstawowy, który obejmuje tylko niezbędne elementy. Wszystkie odrębne plany będziemy przechowywać w plan stół. Dla każdego planu zdefiniujemy:

plan_name – Nazwa, którą wybraliśmy dla tego planu. Wraz z odniesieniem do oprogramowania (software_id ), tworzy to klucz alternatywny/UNIKALNY tej tabeli.
user_group_type_id – Odniesienie wskazujące rodzaj grupy, która może korzystać z tego planu. Może to być grupa jednego użytkownika lub grupa standardowa. To odniesienie określa również maksymalną liczbę członków grupy dla tego planu – np. jeśli nasz plan zezwala na pięć różnych kont w ramach jednej subskrypcji, powinniśmy odwołać się do odpowiedniego user_group_type .
current_price – Aktualna cena tego planu.
insert_ts – Znacznik czasu wstawienia tego rekordu.
active – Flaga informująca, czy ten plan jest aktywny, czy nie.

Wspomnieliśmy już, że plany tego samego oprogramowania będą zawierały różne opcje. Lista wszystkich odrębnych opcji jest przechowywana w option słownik. Każda opcja jest WYJĄTKOWA zdefiniowana przez jej option_name .

Aby przypisać opcje do różnych planów, użyjemy option_included stół. Przechowuje odniesienia do powiązanego planu (plan_id ) i opcję (option_id ). Ta para wraz z date_added atrybut, tworzy klucz UNIKATOWY tej tabeli. date_removed atrybut będzie zawierał wartość tylko wtedy, gdy zdecydowaliśmy się usunąć daną opcję z planu. Może się to zdarzyć, gdy zbudujemy nową opcję w celu zastąpienia starej lub zdecydujemy się nie mieć już danej opcji, ponieważ niewiele osób z niej korzysta.

Ostatnia część tej tematyki dotyczy ofert specjalnych lub promocyjnych. Ogólnie rzecz biorąc, takie oferty zapewniają klientom lepszą obsługę za mniejsze pieniądze i trwają przez określony czas. Mogą mieć na celu pozyskiwanie nowych klientów lub sprzedaż aktualizacji planu (lub szerszego zakresu usług) obecnym klientom.

Wszystkie nasze oferty promocyjne są przechowywane w offer stół. Dla każdej oferty musimy określić:

offer_name – UNIKALNA nazwa, którą wybraliśmy dla tej oferty.
offer_start_date i offer_end_date – Okres, w którym ta oferta jest dostępna.
description – Szczegółowy opis tekstowy oferty.
Rabaty:Potrzebujemy elastyczności, aby mieć dwa rodzaje rabatów – rabat oparty na stałej kwocie (np. uzyskaj 50 USD zniżki) i rabat procentowy (np. zaoszczędź 25%). Jeśli oferujemy stałą zniżkę, wstawimy tę wartość do discount_amount atrybut; jeśli oferujemy zniżkę procentową, wstawimy ten procent do discount_percentage atrybut.
Czas trwania:użyjemy tutaj tej samej logiki, którą zastosowaliśmy w przypadku rabatów. W niektórych przypadkach oferty będą obowiązywać przez określoną liczbę miesięcy (np. przez 24 miesiące po zarejestrowaniu się klienta); w takich przypadkach zdefiniujemy duration_months wartość. Pozostałe oferty będą ważne do określonego ustalonego terminu (np. do 31 grudnia 2019 r.); w tym celu zdefiniujemy datę i zapiszemy ją w duration_end_date atrybut.

Wykorzystamy pozostałe dwie tabele w tym obszarze tematycznym, aby określić, co zawiera każda oferta i jakie ma wymagania wstępne. W tym celu użyjemy dwóch tabel:include i prerequisite . Mają tę samą strukturę i zawierają tę samą UNIKALNĄ parę offer_id – plan_id . Niektóre oferty mogą nie mieć żadnych warunków wstępnych, podczas gdy inne mogą – m.in. jeśli oferujemy zniżkę na uaktualnienie do planu z większą liczbą użytkowników lub subskrypcję oprogramowania dla użytkowników innego oprogramowania.

Oferty mogą być złożone, więc podam kilka przykładów.

Jeśli obecnie korzystamy z planu A i mamy ofertę przejścia na plan B, jest to proste.
Jeśli mamy dwie oferty:„Przejście z planu A do planu B” i „Przejście z planu B do planu C”, powinniśmy stworzyć jeszcze jedną ofertę:„Przejście z planu A bezpośrednio do planu C”. Dzięki temu użytkownicy mogą uaktualnić swoje plany w jednym kroku, a nie w dwóch. Jednym z przykładów takiego uaktualnienia jest zmiana subskrypcji, która obecnie zezwala na pięciu użytkowników na grupę na taką, która pozwala na 20 użytkowników na grupę bez zatrzymywania się po drodze na pośrednim planie dziesięciu użytkowników na grupę.
Jeśli grupa korzysta z Produktu A, możemy otrzymać specjalną ofertę subskrypcji Produktów B i C w promocyjnej cenie. Moglibyśmy również mieć dwie oddzielne oferty subskrypcji tylko produktu B i tylko produktu C.

Ogólnie rzecz biorąc, powinniśmy mieć jedną ofertę, która zmieni bieżący plan na pożądany plan bez żadnych kroków między nimi i tylko jedną ofertę subskrypcji jednego lub więcej nowych produktów.

Sekcja 3:Subskrypcje, plany i płatności

Ostatni obszar tematyczny łączy dwa wcześniej wymienione obszary i jest prawdziwym sercem tego modelu.

Wszystkie subskrypcje są przechowywane w subscription stół. Każdy inny plan będziemy traktować jako osobną subskrypcję, nawet jeśli te subskrypcje/plany są wynikiem tej samej oferty. Powodem tego jest to, że będziemy mogli zarządzać subskrypcjami osobno – m.in. anuluj je osobno, jeśli chcemy. Musimy zdefiniować tutaj kilka szczegółów:

user_group_id – Identyfikator grupy subskrybującej ten plan. Jest to ważne, ponieważ użytkownicy nie będą subskrybować indywidualnie; są subskrybowani pośrednio, jako część grupy.
trial_period_start_date i trial_period_end_date – Dolna i górna granica okresu próbnego (jeśli istnieje) dla tej subskrypcji.
subscribe_after_trial – Flaga wskazująca, czy subskrypcja zostanie automatycznie odnowiona po zakończeniu okresu próbnego (jeśli istnieje).
current_plan_id – Aktualny plan dla tego abonamentu. Jeśli subskrypcja nie jest już aktywna, ten atrybut będzie zawierał wartość ostatniego aktywnego planu.
offer_id – Odniesienie do oferty, której dotyczy ten abonament. Ten atrybut będzie zawierał wartość tylko wtedy, gdy ta subskrypcja była wynikiem określonej oferty.
offer_start_date i offer_end_date – Dolna i górna granica okresu, w którym ta oferta była aktywna. Te atrybuty zostaną zdefiniowane tylko wtedy, gdy ta subskrypcja była wynikiem określonej oferty.
date_subscribed – Kiedy ta grupa zasubskrybowała tę subskrypcję.
valid_to – Ostatnia data ważności tej subskrypcji. W przypadku abonamentu miesięcznego możemy spodziewać się, że valid_to zostanie ustawiony na koniec bieżącego miesiąca. Jeśli klient zrezygnuje z subskrypcji w dowolnym momencie w ciągu miesiąca, nadal będzie mógł korzystać ze swojego oprogramowania do końca tego miesiąca.
date_unsubscribed – Data, w której ta grupa zrezygnowała z subskrypcji tej subskrypcji. Możemy się spodziewać, że data ta zostanie ustawiona ręcznie przez administratora grupy, gdy grupa zdecyduje się nie korzystać z usługi. Jednak może być również ustawiany automatycznie, według wcześniej zdefiniowanych kryteriów – np. automatyczne anulowanie subskrypcji grupy z ich usług, jeśli istnieją dwie lub więcej niezapłaconych faktur.
insert_ts – Znacznik czasu wstawienia tego rekordu.

Plany abonamentowe często zmieniają się w czasie. Aby zachować pełną historię wszystkich naszych planów, będziemy przechowywać wszystkie zmiany planu w plan_history stół. Dla każdego rekordu tutaj potrzebujemy:

subscription_id – Identyfikator powiązanej subskrypcji.
plan_id – Identyfikator powiązanego planu.
date_start i date_end – Okres, w którym ten plan był aktywny.
insert_ts – Znacznik czasu wstawienia tego rekordu.

Ostatnia tabela w naszym modelu będzie przechowywać nasze invoices . W przypadku każdej faktury zachowamy następujące dane:

customer_invoice_data – Opis klienta rozliczanego za tę fakturę. Będą to dane z user_group.customer_invoice_data w momencie wygenerowania faktury.
subscription_id – Identyfikator powiązanej subskrypcji.
plan_history_id – Identyfikator planu aktywnego w tym okresie rozliczeniowym.
invoice_period_start_date i invoice_period_end_date – Przedział czasowy (np. 1 stycznia 2019 r. do 31 stycznia 2019 r.) objęty tą fakturą.
invoice_description – Krótki opis tekstowy faktury.
invoice_amount – Kwota płatności należnej za tę fakturę.
invoice_created_ts – Kiedy ta faktura została wygenerowana i wstawiona do tabeli.
invoice_due_ts – Kiedy ta faktura jest wymagalna.
invoice_paid_ts – Znacznik czasu, kiedy ta faktura została zapłacona.

Powiedz nam, co myślisz o modelu danych SaaS

Domyślam się, że większość z Was spotkała się z SaaS, jako programista lub jako użytkownik. Z niecierpliwością czekam na Twoje podejście do tego i tego modelu danych. Podziel się swoimi doświadczeniami i sugestiami w komentarzach poniżej.