Un modelo de datos de suscripción de SaaS

SaaS (Software as a Service) es uno de los tres componentes principales de la computación en la nube. Por lo general, las aplicaciones SaaS están basadas en la web y pueden manejar muchos usuarios diferentes al mismo tiempo. Las soluciones basadas en suscripción son ofertas de SaaS muy populares. Algunos productos SaaS conocidos incluyen Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe y (por supuesto) Vertabelo. Hoy echaremos un vistazo a un modelo de datos que nos permitiría administrar las suscripciones de SaaS.

La idea

Los productos SaaS pueden ser muy diferentes. Algunos cobran por sus servicios de forma regular, p. mensual o anual; otros cobran solo por la cantidad de tiempo o recursos utilizados (o una combinación de estos dos). Para simplificar las cosas en este artículo, me centraré solo en las suscripciones pagas mensuales.

Supongamos que tenemos algunas soluciones SaaS diferentes y necesitamos rastrear a todos nuestros suscriptores en una base de datos. Este podría ser el caso cuando proporcionamos soluciones de bases de datos (p. ej., Amazon DynamoDB), herramientas de análisis (p. ej., Amazon Athena) o aplicaciones de robótica (p. ej., AWS RoboMaker). De hecho, si miramos a Amazon, podemos ver que hay muchas aplicaciones diferentes disponibles. Elegiríamos solo aquellos que realmente necesitamos.

Modelo de datos

El modelo consta de tres áreas temáticas:

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

Describiremos cada una de estas áreas temáticas en el orden en que aparecen.

Sección 1:Usuarios y Grupos

Los Users & groups El área temática almacena información sobre todos los usuarios de nuestra aplicación. Asumiremos que los usuarios se pueden agrupar, p. cuando una empresa quiere comprar licencias para varios empleados. Crearemos un grupo incluso cuando solo pertenezca un usuario. Esto nos dará la flexibilidad de agregar más tarde nuevos miembros a ese grupo.

La tabla más importante aquí es la user_account mesa. Lo usaremos para almacenar todos los detalles relacionados con las cuentas de usuario. Estos son:

first_name & last_name – El nombre y apellido del usuario. Tenga en cuenta que cada usuario almacenado aquí es un individuo privado.
user_name – Un nombre de usuario (elegido por el usuario).
password – Un valor hash de la contraseña del usuario. (Los usuarios establecen sus propias contraseñas).
email – La dirección de correo electrónico del usuario, configurada durante el proceso de registro.
confirmation_code – El código utilizado durante el proceso de confirmación por correo electrónico.
confirmation_time – Cuando se completó el registro/confirmación.
insert_ts – La marca de tiempo cuando se insertó inicialmente este registro.

Los usuarios pueden crear grupos; los grupos tienen tipos predefinidos. Una lista de todos los tipos de grupos posibles se almacena en el user_group_type mesa. Cada tipo se define ÚNICAMENTE por su type_name . También definiremos el número mínimo y máximo de miembros del grupo permitidos para cada tipo de grupo. Ese rango se define con dos valores:members_min (el límite inferior) y members_max (el límite superior).

Al crear una nueva cuenta, los usuarios también seleccionarán su grupo de usuarios. Esto creará un nuevo registro en el user_group tabla que hace referencia al tipo de grupo seleccionado y almacena la marca de tiempo (insert_ts ) cuando se insertó este registro. Los customer_invoice_data El atributo es una descripción textual de lo que imprimiremos en la factura para ese grupo de usuarios.

La última tabla en esta área temática es in_group mesa. Para cada grupo, almacenaremos una lista de todos sus miembros. Además de las referencias al grupo de usuarios (user_group_id ) y cuenta de usuario (user_account_id ), también almacenaremos la marca de tiempo cuando se agregó un usuario al grupo (time_added ) o eliminado del grupo (time_removed , que solo contendrá un valor si el usuario ha sido eliminado). También tendremos una bandera para indicar si el usuario es el group_admin o no. Los administradores de grupos pueden actualizar los miembros del grupo y agregar nuevos miembros.

Sección 2:Software y Planes

A continuación, debemos definir todo lo que ofreceremos a nuestros clientes (potenciales). Es posible que ofrezcamos solo un tipo de software, pero existe una gran posibilidad de que tengamos varias ofertas diferentes. Un ejemplo común de este caso es tener una herramienta SaaS separada de su aplicación de análisis, p. Raya y Raya Sigma. Cubriremos esos casos en nuestro modelo de datos.

Comenzaremos con el software mesa. En este diccionario, almacenaremos una lista de todas nuestras ofertas de SaaS. Para cada uno, almacenaremos:

software_name – Un nombre de software ÚNICO.
details – Todos los detalles que describen ese software.
access_link – Una ubicación o enlace donde podemos acceder a ese software.

Deberíamos poder ofrecer nuestras soluciones SaaS en uno o más planes diferentes. Cada plan contiene varias opciones. Por ejemplo, podríamos tener un plan premium que incluye todas las opciones que ofrecemos y un plan básico que incluye solo lo esencial. Guardaremos todos los planes distintos en el plan mesa. Para cada plan, definiremos:

plan_name – El nombre que hemos seleccionado para este plan. Junto con la referencia al software (software_id ), esto forma la clave alternativa/ÚNICA de esta tabla.
user_group_type_id – Una referencia que indique el tipo de grupo que puede utilizar este plan. Esto podría ser un grupo de un solo usuario o un grupo estándar. Esta referencia también define el número máximo de miembros del grupo para ese plan, p. si nuestro plan permite cinco cuentas diferentes en una suscripción, debemos hacer referencia al user_group_type adecuado .
current_price – El precio actual de este plan.
insert_ts – La marca de tiempo cuando se insertó este registro.
active – Una bandera que indica si este plan está activo o no.

Ya mencionamos que los planes para el mismo software vendrán con diferentes opciones. Una lista de todas las opciones distintas se almacena en la option diccionario. Cada opción se define ÚNICAMENTE por su option_name .

Para asignar opciones a diferentes planes, usaremos el option_included mesa. Almacena referencias al plan relacionado (plan_id ) y opción (option_id ). Este par, junto con el date_added atributo, forma la clave ÚNICA de esta tabla. El date_removed El atributo contendrá un valor solo si decidimos eliminar una determinada opción de un plan. Esto podría suceder cuando construimos una nueva opción para reemplazar la anterior o decidimos no tener más una opción dada porque pocas personas la usan.

La última parte de esta área temática está relacionada con ofertas especiales o promocionales. En general, tales ofertas brindan a los clientes más servicios por menos dinero y duran un cierto período de tiempo. Podrían tener como objetivo adquirir nuevos clientes o vender actualizaciones de planes (o una gama más amplia de servicios) a clientes existentes.

Todas nuestras ofertas promocionales se almacenan en la offer mesa. Para cada oferta, necesitaremos definir:

offer_name – Un nombre ÚNICO que hemos seleccionado para esta oferta.
offer_start_date y offer_end_date – El período de tiempo durante el cual esta oferta está disponible.
description – Una descripción textual detallada de la oferta.
Descuentos:necesitamos la flexibilidad para tener dos tipos de descuentos:un descuento basado en un monto fijo (por ejemplo, obtenga $50 de descuento) y un porcentaje de descuento (por ejemplo, ahorre un 25%). Si ofrecemos un descuento fijo, insertaremos ese valor en el discount_amount atributo; si ofrecemos un porcentaje de descuento, insertaremos ese porcentaje en el discount_percentage atributo.
Duración:Usaremos la misma lógica aquí que usamos para los descuentos. En algunos casos, las ofertas durarán un número definido de meses (por ejemplo, durante 24 meses después de que los clientes se registren); en estos casos, definiremos la duration_months valor. Otras ofertas serán válidas hasta una determinada fecha fija (por ejemplo, hasta el 31 de diciembre de 2019); para estos, definiremos la fecha y la almacenaremos en duration_end_date atributo.

Usaremos las dos tablas restantes en esta área temática para definir qué contiene cada oferta y qué requisitos previos tiene. Para ello, utilizaremos dos tablas:include y prerequisite . Comparten la misma estructura y contienen el mismo par ÚNICO de offer_id – plan_id . Algunas ofertas pueden no tener requisitos previos, mientras que otras pueden, p. si estamos ofreciendo un descuento por actualizar a un plan con más usuarios o una suscripción de software para usuarios de algún otro software.

Las ofertas pueden ser complejas, por lo que le proporcionaré algunos ejemplos.

Si actualmente usamos el Plan A y tenemos una oferta para actualizar al Plan B, esto es sencillo.
Si tenemos dos ofertas, "El Plan A se actualiza al Plan B" y "El Plan B se actualiza al Plan C", debemos crear una oferta más:"El Plan A se actualiza directamente al Plan C". Esto permite a los usuarios actualizar sus planes en un solo paso en lugar de dos. Un ejemplo de una actualización de este tipo es cambiar una suscripción que actualmente permite cinco usuarios por grupo a una que permite 20 usuarios por grupo sin detenerse en un plan intermedio de diez usuarios por grupo en el camino.
Si un grupo usa el Producto A, podríamos tener una oferta especial para suscribirse a los Productos B y C a un precio promocional. También podríamos tener dos ofertas separadas para suscribirse solo al Producto B y solo al Producto C.

En general, deberíamos tener una oferta que cambie el plan actual al plan deseado sin pasos intermedios y solo una oferta para suscribirse a uno o más productos nuevos.

Sección 3:Suscripciones, planes y pagos

La última área temática conecta las dos áreas mencionadas anteriormente y es el verdadero corazón de este modelo.

Todas las suscripciones se almacenan en la subscription mesa. Trataremos cada plan diferente como una suscripción separada, incluso si estas suscripciones/planes son el resultado de la misma oferta. La razón de esto es que podremos administrar las suscripciones por separado, p. cancelarlos por separado si quisiéramos. Tendremos que definir una serie de detalles aquí:

user_group_id – El ID del grupo que se suscribe a este plan. Esto es importante porque los usuarios no se suscribirán individualmente; están suscritos indirectamente, como parte del grupo.
trial_period_start_date y trial_period_end_date – Los límites inferior y superior del período de prueba (si corresponde) para esta suscripción.
subscribe_after_trial – Una bandera que indica si la suscripción se renovará automáticamente después de que finalice el período de prueba (si corresponde).
current_plan_id – El plan actual para esa suscripción. Si la suscripción ya no está activa, este atributo contendrá el valor del último plan activo.
offer_id – Una referencia a la oferta con la que está relacionada esta suscripción. Este atributo contendrá un valor solo si esta suscripción fue el resultado de una determinada oferta.
offer_start_date y offer_end_date – El límite inferior y superior del período durante el cual esta oferta estuvo activa. Estos atributos se definirán solo si esta suscripción fue el resultado de una determinada oferta.
date_subscribed – Cuando este grupo se suscribió a esta suscripción.
valid_to – La última fecha de validez de esta suscripción. En el caso de una suscripción mensual, podemos esperar que valid_to se establecerá al final del mes actual. Si un cliente cancela su suscripción en cualquier momento durante un mes, aún podrá usar su software hasta el final de ese mes.
date_unsubscribed – La fecha en que ese grupo se dio de baja de esta suscripción. Podemos esperar que el administrador del grupo establezca manualmente esta fecha cuando el grupo decida no usar más el servicio. Sin embargo, también podría configurarse automáticamente, de acuerdo con criterios predefinidos, p. cancelar automáticamente la suscripción de un grupo a su servicio si hay dos o más facturas sin pagar.
insert_ts – La marca de tiempo cuando se insertó este registro.

Los planes de suscripción a menudo cambian con el tiempo. Para mantener un historial completo de todos nuestros planes, almacenaremos todos los cambios de planes en el plan_history mesa. Para cada registro aquí, necesitaremos:

subscription_id – El ID de la suscripción relacionada.
plan_id – El ID del plan relacionado.
date_start y date_end – El período de tiempo en que este plan estuvo activo.
insert_ts – La marca de tiempo cuando se insertó este registro.

La última tabla de nuestro modelo almacenará nuestras invoices . Para cada factura, mantendremos los siguientes detalles:

customer_invoice_data – Una descripción del cliente facturado por esta factura. Estos serán los datos de user_group.customer_invoice_data en el momento en que se generó la factura.
subscription_id – El ID de la suscripción relacionada.
plan_history_id – El ID del plan activo durante este período de facturación.
invoice_period_start_date y invoice_period_end_date – El intervalo de tiempo (por ejemplo, del 1 de enero de 2019 al 31 de enero de 2019) cubierto por esta factura.
invoice_description – Una breve descripción textual de la factura.
invoice_amount – El monto del pago adeudado por esta factura.
invoice_created_ts – Cuándo se generó esta factura y se insertó en la tabla.
invoice_due_ts – Cuándo vence esta factura.
invoice_paid_ts – La marca de tiempo cuando se pagó esta factura.

Díganos qué piensa sobre el modelo de datos SaaS

Supongo que la mayoría de ustedes ha conocido SaaS, ya sea como desarrollador o como usuario. Espero con ansias su opinión sobre él y sobre este modelo de datos. Siéntase libre de compartir sus experiencias y sugerencias en los comentarios a continuación.