Test A/B en Apps Móviles: la Guía Completa (iOS + Android)

El test A/B en app móvil es la misma idea central que el test A/B en la web (dividir al público al azar entre dos versiones y medir cuál convierte más), pero la ejecución cambia en puntos que deciden si el test va a dar una respuesta confiable o se va a trabar a mitad de camino. No existe deploy instantáneo: todo cambio de UI o de flujo pasa por una feature flag remota, porque publicar una nueva versión en la tienda para cada variación sería inviable y lento. La unidad de aleatorización normalmente es el dispositivo o el usuario autenticado, no la sesión. Y la base instalada nunca se actualiza de una vez, lo que crea una forma específica de contaminar la muestra que casi ninguna guía genérica de test A/B cubre.

Esta guía es el artículo madre del clúster de test A/B en móvil de este blog: cubre lo que cambia de iOS y Android respecto a la web, los tres tipos de test que a veces se confunden (client-side, server-side y ASO en la propia tienda), qué testear en cada pantalla de la app, la estadística aplicada con un ejemplo trabajado usando números reales, las herramientas del mercado en una comparación neutral y los errores que más tumban tests móviles. Si ya conoces lo básico del test A/B, mira también la guía completa de test A/B; si tu foco es CRO de sitio web, la guía de optimización de conversión (CRO) cubre el lado web en profundidad. Este artículo va a ganar posts hijos en las próximas semanas, cubriendo cada una de las pantallas de la app en detalle. El primero ya está en camino: mira la guía completa de test A/B de onboarding móvil ->.

Qué es el test A/B en app móvil, de forma directa

Un test A/B en app móvil toma una pantalla, un flujo o un mensaje dentro de la app (o asociado a ella, como una notificación push) con un comportamiento conocido, y testea una variación de eso contra lo que ya existe, con usuarios reales, al mismo tiempo, exactamente como un test A/B de sitio web. La diferencia no está en el concepto estadístico, que es idéntico: está en cómo la variación llega hasta el usuario y en cómo garantizas que la misma persona siempre vea el mismo lado, a pesar de abrir la app decenas de veces a lo largo de semanas en vez de cargar una página una sola vez.

Los términos específicos de móvil que vas a encontrar

• ID de instalación (device ID) o ID de usuario autenticado: la clave estable usada para decidir de qué lado del test está un usuario, en vez de la cookie de sesión común en la web.
• Feature flag remota: un interruptor configurado en el servidor que enciende o apaga un fragmento de código ya publicado en el binario, sin exigir una nueva versión en la tienda.
• Remote Config: el servicio (Firebase Remote Config es uno de los más usados) que entrega los valores de esas flags a la app en tiempo de ejecución.
• Rollout progresivo (staged rollout / phased release): un mecanismo de la propia tienda que libera una nueva versión de app para una porción creciente de la base a lo largo de días, pensado para seguridad de release, no para test A/B propiamente dicho; es fácil confundir los dos porque ambos “muestran cosas diferentes a personas diferentes”, pero el rollout progresivo no tiene grupo de control ni calcula significancia, solo reduce el radio de un problema hasta que confirmas que la versión está estable.
• Versión mínima elegible: la versión de binario a partir de la cual existe el código de la variación; los usuarios por debajo de ella deben ser excluidos del denominador del test, no solo de la exposición.
• Cohorte de instalación: el grupo de usuarios que instaló la app dentro de una misma ventana de tiempo, útil para aislar el efecto de un cambio sobre quienes entraron después de que fue lanzado.

En qué difiere el test A/B móvil del test A/B web

Cuatro diferencias cambian cómo diseñas, corres y lees un test dentro de una app, comparado con un sitio web:

• Unidad de aleatorización. En la web, muchas herramientas todavía piensan en sesión (la cookie del navegador). En la app, la unidad casi siempre necesita ser el dispositivo (un ID de instalación estable) o el usuario autenticado, porque el mismo visitante puede abrir la app decenas de veces a lo largo de semanas y necesita caer siempre en el mismo lado. Si la atribución es por sesión de uso, el mismo usuario puede alternar entre A y B en aperturas diferentes, y su conversión no pertenece a ningún lado.
• Ciclo de release de la tienda en vez de deploy instantáneo. Un sitio publica un cambio en minutos. Una app necesita enviar una nueva versión a la App Store o a Google Play, esperar la revisión (que puede tardar de horas a pocos días, variando por plataforma y época) y todavía esperar a que la base instalada se actualice orgánicamente, lo que lleva semanas. Por eso prácticamente todo programa serio de test móvil depende de un mecanismo de feature flag remota: la variación ya existe dentro del binario publicado, y el servidor decide, en tiempo real, qué parte del código ve cada usuario, sin necesitar una nueva versión para cada test.
• Latencia de propagación del cambio. Incluso con feature flag, una parte de la base está en modo avión, con la app cerrada hace días, o en un dispositivo con política agresiva de ahorro de batería que retrasa la sincronización con el servidor de configuración remota. El test empieza “encendido” para todo el mundo, pero la exposición real se esparce a lo largo de horas o días, no instantáneamente.
• Fragmentación de versión de la app. A diferencia de la web, donde todos cargan la versión más nueva de la página en cada visita, la app tiene varias versiones de binario corriendo en vivo al mismo tiempo: quien actualizó ayer, quien actualizó hace un mes y quien no actualiza hace seis meses porque desactivó la actualización automática. Si tu test depende de un código que solo existe en las versiones más nuevas, los usuarios atrapados en versiones antiguas quedan fuera de la aleatorización real pero todavía entran en el denominador de alguna métrica de producto, distorsionando cualquier lectura que no aísle eso correctamente.

Tres tipos de test que se confunden: client-side, server-side y ASO

“Test A/B móvil” en realidad cubre tres mecanismos bien diferentes, y es común confundir los tres porque todos comparan dos versiones de algo relacionado con la app:

• Client-side (feature flag remota). La variación vive dentro del binario ya publicado. Un SDK de feature flag (Firebase Remote Config, LaunchDarkly, Statsig y otros) busca la configuración del servidor cuando la app abre o sincroniza, y la propia app decide qué renderizar con base en esa configuración. Es el modelo más común para testear UI, textos, orden de pantallas y pequeñas variaciones de flujo dentro de la app.
• Server-side. La decisión de qué variación mostrar nace en el backend, y la app solo pide “qué debo mostrarle a este usuario” y renderiza lo que vuelve. Es el modelo más robusto para reglas de negocio (precios, elegibilidad de oferta, lógica de recomendación) y para cualquier experimento que además tenga que ser consistente entre app, sitio y correo transaccional, porque la misma decisión de backend alimenta los tres canales.
• Test de ASO en la propia tienda. Técnicamente no es un test A/B “en tu app”: es un experimento corrido por la propia tienda sobre la ficha de listado, antes incluso de la instalación. Google lo ofrece como Store listing experiments en Google Play Console; Apple, como Product Page Optimization en App Store Connect. Los dos testean ícono, capturas y video de vista previa con tráfico real de búsqueda y navegación de la tienda; Google además permite testear el texto de la ficha (descripción corta y larga), lo que el Product Page Optimization de Apple no cubre, ya que queda restringido a ícono, capturas y video. El resultado que lees, en ambos casos, es la tasa de conversión de visualización de la ficha en instalación, no ningún evento dentro de la app.

Comparando los tres lado a lado

Criterio	Client-side	Server-side	ASO en la tienda
Dónde nace la decisión	Dentro de la app, leyendo una flag remota	En el backend, la app solo renderiza	Dentro de la propia tienda (Google Play / App Store)
Qué testea típicamente	UI, texto, orden de pantallas, pequeños flujos	Precio, elegibilidad, regla de negocio, recomendación	Ícono, capturas y video de vista previa (Google y Apple); texto de la ficha solo en Google Play
Consistencia entre canales	Solo dentro de la app	Alta (la misma decisión puede alimentar app, sitio y correo)	No aplica, es solo la ficha de la tienda
Quién opera la herramienta	Equipo de producto/móvil, SDK de feature flag	Equipo de backend/growth	Google Play Console / App Store Connect (la propia plataforma)
Métrica típica	Conversión dentro de la app (activación, upgrade)	Conversión de negocio (ingresos, retención)	Tasa de visualización de la ficha en instalación
Depende de revisión de tienda	No, corre sobre un binario ya aprobado	No	No es exactamente “revisión”, corre dentro del flujo propio de la plataforma

Qué testear en cada pantalla de la app

No toda pantalla de la app merece el mismo esfuerzo de test. Las que más concentran ganancia, en orden típico de impacto:

Pantalla / momento	Qué se suele testear	Cuidado específico
Onboarding / tutorial	Número de pantallas, saltar o no saltar, pedir permiso antes o después de mostrar valor	Es la mayor palanca de activación; el abandono aquí nunca vuelve a aparecer en el embudo
Paywall / upgrade	Posición del precio, ancla de plan, disparador de exhibición (por tiempo, por feature, por uso)	Rige los ingresos directamente; sensible a la versión de la app y a las reglas de la tienda sobre pagos
Notificación push	Horario de envío, copy, segmentación por comportamiento	Cuidado con el huso horario de una base global; testea más cerca del envío, no del clic aislado
Navegación / arquitectura de información	Tab bar contra menú lateral, orden de ítems, nombres de secciones	Cambio estructural, difícil de revertir sin confundir al usuario recurrente
Precios	Planes, período de prueba, descuento de entrada	La misma cautela de cualquier test de precio: el efecto de largo plazo (LTV) no siempre aparece rápido
Checkout in-app	Flujo de pago, número de etapas, métodos aceptados	La compra dentro de la app sigue reglas de Apple y Google sobre comisión y sistema de pago propio de la tienda, que cambian con frecuencia por decisión regulatoria y de plataforma; confirma la regla vigente antes de diseñar el test, en vez de asumir lo que valía hace un año

Sobre el último punto: las políticas de compra dentro de la app (in-app purchase) de Apple y Google ya pasaron por cambios relevantes de comisión y de obligatoriedad de sistema de pago propio en diferentes mercados y períodos, por decisión de las propias plataformas o por presión regulatoria. Trata eso como algo que cambia, no como una regla fija: revisa la documentación oficial vigente de App Store Connect y Google Play Console antes de diseñar cualquier test de checkout in-app, en vez de replicar lo que valía en una época anterior.

La notificación push tiene una relación cercana con el email marketing (el mismo razonamiento de test de asunto y horario de envío se aplica), pero el foco de esta guía es el comportamiento dentro de la app; si tu programa de mensajes cubre también el correo, trata los dos canales con la misma disciplina estadística, cada uno con su propia muestra.

Cómo escribir una hipótesis de test móvil

La misma disciplina de hipótesis que vale para cualquier test A/B vale aquí, solo que la “observación” que origina la hipótesis suele venir de analytics de producto (evento instrumentado en la app), no de un heatmap de sitio web. El formato sigue siendo el mismo: porque observé [dato del producto], creo que [cambio en la pantalla/flag] va a generar [efecto], medido por [métrica de producto].

Un ejemplo concreto de móvil: “porque el 38% de los usuarios abandona el onboarding en la pantalla de pedido de permiso de notificación (dato del embudo de activación instrumentado en la app), creo que mover ese pedido para después de que el usuario complete la primera acción de valor va a reducir el abandono, medido por la tasa de conclusión del onboarding en D1”. Fíjate que esa frase ya entrega la métrica primaria (conclusión del onboarding en D1), la dirección esperada (subir) y el origen (un evento de producto real, no una corazonada del equipo). Las hipótesis débiles en móvil suelen sonar como “y si dejáramos la app más bonita”, sin métrica ni dirección; descarta ese formato antes de gastar un ciclo de desarrollo en él.

Métrica primaria y guardrails específicos de móvil

Toda la lógica de métrica primaria, secundaria y de guarda del test A/B clásico se aplica sin alteración, pero móvil agrega guardrails que prácticamente no existen (o importan mucho menos) en un test de sitio web:

Guardrail	Por qué monitorearlo en móvil	Señal de alerta
Tasa de crash	Una variación puede convertir mejor y aun así tumbar la app con más frecuencia en un dispositivo o versión de sistema operativo específica	La tasa de crash sube de forma aislada en una de las variaciones
Calificación y sentimiento en la tienda	Un cambio agresivo de flujo (paywall demasiado temprano, permiso insistente) puede mejorar una métrica de corto plazo y empeorar la evaluación pública de la app	Caída en la calificación media o aumento de reseñas negativas mencionando el cambio testeado
Tasa de desinstalación	La ganancia de conversión que viene a costa de fricción percibida tiende a aparecer primero aquí, antes de aparecer en churn de suscripción	La desinstalación sube en la variación “ganadora”
Tiempo de carga / cold start	Cualquier SDK de feature flag o remote config agrega una llamada de red; si está mal implementado, retrasa la primera pantalla	El tiempo hasta la primera pantalla interactiva empeora en la variación con la flag

Ignorar esos guardrails es como celebrar un test A/B de sitio web que mejoró la conversión pero también disparó las cancelaciones: el número que decide el test subió, pero el negocio, en el agregado, empeoró.

La estadística aplicada a móvil: por qué la muestra tarda más

La matemática detrás de un test A/B móvil es exactamente la misma de un test A/B web (la misma aproximación normal de dos proporciones), pero tres factores hacen la cuenta más dura en la práctica:

1. Menor tráfico elegible. Un sitio de marketing puede tener decenas de miles de visitantes por semana en una sola página. Una app suele tener un volumen de instalaciones nuevas o de usuarios activos en una pantalla profunda del embudo (paywall, checkout) que es una fracción de eso, porque el público ya pasó por un filtro de instalación antes de llegar ahí.
2. Ciclos de actualización de la app. Si el test depende de una versión nueva del binario, una parte de tu público objetivo simplemente todavía no es elegible, porque no actualizó. El denominador “todos los que deberían entrar en el test” crece despacio, al ritmo de la actualización orgánica.
3. Contaminación por versión antigua. Los usuarios en una versión antigua de la app, que no tienen el código de la variación ni de la flag, siguen generando eventos de producto (aperturas, conversiones) que pueden terminar entrando en una métrica agregada si el pipeline de análisis no filtra por versión mínima elegible, distorsionando la lectura sin que nadie se dé cuenta a tiempo.

Calcula la muestra de tu test móvil

Ajusta la tasa de conversión de la pantalla, el efecto mínimo que quieras detectar y el volumen semanal real de tu app (no el tráfico del sitio, el volumen de usuarios elegibles de esa pantalla específica):

Tasa de conversión actual%Efecto mínimo detectablerelativo (%)absoluto (pp)Confianza909599%Poder8090%Visitantes por semana (total)Testbilateralunilateral

-Visitantes por variación

-Total (2 variaciones)

-Duración estimada

Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.

Un ejemplo trabajado con números reales

Vamos a usar un escenario común de app móvil: una pantalla de activación (el usuario completa la acción central en los primeros 7 días, el “D7”) con tasa base de 22%, testeando un cambio en el onboarding que el equipo espera que mejore en +15% relativo (de 22% a cerca de 25,3%). Con 95% de confianza y 80% de poder (los mismos estándares usados en toda calculadora de este blog), la fórmula de tamaño de muestra devuelve 2.602 usuarios por variación.

Si la app tiene 2.500 nuevas instalaciones elegibles por semana (un volumen realista para una app de porte medio, bien por debajo del tráfico de una landing page de marketing), la duración del test queda en 15 días para cerrar las dos variaciones, cerca de dos semanas de espera, incluso con un efecto relativamente generoso de +15%. Es exactamente ese tipo de cuenta lo que explica por qué los tests móviles en pantallas profundas del embudo tardan más que los tests de landing page: no es falta de rigor, es un volumen elegible menor por defecto.

Ahora fíjate en lo que ocurre si el equipo se pone ansioso y decide mirar el resultado con solo 900 usuarios por variación (un tercio de lo necesario), con la misma proporción observada de conversión (22% en el control contra 25,7% en la variación, la misma mejora de +16,7% relativo que aparecería en el test completo):

	Muestra completa (2.602 por variación)	Muestra parcial (900 por variación)
Tasa A (control)	22,0%	22,0%
Tasa B (variación)	25,6%	25,7%
Mejora relativa observada	+16,6%	+16,7%
Valor p	0,00199	0,0679
Intervalo de confianza de la diferencia	+1,3 a +6,0 puntos	−0,3 a +7,6 puntos
Veredicto	Significativo, B gana	Inconcluso

La mejora observada es casi la misma en los dos casos (la variación realmente parece ~16% mejor), pero el veredicto cambia por completo: con la muestra completa, el valor p queda en 0,00199 y el intervalo de confianza de la diferencia no cruza el cero (queda entre +1,3 y +6,0 puntos), un resultado sólido. Con un tercio de la muestra, el mismo efecto real produce un valor p de 0,068, por encima del umbral de 0,05, y el intervalo de confianza cruza el cero (va de −0,3 a +7,6 puntos), o sea, todavía es plausible que no haya ninguna diferencia. Eso no quiere decir que el test parcial “salió mal”: quiere decir que faltó muestra para que el mismo efecto real se convirtiera en evidencia estadística, exactamente el motivo de calcular la N antes de correr, y no decidir “a ojo en el panel” a mitad de camino.

SRM en móvil: la versión antigua de la app como sospechosa principal

El SRM (Sample Ratio Mismatch, divergencia en la proporción de muestra) ocurre cuando la división observada entre variaciones se aleja de la configurada por un problema de recolección, no por azar. En móvil, dos causas dominan la lista de sospechosos:

• Bug de actualización forzada. Una pantalla de “actualiza para continuar” que solo aparece para una variación empuja desproporcionadamente a usuarios de versiones antiguas hacia el otro lado, porque quien actualiza primero tiende a tener un perfil de engagement diferente de quien tarda.
• Crash aislado en una variación. Si la variación B tiene un bug que tumba la app antes de registrar el evento de exposición, la app “desaparece” del conteo de B sin siquiera contar como abandono, inflando artificialmente la participación de A en el total observado.

Un ejemplo con números reales: un test configurado para 50/50 registra, al final, 7.150 usuarios en la variación A contra 4.850 en la B, de un total de 12.000. El verificador de chi-cuadrado de bondad de ajuste (la misma matemática usada en la calculadora de SRM de este blog) devuelve un valor p prácticamente cero para esa divergencia, bien por debajo del umbral de alerta del 1%, o sea, una división de esa magnitud es estadísticamente imposible de ocurrir por azar en un split configurado 50/50. Cualquier resultado de conversión medido en ese test es sospechoso hasta que la causa de la divergencia sea encontrada y corregida, aunque la diferencia entre A y B parezca favorable y “limpia” a primera vista.

Cuánto tiempo dejar corriendo un test móvil

La regla general no cambia: corre por al menos una o dos semanas enteras, aunque la muestra calculada se alcance antes, para cubrir un ciclo completo de días hábiles y fin de semana. En móvil, dos factores adicionales alargan ese plazo en la práctica. El primero es la propagación de la propia feature flag: si el test depende de una versión nueva de la app, el plazo real de “muestra elegible suficiente” solo empieza a contar después de que una porción relevante de la base actualizó, no el día en que configuraste el experimento en el panel. El segundo es el comportamiento cíclico específico de app: el uso de fin de semana en apps de consumo (juegos, entretenimiento, redes sociales) suele diferir bastante del uso en días hábiles de apps de productividad o financieras, y cerrar un test móvil en tres o cuatro días captura una porción sesgada de tu base tanto como la capturaría en un sitio web.

Si el test involucra notificaciones push, el cuidado de huso horario ya discutido antes también afecta la duración: un test que “corre 14 días” en el reloj del servidor puede, en la práctica, exponer a una parte de la base a menos ciclos de envío completos, si el disparo es siempre en el mismo horario de servidor y una porción de la audiencia está en husos donde ese horario cae de madrugada.

Checklist antes de encender un test móvil (activo copiable)

Antes de girar la llave de un test en producción, confirma cada ítem de abajo. Es la versión móvil del test A/A y de los cuidados de ejecución que cualquier test A/B honesto exige, adaptada a los puntos que solo existen en app:

Ítem	Confirmar antes de encender
Unidad de aleatorización	Device ID o user ID estable, nunca sesión de uso
Versión mínima elegible	Los usuarios por debajo de ella están excluidos del denominador, no solo de la exposición
Feature flag testeada en ambos sistemas operativos	La flag renderiza correctamente en iOS y Android antes de que el test salga al aire
Verificación de SRM por plataforma configurada	El verificador de chi-cuadrado corre por separado para iOS y Android, además del agregado
Guardrails instrumentados	Tasa de crash, desinstalación y (cuando aplique) calificación de la tienda monitoreados desde el día 1
Muestra y duración calculadas antes	N por variación y plazo definidos con la calculadora de esta guía, no “vamos a ver cómo va”
Huso horario tratado (si hay push)	Envío y lectura de resultado segmentados por huso del usuario, no por horario del servidor
Test A/A previo (si es la primera vez en la herramienta)	Dos variaciones idénticas no acusan diferencia significativa ni SRM, confirmando que la recolección está limpia

Trata esa lista como una compuerta de calidad, no como burocracia: cada línea existe porque alguna de las causas de test móvil invalidado (peeking aparte) ya apareció en algún programa de experimentación real.

Herramientas de test A/B móvil (visión neutral)

No existe una herramienta correcta para todo el mundo. El criterio que decide es siempre el mismo: client-side o server-side, costo por evento/usuario e integración con el analytics móvil que ya usas (Firebase Analytics, Amplitude, Mixpanel y afines).

Herramienta	Modelo	Punto fuerte	Considérala cuando
Firebase A/B Testing + Remote Config	Client-side	Gratuito hasta un volumen alto, integración nativa con Firebase Analytics y Cloud Messaging	Tu app ya usa el ecosistema Firebase y el test es de UI/flujo dentro de la app
Optimizely Full Stack	Client-side y server-side	Maduro, soporta múltiples SDKs (móvil, servidor, web) bajo el mismo experimento	Necesitas el mismo experimento coordinado entre móvil y backend
LaunchDarkly	Client-side y server-side (feature flag primero)	Foco fuerte en flag de release/rollout progresivo, con experimentación como capa adicional	El objetivo principal es control de release seguro, y el test A/B es un bonus sobre eso
Statsig	Client-side y server-side	Estadística y feature flags integradas desde el inicio, buen soporte a métricas de producto	Quieres experimentación y analytics de producto en la misma herramienta
PostHog	Client-side y server-side (open source)	Analytics de producto, feature flags y experimentos en una sola suite, con opción self-hosted	Ya usas PostHog para analytics y quieres unificar con experimentación
VWO Mobile	Client-side	Viene del mundo de CRO web, curva de uso familiar para quien ya testea landing pages	Tu equipo de marketing ya usa VWO en la web y quiere el mismo modelo mental en la app
AB Tasty App	Client-side	Editor visual pensado para marketing, menos dependiente de ingeniería para variaciones simples	El equipo que crea los tests es de marketing/producto, no solo ingeniería

Vale un criterio final, además de los de la tabla: el costo crece con el volumen de eventos o de usuarios únicos, no con el número de tests corriendo, en la mayoría de esas herramientas. Una app con pocos millones de eventos por mes suele caber en planes gratuitos o de entrada de Firebase, Statsig o PostHog; el volumen alto de eventos es donde la conversación de costo cambia de nivel entre las opciones, y vale pedir una cotización real antes de decidir, en vez de asumirla por el tier público del sitio.

Donnu A/B hoy es una herramienta enfocada en el lado web y client-side: snippet ligero, sin trabar la página, estadística bayesiana honesta. Todavía no cubre app móvil nativa (iOS/Android), y esta guía no afirma lo contrario. Si tu producto es una app híbrida o tiene una capa web relevante (onboarding vía web view, checkout web, landing page que alimenta la instalación), Donnu ya resuelve esa porción con el mismo rigor estadístico que esta guía defiende para toda la app.

Errores comunes específicos de móvil

• Testear con poblaciones de dispositivo desbalanceadas sin verificar SRM por plataforma. iOS y Android suelen tener perfiles de usuario, comportamiento y tasa de conversión diferentes. Correr el verificador de SRM solo en el agregado puede esconder un desbalance que existe dentro de una plataforma específica.
• Ignorar la diferencia de comportamiento entre iOS y Android. Una ganancia fuerte en el agregado puede estar impulsada enteramente por una plataforma, escondiendo una pérdida en la otra. Siempre que el volumen lo permita, lee el resultado segmentado por plataforma antes de generalizar la decisión a toda la app.
• No considerar el huso horario en tests de notificación push. Una base global no está toda despierta al mismo tiempo. Enviar (y medir) push en un horario fijo de servidor, sin ajustar por huso del usuario, mezcla gente en pico de atención con gente durmiendo, distorsionando tanto el test como la experiencia.
• Ignorar la versión desactualizada de la app como fuente de ruido. Como ya cubrimos en la sección de estadística, los usuarios atrapados en una versión antigua sin el código de la variación siguen generando eventos que pueden contaminar métricas agregadas si el pipeline de análisis no filtra por versión mínima elegible.
• Correr el test solo con la métrica de conversión, sin guardrail. Un paywall más agresivo puede elevar la conversión de upgrade en el corto plazo y, al mismo tiempo, aumentar las cancelaciones y las reseñas negativas semanas después. Sin guardrail instrumentado desde el inicio, ese efecto solo aparece demasiado tarde para revertirlo con facilidad.
• Confiar en una muestra pequeña por prisa de lanzamiento. Es tentador declarar ganador apenas el panel muestra cualquier mejora, principalmente cuando el equipo ya quiere avanzar hacia la próxima feature. El ejemplo trabajado de esta guía muestra cómo el mismo efecto real puede parecer “inconcluso” o “significativo” dependiendo solo del tamaño de la muestra, no de la calidad de la idea testeada.

Cuándo NO vale la pena correr un test A/B móvil

El test A/B móvil es la herramienta equivocada en algunos escenarios específicos, y forzar un test que nunca va a cerrar es peor que no testear:

Escenario	Por qué no vale	Qué hacer en su lugar
App con pocos cientos de instalaciones nuevas por semana	El cálculo de muestra fácilmente pide meses para cerrar en una pantalla de conversión rara	Aplica heurísticas conocidas de UX móvil y correcciones de fricción obvia, sin exigir significancia estadística; mira también el concepto de bajo tráfico en la guía de CRO, que vale igual para app
Corrección obvia y sin riesgo	Un crash, un botón que no responde, un texto equivocado: son bugs, no hipótesis	Corrige directo, sin correr un test para “confirmar” lo obvio
La pregunta es “por qué”, no “cuánto”	El test A/B mide el efecto de un cambio, no explica el motivo del comportamiento actual	Usa investigación cualitativa (entrevista con usuario, grabación de sesión, test de usabilidad)
El cambio depende de una nueva versión de binario que la mayor parte de la base todavía no tiene	Mientras la actualización no se propague, la muestra elegible queda demasiado pequeña para cualquier lectura confiable	Espera a que la propagación alcance un piso razonable de la base, o usa feature flag para no depender de una nueva versión en ese test específico

Hazlo automático con Donnu

Esta guía mostró lo que cambia de verdad cuando el test A/B sale del navegador y entra en la app: unidad de aleatorización por dispositivo, feature flag remota en lugar de deploy instantáneo, una muestra que tarda más en cerrar y un SRM que suele nacer de un bug de actualización o de una versión antigua en campo. Es el mismo rigor estadístico que este blog defiende en cada artículo, solo que aplicado a un terreno con más fricción operativa.

Donnu hoy resuelve la parte web y client-side de esa disciplina: snippet ligero que nunca traba la página, dimensionamiento de muestra automático y estadística bayesiana honesta, sin corazonadas. Si tu producto ya mezcla app y web (una landing page que alimenta instalaciones, un checkout u onboarding en web view, un área logueada accedida tanto por el navegador como por la app), el próximo paso natural es llevar esa misma disciplina estadística a tu sitio con una prueba gratis de 14 días, mientras el clúster de móvil de este blog crece con los posts hijos que cubren cada pantalla de la app en detalle, empezando por la guía de test A/B de onboarding móvil.

Referencias

• Firebase. A/B Testing. Documentación oficial de Google sobre cómo testear cambios de UI, features y campañas con Remote Config y Cloud Messaging. firebase.google.com/docs/ab-testing.
• Firebase. Remote Config. Documentación oficial sobre el servicio de configuración remota que permite cambiar el comportamiento y la apariencia de la app sin exigir actualización de versión. firebase.google.com/docs/remote-config.
• Google Play Console. Store listing experiments. Página oficial sobre el test A/B nativo de la ficha de listado en Google Play, con tráfico real de la tienda. play.google.com/console/about/store-listing-experiments.
• Apple. Product Page Optimization. Documentación oficial sobre el recurso de App Store Connect que testea hasta tres variaciones de ícono, capturas y video de vista previa contra la ficha original. developer.apple.com/app-store/product-page-optimization.
• Sensor Tower. App Store Optimization: visibility and conversions. Contenido de Sensor Tower sobre prácticas de ASO, incluyendo el test de elementos visuales de la ficha de la tienda para elevar la conversión. sensortower.com/blog/app-store-optimization-visibility-conversions.