Embudos de onboarding y paywall: qué medir

En la mayoría de las apps de suscripción, los primeros minutos lo deciden casi todo. Alguien instala, pasa por el onboarding, se encuentra con un paywall y, o bien empieza una prueba, o bien se va. Si puedes ver dónde abandona la gente esa secuencia, sabes qué arreglar a continuación. Si no, estás adivinando, y la suposición habitual (cambiar el precio del paywall) suele ser la equivocada.

Este artículo es una lista práctica de qué medir entre la instalación y la compra, cómo nombrarlo, qué cifras vigilar y los errores que hacen que los embudos mientan.

El embudo, paso a paso

El embudo típico de una app de suscripción tiene cinco pasos:

1. Instalación: la app se abrió por primera vez.
2. Onboarding terminado: la persona pasó tus pantallas de introducción y tus preguntas.
3. Paywall visto: se mostró tu oferta.
4. Prueba iniciada (si ofreces una).
5. Pago: una primera compra, o una prueba que se convirtió.

Algunas apps añaden creó una cuenta entre el 2 y el 3, o ponen el paywall en mitad del onboarding. No pasa nada. El embudo debe seguir a tu app, no a una plantilla. Eso sí, que sea corto: cinco o seis pasos sobre los que de verdad vas a actuar valen más que veinte que nunca vas a leer.

Los eventos

Cada paso es un evento que tu app envía en un momento concreto. El momento importa más que el nombre.

Unas pocas reglas hacen que estos eventos sean fiables:

• Nombres fijos y cortos para las pantallas, como goal, notifications, plan. No «Pantalla 3», que cambia de significado el día que reordenas el onboarding.
• Una ubicación en cada paywall. El paywall al final del onboarding y el que está detrás de una función bloqueada son ofertas distintas para personas distintas. Si los mezclas, las dos cifras dejan de significar nada.
• Registro solo para cuentas nuevas. Si los usuarios que vuelven e inician sesión en un teléfono nuevo también envían sign_up, tu tasa de registro sube cada vez que alguien reinstala.
• Las compras, desde la fuente de verdad. Una compra enviada desde la app no puede ver renovaciones, reembolsos ni pruebas que se convierten con la app cerrada. Si usas RevenueCat o un servidor, deja que sea él quien informe de las compras.

Nunca pongas respuestas ni datos personales en los eventos

Las cifras que vigilar

Convierte los eventos en unas pocas tasas y míralas cada semana.

• Onboarding completado: onboarding terminado ÷ instalaciones. ¿Es baja? Mira el abandono pantalla por pantalla.
• La mayor caída: la pantalla donde se va más gente. Arregla esa primero; casi siempre es una petición de permiso demasiado pronto, un formulario largo o una pantalla lenta.
• Alcance del paywall: paywall visto ÷ instalaciones. Si es bajo, el paywall no es tu problema: la gente nunca llega a él.
• Conversión del paywall: prueba o compra ÷ paywall visto, por ubicación.
• De prueba a pago: pago ÷ prueba iniciada, medido solo en pruebas lo bastante antiguas como para haber terminado.
• Tiempo hasta el pago: cuántos días después de instalar paga la gente por primera vez. Te dice cuánto esperar antes de juzgar las instalaciones de una semana.

Míralas también por fuente. La gente que llegó desde el vídeo de un creador a menudo no se parece en nada a la que llegó desde un anuncio de búsqueda, y una media de ambas oculta lo que necesita cada una.

Errores que hacen que los embudos mientan

Contar por fecha del evento en lugar de por fecha de instalación

Si cuentas «pagos de esta semana» frente a «instalaciones de esta semana», una prueba iniciada la semana pasada que se convierte el martes cae en la cohorte equivocada. Elige a las personas por cuándo instalaron y luego cuenta todo lo que hicieron después, por tarde que sea. Cuenta con que las cifras de la semana pasada suban a medida que llegan los que pagan tarde; es lo correcto, no un error.

Exigir un orden estricto cuando tu app no lo tiene

Si alguien puede ver el paywall antes de terminar el onboarding (con un botón de «ir a los planes», por ejemplo), un embudo con orden estricto lo deja fuera. Cuenta cada paso para cualquiera que lo haya hecho en cualquier momento, y usa un orden estricto solo cuando tu pregunta sea sobre la secuencia.

Dar a la gente por «perdida» demasiado pronto

Quien no ha terminado el onboarding después de diez minutos puede estar haciendo la cena. Espera un día antes de considerarlo un abandono.

Dispositivos de prueba en tus cifras

Tus propios builds de depuración, las instalaciones de TestFlight y las compras de sandbox inflan todos los pasos. Déjalos fuera automáticamente, no acordándote de filtrarlos.

Demasiado poca gente

Con 40 instalaciones, una compra más mueve la conversión más de dos puntos. Antes de comparar dos versiones, espera a que cada una tenga suficiente gente como para que la diferencia no sea ruido.

Hacerlo con Unolink

Montar todo esto a mano significa una herramienta de analítica, un generador de embudos, una fuente de compras y una hoja de cálculo para unirlo todo. El SDK de Unolink (plan Pro y superiores, 19 US$ al mes) lo hace en un solo sitio. Es una librería pequeña para iOS, Android, React Native y Flutter, con un evento listo para cada paso de arriba, así que añades una línea por momento y te ahorras los debates sobre nombres. La referencia de eventos los enumera.

• Onboarding muestra el alcance de cada pantalla, cuántos se fueron ahí, cuántos la omitieron y cuánto tardaron. Los eventos de pantalla son gratis: no cuentan para la cuota mensual de eventos de tu plan. Consulta Encuentra la pantalla del onboarding donde la gente abandona.
• Embudo cuenta a las personas por fecha de instalación e incluye los pagos tardíos. Los pasos cuentan en cualquier momento, con la opción «Contar pasos solo en este orden». Divídelo por enlace, UTM, plataforma, país, pantalla de onboarding o ubicación del paywall.
• Recorridos muestra cada instalación del clic a la compra: su camino, dónde dejó el onboarding y cuándo pagó.
• Informe señala fugas, picos y cuánto tarda la gente en pagar, con reglas fijas sobre tus propias cifras, sin IA.
• Los usuarios nuevos y los que vuelven se distinguen, así que las reinstalaciones no parecen registros nuevos.
• RevenueCat se conecta con una línea; después, las pruebas, compras, renovaciones y reembolsos llegan solos y nada se cuenta dos veces. Consulta Atribución en RevenueCat.
• Los dispositivos de prueba quedan fuera automáticamente.

Como Unolink también sabe qué enlace trajo cada instalación, el mismo embudo se divide por publicación, creador o anuncio. Así descubres que el creador con menos instalaciones en realidad trajo más usuarios de pago.