¿Por qué hacer pruebas A/B específicamente de capturas?

Las capturas son el activo con mayor impacto en una ficha de tienda. Los propios datos de Apple sobre Product Page Optimization muestran que las primeras tres capturas generan la mayor parte del aumento en conversión de una ficha — más que el ícono, el subtítulo o incluso el video de vista previa de la app. La documentación de Store Listing Experiments de Google reporta lo mismo: las pruebas ganadoras de gráficos suelen superar por amplio margen a las de texto.

La razón por la que los equipos omiten las pruebas de capturas es la fricción. Producir cuatro conjuntos de variantes (control + 3 variantes) × tres tamaños de iPhone × dos tamaños de iPad × los idiomas en los que publicas significa decenas de archivos por prueba. Con una API de renderizado, la fricción desaparece — un duplicado de plantilla, un cambio de parámetro, una llamada a la API.

¿Qué deberías probar realmente?

Prueba una variable por ronda. Las variables de mayor impacto, en orden aproximadamente descendente, son:

El titular de la primera captura — visible sin desplazarse en los resultados de búsqueda
Función destacada — qué capacidad presentas primero
Estilo de fondo — color plano vs degradado vs fotográfico
Marco del dispositivo — con marco vs sin marco, ángulo del mockup
Posición del texto — arriba, abajo o superpuesto
Color del elemento de llamada a la acción — color principal de marca vs color de acento contrastante

Resiste el impulso de probar cinco cosas a la vez. Las pruebas multivariadas requieren un volumen de tráfico que la mayoría de las apps no tienen, y terminas con una ganadora que no puedes explicar.

¿Cómo generas variantes de forma programática?

Duplica la plantilla de control en el editor, cambia un elemento, guarda. Luego renderiza cada variante con la misma estructura de llamada a la API — solo cambia el templateId:

generate-variants.sh

bash

# Render the control + 3 challengers
for VARIANT in control red_cta photo_bg short_headline; do
  curl -X POST https://api.screenshots.live/v1/renders \
    -H "Authorization: Bearer $SCREENSHOTSLIVE_API_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{
      \"templateId\": \"tpl_home_v3_${VARIANT}\",
      \"locales\": [\"en-US\"],
      \"devices\": [\"iphone-6.7\", \"iphone-6.1\"],
      \"outputDir\": \"./variants/${VARIANT}\"
    }"
done

Para la mayoría de las pruebas, renderiza solo los idiomas que la prueba realmente apunta. Product Page Optimization de App Store Connect se ejecuta por idioma, así que una prueba solo para EE. UU. solo necesita activos en en-US.

¿Cómo configuras la prueba en App Store Connect (PPO)?

Product Page Optimization de Apple te permite probar hasta tres páginas retadoras contra tu página predeterminada en un solo idioma. Apple distribuye el tráfico de forma aleatoria, reporta impresiones y tasa de conversión por variante, y muestra intervalos de confianza cuando la prueba alcanza significancia.

En App Store Connect, abre tu app → Product Page Optimization → Crear nueva prueba.
Agrega hasta tres variantes de página de producto. Cada variante tiene su propio conjunto de capturas, vista previa de app e ícono.
Asigna el tráfico. El 25 % por defecto por variante (control + tres) funciona para la mayoría de las apps.
Elige una localización. PPO se ejecuta por idioma — la misma prueba no puede aplicarse a varios idiomas simultáneamente.
Envía a revisión. Cada variante es revisada por App Review como un envío binario normal.
Inicia la prueba una vez que todas las variantes estén aprobadas.

Consulta la página oficial de Apple Product Page Optimization para conocer los límites actuales y los tiempos de revisión.

¿Cómo configuras Google Play Store Listing Experiments?

El flujo de Google es similar pero más flexible. Desde Play Console, ve a Presencia en la tienda → Store Listing Experiments → Crear experimento. Elige:

Tipo: Ficha predeterminada (global) o Ficha localizada (por idioma)
Activo: capturas de teléfono, tablet de 7 pulgadas, tablet de 10 pulgadas, gráfico destacado, ícono
Variantes: hasta tres retadoras vs control
División de audiencia: 25 %/25 %/25 %/25 % por defecto, o personalizada

Play Console gestiona los intervalos de confianza automáticamente y señala la ganadora cuando el aumento es estadísticamente significativo. Lee la documentación más reciente de Google en Ejecutar experimentos en tu ficha de tienda.

¿Qué tan grande debe ser la muestra?

Usa una calculadora estándar de prueba z de dos proporciones con estos parámetros:

Tasa de conversión base: la tasa de clics actual de tu página de producto (típicamente 25–35 % en App Store, 5–10 % en Play Store)
Aumento mínimo detectable: un aumento relativo del 5 % es un umbral razonable; por debajo del 3 % rara vez vale la pena el tiempo
Nivel de significancia: 95 % (α = 0.05)
Potencia: 80 % (β = 0.20)

Para una base del 30 % y un aumento relativo del 5 %, necesitas aproximadamente 100k–150k impresiones por variante. La mayoría de las apps con menos de 50k impresiones semanales deberían ejecutar pruebas secuenciales (una variante durante dos semanas, luego la siguiente, comparando con una base histórica estable) en lugar de concurrentes.

¿Cuánto tiempo deberías ejecutar una prueba?

Al menos una semana completa. Los patrones de conversión varían significativamente según el día de la semana y la fuente de tráfico (Search Ads vs orgánico). Siete días capturan un ciclo semanal completo. Dos semanas es mejor cuando el tráfico es bajo. Detén la prueba antes solo si (a) la diferencia es abrumadora (>30 % de aumento) y (b) la prueba ha corrido al menos siete días completos. Detenerse antes por ruido es la forma más común de publicar una ficha peor que la inicial.

¿Cómo lees los resultados sin engañarte?

Usa el intervalo de confianza propio de la plataforma. Tanto Apple PPO como Google Play Experiments reportan intervalos de confianza al 90 % / 95 % sobre el aumento de la variante respecto al control. Si el intervalo cruza cero, la prueba no es concluyente — no publiques la retadora solo porque la estimación puntual es positiva.

No intentes derivar resultados desde datos de un MMP de terceros. La variante que ve un usuario la decide Apple o Google del lado del servidor — tu MMP no puede ver de qué variante provino el usuario. El panel propio de la tienda es la única fuente de verdad.

¿Qué haces con la ganadora?

Promueve la variante ganadora a predeterminada. Las plantillas perdedoras no deberían eliminarse — guárdalas como puntos de referencia y escribe una nota de una línea sobre lo que cambió y lo que aprendiste. La siguiente prueba se basa en la anterior: si un titular corto le ganó a uno largo, tu próxima prueba podría explorar estilos de ícono dentro del marco del titular corto.

Combina esta guía con la guía de automatización CI/CD para que las variantes se generen automáticamente en cada lanzamiento, y la guía de localización para que tu ganadora se traduzca a más de 30 idiomas sin tener que volver a probar cada uno.

Cómo hacer pruebas A/B de capturas de pantalla en App Store para conversión

Resumen