👋 Hola soy Pavel, bienvenido a una nueva ✨edición gratuita✨ de El Descubrimiento. Cada semana hablamos sobre producto, growth y oportunidades en el sector tech.
Si aún no eres suscriptor, esto es lo que te has perdido en este mes:
Las empresas con productos basados en suscripción son las que más han crecido en revenue durante los pasados 5 años y se prevé que este crecimiento no aminore.
Es por esta tendencia por el que empresas como Google, ha virado su herramienta analítica con Google Analytics 4, para adaptarse a esta tendencia al igual que lo están haciendo herramientas como Mixpanel y Amplitude.
Todas ellas ofrecen el mismo valor, una estructura de eventos para crear dashboard analíticos en los que ver representados de una forma eficiente los reportes de suscripción, con el objetivo de ayudar a las empresas a optimizar sus planes, precios, adquisición de usuarios de pago y revenue.
El objetivo de este número es que seas capaz de visualizar en algún tipo de herramienta de medición los siguientes KPIs.
Instrumentación → Que queremos medir
Uno de los primeros pasos que tenemos que realizar en poner los pies sobre la tierra y crear nuestra base analítica y taxonómica, la cuál ha de estar pensada para ser escalada en el futuro proximo.
En data, hablamos de layers para diferenciar las diferentes capas de datos que puede existir, casi en cualquier negocio de suscripción o donde se producen transacciones deber ser el siguiente:
Nivel de usuario: Eventos sobre el usuario y la retención.
Nivel de suscripción: Eventos para monitorear las suscripciones.
Nivel de transacciones: Evento para mirar de cerca cada una de las transacciones.
Para que esta estructura tenga forma y podamos hacer el reporting deseado, tenemos que trackear de forma correcta los siguientes eventos:
1. Nivel usuario
Si implementamos correctamente estos eventos podemos visualizar en un reporte de forma sencilla un panorama real de cuantos usuarios gratuitos tenemos, en Trial y suscritos. Además si las combinamos con el resto de layers podemos profundizar en usuarios con problemas de pagos, en periodo de renovación fallida y más corner cases.
Usuario ha activado el Trial.
Usuario ha cancelado el Trial.
Usuario ha convertido de Trial a Paid.
Usuario ha renovado la suscripción.
Usuario ha renovado la suscripción a un plan más caro.
Usuario ha renovado la suscripción a un plan más barato.
Usuario ha pasado de plan mensual a anual o viceversa.
Usuario ha cancelado la suscripción.
Usuario ha pausado la suscripción.
Usuario se ha re-suscrito nuevamente a un plan de pago.
Usuario iba a renovar pero ha habido un problema de tarjeta.
2. Nivel suscripción
Necesitamos incorporar eventos relacionados con la propia suscripción, aquí tienes una lista completa:
Si implementamos correctamente estos eventos y propiedades, podemos visualizar en directo las suscripciones activas, nuevas suscripciones, cambios de planes y el Life Time Valie (LTV).
Subscription length → duración de la suscripción (semanal, mensual o anual).
Subscription status → puede ser Trial, activa, cancelada o pausada.
Subscription price → se trata del precio por defecto del producto.
Subscription trial → es un valor YES/NO para identificar si el usuario viene de un trial o no.
Subscription start date → el día que se inicializa la suscripción.
Subscription end date → el día que ha finalizado la suscripción.
Subscription cancel date → el día que finaliza la suscripción (a futuro).
Number of payments → número de pagos realizados, referente a la renovación, evento clave para calcular y representar en un reporting el LTV.
3. Nivel de transacciones
Estos eventos profundizan en el detalle de las transacciones realizadas por los usuarios, independientemente de la suscripción.
Si implementamos correctamente estos eventos y propiedades, podemos visualizar nuestro MRR, revenue neto, refunds, revenue por usuario y otro tipo de combinaciones de revenue.
Transaction date → día de la transacción
Transaction due date → día en que se espera que se realice la transacción.
Amount paid → total de revenue generado por usuario. Suma total de las transacciones.
Discount → dentro de esta propiedad incluiríamos a través de que descuento se ha realizado la transacción.
Refund amount → Importe que se ha devuelto al usuario.
Una vez implementados estos eventos, tendríamos una matrix similar a la que vemos a continuación.
🚧 ¿Te gusta esta newsletter?
Si te ha gustado esta newsletter ✨ edición gratuita ✨ de El Descubrimiento agradecería tu apoyo con un like o compartido.
Si además quieres probar la 🔒 edición para suscriptores 🔒, puedes hacerlo de forma gratuita por 7 días.
Que tengas una feliz semana.
Pavel 👋