Test A/B: De Trial a Pago en el Flujo de Upgrade
Cómo testear A/B el flujo de upgrade de trial a pago en tu SaaS: dónde testear, qué exige cautela y cómo medir sin sesgo de cohorte incompleta.
📚 Este artículo es parte de la guía Growth Experimentation para SaaS: Playbook PLG.
Testear A/B el flujo de upgrade de trial a pago parece un test común: cambiar un texto, medir quién se volvió pagante, declarar un ganador. En la práctica, es uno de los experimentos que más engaña a quien lee el panel demasiado pronto, porque la métrica que decide todo, la conversión de trial a pago, solo existe de verdad después de que el ciclo entero del trial de cada usuario ya corrió. Este artículo es un capítulo práctico dentro de la guía de growth experimentation para SaaS: dónde están los puntos de decisión del upgrade, qué es seguro testear rápido, qué exige cautela redoblada, y cómo medir sin caer en la trampa de la cohorte incompleta.
Dónde están los puntos de decisión del upgrade
En un producto self-serve, el usuario en trial encuentra la invitación a pagar en al menos cuatro lugares distintos, cada uno con una función diferente:
- Prompt in-app. Aparece dentro del producto, normalmente después de que el usuario topa con un límite o intenta usar una funcionalidad paga. Es el punto de mayor contexto: la persona acaba de sentir la falta de eso.
- Paywall (suave o rígido). Una pantalla o modal que bloquea el avance hasta la decisión de pagar. El paywall suave deja rodear o posponer; el paywall rígido no deja pasar sin elegir un plan.
- Correo de fin de trial. La secuencia que se dispara conforme el trial se acerca al fin, normalmente con urgencia creciente (aviso de 7 días, de 2 días, del último día).
- Página de precios dentro del producto. La pantalla a la que cualquiera de los puntos anteriores lleva al usuario cuando decide seguir adelante. Según Kissmetrics, quien hace clic en “hacer upgrade” necesita ver ahí “una página de precios clara y simple, que deje obvio qué plan elegir”, no una segunda decisión difícil justo después de la primera.
El timing de cada prompt importa tanto como el lugar. Kissmetrics y Appcues convergen en el mismo principio: los disparadores por comportamiento (el usuario acaba de completar una acción que indica valor percibido) funcionan mejor que los disparadores por calendario (mostrar el prompt siempre el día 5, sin importar lo que el usuario hizo). Un ejemplo citado por Appcues: dispara un correo de tutorial rápido 48 horas después de que la cuenta fue creada si el usuario todavía no creó el primer proyecto, en vez de esperar un día fijo del calendario.
Qué es seguro testear y qué exige cautela redoblada
No todo elemento del flujo de upgrade tiene el mismo riesgo. Algunos pueden testearse con la misma ligereza que cualquier test de CRO; otros mueven directamente los ingresos y piden más rigor, mayor muestra y un test más largo.
| Seguro de testear rápido | Exige cautela redoblada |
|---|---|
| Copy del prompt de upgrade (texto, tono, beneficios listados) | El precio en sí (valor cobrado, moneda, forma de mostrar el número) |
| Timing del prompt (justo después de la acción clave versus al día siguiente) | Estructura de planes y tiers (qué incluye cada plan) |
| Descuento o urgencia al fin del trial (ej.: condición especial en las últimas 48 horas) | Cualquier cambio que haga que clientes paguen valores distintos en la misma ventana |
| Layout y posición del banner de paywall in-app | Cambios que afecten contratos o cobros ya en curso |
| Asunto y CTA del correo de fin de trial | Cambiar el precio mostrado a quien ya está a mitad de la decisión de compra |
| Número de días de trial (7, 14 o 30) |
Testear el precio no está prohibido, es solo más caro de hacer con honestidad. Según el propio glosario estadístico de este blog, cuanto menor el efecto que quieres detectar, mayor la muestra necesaria, y los efectos en ingreso por usuario suelen ser más sutiles que los efectos en tasa de conversión de clic. Antes de correr cualquier test de precio, calcula el tamaño de muestra con la guía completa de test A/B o con la calculadora de tamaño de muestra, y prepárate para un test más largo que los de copy.
El ítem “número de días de trial” merece una salvedad aunque esté en la columna segura: no cambia el precio cobrado, pero cambia cuánto tiempo necesitas esperar para leer el resultado de cada cohorte, porque la variación con trial más largo simplemente tarda más en “cerrar” el ciclo de cada usuario. Esto no es un motivo para evitar el test, es un motivo para planear la duración correcta de él, el tema de la próxima sección.
Cómo medir la conversión de trial a pago sin engañarte
La métrica primaria correcta para este test es la tasa de conversión de trial a pago: cuántos usuarios que iniciaron el trial en cada variación terminaron pagando. El problema no está en la fórmula, está en el momento en que la miras.
El problema de la censura
En una cohorte de usuarios que entraron al test en fechas distintas, quien entró hace poco tiempo todavía está dentro del período de trial cuando haces la lectura. Ese usuario no convirtió, pero tampoco tuvo la oportunidad de no convertir: simplemente todavía no llegó al fin de su propio ciclo. Tratar a ese usuario como “no convirtió” a mitad del análisis es un error clásico de medición, llamado censura: estás contando como resultado negativo algo que, en realidad, todavía es desconocido.
ChartMogul documenta este efecto con un ejemplo real: la misma cohorte de usuarios, medida en momentos distintos, mostró 5% de conversión a los 30 días, 9% a los 45 días y 16% a los 90 días. No es que la conversión “aumentó” con el tiempo en un sentido mágico: es que buena parte de los usuarios de esa cohorte simplemente todavía no había terminado de decidir cuando se hizo la primera medición. Según la propia ChartMogul, calcular la conversión comparando solo los trials y las conversiones de un mismo mes, sin considerar el ciclo de cada cohorte, es “demasiado simple para ser útil o precisa”.
La corrección práctica es simple de enunciar y fácil de olvidar a la hora de correr el test: solo entra en la comparación la cohorte cuyo trial ya cerró por completo. Si el trial dura 14 días, un usuario que empezó el test hace 5 días todavía no tiene un resultado válido, positivo o negativo, y debería quedar fuera de la lectura hasta completar su propio ciclo.
Un test de prompt de upgrade, con números reales
Imagina un SaaS self-serve con trial de 14 días y una tasa de conversión de trial a pago de 15%, dentro del rango que Userpilot reporta (citando datos de ChartMogul) para productos B2B, que va de 6-10% en el percentil mediano a 15-20% en el percentil más alto del mercado. La hipótesis: reescribir el prompt in-app que aparece cuando el usuario topa con un límite del plan gratuito, agregando un ejemplo concreto de lo que gana al hacer upgrade, debería aumentar la conversión en al menos 15% en términos relativos, de 15% a 17,25%.
Corriendo estos números en la misma fórmula de dos proporciones de este blog (95% de confianza, 80% de poder, test bilateral), el tamaño de muestra necesario es de aproximadamente 4.193 trials por variación. Con un volumen de 1.000 nuevos trials por semana, dividido entre las dos variaciones, juntar esa muestra toma cerca de 59 días. Pero ese no es el plazo real del test: el último usuario que entre al test en el día 59 todavía necesita completar sus propios 14 días de trial antes de tener un resultado válido. La lectura final y limpia solo ocurre alrededor del día 73, exactamente dos semanas después de que la muestra “llegó a la meta”.
Ajusta la tasa de conversión, el efecto que quieres detectar y el volumen semanal de tu propio producto para ver cómo cambia esto en tu caso:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Supón que el test realmente corrió hasta el final y el control registró 629 conversiones en 4.193 trials, contra 723 conversiones en 4.193 trials en la variación con el nuevo prompt. La tasa del control queda en 15,0%, la de la variación en 17,2%, una mejora relativa de aproximadamente 15%, exactamente el efecto que el test fue diseñado para detectar. Aplicando el mismo test z de dos proporciones usado en toda calculadora de este blog, el puntaje z queda cerca de 2,79 y el valor p bilateral cerca de 0,005, muy por debajo del límite de 0,05. Para el paso a paso de esta cuenta, mira cómo declarar significancia estadística sin engañarte.
Errores comunes al testear el flujo de trial a pago
| Error | Por qué distorsiona el resultado |
|---|---|
| Comparar cohortes con duración de trial distinta | Una cohorte de trial de 30 días medida en el día 20 parece peor que una cohorte de 7 días ya cerrada, pero la segunda simplemente tuvo más tiempo para resolverse |
| Contar “todavía en trial” como “no convirtió” | Infla artificialmente la tasa de no conversión de la cohorte más reciente, aplanando el resultado del test hacia abajo sin motivo real |
| Correr el test del prompt al mismo tiempo que otro cambio de producto | Un rediseño de onboarding o un cambio en la página de precios corriendo en paralelo contamina cuál de los dos cambios movió la métrica |
| Terminar la lectura en cuanto se alcanza la muestra | Ignora que la última cohorte rezagada todavía no tuvo el ciclo de trial completo para resolverse, ver la sección de censura arriba |
| Cambiar la métrica a mitad de camino | Migrar de “conversión pagada” a “clics en el prompt” solo porque el segundo número “dio victoria” primero es el mismo error de pesca de cualquier test A/B |
El segundo error de la lista (correr otro cambio de producto al mismo tiempo) es especialmente común en equipos de growth que tienen varios equipos tocando el onboarding, el pricing y el flujo de upgrade en la misma semana. Si otro equipo está testeando o lanzando algo que también afecta el momento entre el inicio del trial y la decisión de pagar, aislar qué cambio causó qué efecto deja de ser posible. Trata el calendario de cambios en el flujo de upgrade como un recurso compartido, no un free-for-all.
Automatiza esto con Donnu
Testear el flujo de upgrade de trial a pago es el tipo de experimento que más castiga a quien lee el panel demasiado pronto: la métrica que decide ingresos reales queda incompleta hasta que el ciclo del trial cierra para la última cohorte, y declarar un ganador antes de eso es decidir con base en usuarios que ni siquiera tuvieron la oportunidad de convertir. Donnu ayuda en la parte que se puede automatizar de esta disciplina: el motor estadístico de Donnu calcula la muestra antes de que corras el test, y el snippet ligero no bloquea la página de upgrade ni el correo transaccional que dispara el prompt. La decisión de esperar a que el ciclo del trial cierre antes de leer el resultado sigue siendo tuya, y es exactamente esa etapa la que más equipos se saltan.
Empieza un test gratis de 14 días y mide tu propio flujo de upgrade sin caer en la trampa de la cohorte incompleta.
Lee también: Growth experimentation para SaaS · Cómo hacer un test A/B paso a paso · Cómo declarar significancia estadística sin engañarte
¿Prefieres leerlo en portugués? Mira la versión en portugués de este artículo.
Referencias
- ChartMogul. Make trial-to-paid conversion rates meaningful with Cohorts. chartmogul.com/blog/make-trial-to-paid-conversion-rates-meaningful-with-cohorts.
- Userpilot. SaaS Average Free Trial Conversion Rate: Benchmarks. userpilot.com/blog/saas-average-conversion-rate.
- Kissmetrics. Trial to Paid Conversion: Strategies That Move Users Past the Paywall. kissmetrics.io/blog/trial-to-paid-conversion.
- Appcues. Free trial conversion rate: benchmarks and 12 strategies to improve. appcues.com/blog/free-to-paid-conversion-strategies.
Preguntas frecuentes
- ¿Puedo testear el número de días del trial (7, 14 o 30) como un test A/B común?
- Sí, es uno de los elementos más seguros de testear, pero con una trampa de medición: la variación con trial más largo tarda más en cerrar el ciclo de cada cohorte, así que el test en conjunto necesita correr más tiempo antes de que cualquier lectura sea justa. Nunca compares la conversión de una cohorte de 7 días ya cerrada con una cohorte de 30 días todavía en curso: espera el mismo número de días corridos desde el inicio del trial para ambas variaciones antes de comparar.
- ¿Por qué la tasa de conversión de trial a pago cae cuando mido a mitad del test?
- Porque parte de los usuarios que entraron al test más recientemente todavía está dentro del período de trial y no tuvo la oportunidad de convertir ni de dejar que el trial expire. Contar a esos usuarios como "no convirtió" es un error de censura: no son un resultado negativo, son un resultado todavía desconocido. ChartMogul documenta esto con números reales de una cohorte: 5% de conversión medida a los 30 días, 9% a los 45 días y 16% a los 90 días, el mismo grupo de usuarios, solo que leído en momentos distintos del ciclo.
- ¿Es seguro testear el precio en sí dentro del flujo de upgrade?
- No de la misma forma en que se testea copy o el timing de un prompt. Cambiar el valor cobrado afecta directamente los ingresos, puede generar problemas de paridad de precio entre clientes que pagaron valores distintos en la misma ventana, y normalmente exige una muestra mayor y un test más largo para leerse con seguridad, porque el efecto en ARPU suele ser más sutil que el efecto en tasa de conversión. Calcula el tamaño de muestra necesario antes de correr este tipo de test, no después.
- ¿Qué métrica debería decidir un test en el prompt de upgrade: clics, activación o conversión pagada?
- La conversión de trial a pago es la métrica primaria, porque es la única que refleja ingresos reales. Los clics en el prompt y la activación de funcionalidades son métricas secundarias, útiles para entender el "por qué" de un resultado, pero no deberían decidir por sí solas si una variación ganó: es común que una variación genere más clics y, aun así, convierta menos en pago.
- ¿Cuánto tiempo, como mínimo, debería correr un test en el flujo de trial a pago?
- El tiempo para juntar la muestra calculada más la duración entera del trial de la última cohorte que entró al test. Si tu trial dura 14 días y el último usuario entró al test en el día 59 de recolección, solo tienes una lectura limpia y completa en el día 73, no en el día 59. Terminar antes de eso es decidir con parte de los datos todavía censurada.