Test A/B de Onboarding Móvil: qué Mejora la Retención
Test a/b onboarding móvil: qué métrica de activación usar, el efecto real de los permisos del sistema y el error estadístico que engaña a las apps.
📚 Este artículo es parte de la guía Test A/B en Apps Móviles: la Guía Completa (iOS + Android).
Testear A/B el onboarding de una app móvil solo produce una respuesta confiable cuando la métrica que decide el test es la activación de verdad, la conclusión de una acción clave específica dentro de una ventana fija de días, y no una métrica de vanidad como “pantallas del tutorial vistas”. Este artículo forma parte de la guía completa de test A/B en apps móviles (iOS + Android) y cubre el experimento más común y peor medido del móvil: el onboarding. Vas a ver qué métrica usar, qué cambian la pantalla pequeña y los permisos del sistema en la conversión, el sesgo que infla resultados sin que nadie lo note y la trampa estadística exclusiva de apps con versiones diferentes en campo.
La métrica real de activación: D1/D7/D30 y la acción clave, no pantallas del tutorial
La trampa más común de quien testea onboarding móvil es optimizar lo que es fácil de contar (pantallas vistas, botones tocados, porcentaje del tour completado) en vez de lo que de hecho predice si ese usuario va a volver. La práctica recomendada de growth móvil trabaja con una curva de retención en tres hitos: D1 (el usuario abre la app de nuevo al día siguiente), D7 (vuelve y repite la acción central dentro de una semana) y D30 (el hábito se consolidó). Ninguno de esos tres hitos es “vio el tutorial entero”. Cada producto tiene su propia acción clave: para una app de finanzas puede ser conectar una cuenta; para una de fitness, registrar el primer entrenamiento; para una de mensajería, tener la primera conversación real. Define la tuya antes de testear cualquier cosa en el flujo de bienvenida.
Los benchmarks de mercado ayudan a calibrar la expectativa, nunca a definir una meta. El relevamiento de retención móvil de UXCam reporta estos rangos para las apps de mejor desempeño, el percentil 75 de cada categoría:
| Categoría | D1 | D7 | D30 |
|---|---|---|---|
| Social | 50% a 60% | 25% a 30% | 15% a 20% |
| Fintech | 35% a 45% | 18% a 25% | 10% a 15% |
| Productividad | 40% a 50% | 22% a 28% | 12% a 18% |
| Juegos | 40% a 50% | 12% a 18% | 5% a 8% |
| E-commerce | 25% a 30% | 8% a 12% | 3% a 6% |
Lee esos rangos como el cuartil superior, no como el promedio. Según el mismo relevamiento de UXCam, un D30 por debajo del 5% es la norma en la mayoría de las categorías, no la excepción, con la mediana alrededor del 4%. Si tu app convierte por encima de eso, el problema no es la curva general, es cuánto tu onboarding empuja gente hacia arriba o hacia abajo de ella, y eso solo un test A/B con la métrica correcta consigue medirlo.
Pantalla pequeña, decisiones grandes: qué cambia del onboarding web al móvil
En el onboarding web, el usuario tiene una pantalla grande, varias ventanas abiertas y la chance de volver después. En móvil, cada elemento de la pantalla compite por una atención mucho más escasa: el espacio físico es menor, la sesión es más corta y la distracción (una notificación de otra app, una llamada) está a un toque de distancia. Eso cambia lo que vale la pena testear:
- Un elemento por pantalla pesa más. Un formulario de registro entero en una pantalla móvil suele convertir peor que el mismo formulario dividido en pasos cortos, porque cada campo extra visible compite directamente por el pulgar del usuario.
- El permiso del sistema operativo entra en medio del flujo. Es la diferencia más concreta y más medible entre onboarding móvil y web: pedir push, ubicación o cámara es una interrupción nativa que el navegador no tiene, y el momento en que aparece afecta directamente cuántas personas terminan el onboarding.
- La actualización de la app no es instantánea. En la web, publicar un cambio afecta a todos en la siguiente carga de página. En móvil, una variación nueva de onboarding solo llega a quien está en una versión de la app que la soporta, y eso crea una trampa estadística propia, que vamos a ver más adelante.
El punto que más tumba la conclusión: cuándo pedir permiso del sistema
Pedir push, ubicación o cámara en la primera pantalla del onboarding es el error de UX más repetido en apps móviles, y su costo es medible, no apenas una sensación de “fricción”. La documentación oficial de Android sobre buenas prácticas de permisos recomienda pedir el permiso en el contexto de uso, en el momento en que el usuario está a punto de usar la funcionalidad que lo necesita, y no de forma genérica al inicio de la app: el usuario acepta más cuando entiende por qué se le está preguntando, y rechaza más cuando el pedido llega sin contexto. El mismo patrón aparece del lado de iOS: las pantallas de priming (una explicación del valor antes del prompt oficial del sistema) tienden a elevar la tasa de aceptación, mientras que empujar el prompt en el primer acceso tiende a reducirla.
El embudo de abajo marca dónde suele entrar ese pedido en un onboarding self-serve típico, y el tamaño de la caída que aparece exactamente ahí:
Trata el momento del pedido de permiso como cualquier otra variable testeable: la variación A pide en el primer acceso, la variación B pide solo cuando el usuario toca una funcionalidad que exige ese permiso. Mide el efecto en la conclusión del onboarding y en la activación real, porque el permiso en sí no es el objetivo, es solo un medio.
El sesgo de supervivencia ataca el onboarding móvil de la misma forma
El mismo error estadístico que invalida tests de onboarding en SaaS web aparece aquí, y el artículo hermano sobre test A/B de onboarding en SaaS ya describe la lógica general: comparar la activación solo entre quienes terminaron el onboarding, ignorando a quienes abandonaron en el medio, es comparar dos grupos que ya fueron filtrados de formas diferentes. En móvil eso suele ser más severo, porque la pantalla de permiso y la pantalla pequeña juntas producen más abandono precoz que la mayoría de los flujos web.
Reaprovechando los números del embudo anterior: 1.000 personas instalaron la app, 640 completaron el onboarding y 220 realizaron la acción clave dentro de 7 días. Si mides la activación solo entre quienes terminaron el onboarding (el error común), el número parece excelente. Si la mides contra todos los que entraron, el número honesto es bastante menor:
En la práctica, define la ventana de activación (D7, por ejemplo) contada a partir de la instalación, y cuenta cada instalación que entró en el test en el denominador, incluso la que nunca volvió a abrir la app. Es más incómodo de mirar, pero es el único número que representa lo que de hecho ocurrió.
La trampa exclusiva del móvil: atrapado en una versión antigua, y el SRM que nadie detecta
Existe un problema estadístico que prácticamente no existe en la web y que es común en móvil: parte de tus usuarios queda atrapada en una versión antigua de la app, porque el cambio de onboarding solo existe a partir de una versión nueva publicada en la tienda, o porque el dispositivo todavía no buscó la configuración actualizada de un remote config. Según la documentación de Firebase Remote Config, el intervalo mínimo por defecto de búsqueda en producción es de 12 horas: una app puede quedar corriendo con la configuración antigua en caché por hasta medio día después de que publicaste el cambio, y un usuario que no abre la app con frecuencia puede quedar atrapado en la versión antigua por mucho más tiempo que eso.
El efecto práctico: si la división del test depende de que el dispositivo ya haya recibido la variación nueva, quien está atrapado en la versión antigua nunca entra en el experimento como debería, y el tráfico que sobra para cada lado deja de coincidir con el 50/50 que configuraste. Eso es exactamente lo que detecta el SRM (Sample Ratio Mismatch): un test de bondad de ajuste entre la división observada y la esperada. La investigación de Microsoft sobre diagnóstico de SRM en tests A/B trata ese problema como lo bastante serio como para trabar la lectura de cualquier test hasta que sea descartado, y el usuario atrapado en una versión antigua de la app es el caso móvil más común de ese mismo defecto: parte del público nunca tuvo una chance real de caer en el lado esperado.
Mira cómo aparece eso en los números. Un test configurado para 50/50 (6.000 esperados de cada lado, de un total de 12.000) pero con una porción de usuarios atrapada en la versión antigua produce una división bien diferente de la esperada:
La corrección práctica: segmenta el verificador de SRM por versión de la app, no solo por el total agregado. Si el desequilibrio desaparece al excluir versiones antiguas del cálculo, el problema está confirmado y la solución es forzar la actualización (o excluir versiones incompatibles de la división), nunca solo “ignorar y mirar el resultado de activación de todas formas”.
Onboarding móvil y onboarding SaaS web: misma disciplina, detalles diferentes
La estadística detrás de un test A/B de onboarding es la misma en cualquier canal: muestra dimensionada antes de correr, denominador completo contra el sesgo de supervivencia, y ninguna lectura de significancia sin verificar la salud de la división. El test A/B de onboarding en SaaS cubre exactamente esa disciplina para productos web, y vale la lectura complementaria. Lo que cambia en móvil son los detalles de ejecución: la variación depende de qué versión de la app tiene instalada el usuario (la web no tiene ese concepto, toda visita ya carga el código más reciente), y la entrega de un cambio vía remote config tiene una latencia real de propagación hasta que el dispositivo busca la configuración nueva, en vez de ocurrir instantáneamente como en la siguiente carga de una página web. Ignorar esas dos diferencias es la forma más común de importar un test A/B “de libro” de la web y que falle silenciosamente en móvil.
Tour guiado, sandbox libre o progressive onboarding: sin ganador universal
Las tres estructuras más comunes de onboarding móvil resuelven problemas diferentes, y ninguna de ellas gana siempre:
La tabla resume qué testear en cada etapa del onboarding móvil y dónde vive el riesgo de engañarse:
| Etapa | Qué testear | Hipótesis común | Riesgo de engañarse |
|---|---|---|---|
| Permiso del sistema | Momento de pedir push, ubicación o cámara (en el 1er acceso contra después de una acción de valor) | Pedir con contexto aumenta la aceptación | Medir solo la tasa de opt-in infla el permiso como éxito; mide el efecto en la activación, no solo en la aceptación |
| Estructura del flujo | Tour guiado contra sandbox libre contra progressive onboarding | Menos carga cognitiva en la pantalla pequeña aumenta la conclusión | Concluir el tour no es activar; mide la acción clave, no pantallas vistas |
| Densidad de la pantalla | Cuántos elementos por pantalla (un CTA contra varios) | Pantallas más “vacías” reducen el abandono | Una pantalla demasiado vacía puede esconder información que faltaba, y eso solo aparece en la retención, no en la conclusión de la pantalla |
| Push de reactivación | Notificación posinstalación (timing y disparador) para quien no volvió solo | Un recordatorio en el momento correcto recupera el uso | Solo alcanza a quien aceptó push; comparar sin ajustar el denominador reintroduce el sesgo de supervivencia |
| Entrega de la variación | Rollout vía nueva versión de tienda contra vía remote config | El remote config llega más rápido a todos | El caché local y los usuarios atrapados en versión antigua distorsionan la división 50/50 (verificar SRM por versión) |
Dimensionando el test: cuántos usuarios nuevos necesitas
Supongamos que tu app activa hoy el 22% de los nuevos registros dentro de 7 días (la acción clave ya validada, en la ventana de D7) y quieres detectar una mejora relativa del 15% traída por un nuevo posicionamiento de la pantalla de permiso, es decir, llevar la activación a cerca de 25,3%. Con 95% de confianza y 80% de poder, los parámetros estándar de mercado, ajusta la calculadora de abajo a tu propio escenario:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Corriendo esos números en la misma matemática de la calculadora (sampleSizePerVariant), el resultado es 2.602 registros por variación (5.204 en total). Con un volumen de 2.500 nuevas instalaciones por semana, el test tarda cerca de 15 días en reunir esa muestra, tiempo suficiente para cubrir al menos dos semanas completas de comportamiento, incluyendo fines de semana.
Mira por qué ignorar esa cuenta es la forma más común de descartar una buena idea de onboarding. Simulando el mismo efecto real usado en la cuenta de arriba (22% contra 25,3%, usando significance()) en dos volúmenes de muestra diferentes:
| Escenario | N por variación | Activados (A / B) | Valor p | Veredicto |
|---|---|---|---|---|
| Muestra dimensionada | 2.602 | 572 / 658 | ≈ 0,0050 | Significativo, B gana |
| Muestra insuficiente | 900 | 198 / 228 | ≈ 0,0962 | Inconcluso, mismo efecto real |
La diferencia entre “funcionó” y “no funcionó” no vino de que el efecto real cambiara, es la misma ganancia de activación en los dos casos. Lo único que cambió fue el tamaño de la muestra. Los equipos de onboarding móvil en etapa temprana, con pocos cientos de instalaciones por semana, son especialmente vulnerables a esa trampa: corren el test por 10 días, leen “no dio significativo” y descartan una idea que en realidad funcionaba, solo faltó muestra.
Antes de correr cualquier test de onboarding, escribe la hipótesis primero: la guía de cómo escribir una hipótesis de test A/B tiene el formato exacto y evita que termines “descubriendo” un ganador entre decenas de métricas secundarias solo por azar.
Hazlo automático con Donnu
Declarar un ganador de onboarding móvil sin corregir el sesgo de supervivencia o sin verificar el SRM por versión de app es la forma más común de celebrar un resultado que no existe. Donnu A/B aplica el mismo motor de significancia de este artículo a cada variación, siempre contra el denominador completo de quienes entraron en el test, y el snippet ligero nunca traba el flujo de onboarding de tu producto. Antes de declarar cualquier ganador, dimensiona el test con la calculadora de arriba y confirma la salud de la división segmentada por versión de la app, no solo en el agregado.
Empieza una prueba gratis de 14 días y dimensiona el próximo test de onboarding con el rigor correcto, no con el volumen que “parece suficiente”.
Lee también: Test A/B en Apps Móviles: la Guía Completa (iOS + Android) · Test A/B de Onboarding en SaaS: qué Activa Más · Cómo escribir una hipótesis de test A/B
Referencias
- Android Developers. App permissions best practices (timing y contexto del pedido de permiso). developer.android.com/training/permissions/usage-notes.
- UXCam. Mobile App Retention Benchmarks by Industry. uxcam.com/blog/mobile-app-retention-benchmarks.
- AppsFlyer. 5 ways to increase your ATT opt-in rates (priming antes del prompt del sistema). appsflyer.com/blog/tips-strategy/apps-boost-att-opt-in.
- Microsoft Research. Diagnosing Sample Ratio Mismatch in A/B Testing. microsoft.com/en-us/research/articles/diagnosing-sample-ratio-mismatch-in-a-b-testing.
- Firebase. Get started with Remote Config on Android (intervalo por defecto de búsqueda/caché). firebase.google.com/docs/remote-config/android/get-started.
Preguntas frecuentes
- ¿Cuál es la métrica real de activación en un onboarding móvil?
- Es la conclusión de una acción clave específica de tu producto (la core action) dentro de una ventana fija de días, como D7 o D30, contada a partir de la instalación, no a partir del final del tutorial. "Pantallas del onboarding vistas" o "tour completado" son métricas de vanidad: describen si el usuario pasó por la introducción, no si volvió a usar la app. Valida la acción clave cruzando quién la hizo con quién realmente sigue activo en D7/D30, antes de testear cualquier variación de onboarding.
- ¿Pedir permiso de push, ubicación o cámara durante el onboarding tumba la conversión?
- Sí, y el efecto es medible, no solo una impresión. La documentación de Android sobre buenas prácticas de permisos recomienda pedir el permiso en el contexto de uso, no al inicio de la app, porque el usuario acepta más cuando entiende por qué se le está preguntando. El patrón relatado por proveedores de medición de apps sobre el opt-in de ATT en iOS apunta en la misma dirección: una pantalla de priming antes del prompt oficial del sistema, mostrando el valor primero, tiende a aumentar la aceptación, mientras que empujar el pedido en el primer acceso tiende a reducirla. El timing exacto es testeable: trátalo como una variación más de tu test A/B de onboarding, no como un detalle técnico fijo.
- ¿Por qué mi test de onboarding móvil puede "dar significativo" y aun así estar equivocado?
- El motivo más común es el sesgo de supervivencia: medir la activación solo entre quienes terminaron el onboarding, y no entre todos los que entraron en el test. Si una variación aleja a más gente temprano (una pantalla de permiso mal posicionada, por ejemplo), quienes quedan tienden a ser un público más comprometido por naturaleza, y la tasa "entre quienes terminaron" queda artificialmente mejor aunque la activación real, mirando a todos, sea peor o igual. La comparación correcta siempre usa el denominador completo: todos los que instalaron y entraron en el test.
- ¿Qué rompe la división 50/50 cuando testeo el onboarding en una app móvil?
- El caso más específico de móvil es el usuario atrapado en una versión antigua de la app que nunca recibe la nueva variación, porque el cambio solo existe a partir de una versión nueva publicada en la tienda (o porque el caché local del remote config todavía no buscó la configuración actualizada). Eso empuja tráfico desproporcionado hacia el lado antiguo y rompe la división que configuraste como 50/50. Corre el verificador de SRM (Sample Ratio Mismatch) segmentado por versión de la app antes de confiar en cualquier resultado de activación.
- ¿Tour guiado, sandbox libre o progressive onboarding: cuál convierte más?
- No existe un ganador universal, y por eso mismo esto es un test, no una elección de diseño hecha de oído. Los productos con un camino único y obvio hasta el valor central tienden a ganar con un tour guiado. Los productos cuyo valor depende del contexto específico del usuario (datos propios, integraciones, casos de uso variados) tienden a ganar con un sandbox libre o con un progressive onboarding, que solo pregunta lo necesario conforme avanza el uso. Mide por la activación real en la ventana fija de días, no por la tasa de conclusión del flujo.