Registro diferido móvil: probar antes de registrarse
La tasa de abandono entre "descargar una aplicación" y "crear una cuenta" es brutal. Los estudios muestran que del 40 al 60% de los usuarios abandonan en el momento del registro. Tú pagaste por la adquisición, el usuario hizo el esfuerzo de descargar, y se va porque le pides su correo electrónico incluso antes de que haya visto tu primera funcionalidad.
Mi solución para TAMSIV: retrasar el registro al máximo. Dejar que el usuario pruebe todo —crear tareas, dictar notas, explorar las funciones— sin pedirle nunca una cuenta. Esto se llama lazy registration, y es la mejor decisión de UX que he tomado.
Puntos clave a recordar:
- Supabase Anonymous Auth crea una cuenta invisible desde el primer lanzamiento
- El usuario obtiene un UUID real y los mismos permisos que una cuenta clásica
- La migración anónima a una cuenta real conserva todos los datos intactos
- Los recordatorios de registro deben ser contextuales, nunca intrusivos
- Un onboarding de 3 diapositivas como máximo con un botón "Omitir" visible es suficiente
¿Por qué la fricción del registro mata las conversiones?
Para entender el problema, pongámonos en el lugar del usuario. Descubre TAMSIV en la Play Store, las capturas de pantalla le interesan, la descarga. La aplicación se abre y... formulario de registro. Correo electrónico, contraseña, confirmación por correo electrónico.
En ese momento, el usuario no sabe si la aplicación vale la pena. No ha visto nada, no ha probado nada. Tú le pides un compromiso (sus datos personales) a cambio de una promesa (tu aplicación es genial). Es un trato desequilibrado.
Las cifras son contundentes. Según AppsFlyer, la tasa media de registro post-descarga en las aplicaciones de productividad es del 45%. Esto significa que más de la mitad de los usuarios que descargan nunca crean una cuenta. Es un enorme desperdicio de presupuesto de adquisición.
La lazy registration invierte el problema: en lugar de pedir "regístrate para probar", decimos "prueba, y regístrate si te gusta".
¿Cómo funciona la autenticación anónima de Supabase?
En el primer lanzamiento de TAMSIV, la aplicación crea automáticamente una cuenta anónima a través de Supabase Anonymous Auth. El usuario no ve nada —sin formulario, sin ventana emergente, sin carga. Pero en segundo plano, se crea una cuenta real:
- Se asigna un UUID único (idéntico a una cuenta clásica)
- Se genera un JWT token para la autenticación
- Las RLS policies (Row Level Security) se aplican normalmente
- El usuario puede crear tareas, notas, usar la voz — todo funciona
Técnicamente, la única diferencia entre una cuenta anónima y una cuenta real: no hay correo electrónico asociado. El UUID es idéntico, los permisos son idénticos, el almacenamiento es idéntico. Para el backend y la base de datos, un usuario anónimo es un usuario como cualquier otro.
Es elegante porque evita tener que gestionar dos "modos" en el código. No hay una condición if (isAnonymous) { ... } por todas partes. Los mismos servicios, los mismos RPC, las mismas tablas funcionan de manera uniforme.
¿Cómo diseñar un onboarding minimalista?
El onboarding de TAMSIV son 3 diapositivas. No 7. No 10. Tres.
Cada diapositiva responde a una pregunta:
- "¿Qué es TAMSIV?" — Una frase. "Tus tareas y notas, por voz."
- "¿Cómo funciona?" — Una ilustración animada del dictáfono.
- "¿Por dónde empezar?" — Una CTA directa al dictáfono.
El botón "Omitir" siempre está visible. Siempre. Los usuarios impacientes (y son muchos) deben poder saltarse el onboarding sin fricción. Obligar a alguien a ver 3 diapositivas que no quiere ver es perder su confianza desde los primeros segundos.
Este diseño minimalista está inspirado en las recomendaciones de Nielsen Norman Group sobre el onboarding: mostrar, no explicar. El onboarding más eficaz es aquel que el usuario olvida inmediatamente porque fue natural.
¿Qué son los estados vacíos ricos y por qué son importantes?
Después del onboarding, el usuario llega a la aplicación. Y todo está vacío. Sin tareas, sin notas, sin actividad en el feed. Es un momento crítico: o el usuario entiende qué hacer, o cierra la aplicación.
Los estados vacíos ricos son la solución. En lugar de una pantalla vacía con un mensaje genérico ("Ninguna tarea"), cada pantalla vacía contiene:
- Una ilustración atractiva (no un icono genérico)
- Un mensaje accionable: "Toca el micrófono para crear tu primera tarea"
- Una CTA directa: un botón que inicia inmediatamente la acción
El feed vacío dice: "Dicta tu primera tarea y mira cómo aparece aquí." El botón lanza directamente el dictáfono. Con un toque, el usuario está en acción.
Los estados vacíos sirven como tutorial implícito. No se necesita una guía de 10 pantallas — cada pantalla vacía explica su propia funcionalidad. Es coaching en contexto, el patrón más eficaz para el aprendizaje móvil.
¿En qué momento solicitar el registro?
Esta es la pregunta estratégica. Demasiado pronto, pierdes al usuario. Demasiado tarde, nunca tienes su correo electrónico. El momento es un arte delicado.
He identificado 4 momentos estratégicos para recordar suavemente el registro:
1. Después de la 5ª tarea creada. El usuario ha invertido tiempo. Tiene contenido que no quiere perder. El recordatorio dice: "Crea una cuenta para guardar tus tareas en todos tus dispositivos." El miedo a la pérdida es una palanca poderosa.
2. Después de 3 días de uso. El hábito comienza a formarse. El recordatorio es contextual: "Has estado usando TAMSIV durante 3 días — crea una cuenta para no perder nada."
3. Cuando intenta una función Pro. El sistema de suscripciones requiere una cuenta. El recordatorio es natural: "Esta función está disponible en Pro — crea una cuenta para acceder a ella."
4. Cuando intenta unirse a un grupo. Los grupos colaborativos requieren una identidad. El recordatorio es funcional: "Para unirte a un grupo, crea una cuenta para que tus compañeros de equipo puedan reconocerte."
El punto en común: cada recordatorio aporta valor. No "regístrate porque queremos tu correo electrónico", sino "regístrate porque te desbloquea algo". Nunca intrusivo. Siempre contextual.
¿Cómo migrar una cuenta anónima a una cuenta real?
Esta es la parte mágica. Supabase permite vincular una cuenta anónima a un correo electrónico sin perder ningún dato. El proceso técnico:
- El usuario hace clic en "Crear una cuenta" (uno de los recordatorios contextuales)
- Introduce su correo electrónico y una contraseña
- Supabase "vincula" el correo electrónico a la cuenta anónima existente
- El UUID no cambia
- Todos los datos (tareas, notas, preferencias) permanecen intactos
- El token JWT se renueva con la información de la cuenta real
Para el usuario, es invisible. Tiene la impresión de "crear" una cuenta, pero en realidad "completa" una cuenta que ya existía. Sin migración de datos, sin fusión de cuentas, sin pérdidas. Es mágico desde el punto de vista de la UX.
Es similar a lo que hace Firebase Anonymous Auth, pero la implementación de Supabase es más limpia porque el UUID permanece idéntico. Con Firebase, la migración a veces puede cambiar el UID, lo que rompe las referencias en la base de datos.
¿Cuáles son los riesgos de la lazy registration?
No todo son ventajas. Aquí están los riesgos que he identificado y cómo los gestiono:
Pérdida de datos si la aplicación se desinstala. Una cuenta anónima sin correo electrónico es una cuenta sin forma de recuperación. Si el usuario desinstala la aplicación, todo se pierde. Este es el riesgo principal, y es exactamente por eso que los recordatorios de registro son importantes.
Cuentas zombie en la base de datos. Muchos usuarios crearán una cuenta anónima, probarán la aplicación durante 2 minutos y nunca volverán. Esto genera cuentas y datos huérfanos. He implementado una limpieza automática: las cuentas anónimas inactivas durante más de 30 días se eliminan.
Sin correo electrónico para marketing. Sin correo electrónico, es imposible enviar correos electrónicos de reenganche, boletines o notificaciones de funciones. Este es un costo comercial real de la lazy registration. El compromiso: los usuarios que se registran son usuarios convencidos, no usuarios forzados.
Sincronización multidispositivo imposible. Una cuenta anónima no puede iniciar sesión en otro dispositivo. El usuario no aprovecha el sistema de autenticación por código QR ni la aplicación web hasta que no ha creado una cuenta. Esto es precisamente una de las palancas de conversión.
¿Qué impacto tiene en la retención y las métricas?
Desde la implementación de la lazy registration, las métricas han evolucionado significativamente:
- Tasa de exploración: más del 80% de los nuevos usuarios crean al menos una tarea (frente a ~40% con registro obligatorio)
- Retención D1: aumento significativo — los usuarios que han probado la aplicación regresan con más frecuencia
- Tasa de conversión a cuenta real: aproximadamente el 35% de los usuarios terminan registrándose (pero son usuarios comprometidos)
- Calidad de los registrados: los usuarios que se registran después de probar la aplicación tienen una retención D30 mucho mayor que aquellos que se registraban de inmediato
El compromiso es claro: menos registros, pero registros de mejor calidad. Es una elección deliberada que se alinea con la filosofía de TAMSIV: preferimos usuarios convencidos a métricas infladas.
¿Cómo medir la eficacia del onboarding?
El panel de administración de TAMSIV sigue varias métricas clave:
- Embudo de onboarding: cuántos usuarios ven cada diapositiva, cuántos se saltan
- Tiempo hasta la primera acción: cuánto tiempo transcurre entre la apertura y la primera tarea creada
- Conversión anónima → real: en qué momento (día, acción) se registran los usuarios
- Tasa de abandono por etapa: qué pantalla hace que los usuarios se vayan
El "tiempo hasta la primera acción" es la métrica más importante. Cuanto más corto sea, más eficaz será el onboarding. El objetivo es bajar de los 60 segundos entre el primer lanzamiento y la primera tarea creada. Con el dictáfono de voz, es perfectamente alcanzable: abrir la aplicación, tocar el micrófono, hablar, listo.
Lo que aprendí sobre la UX móvil como desarrollador individual
Construir el onboarding de TAMSIV me enseñó una lección fundamental: como desarrollador individual, cada fricción que añades se paga caro. No tienes el presupuesto de marketing de Todoist o Notion para compensar un onboarding mediocre. Cada usuario perdido en el momento del registro es un usuario que no tienes los medios para recuperar.
La lazy registration no es solo una técnica, es una filosofía: confía en tu producto. Si tu aplicación es buena, los usuarios se registrarán naturalmente. Si no lo es, forzar el registro no cambiará nada.
Es la misma lógica que apliqué al sistema de referidos: la mejor adquisición es el boca a boca de usuarios satisfechos. Y los usuarios satisfechos comienzan con un onboarding que respeta su tiempo.
Preguntas frecuentes
¿Supabase Anonymous Auth es gratuito?
Sí, Anonymous Auth está incluido en el plan gratuito de Supabase. Las cuentas anónimas cuentan como usuarios normales en la cuota (50.000 MAU en el plan gratuito). Las cuentas inactivas limpiadas automáticamente no afectan las cuotas una vez eliminadas.
¿Los datos de una cuenta anónima son seguros?
Sí. Se aplican las mismas políticas RLS (Row Level Security). Un usuario anónimo solo puede acceder a sus propios datos. La única diferencia: sin correo electrónico, la cuenta no se puede recuperar en caso de desinstalación.
¿Se puede combinar la lazy registration con el registro social (Google, Apple)?
Sí. Supabase permite vincular una cuenta anónima a un proveedor OAuth (Google, Apple, GitHub). El proceso es idéntico a la vinculación por correo electrónico: el UUID sigue siendo el mismo, los datos se conservan.
¿Cuánto tiempo se deben mantener las cuentas anónimas inactivas?
TAMSIV elimina las cuentas anónimas después de 30 días de inactividad. Es un equilibrio entre dar tiempo al usuario para que regrese y evitar la acumulación de datos huérfanos. Las cuentas con contenido (tareas, notas) se conservan por más tiempo.
¿La lazy registration funciona para todas las aplicaciones?
No. Las aplicaciones que requieren una identidad desde el principio (mensajería, redes sociales, fintech) no pueden usar este patrón. Es ideal para aplicaciones utilitarias, de productividad o de contenido donde el usuario puede obtener valor antes de identificarse.