Test A/B de Ficha en App Store (ASO): qué puedes testear

El test A/B de ficha en app store es un test que la plataforma ejecuta en tu página de tienda, antes de que nadie instale, y se mide con un único número: la conversión de vista de ficha a instalación. No es el mismo mecanismo que un test A/B dentro de tu app, no usa tu código, y ninguna herramienta de terceros puede ejecutarlo por ti. Este artículo forma parte de la guía completa de test A/B en apps móviles y cubre qué te dejan testear realmente Google Play y la App Store, cómo decide cada una al ganador, cómo dimensionar un test de tienda con números reales, y las trampas que hacen que una ficha “ganadora” no mueva las instalaciones tras el lanzamiento.

Dónde encaja un test de ficha dentro del embudo

Todo lo que un equipo de app puede testear se divide limpiamente en dos zonas, separadas por la propia instalación.

Qué te deja testear cada tienda

Las dos plataformas están cerca en espíritu y lejos en cobertura. Ambas ejecutan el experimento contra tráfico real de tienda, lo dividen ellas mismas y reportan la conversión de cada variante. Dónde se separan es en qué te permiten variar.

	Google Play (experimentos de ficha)	App Store (Product Page Optimization)
Recursos visuales testeables	Icono, gráfico destacado, capturas, vídeo de vista previa	Icono, capturas, vistas previas de la app
Texto de la ficha testeable	Sí, las descripciones de la app	No, Product Page Optimization no cubre nombre, subtítulo ni descripción
Dónde se configura	Google Play Console	App Store Connect
Tráfico usado	Tráfico real de búsqueda y exploración de Google Play	Tráfico real de la App Store, con una parte configurable asignada al test
Duración máxima	Google documenta una parada automática a los 6 meses	Apple documenta hasta 90 días
Métrica reportada	Clics de instalación por variante, reportados con intervalo de confianza	Tasa de conversión de cada tratamiento frente al original
Localización	Los experimentos se configuran por localización de la ficha	Los tratamientos pueden localizarse por mercado

De esa tabla se deducen dos consecuencias. Primera, si tu hipótesis es sobre las palabras (“¿llamarlo agenda en lugar de lista de tareas sube las instalaciones?”), Google Play puede responderla de forma nativa y la App Store no: en iOS tendrías que cambiar los metadatos y comparar periodos, que no es un experimento controlado. Segunda, un test de icono es la única hipótesis que las dos tiendas responden igual, y por eso el icono es el primer test más habitual en ambas plataformas.

Hay otra función de Apple que la gente confunde con un test: las páginas de producto personalizadas, que son versiones alternativas de tu página con sus propias URL, usadas para casar una campaña de adquisición concreta con un mensaje concreto. Son una herramienta de segmentación, no un experimento: no hay división aleatoria ni grupo de control. Úsalas para alinear el tráfico de pago con la página a la que llega, y usa Product Page Optimization cuando quieras una comparación controlada.

Qué no puedes testear en la tienda

Vale la pena decir con claridad la lista de lo que queda fuera de los experimentos nativos, porque mucha guía de ASO pasa de puntillas por encima:

• Precio y niveles de compra dentro de la app. No forman parte de ningún experimento de tienda. Los experimentos de precio pertenecen a tu backend o a una estrategia promocional, y traen sus propias consideraciones de equidad y comunicación.
• Palabras clave de metadatos como test controlado. Puedes cambiar palabras clave y observar qué pasa, pero ninguna tienda divide el tráfico entre dos conjuntos de palabras clave, así que lo que obtienes es una comparación de antes y después contaminada por estacionalidad, movimientos de la competencia y deriva de ranking.
• Categoría y clasificación por edad. Configuración, no creatividad.
• La propia app. Cualquier cosa posterior a la instalación es un test de feature flag, no un test de tienda.
• Comparaciones entre tiendas. Una variante que gana en Google Play no te dice nada estadísticamente válido sobre la App Store. Audiencias distintas, disposición de página distinta, mezcla de tráfico distinta. Ejecuta cada test donde corresponde.

Cómo deciden las tiendas al ganador, y por qué aun así conviene hacer las cuentas

Las dos plataformas reportan su propia estimación de confianza, y las dos son honestas al decir que un resultado dentro de la banda de incertidumbre no es un resultado. Eso es genuinamente útil, y también es donde la mayoría de los equipos deja de pensar, lo cual es un error por dos razones.

La primera es que el veredicto nativo de la tienda responde “¿es esta diferencia distinguible del ruido?”, no “¿cuánto voy a esperar y merece la pena esa espera?”. Solo un cálculo de tamaño de muestra responde a la segunda pregunta antes de comprometer semanas de tráfico de tienda en un test.

La segunda es que el tráfico de tienda no es tuyo para aumentarlo cuando quieras. En una web puedes apuntar anuncios a una página para acelerar un test. En una ficha de tienda, el experimento consume impresiones orgánicas al ritmo que la tienda las envíe, lo que significa que un test de ficha subdimensionado no solo falla, falla despacio.

Dimensiona el test antes de lanzarlo

Introduce tu tasa de conversión actual de la ficha, la mejora mínima que merecería publicarse y tus vistas semanales de ficha:

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

Toma una ficha que convierte el 28% de las vistas de página de tienda en instalaciones, una cifra plausible para una app establecida con encaje claro de categoría. Tres efectos objetivo, al 95% de confianza y 80% de poder, producen compromisos muy distintos:

Mejora objetivo	Nueva tasa	Muestra por variante	A 10.000 vistas de ficha/semana	A 50.000 vistas/semana
+5% relativo	29,4%	16.388	23 días	5 días
+10% relativo	30,8%	4.155	6 días	2 días
+15% relativo	32,2%	1.872	3 días	1 día

Lee esa tabla antes de diseñar la creatividad, no después. Perseguir una subida relativa del +5% en una ficha que recibe 10.000 vistas por semana significa comprometer más de tres semanas de tráfico de tienda en una sola comparación; perseguir una subida del +15% con un concepto de icono genuinamente distinto se cierra en días. Es el mismo intercambio entre ambición y paciencia que aplica a cualquier test, y el artículo sobre testear con poco tráfico cubre la versión general.

Ahora el lado del resultado. Supongamos que el test corrió hasta 30.000 vistas por variante y produjo 8.400 instalaciones en el control (28,0%) contra 8.820 en el tratamiento (29,4%), exactamente la subida relativa del +5% de la primera fila. Pasando esos números por el mismo motor de significancia usado en todo este blog se obtiene z = 3,79, valor-p ≈ 0,00015, con un intervalo de confianza de la diferencia de +0,68 a +2,12 puntos porcentuales. El intervalo nunca toca el cero, así que el tratamiento convierte genuinamente mejor. Fíjate en lo modesta que es la afirmación honesta: la mejora está en algún punto entre unos dos tercios de punto y dos puntos de conversión, no “el icono nuevo subió las instalaciones un 5%” dicho como certeza.

Las trampas propias de los tests de tienda

La estacionalidad se come los efectos pequeños. La mezcla de tráfico de tienda cambia con las fiestas, las selecciones editoriales de la plataforma, los lanzamientos de la competencia y las campañas de pago que tengas corriendo en otro sitio. Un test que corre durante un pico de toda la categoría está comparando dos variantes en condiciones que ninguna volverá a encontrar. Prefiere una ventana estable, y trata como provisional cualquier resultado hallado solo durante un periodo anómalo.

La mezcla de fuentes de tráfico no es constante. Quien llega desde una búsqueda de tu marca en la tienda se comporta distinto de quien explora un ranking de categoría, que a su vez se comporta distinto de quien toca un enlace de anuncio. Si tu test corre mientras una campaña de pago empuja tráfico atípico a la página, la variante ganadora es la que le conviene a esa mezcla, no necesariamente la que le conviene a tu mezcla normal.

Localizar no es traducir. Un juego de capturas que gana en un mercado pierde con frecuencia en otro, porque las convenciones visuales, el conjunto competitivo y las razones por las que la gente instala son distintas. Ejecuta el test por localización en lugar de generalizar el ganador de un mercado a todos.

Las instalaciones no son el objetivo. Es la trampa más cara de la lista. Una ficha agresiva, que promete más de lo que el producto entrega, sube de forma fiable la conversión a instalación y baja con la misma fiabilidad la retención al día 7, porque recluta gente a la que el producto nunca iba a satisfacer. Por eso la métrica de guarda de abajo importa más que la métrica primaria.

La métrica de guarda: la retención de la cohorte que el test reclutó

Las dos tiendas reportan la conversión a instalación y ahí se detienen, lo cual es razonable, porque no pueden ver dentro de tu app. Tú sí. Etiqueta la cohorte de instalación por variante de test en tu propia analítica y compara la retención al día 1 y al día 7 entre ellas, junto al veredicto de conversión de la tienda.

La regla a adoptar: publica la variante que gana en usuarios retenidos, no en instalaciones. Si la variante B sube la conversión a instalación un 5% relativo y baja la retención al día 7 más que eso en términos relativos, B es una ficha peor que resulta parecer mejor en el panel de la tienda. Es el mismo razonamiento de las métricas de guarda en cualquier experimento, cubierto en el artículo sobre errores comunes en tests A/B.

Lista de comprobación previa a un test de ficha de app store

Elemento	Confirma antes de lanzar
Hipótesis escrita	Una afirmación concreta sobre por qué el recurso nuevo debería convertir mejor, no “probemos un icono más fresco”
Tamaño de efecto elegido de antemano	La mejora mínima que merece publicarse, traducida a muestra y calendario con la calculadora de arriba
Una variable a la vez (cuando sea posible)	Cambiar icono y capturas juntos te dice que ganó el paquete, no qué parte lo hizo
Ventana estable	Sin función de plataforma solapada, pico estacional ni campaña de pago inusual inflando la página
Por localización	Test configurado para el mercado que quieres cambiar, no un mercado generalizado a todos
Métrica de guarda de retención instrumentada	Cohorte de instalación etiquetada por variante en tu propia analítica antes de empezar el test
Verificación posterior al lanzamiento	Tras publicar al ganador, observa la conversión durante un ciclo completo para confirmar que el efecto sobrevive fuera del test

Combinar tests de tienda con tests dentro de la app

La secuencia que funciona es aburrida y eficaz: arregla primero la fuga mayor. Si tu ficha convierte bien y tu onboarding gotea, un icono mejor solo manda más gente a un embudo roto. Si tu onboarding es sólido y casi nadie llega a él, la creatividad de la ficha es el sitio correcto para gastar el próximo mes. Mide las dos, decide con la aritmética, y corre un test cada vez en cada zona en lugar de cuatro tests solapados cuyos efectos ya no puedes separar.

Para la mitad dentro de la app de ese emparejamiento, el test A/B de onboarding móvil cubre la métrica de activación y el sesgo de supervivencia que arruina la mayoría de los resultados de onboarding.

Haz esto automáticamente con Donnu

Los tests de ficha solo pueden ejecutarlos las propias plataformas, y este artículo no pretende otra cosa. Lo que sí viaja entre las dos zonas es la disciplina: dimensiona el test antes de correrlo, lee el intervalo de confianza en lugar de la subida de titular, y mantén siempre una métrica de guarda sobre lo que viene después de aquello que estás optimizando.

Donnu A/B aplica exactamente esa disciplina al lado web de tu embudo: la landing page que alimenta instalaciones, el checkout en vista web, el área logueada accesible desde un navegador. Snippet ligero, dimensionamiento automático de muestra, estadística bayesiana honesta, sin certezas inventadas. Empieza una prueba gratuita de 14 días y deja de publicar ganadores que solo existen dentro del ruido.

Lee también: Test A/B en apps móviles: la guía completa · Test A/B de onboarding móvil · Errores comunes en tests A/B

Referencias

• Google Play Console. Store listing experiments. Página oficial del experimento nativo de ficha de Google Play, ejecutado contra tráfico real de tienda. play.google.com/console/about/store-listing-experiments.
• Apple. Product Page Optimization. Documentación oficial de la función de App Store Connect que testea variantes de icono, capturas y vistas previas frente a la página original. developer.apple.com/app-store/product-page-optimization.
• Apple. Custom product pages. Documentación oficial de las páginas de producto alternativas con sus propias URL, usadas para segmentación de campañas y no para experimentar. developer.apple.com/app-store/custom-product-pages.
• Google Play Console Help. Run A/B tests on your store listing. Referencia de configuración y reporte de los experimentos de Play Console, incluidas métricas objetivo, experimentos localizados y la parada automática a los seis meses. support.google.com/googleplay/android-developer/answer/12053285.
• Sensor Tower. App Store Optimization: visibility and conversions. Referencia de industria sobre práctica de ASO, incluido el test de elementos visuales de la ficha para subir la conversión. sensortower.com/blog/app-store-optimization-visibility-conversions.