Test A/B de Paywall Móvil: una Guía Práctica
Testea el paywall móvil: dónde posicionar el disparador, hard y soft paywall, la métrica que decide y la estadística correcta para apps iOS y Android.
📚 Este artículo es parte de la guía Test A/B en Apps Móviles: la Guía Completa (iOS + Android).
Un test A/B de paywall móvil compara dos versiones de cómo y cuándo le pides al usuario que pague, midiendo cuál genera más conversión de suscripción sin destruir la retención después. Es el test que más decide los ingresos de una app de suscripción, y también el más fácil de leer mal, porque un paywall más agresivo casi siempre eleva la conversión del primer momento, incluso cuando empeora el negocio en el agregado. Este artículo es hijo de test A/B en apps móviles (la guía completa del clúster) y asume la misma base estadística explicada allí: unidad de aleatorización por dispositivo, feature flag remota en lugar de despliegue instantáneo y cuidado redoblado con el SRM entre versiones de app.
Si tu foco todavía es la primera experiencia del usuario antes de llegar al paywall, mira también la guía de test A/B de onboarding móvil, porque dónde aparece el paywall dentro del onboarding es, en la práctica, una decisión conjunta de los dos experimentos.
Dónde posicionar el paywall en la app
El timing del paywall es la variable aislada que más cambia el resultado de un test de monetización móvil, más incluso que el texto o el diseño de la pantalla. Tres momentos concentran la mayor parte de los tests reales:
- Antes del onboarding (paywall inmediato, hard). El usuario ve la oferta de suscripción antes siquiera de usar el producto, a veces con un trial de plazo fijo incorporado. Convierte mejor entre quienes ya llegaron decididos a pagar (tráfico pago cualificado, por ejemplo), pero aleja a parte de quienes solo querían probar, reduciendo el volumen total que llega a activar.
- Después del “aha moment” (paywall en medio del embudo). El usuario ya sintió el valor central del producto (completó la primera acción relevante, vio el primer resultado) antes de ver cualquier oferta. Tiende a convertir una base menor, pero más convencida, porque la decisión de pagar viene después de una experiencia real, no de una promesa.
- Al alcanzar un límite de uso (soft paywall). El usuario usa una versión gratuita real hasta chocar con un tope (un número de búsquedas, un límite de ítems guardados, un recurso premium específico), y solo entonces ve la oferta. Es el modelo más común en apps de productividad y herramientas, porque deja que el producto pruebe su valor antes de cobrar.
Hard paywall y soft paywall: qué testea cada uno
Hard y soft paywall no son solo posiciones diferentes en el embudo, son modelos de negocio diferentes, y testear uno contra el otro es una decisión mayor que testear copy o color de botón.
| Criterio | Hard paywall | Soft paywall (freemium) |
|---|---|---|
| Acceso al producto sin pagar | Ninguno, o solo un trial con plazo fijo | Real, hasta un límite de uso o recurso |
| Conversión trial/free a pago (mediana, RevenueCat) | 10,7% en D35 | 2,1% |
| Top 10% de las apps (RevenueCat) | 38,7% | no medido en el mismo corte por RevenueCat |
| Volumen de instalaciones que llega a experimentar el valor | Menor (quien no convierte, se va temprano) | Mayor (un producto gratuito real retiene a más gente) |
| Qué testear típicamente | Duración del trial, momento del prompt, mensaje de urgencia | Dónde queda el límite, qué es gratuito, el disparador de exhibición de la oferta |
| Riesgo principal | Alejar al usuario que solo quería probar | Nunca convertir a quien ya recibe valor gratis |
Según el mismo reporte de RevenueCat, incluso dentro del modelo hard paywall la duración del trial cambia mucho el resultado: los trials de 17 a 32 días convierten a una mediana del 42,5%, contra 25,5% en trials de menos de 4 días, y el 55% de las cancelaciones de trials de 3 días ya ocurren en el día 0, antes incluso de que el usuario pruebe el producto por un día entero. Eso no decide qué duración es la correcta para tu producto, pero muestra que “cuánto tiempo dar de trial” es, en sí mismo, una variable de test tan relevante como el texto del paywall.
Qué testear en el paywall móvil
Cuatro variables concentran la mayor parte de los tests de paywall con efecto real medible:
- El mensaje. Lo que el paywall promete (ahorro de tiempo, un recurso específico, prueba social) cambia la percepción de valor incluso antes de que aparezca el precio. Testea un beneficio concreto contra una lista de recursos genérica.
- La posición del disparador. Cuándo aparece el paywall (por tiempo de uso, por intento de usar un recurso, por número de sesiones) cambia quién lo ve y en qué estado de intención.
- Hard paywall contra soft paywall. Como ya se detalló, es el test de mayor impacto y también el de mayor riesgo, porque cambia el modelo de adquisición, no solo la pantalla.
- Presentación de los planes: anual y mensual. Qué plan viene preseleccionado, cómo se ancla el anual (precio por mes equivalente, descuento porcentual, ahorro en valor absoluto) y el orden de exhibición de los planes afectan tanto la conversión como el plan elegido, lo que cambia el LTV incluso sin cambiar la conversión bruta.
Sobre el último punto: testear qué plan viene preseleccionado por defecto suele tener un efecto desproporcionado al esfuerzo de implementación, porque la mayoría de los usuarios acepta la opción ya marcada en lugar de cambiarla activamente. Ese es también el punto donde Apple es más rígida: la App Store Review Guideline 3.1.2 exige que el valor total cobrado sea el elemento de precio más visible y legible de la pantalla de compra, con cualquier precio promocional, trial o cálculo de descuento exhibido en posición subordinada y menor. En la práctica, eso restringe tests que intenten esconder o reducir la prominencia del precio completo para empujar el plan anual, el mismo tipo de variación que pasaría sin problema en un paywall web.
La métrica que decide: conversión free-to-paid y retención posconversión
El principio es el mismo de cualquier test de paywall o pricing en la web: la métrica primaria es la conversión de free (o trial) a pago, siempre acompañada de un guardrail de retención posconversión, porque convertir a más gente que cancela rápido después no es una victoria, es solo postergar la pérdida. El matiz móvil está en dos puntos que casi no existen en un checkout web:
- Cancelar es más fácil dentro del app store. Apple exige que la cancelación de una suscripción se haga por el gestor de suscripciones de la propia cuenta Apple, y la app del desarrollador ni siquiera tiene acceso para procesar esa cancelación directamente. Google también garantiza la cancelación por la Play Store, pero su política de suscripciones pasó a exigir que la propia app del desarrollador ofrezca un camino de cancelación fácil, en un máximo de dos toques, prohibiendo patrones de diseño que escondan o dificulten esa opción. En los dos casos, quien controla cuánto se puede dificultar la cancelación no es el desarrollador, al contrario de un checkout web, donde el propio producto controla el flujo (y a veces lo dificulta a propósito), lo que quiere decir que un paywall agresivo tiende a mostrar el efecto de cancelación más rápido en móvil que en la web.
- El reembolso vía tienda tiene un plazo propio, fuera de tu control. Según el soporte de Google Play, las suscripciones son reembolsables dentro de las 48 horas de la compra inicial por el proceso estándar de solicitud; después de eso, cancelar impide cobros futuros, pero no devuelve el período ya pagado. Apple, según su propio soporte oficial, recomienda que el pedido de reembolso se haga en hasta 14 días pero técnicamente acepta solicitudes de hasta 90 días desde la compra, evaluando cada caso individualmente. Ninguna de las dos ventanas la define tu producto, así que cualquier cálculo de ingresos netos de un test de paywall necesita considerar ese plazo específico de la tienda, no el plazo de reembolso que usarías en un checkout propio.
Trata esos dos puntos como guardrail, no solo como nota al pie: un paywall ganador en la conversión bruta que también eleva el reembolso y la cancelación en el primer mes puede estar solo comprimiendo en el tiempo unos ingresos que de todos modos se iban a ir.
Particularidades móviles que cambian el test
Tres factores específicos de móvil amenazan la lectura de un test de paywall y pasarían desapercibidos en un test de sitio web:
SRM entre versiones de app
Si la variación del paywall depende de una versión nueva de la app o de una configuración remota que todavía no llegó a todo el mundo, una parte de la base cae en el control por defecto (o ni siquiera entra en el test), sin que nadie lo haya decidido a propósito. Un ejemplo con números reales: un test de paywall configurado a 50/50 debería exponer 5.000 usuarios a cada variación, de un total de 10.000 que llegaron al momento del paywall en una semana. Como la variación nueva solo renderiza en versiones de app iguales o más recientes que la actualización, el resultado observado fue 6.200 usuarios en la variación de control y 3.800 en la variación nueva. El chi cuadrado de bondad de ajuste para esa divergencia ((6200-5000)² / 5000 + (3800-5000)² / 5000) da aproximadamente 576, un valor muy por encima del umbral crítico de significancia al 1% (6,63 con 1 grado de libertad), es decir, una división de esa magnitud es, en la práctica, imposible que ocurra por azar. La causa más probable es técnica (versión de app o caché de configuración remota), no estadística, y ningún resultado de conversión de ese test debería ser confiable hasta que la causa sea corregida.
Latencia de propagación de la configuración remota
Incluso cuando la variación del paywall no depende de una nueva versión de binario (solo de una flag leída vía remote config), el dispositivo necesita buscar esa configuración antes de exhibirla, y ese proceso no es instantáneo. Una app en segundo plano por días, o en un dispositivo con ahorro agresivo de batería, puede seguir mostrando la versión antigua del paywall por bastante más tiempo del esperado. Trata los primeros días de cualquier test de paywall como un período de propagación, no como muestra válida para sumar sin verificación a la lectura final.
Reglas de tienda sobre el precio en el paywall
Además de la Guideline 3.1.2 de Apple ya citada, Google Play ofrece nativamente la herramienta Price experiments en Play Console, hecha para testear precio con tráfico real; el propio Google recomienda esperar la significancia estadística antes de aplicar la variación ganadora, pero esa aplicación es manual (un botón que el desarrollador acciona), no automática, y esa herramienta hoy está limitada a productos sueltos (in-app products) dentro de la app, no al precio de la suscripción del paywall en sí. Apple no tiene una herramienta nativa equivalente de test de precio dentro de App Store Connect; testear precio, copy y layout del paywall en iOS depende de tu propio mecanismo de remote config, respetando los límites de la Guideline 3.1.2 sobre la prominencia del valor cobrado.
Un ejemplo trabajado con números reales
Escenario: una app con paywall soft (el usuario usa gratis hasta un límite, después ve la oferta) convierte hoy al 7% de los usuarios que ven el paywall de free a pago. El equipo rediseña el mensaje y el momento del disparador, esperando una mejora relativa del 20% (del 7% a cerca del 8,4%). Con 95% de confianza y 80% de poder, los mismos estándares usados en toda calculadora de este blog, ajusta los números 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 ese cálculo con la misma matemática de la calculadora (sampleSizePerVariant), el resultado es 5.691 usuarios por variación (11.382 en total, contando a quienes realmente ven el paywall, no el total de instalaciones de la app). Si 1.800 usuarios por semana llegan al momento del paywall (un volumen realista para una app de porte medio en una pantalla de conversión, bastante por debajo del total de instalaciones), la duración del test queda en 45 días, cerca de seis semanas y media, para que las dos variaciones cierren la muestra.
Ahora mira lo que ocurre si el equipo decide mirar el resultado temprano, con solo un tercio de la muestra calculada (1.897 por variación), con tasas de conversión observadas casi idénticas a las del escenario completo:
| Muestra completa (5.691 por variación) | Muestra parcial, ⅓ (1.897 por variación) | |
|---|---|---|
| Tasa A (control) | 6,99% | 7,01% |
| Tasa B (variación) | 8,40% | 8,38% |
| Mejora relativa observada | +20,1% | +19,5% |
| Valor p | 0,0049 | 0,113 |
| Intervalo de confianza de la diferencia | +0,43 a +2,38 puntos | −0,33 a +3,07 puntos |
| Veredicto | Significativo, B gana | Inconcluso |
La mejora observada es prácticamente la misma en los dos casos (la variación nueva realmente parece cerca de un 20% mejor), pero el veredicto cambia por completo: con la muestra completa, el valor p queda en 0,0049 y el intervalo de confianza de la diferencia no cruza el cero, entre 0,43 y 2,38 puntos porcentuales, un resultado sólido. Con un tercio de la muestra, el valor p sube a 0,113, por encima del umbral de 0,05, y el intervalo cruza el cero (va de −0,33 a +3,07 puntos), es decir, todavía es plausible que el nuevo paywall no haga ninguna diferencia. Eso no significa que el test parcial “salió mal”, significa que faltó muestra para que el mismo efecto real se convirtiera en evidencia estadística, y es exactamente por eso que la duración calculada de 45 días existe: para no decidir mirando el panel a mitad de camino.
Errores comunes en el test de paywall móvil
| Error | Por qué ocurre | Consecuencia |
|---|---|---|
| Medir solo conversión, sin guardrail de retención | La conversión del primer momento es más fácil de ver que la cancelación de semanas después | Paywall “ganador” que en realidad solo aceleró una pérdida de ingresos que ya iba a ocurrir |
| No segmentar el SRM por versión de app | La variación nueva solo llega a quien ya actualizó, y eso pasa desapercibido en el agregado | Resultado de conversión inválido, incluso pareciendo “limpio” a primera vista |
| Confundir test de ASO con test de paywall | Los dos comparan “dos versiones de algo”, pero en puntos diferentes del embudo | Optimizar icono y capturas no mueve la conversión de suscripción dentro de la app, y viceversa |
| Ignorar el plazo de propagación de la configuración remota | La flag se lee en la próxima sincronización de la app, no instantáneamente | Primeros días del test contaminados con usuarios que todavía ven la versión antigua |
| Testear variaciones de precio que esconden el valor cobrado en iOS | Prisa por replicar un test que funcionaría en un paywall web | Riesgo de rechazo en la revisión de Apple por violar la Guideline 3.1.2 |
| Declarar ganador con muestra parcial | Ansiedad por lanzar rápido, mirando el panel antes de tiempo | El mismo efecto real puede aparecer como inconcluso solo por falta de muestra, como en el ejemplo trabajado de arriba |
ASO y paywall: dos cosas diferentes
Es común confundirlos porque ambos “testean dos versiones de algo relacionado con la app”. El test de ASO (App Store Optimization) corre en la ficha de la tienda, antes de la instalación: Apple lo ofrece como Product Page Optimization en App Store Connect, testeando solo elementos visuales (icono, capturas, video de preview), y Google como Store listing experiments en Google Play Console, que va más allá de lo visual y también testea texto (descripción corta y descripción completa), los dos con tráfico real de búsqueda y navegación de la tienda. Lo que decide un test de ASO es la tasa de conversión de visualización de la ficha en instalación. El test de paywall in-app corre después, dentro del producto ya instalado, y lo que decide es la conversión de free (o trial) a pago. Una app puede ganar un test de ASO y seguir con el mismo paywall débil, o al revés: son optimizaciones independientes, sobre métricas diferentes, y vale la pena correr las dos, pero nunca tratar una como sustituta de la otra.
Haz esto automático en Donnu
Esta guía cubrió lo que cambia de verdad cuando el test de paywall sale de un checkout web y entra en la app: hard contra soft paywall como decisión de modelo de negocio, SRM que suele nacer de una versión de app desactualizada, latencia de propagación de configuración remota y reglas de tienda sobre la prominencia del precio cobrado, todo eso además de la misma disciplina de muestra y significancia que vale para cualquier test A/B.
Donnu hoy es una herramienta enfocada en el lado web y client-side: un snippet ligero que nunca traba la página, detección de SRM y estadística bayesiana honesta, con el intervalo de confianza del 95% al frente del veredicto. No testea paywall dentro de una app nativa iOS/Android, y esta guía no afirma lo contrario. Si tu producto tiene una capa web que participa del recorrido de pago (una landing page que vende el plan antes de la instalación, un checkout web complementario, un área logueada accedida también por el navegador), Donnu ya aplica ese mismo rigor estadístico a esa parte con una prueba gratis de 14 días.
Lee también: Test A/B en apps móviles: la guía completa (iOS + Android) · Test A/B de onboarding móvil
Referencias
- RevenueCat. State of Subscription Apps 2026. Benchmarks de conversión de trial/free a pago por modelo de paywall y duración de trial, con base en más de 100 mil apps. revenuecat.com/state-of-subscription-apps.
- Google Play Console. Price experiments. Página oficial sobre la herramienta nativa de test A/B de precio de productos sueltos (in-app products), con aplicación manual de la variación ganadora recomendada después de la significancia estadística; hoy no cubre el precio de suscripción. play.google.com/console/about/price-experiments.
- Apple Developer. App Review Guidelines (sección 3.1.2, Subscriptions). Reglas oficiales sobre la prominencia del valor cobrado e información de suscripción en la pantalla de compra. developer.apple.com/app-store/review/guidelines.
- Apple Support. Request a refund for apps or content that you bought from Apple. Plazo y proceso oficial de solicitud de reembolso de compras y suscripciones. support.apple.com/en-us/118223.
- Google Play Help. Apps, games, & in-app purchases (including subscriptions) refund policies. Ventana de 48 horas y proceso de solicitud de reembolso para suscripciones en Google Play. support.google.com/googleplay/answer/15574908.
- Google Play Console. Store listing experiments. Test A/B nativo de la ficha de listado (icono, feature graphic, capturas, video y también descripción corta y completa), distinto del test de paywall dentro de la app. play.google.com/console/about/store-listing-experiments.
- Apple. Product Page Optimization. Recurso de App Store Connect que testea variaciones de icono, capturas y video de preview de la ficha, también distinto del paywall in-app. developer.apple.com/app-store/product-page-optimization.
Preguntas frecuentes
- ¿Cuál es el mejor momento para mostrar el paywall en una app móvil?
- No existe un momento universal, por eso esto es un test y no una elección de diseño. Tres posiciones concentran la mayor parte de los tests: antes del onboarding (paywall inmediato, hard), después del "aha moment" (cuando el usuario ya sintió el valor central del producto) y al alcanzar un límite de uso (soft paywall, el usuario usa gratis hasta un tope y solo entonces ve la oferta). Cada una convierte diferente dependiendo de qué tan rápido tu producto entrega valor perceptible; mide por la conversión free-to-paid real, no por la tasa de clic en el botón de suscribirse.
- ¿Cuál es la diferencia entre hard paywall y soft paywall?
- El hard paywall bloquea el acceso al producto hasta que el usuario se suscribe (o, como máximo, libera un trial con plazo fijo antes de cobrar). El soft paywall deja al usuario usar una versión gratuita real, con límite de uso o de recursos, y solo muestra la oferta de pago cuando aparece ese límite o cuando el usuario intenta una función premium. Según RevenueCat, en el reporte State of Subscription Apps, las apps con hard paywall convierten a una mediana del 10,7% de trial a pago en D35, contra 2,1% en apps con modelo freemium (soft paywall), una diferencia de cerca de 5 veces, pero eso no decide por sí solo qué modelo es el correcto para tu producto: el hard paywall también tiende a reducir el volumen total de instalaciones que llega a experimentar la app.
- ¿La métrica de un test de paywall es solo la conversión free-to-paid?
- No, y tratar solo la conversión como métrica primaria es el error más caro en este tipo de test. La conversión free-to-paid decide el test, pero siempre leída junto con un guardrail de retención posconversión (el suscriptor sigue pagando en los meses siguientes, o cancela rápido) y, en móvil, con la tasa de reembolso vía tienda, porque cancelar y pedir reembolso dentro del app store es más fácil para el usuario que en cualquier checkout web, y un paywall agresivo puede inflar la conversión del primer momento y derribar los ingresos reales semanas después.
- ¿Qué es el SRM entre versiones de app y por qué amenaza un test de paywall?
- El SRM (Sample Ratio Mismatch) es cuando la división observada entre variaciones diverge de la configurada por un problema de recolección, no por azar. En el paywall, la causa más común es que la variación nueva dependa de una versión de app o de una configuración remota que todavía no llegó a una parte de la base: esos usuarios caen en el control por defecto (o ni siquiera entran en el test), inflando un lado sin que nadie lo haya decidido a propósito. Segmenta siempre el verificador de SRM por versión de app antes de confiar en cualquier resultado de conversión del paywall.
- ¿El test de paywall in-app es lo mismo que un test de ASO?
- No, son mecanismos completamente diferentes. El test de paywall corre dentro de la app ya instalada, después de que el usuario abrió el producto, y mide conversión de suscripción. El test de ASO (App Store Optimization), como el Product Page Optimization de Apple o los Store listing experiments de Google Play, corre en la ficha de la tienda, antes de la instalación, y mide conversión de visualización en instalación. Apple testea solo elementos visuales (icono, capturas, video de preview); Google Play va más allá y también testea texto (descripción corta y descripción completa) además de lo visual. Ninguno de los dos testea precio ni el flujo de suscripción dentro del producto.
- ¿Puedo testear el precio de suscripción móvil igual que testeo el copy del paywall?
- Técnicamente sí, pero con más cautela regulatoria que un test de copy o de posición del disparador. Google Play Console tiene una herramienta nativa llamada Price experiments, pero hoy cubre precio de productos sueltos (in-app products), no el precio de suscripción en sí; para suscripción, Google ofrece otros mecanismos, como aumento de precio con aviso previo a los suscriptores actuales, no un test A/B de precio en ese formato. Del lado de Apple, la App Store Review Guideline 3.1.2 exige que el valor cobrado sea el elemento de precio más visible y legible de la pantalla, con cualquier texto de trial o precio promocional en posición subordinada, lo que limita qué variaciones de layout de precio son seguras de testear en un paywall iOS sin correr riesgo de rechazo.