Model Data Berlangganan SaaS

SaaS (Software as a Service) adalah salah satu dari tiga komponen utama komputasi Cloud. Biasanya, aplikasi SaaS berbasis web dan dapat menangani banyak pengguna yang berbeda pada satu waktu. Solusi berbasis langganan adalah penawaran SaaS yang sangat populer. Beberapa produk SaaS yang terkenal antara lain Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe, dan (tentu saja) Vertabelo! Hari ini kita akan melihat model data yang memungkinkan kita mengelola langganan SaaS.

Ide

Produk SaaS bisa sangat berbeda. Beberapa membebankan biaya untuk layanan mereka secara teratur, mis. bulanan atau tahunan; yang lain hanya mengenakan biaya untuk jumlah waktu atau sumber daya yang digunakan (atau kombinasi keduanya). Untuk mempermudah dalam artikel ini, saya hanya akan fokus pada langganan berbayar bulanan.

Mari kita asumsikan bahwa kita memiliki beberapa solusi SaaS yang berbeda dan kita perlu melacak semua pelanggan kita dalam satu database. Hal ini dapat terjadi saat kami menyediakan solusi database (mis. Amazon DynamoDB), alat analitik (mis. Amazon Athena), atau aplikasi robot (mis. AWS RoboMaker). Padahal, jika kita melihat Amazon, kita bisa melihat ada banyak aplikasi berbeda yang tersedia. Kami hanya akan memilih yang benar-benar kami butuhkan.

Model Data

Model ini terdiri dari tiga bidang subjek:

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

Kami akan menjelaskan masing-masing bidang subjek ini dalam urutan daftarnya.

Bagian 1:Pengguna dan Grup

Users & groups area subjek menyimpan informasi tentang semua pengguna aplikasi kita. Kami akan berasumsi bahwa pengguna dapat dikelompokkan, mis. ketika sebuah perusahaan ingin membeli lisensi untuk beberapa karyawan. Kami akan membuat grup meskipun hanya satu pengguna yang menjadi anggotanya. Ini akan memberi kami fleksibilitas untuk kemudian menambahkan anggota baru ke grup itu.

Tabel terpenting di sini adalah user_account meja. Kami akan menggunakannya untuk menyimpan semua detail yang terkait dengan akun pengguna. Ini adalah:

first_name & last_name - Nama depan dan belakang pengguna. Harap diperhatikan bahwa setiap pengguna yang disimpan di sini adalah individu pribadi.
user_name – Nama pengguna (dipilih oleh pengguna).
password – Nilai hash dari kata sandi pengguna. (Pengguna mengatur kata sandi mereka sendiri.)
email – Alamat email pengguna, disetel selama proses pendaftaran.
confirmation_code – Kode yang digunakan selama proses konfirmasi email.
confirmation_time – Saat pendaftaran/konfirmasi selesai.
insert_ts – Stempel waktu saat catatan ini pertama kali dimasukkan.

Pengguna dapat membuat grup; kelompok memiliki tipe yang telah ditentukan. Daftar semua kemungkinan jenis grup disimpan di user_group_type meja. Setiap jenis secara UNIK ditentukan oleh type_name-nya . Kami juga akan menentukan jumlah minimum dan maksimum anggota grup yang diizinkan untuk setiap jenis grup. Rentang itu ditentukan dengan dua nilai – members_min (batas bawah) dan members_max (batas atas).

Saat membuat akun baru, pengguna juga akan memilih grup pengguna mereka. Ini akan membuat rekor baru di user_group tabel yang mereferensikan jenis grup yang dipilih dan menyimpan stempel waktu (insert_ts ) saat catatan ini dimasukkan. customer_invoice_data adalah deskripsi tekstual tentang apa yang akan kami cetak pada faktur untuk grup pengguna tersebut.

Tabel terakhir di area subjek ini adalah in_group meja. Untuk setiap grup, kami akan menyimpan daftar semua anggotanya. Selain referensi ke grup pengguna (user_group_id ) dan akun pengguna (user_account_id ), kami juga akan menyimpan stempel waktu saat pengguna ditambahkan ke grup (time_added ) atau dikeluarkan dari grup (time_removed , yang hanya akan berisi nilai jika pengguna telah dihapus). Kami juga akan memiliki tanda untuk menunjukkan jika pengguna adalah group_admin atau tidak. Admin grup dapat memperbarui anggota grup dan menambahkan anggota baru.

Bagian 2:Perangkat Lunak dan Paket

Selanjutnya, kita perlu mendefinisikan semua yang akan kita tawarkan kepada (calon) pelanggan kita. Kami mungkin hanya menawarkan satu jenis perangkat lunak, tetapi ada kemungkinan besar kami akan memiliki beberapa penawaran berbeda. Contoh umum dari kasus ini adalah memiliki alat SaaS yang terpisah dari aplikasi analitiknya, mis. Garis dan Sigma Garis. Kami akan membahas kasus seperti itu dalam model data kami.

Kita akan mulai dengan software meja. Dalam kamus ini, kami akan menyimpan daftar semua penawaran SaaS kami. Untuk masing-masing, kami akan menyimpan:

software_name – Nama perangkat lunak yang UNIK.
details – Semua detail yang menjelaskan perangkat lunak tersebut.
access_link – Lokasi atau tautan tempat kami dapat mengakses perangkat lunak tersebut.

Kami harus dapat menawarkan solusi SaaS kami dalam satu atau lebih paket yang berbeda. Setiap paket berisi berbagai opsi. Misalnya, kami dapat memiliki paket premium yang mencakup semua opsi yang kami tawarkan dan paket dasar yang hanya mencakup hal-hal penting. Kami akan menyimpan semua paket berbeda di plan meja. Untuk setiap paket, kami akan menentukan:

plan_name – Nama yang telah kami pilih untuk rencana ini. Bersama dengan referensi ke perangkat lunak (software_id ), ini membentuk kunci alternatif/UNIQUE dari tabel ini.
user_group_type_id – Referensi yang menunjukkan jenis kelompok yang dapat menggunakan rencana ini. Ini bisa berupa grup pengguna tunggal atau grup standar. Referensi ini juga menentukan jumlah maksimum anggota grup untuk rencana tersebut – mis. jika paket kami mengizinkan lima akun berbeda dalam satu langganan, kami harus merujuk user_group_type yang sesuai .
current_price – Harga saat ini untuk paket ini.
insert_ts – Stempel waktu saat catatan ini dimasukkan.
active – Bendera yang menunjukkan apakah rencana ini aktif atau tidak.

Kami telah menyebutkan bahwa paket untuk perangkat lunak yang sama akan datang dengan opsi yang berbeda. Daftar semua opsi berbeda disimpan di option kamus. Setiap opsi secara UNIK ditentukan oleh option_name-nya .

Untuk menetapkan opsi ke paket yang berbeda, kami akan menggunakan option_included meja. Ini menyimpan referensi ke paket terkait (plan_id ) dan opsi (option_id ). Pasangan ini, bersama dengan date_added atribut, membentuk kunci UNIK tabel ini. date_removed atribut akan berisi nilai hanya jika kami memutuskan untuk menghapus opsi tertentu dari rencana. Ini bisa terjadi ketika kami membuat opsi baru untuk menggantikan yang lama atau kami memutuskan untuk tidak memiliki opsi yang diberikan lagi karena hanya sedikit orang yang menggunakannya.

Bagian terakhir dari area subjek ini terkait dengan penawaran khusus atau promosi. Secara umum, penawaran semacam itu memberi pelanggan lebih banyak layanan dengan lebih sedikit uang dan bertahan untuk jangka waktu tertentu. Mereka dapat ditujukan untuk memperoleh pelanggan baru atau menjual peningkatan paket (atau layanan yang lebih luas) kepada pelanggan yang sudah ada.

Semua penawaran promosi kami disimpan di offer meja. Untuk setiap penawaran, kita perlu menentukan:

offer_name – Nama UNIK yang kami pilih untuk penawaran ini.
offer_start_date dan offer_end_date – Jangka waktu selama penawaran ini tersedia.
description – Deskripsi tekstual yang mendetail tentang penawaran.
Diskon:Kami membutuhkan fleksibilitas untuk memiliki dua jenis diskon – diskon berdasarkan jumlah tetap (mis. diskon $50) dan diskon persentase (mis. hemat 25%). Jika kami menawarkan diskon tetap, kami akan memasukkan nilai tersebut ke dalam discount_amount atribut; jika kami menawarkan persentase diskon, kami akan memasukkan persentase tersebut ke dalam discount_percentage atribut.
Durasi:Kami akan menggunakan logika yang sama dengan yang kami gunakan untuk diskon. Dalam beberapa kasus, penawaran akan berlangsung selama beberapa bulan tertentu (misalnya selama 24 bulan setelah pelanggan mendaftar); dalam kasus ini, kami akan menentukan duration_months nilai. Penawaran lainnya akan berlaku hingga tanggal tertentu (misalnya hingga 31 Desember 2019); untuk ini, kami akan menentukan tanggal dan menyimpannya di duration_end_date atribut.

Kami akan menggunakan dua tabel yang tersisa di area subjek ini untuk menentukan isi setiap penawaran dan prasyarat yang dimilikinya. Untuk tujuan ini, kami akan menggunakan dua tabel:include dan prerequisite . Mereka berbagi struktur yang sama dan berisi pasangan UNIK yang sama dari offer_id – plan_id . Beberapa penawaran mungkin tidak memiliki prasyarat, sementara yang lain mungkin – mis. jika kami menawarkan diskon untuk meningkatkan ke paket dengan lebih banyak pengguna atau langganan perangkat lunak untuk pengguna beberapa perangkat lunak lain.

Penawaran bisa rumit, jadi saya akan memberikan beberapa contoh.

Jika saat ini kami menggunakan Paket A dan memiliki tawaran untuk meningkatkan ke Paket B, ini sangat mudah.
Jika kami memiliki dua penawaran, “Peningkatan Paket A ke Paket B” dan “Peningkatan Paket B ke Paket C”, kami harus membuat satu penawaran lagi:“Peningkatan Paket A langsung ke Paket C”. Ini memungkinkan pengguna untuk meningkatkan paket mereka dalam satu langkah, bukan dua. Salah satu contoh peningkatan tersebut adalah mengubah langganan yang saat ini memungkinkan lima pengguna per grup menjadi langganan yang memungkinkan 20 pengguna per grup tanpa berhenti pada paket perantara sepuluh pengguna per grup.
Jika grup menggunakan Produk A, kami dapat memiliki penawaran khusus untuk berlangganan Produk B dan C dengan harga promo. Kami juga dapat memiliki dua penawaran terpisah untuk berlangganan hanya ke Produk B dan hanya ke Produk C.

Secara umum, kita harus memiliki satu penawaran yang akan mengubah paket saat ini ke paket yang diinginkan tanpa langkah apa pun di antaranya dan hanya satu penawaran untuk berlangganan satu atau lebih produk baru.

Bagian 3:Langganan, Paket, dan Pembayaran

Area subjek terakhir menghubungkan dua area yang disebutkan sebelumnya dan merupakan inti sebenarnya dari model ini.

Semua langganan disimpan di subscription meja. Kami akan memperlakukan setiap paket yang berbeda sebagai langganan terpisah, meskipun langganan/paket ini adalah hasil dari penawaran yang sama. Alasannya adalah agar kami dapat mengelola langganan secara terpisah – mis. batalkan secara terpisah jika kita mau. Kami perlu menentukan sejumlah detail di sini:

user_group_id – ID grup yang berlangganan paket ini. Ini penting karena pengguna tidak akan berlangganan satu per satu; mereka berlangganan secara tidak langsung, sebagai bagian dari grup.
trial_period_start_date dan trial_period_end_date – Batas bawah dan atas periode uji coba (jika ada) untuk langganan ini.
subscribe_after_trial – Bendera yang menunjukkan apakah langganan akan diperpanjang secara otomatis setelah masa uji coba (jika ada) berakhir.
current_plan_id – Paket saat ini untuk langganan itu. Jika langganan tidak lagi aktif, atribut ini akan berisi nilai paket aktif terakhir.
offer_id – Referensi ke penawaran yang terkait dengan langganan ini. Atribut ini akan berisi nilai hanya jika langganan ini adalah hasil dari penawaran tertentu.
offer_start_date dan offer_end_date – Batas bawah dan atas periode selama penawaran ini aktif. Atribut ini akan ditentukan hanya jika langganan ini adalah hasil dari penawaran tertentu.
date_subscribed – Saat grup ini berlangganan langganan ini.
valid_to – Tanggal terakhir langganan ini berlaku. Dalam hal langganan bulanan, kami dapat mengharapkan bahwa valid_to akan ditetapkan ke akhir bulan berjalan. Jika pelanggan berhenti berlangganan kapan saja selama sebulan, mereka masih dapat menggunakan perangkat lunaknya hingga akhir bulan itu.
date_unsubscribed – Tanggal ketika grup tersebut berhenti berlangganan dari langganan ini. Kami berharap tanggal ini akan disetel secara manual oleh admin grup saat grup memutuskan untuk tidak menggunakan layanan ini lagi. Namun, itu juga dapat diatur secara otomatis, sesuai dengan kriteria yang telah ditentukan – mis. secara otomatis berhenti berlangganan grup dari layanan mereka jika ada dua atau lebih faktur yang belum dibayar.
insert_ts – Stempel waktu saat catatan ini dimasukkan.

Paket berlangganan sering berubah seiring waktu. Untuk mempertahankan riwayat lengkap semua paket kami, kami akan menyimpan semua perubahan paket di plan_history meja. Untuk setiap record di sini, kita memerlukan:

subscription_id – ID langganan terkait.
plan_id – ID paket terkait.
date_start dan date_end – Jangka waktu saat rencana ini aktif.
insert_ts – Stempel waktu saat catatan ini dimasukkan.

Tabel terakhir dalam model kita akan menyimpan invoices . Untuk setiap faktur, kami akan menyimpan detail berikut:

customer_invoice_data – Deskripsi pelanggan yang ditagih untuk faktur ini. Ini akan menjadi data dari user_group.customer_invoice_data pada saat faktur dibuat.
subscription_id – ID langganan terkait.
plan_history_id – ID paket yang aktif selama periode faktur ini.
invoice_period_start_date dan invoice_period_end_date – Interval waktu (misalnya 1 Januari 2019 hingga 31 Januari 2019) yang tercakup dalam faktur ini.
invoice_description – Deskripsi tekstual singkat tentang faktur.
invoice_amount – Jumlah pembayaran yang harus dibayar untuk faktur ini.
invoice_created_ts – Saat faktur ini dibuat dan dimasukkan ke dalam tabel.
invoice_due_ts – Saat faktur ini jatuh tempo.
invoice_paid_ts – Stempel waktu saat faktur ini dibayarkan.

Beri tahu Kami Pendapat Anda Tentang Model Data SaaS

Saya rasa sebagian besar dari Anda telah bertemu SaaS, baik sebagai pengembang maupun sebagai pengguna. Saya menantikan pendapat Anda tentang model data ini. Jangan ragu untuk membagikan pengalaman dan saran Anda di komentar di bawah.