Test A/B Móvil vs Web: lo que Realmente Cambia
Test a/b móvil vs web: ciclo de release, unidad de aleatorización, muestra, latencia de propagación y métricas guardia que solo existen dentro de la app.
📚 Este artículo es parte de la guía Test A/B en Apps Móviles: la Guía Completa (iOS + Android).
Test A/B móvil y test A/B web usan exactamente la misma estadística y casi nada más en común. El test de dos proporciones, el valor p, el intervalo de confianza y la fórmula de muestra son idénticos; lo que cambia es el ciclo de release, la unidad de aleatorización, el retraso entre asignar una variación y que aparezca, el volumen de tráfico disponible en las pantallas que importan y las métricas guardia que solo existen dentro de una app. Este artículo es hijo de la guía completa de test A/B en apps móviles y trata una sola pregunta: qué necesita desaprender un equipo que ya testea bien en la web antes de testear dentro de una aplicación.
La versión corta: en la web la parte difícil suele ser decidir qué testear, porque publicar una variación cuesta minutos. En móvil la parte difícil es la maquinaria alrededor del test, porque una variación que no está detrás de una flag remota puede tardar semanas en alcanzar a todo el mundo y no se puede apagar cuando sale mal.
Test A/B móvil vs web: las seis diferencias que cambian el resultado
| Dimensión | Web | App móvil |
|---|---|---|
| Publicar una variación | Inmediato, un snippet o un deploy | Depende del release, la revisión de la tienda y la adopción del usuario, salvo que esté detrás de remote config |
| Matar una variación mala | Inmediato, apagar la flag o revertir | Inmediato solo con remote config; si no, nuevo envío y nuevo ciclo de actualización |
| Unidad de aleatorización | Cookie o storage del navegador, fácil de perder | Identificador de dispositivo o de instalación, a veces la cuenta con sesión |
| Retraso entre asignar y renderizar | Milisegundos | Segundos a días, según la búsqueda de configuración y la apertura de la app |
| Tráfico en la pantalla que decide | Muchas veces decenas de miles por semana | Muchas veces algunos miles por semana |
| Métricas guardia extra | Tiempo de carga, tasa de error | Crash, nota de la tienda, tamaño de la app, batería y consumo de datos |
Cada fila de esa tabla tiene la misma consecuencia práctica: en móvil tienes menos experimentos, más lentos y más caros, así que cada uno necesita ser elegido y dimensionado con más criterio que su equivalente en la web.
Diferencia 1: publicar y matar una variación
En la web, una variación es un deploy o una regla de snippet, y revertir es otro deploy. En móvil, una variación embebida en el binario tiene que pasar por la revisión de la tienda y después esperar a que los usuarios actualicen, lo que hace que la población del test crezca despacio y de forma desigual. Peor: no se puede interrumpir. Una variación que hunde la conversión o rompe una pantalla en una familia específica de dispositivo sigue corriendo hasta que salga una versión nueva y sea adoptada.
Por eso la configuración remota no es un lujo en móvil, es la precondición para testear. La variación viaja dentro del binario pero nace inactiva; una flag en el servidor decide quién la ve, y la misma flag la apaga en minutos. Firebase Remote Config y la capa de A/B Testing encima de él son la implementación más común en ambas plataformas, y toda alternativa seria funciona igual.
Una consecuencia a planificar: la flag se busca, se cachea y se aplica al ritmo de la app, no al tuyo.
Diferencia 2: latencia entre asignación y renderizado
En la web, asignación y renderizado ocurren en la misma carga de página. En móvil existe un hueco. La app busca la configuración remota, la guarda en caché y muchas veces aplica el valor nuevo solo en la apertura siguiente, así que un usuario puede estar asignado a la variación B y seguir viendo la variación A durante horas o días. Dispositivos en modo agresivo de ahorro de batería, o apps dejadas en segundo plano una semana, estiran eso todavía más.
De ahí salen dos reglas prácticas. Primera: trata los días iniciales de un test móvil como ventana de propagación, no como muestra válida; si tu plataforma lo permite, cuenta la exposición a partir del primer evento que prueba que la variación de hecho se renderizó, y no a partir de la asignación. Segunda: nunca compares el número del primer día de un test móvil con el del primer día de un test web, porque el del móvil incluye una mezcla de gente que todavía no ha recibido el cambio.
Diferencia 3: la unidad de aleatorización
Un test web aleatoriza por cookie o clave de storage del navegador, lo que es frágil: storage limpiado, ventana de incógnito y un segundo dispositivo producen una identidad nueva para la misma persona. Un test móvil aleatoriza por identificador de dispositivo o de instalación, bastante más estable dentro de un dispositivo e igualmente inestable entre dispositivos: la misma persona en el móvil y en la tablet puede quedar en los dos lados del experimento.
| Situación | Unidad recomendada | Por qué |
|---|---|---|
| App sin login, un dispositivo por usuario | Identificador de dispositivo o instalación | Estable, simple, no exige identidad |
| Producto con login usado en varios dispositivos | Identificador de la cuenta | Mantiene a la misma persona en la misma variación en todas partes |
| Test que cambia algo antes del login | Identificador de dispositivo, con usuarios logueados analizados aparte | Mezclar las dos unidades en una sola lectura contamina la división |
| Test cuyo efecto solo aparece después del login | Identificador de la cuenta, excluyendo sesiones sin login | Incluir sesiones que no podían convertir diluye el efecto e infla la muestra necesaria |
La regla práctica: elige la unidad que corresponde al nivel en el que ocurre el efecto, y nunca mezcles dos unidades en la misma lectura. Esto se conecta directo con SRM, porque cambiar de unidad a mitad del test aparece como una proporción de división que cambia a lo largo del tiempo.
Diferencia 4: muestra y la aritmética de la paciencia
Aquí la diferencia deja de ser conceptual y pasa a costar semanas. La fórmula no cambia, solo el denominador. Ajusta los números de abajo a tu base y tu tráfico:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
El mismo test, dos plataformas
Toma una tasa de conversión del 3% en la pantalla que decide y un objetivo de detectar una mejora relativa del 10% (de 3,0% a 3,3%), al 95% de confianza y 80% de potencia. La matemática devuelve 53.211 usuarios por variación, en la web y dentro de la app por igual, porque a la estadística no le importa dónde está el usuario.
Lo que cambia es cuánto tiempo lleva acumular eso:
- Web, 40.000 visitantes por semana en la página testeada: cerca de 19 días.
- App, 6.000 usuarios por semana llegando a la pantalla testeada: cerca de 125 días, más de cuatro meses, lo que no es un test, es una estación del año.
La respuesta honesta en móvil no es correrlo igual y espiar. Es cambiar la pregunta: apunta a una mejora relativa del 20% (de 3,0% a 3,6%) y el requisito cae a 13.914 por variación, que con los mismos 6.000 usuarios por semana lleva cerca de 33 días. Un efecto mayor exige un cambio mayor, lo que en la práctica significa testear una pantalla rediseñada en lugar de un botón reescrito.
Diferencia 5: qué se puede y qué no se puede testear
Algunos experimentos simplemente no existen del otro lado de la frontera.
- Solo en la web: cualquier cosa que dependa de publicación instantánea, como testear varias versiones de titular en la misma semana, y cualquier cosa movida por tráfico de búsqueda o referencia que cae directo en la página testeada.
- Solo en la app: tests de ficha de tienda (Product Page Optimization de Apple, experimentos de ficha de Google Play), tests de notificación push y cualquier cosa atada a permisos nativos, como el momento de pedir permiso de notificación o de rastreo.
- En ambas, con reglas distintas: el precio. En la web controlas el checkout y la exhibición del precio. En la app, los requisitos de Apple para suscripciones renovables exigen que el importe que se va a cobrar sea el elemento de precio más prominente del layout en la pantalla de compra, con precio equivalente o ahorro exhibidos en posición y tamaño subordinados, lo que elimina toda una familia de layouts de anclaje que pasarían en un paywall web. La guía de test A/B de paywall móvil cubre esos límites en detalle.
Diferencia 6: métricas guardia que solo existen en una app
Un test web sigue tiempo de carga y tasa de error. Un test móvil necesita seguir tres más, y las tres pueden convertir a un ganador estadístico en una pérdida de negocio.
- Tasa de crash y de app no responsiva por variación. Una variación que carga una pantalla más pesada puede romperse en dispositivos antiguos mientras convierte mejor en los nuevos. Lee estabilidad por variación y, cuando el volumen lo permita, por franja de dispositivo.
- Nota de la tienda y sentimiento de las reseñas. Un cambio de monetización puede ganar en conversión y costar una fracción de estrella, y la nota alimenta el volumen de instalación. Es una pérdida lenta y compuesta que ningún panel de conversión muestra.
- Tamaño de la app, batería y consumo de datos. El usuario de dispositivo de gama baja y de plan de datos limitado se va en silencio. Su ausencia no aparece como conversión menor, aparece como denominador menor, exactamente el tipo de pérdida que una lectura agregada esconde.
El error de sumar móvil y web en un solo resultado
El error más caro de quien corre las dos superficies es tratarlas como un solo experimento con una sola muestra. Las dos poblaciones tienen tasas base distintas, llegan por canales distintos y convierten en plazos distintos. Sumar crea las condiciones clásicas de la paradoja de Simpson, en la que cada grupo apunta hacia un lado y el agregado apunta hacia el otro. Corre dos experimentos, dimensiona cada uno con su propia base y su propio tráfico, y compara las dos lecturas como dos evidencias independientes. Si concuerdan, tu confianza en el mecanismo sube. Si discrepan, aprendiste algo específico sobre la superficie, lo que es más útil que un número mezclado que no describe a ninguna de las dos.
La misma disciplina vale para SRM. Un test de 10.000 usuarios que debería dividir 50/50 y observa 5.300 contra 4.700 produce un chi cuadrado de bondad de ajuste de 36 con 1 grado de libertad, muy por encima del umbral de 6,63 al 1%, con un valor p del orden de dos en mil millones. En la web eso normalmente significa una redirección o un filtro de bots. En móvil normalmente significa una versión de la app o una caché de configuración, e invalida la lectura en ambos casos hasta encontrar la causa.
Un ejemplo trabajado: leer un resultado web con honestidad
Un checkout web convierte al 3,00%. El equipo publica un nuevo layout del paso de pago y corre el test hasta 26.000 visitantes por variación, cerrando con 780 pedidos en el control y 866 en la variación (3,33%). Pasando esos cuatro números por la misma matemática de dos proporciones que este blog usa en todas partes: z = 2,15, valor p ≈ 0,0312, con intervalo de confianza del 95% de la diferencia entre +0,03 y +0,63 puntos porcentuales, y ganancia relativa observada de +11,0%.
El resultado es significativo, y el intervalo es un buen recordatorio de lo impreciso que puede ser un resultado significativo: la ganancia verdadera puede ser tan pequeña como 0,03 puntos, que es casi nada, o tan grande como 0,63 puntos. En la web, correr más tiempo para estrechar ese intervalo cuesta algunos días. Dentro de una app con 6.000 usuarios semanales en la misma pantalla, estrechar el mismo intervalo costaría meses, y esa es la razón real por la que los programas móviles deberían preferir pocos experimentos audaces a muchos experimentos marginales. La guía de significancia estadística explica cómo leer cada uno de esos números.
Hazlo automático en Donnu
Si tu producto vive en las dos superficies, la división honesta del trabajo es esta: dentro de la app, necesitas remote config, aleatorización por dispositivo y métricas guardia de estabilidad; en la web, necesitas un snippet que no retrase la página, dimensionamiento automático de muestra y estadística que no inventa certeza.
Donnu cubre la mitad web y client-side de ese cuadro: snippet ligero, dimensionamiento automático y estadística bayesiana honesta, sin entregar un framework al visitante. No corre experimentos dentro de un binario nativo iOS o Android, y esta guía no finge lo contrario. Si tu recorrido incluye una landing page, un checkout web o un área con sesión accesible desde el navegador, empieza una prueba gratis de 14 días y aplica el mismo rigor a esa mitad.
Lee también: Test A/B en apps móviles: la guía completa (iOS + Android) · Test A/B de paywall móvil · Test A/B client-side vs server-side · Read in English
Referencias
- Firebase. A/B Testing with Firebase Remote Config. Documentación oficial sobre configuración remota, asignación de variante y rollout en iOS y Android. firebase.google.com/docs/ab-testing.
- Apple Developer. Auto-renewable Subscriptions. Requisito oficial de que el importe a cobrar sea el elemento de precio más prominente del layout en la pantalla de compra. developer.apple.com/app-store/subscriptions.
- Apple Developer. App Review Guidelines (sección 3.1.2, Subscriptions). Reglas de revisión para suscripciones, que remiten a los requisitos anteriores. developer.apple.com/app-store/review/guidelines.
- Apple. Product Page Optimization. Test de ficha de tienda en App Store Connect, un tipo de experimento sin equivalente en la web. developer.apple.com/app-store/product-page-optimization.
- Google Play Console. Store listing experiments. Test A/B nativo de ficha de tienda, incluyendo texto además de imágenes. play.google.com/console/about/store-listing-experiments.
- Ayuda de Google Play Console. Release app updates with staged rollouts. Documentación oficial sobre adopción escalonada de versión, que es lo que hace que una variación atada a la versión alcance a los usuarios de forma desigual. support.google.com/googleplay/android-developer/answer/6346149.
- Kohavi, R., Tang, D. y Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material de apoyo en experimentguide.com.
Preguntas frecuentes
- ¿La estadística de un test A/B móvil es distinta de la de un test web?
- No. La matemática es idéntica: mismo test de dos proporciones, mismo valor p, mismo intervalo de confianza, misma fórmula de tamaño de muestra. Lo que cambia es todo lo que rodea a la matemática, y eso es lo que cambia el resultado. Móvil tiene un ciclo de release más lento, unidad de aleatorización ligada al dispositivo en lugar del navegador, retraso entre asignar una variación y que aparezca en pantalla, y mucho menos tráfico en las pantallas que importan. Misma estadística, condiciones más difíciles.
- ¿Por qué los tests A/B móviles tardan tanto más?
- Porque el denominador es menor y la propagación es más lenta. Una landing page puede ver decenas de miles de visitantes por semana; la pantalla de paywall de una app mediana ve algunos miles de usuarios por semana. Con la matemática de este blog, detectar una mejora relativa del 10% sobre una base del 3% exige cerca de 53.211 usuarios por variación. A 40.000 visitantes semanales en la web, eso da aproximadamente 19 días. A 6.000 usuarios semanales dentro de la app, el mismo test tardaría cerca de 125 días, y por eso los equipos móviles suelen elevar el efecto mínimo detectable en lugar de esperar.
- ¿Puedo correr el mismo test en la app y en el sitio y sumar los resultados?
- No, y ese es uno de los errores más comunes. Las dos poblaciones se comportan de forma distinta, entran al embudo por canales distintos y suelen tener tasas base distintas. Sumarlas crea las condiciones de la paradoja de Simpson, en la que la dirección agregada contradice la dirección de cada grupo por separado. Córrelos como dos experimentos separados, cada uno con su propio dimensionamiento, y compara las dos lecturas después como dos evidencias, nunca como un solo conjunto de datos.
- ¿Cuál es la unidad de aleatorización en un test dentro de la app?
- Normalmente el dispositivo o un identificador de instalación, a veces la cuenta con sesión iniciada cuando existe. Eso es más estable que una cookie de navegador, que se borra o se particiona con frecuencia, pero crea un problema distinto: un usuario con móvil y tablet puede caer en variaciones distintas, y una reinstalación puede generar un identificador nuevo para la misma persona. Cuando el mismo usuario tiene que ver siempre la misma variación en cualquier dispositivo, la unidad tiene que ser la cuenta, y quien no ha iniciado sesión debe quedar fuera del análisis en lugar de entrar mezclado.
- ¿Sigo necesitando remote config si mi app puede publicar cada semana?
- Sí, por dos motivos independientes. Primero, publicar no es lo mismo que ser adoptado: una versión solo alcanza a quien realmente actualiza, así que una variación atada a la versión siempre produce una división desigual. Segundo, un test que vive en el binario no se puede apagar. Sin configuración remota, matar una variación perjudicial exige nuevo envío, nueva revisión y nuevo ciclo de actualización, mientras la variación sigue corriendo en todos los dispositivos ahí fuera.
- ¿Qué métricas guardia existen en móvil y no existen en la web?
- Tres que importan. Tasa de crash y de app no responsiva por variación, porque una variación puede estar ganando estadísticamente mientras degrada la estabilidad en un subconjunto de dispositivos. Nota de la tienda y sentimiento de las reseñas, porque un cambio de monetización puede subir la conversión y bajar la nota, lo que después deprime el volumen de instalación. Tamaño de la app y consumo de batería o datos, porque una variación más pesada pierde usuarios en dispositivos de gama baja y redes limitadas, y esas pérdidas no aparecen en la tasa de conversión de quien se quedó.
- ¿Cuánto tiempo del inicio de un test móvil debe descartarse?
- Lo suficiente para que la configuración remota alcance a la base, y ese plazo se mide en lugar de adivinarse. Los primeros días de un test móvil mezclan usuarios que ya recibieron la variación con usuarios que todavía ven la versión antigua, así que tratarlos como muestra válida diluye el efecto. Si tu plataforma lo permite, cuenta la exposición a partir del primer evento que prueba que la variación se renderizó, y no a partir de la asignación. En la práctica, mirar la curva de exposición diaria y empezar a contar cuando se estabiliza funciona bien.