Store Listing Experiments de Google Play: A/B testing de tus capturas de pantalla (2026)
En Google Play no tienes que adivinar si una nueva primera captura de pantalla convierte mejor que la anterior — puedes probarlo con tráfico real de Play Store. Los Store Listing Experiments están integrados en Play Console bajo Test and release → Store listing experiments (Google ha movido la ubicación del menú más de una vez; guías más antiguas lo llaman «Grow → Store listing experiments»). Son gratuitos, se ejecutan sobre tu ficha en producción y Google se encarga de la división del tráfico y de la estadística.
Si publicas en las dos tiendas, esta es la contraparte de la configuración de Apple. Cubrimos el lado de iOS en A/B testing de capturas de pantalla de App Store con Product Page Experiments — misma idea, mecánica distinta. Este artículo es el complemento del lado de Play.
Cómo funcionan los Store Listing Experiments
Creas un experimento, eliges qué recurso probar (icono de la app, capturas de pantalla, feature graphic, vídeo promocional, descripción corta o descripción larga) y subes hasta 3 variantes junto a tu ficha en producción — que actúa como control. Google muestra entonces las variantes a una parte de los usuarios que llegan a tu página de la tienda y mide cuál genera más instalaciones.
Dos métricas importan en los resultados:
- Adquisición (conversión de ficha en la tienda). El porcentaje de visitantes que instalan tras ver una variante concreta. Es el dato principal en las pruebas de capturas de pantalla.
- Retención de instaladores primerizos (retención a 1 día). Si las personas que atrajo una variante realmente se quedan un día después. Una variante que consigue más instalaciones pero peor retención puede haber prometido de más.
Google calcula un intervalo de confianza por variante y, cuando una variante supera el umbral de confianza que elegiste, la declara ganadora. Puedes activar una alerta por correo para no tener que vigilar el panel constantemente. Aplicar un ganador es un solo clic — pero normalmente conviene igualmente pasar el recurso ganador por tu flujo habitual de publicación/revisión para que el resto de tu ficha se mantenga coherente.
Gráficos predeterminados vs experimentos localizados
Esta es la parte con la que la gente tropieza, y determina cuántas pruebas puedes ejecutar en paralelo.
- Experimento de gráficos predeterminados. Prueba los recursos de tu ficha predeterminada — la ficha que ve cualquiera al que no se le muestra una versión localizada. Los usuarios a los que se les muestran recursos localizados quedan excluidos de la audiencia de este experimento. Solo puedes ejecutar un experimento de gráficos predeterminados a la vez.
- Experimento de ficha localizada. Prueba recursos (y/o textos) para un idioma concreto. Puedes ejecutar hasta 5 experimentos localizados de forma simultánea — por ejemplo, uno para alemán, otro para japonés, otro para portugués brasileño, y así sucesivamente, todos a la vez.
En la práctica: si tu base de instalaciones se concentra en unos pocos mercados, los experimentos localizados te permiten probar esos mercados en paralelo en lugar de esperar cola detrás de una única prueba global. Y no asumas que un idioma equivale a un país — seleccionar «inglés (Estados Unidos)» no restringe la audiencia a EE. UU.: apunta a todos a quienes se les muestra esa ficha localizada, estén donde estén.
Cómo configurar una prueba A/B de capturas de pantalla
- Abre Store listing experiments y crea uno. Elige la ficha predeterminada o una ficha localizada concreta, y ponle un nombre que sigas entendiendo dentro de tres semanas («Captura principal — texto orientado a beneficio v2»).
- Elige el recurso. Selecciona capturas de pantalla. Prueba un solo elemento por experimento — no cambies el icono y las capturas de pantalla en la misma prueba, o no sabrás qué provocó el cambio.
- Sube hasta 3 variantes. Tu ficha en producción es el control. Cada variante es un conjunto completo de capturas de pantalla, con las dimensiones correctas de Play — consulta la guía de tamaños de capturas de pantalla de Google Play para las especificaciones exactas.
- Configura la audiencia, la confianza y el MDE. Reparte el tráfico entre variantes (habitualmente a partes iguales — 50/50 para una variante frente al control, o aproximadamente un tercio cada una para tres). Elige un nivel de confianza (90 %, 95 %, 98 % o 99 %) y un efecto mínimo detectable — la mejora más pequeña que merece la pena detectar, configurable aproximadamente entre 0,5 % y 6 %. Play Console muestra las condiciones de finalización para que veas a qué te comprometes antes de empezar.
- Inícialo y no lo toques. Resiste la tentación de mirar los datos y detenerlo en cuanto una variante parezca ir por delante. Déjalo correr hasta las condiciones que fijaste.
Tamaño de muestra, duración y cómo alcanzar significación
La respuesta honesta a «¿cuánto debería ejecutarlo?» es: hasta que alcance las condiciones de significación que fijaste — no un número fijo de días. Pero hay suelos y techos del mundo real.
- Ejecútalo al menos 7 días. El comportamiento de instalación varía entre entresemana y fin de semana. Cualquier duración menor a una semana completa introduce un sesgo por día de la semana en tu resultado. Dos semanas (14 días) es un valor predeterminado habitual y más seguro, y las apps con poco tráfico a menudo necesitan 28 días.
- Instalaciones suficientes por variante para que importen. La significación depende de tu volumen de instalaciones, el número de variantes, tu nivel de confianza y tu MDE. Como objetivo aproximado de trabajo, apunta a un orden de 1.000+ instalaciones por variante antes de fiarte del resultado — más si fijas un nivel de confianza alto o un MDE pequeño.
- Configuraciones más exigentes cuestan más tráfico. Un nivel de confianza del 99 % o un MDE del 0,5 % necesita muchas más instalaciones que un 90 % / 3 %. Si tu app tiene poco volumen, una configuración exigente puede no alcanzar nunca significación — relaja el MDE o acepta el 90 %.
Una prueba que termina «inconclusa» es un resultado real, no un fracaso. Suele significar que las variantes eran demasiado parecidas para separarse a tu nivel de tráfico, o que no la ejecutaste el tiempo suficiente. Ambas cosas tienen solución — haz las variantes más distintas, o dale más tiempo.
El límite de variantes y qué implica
Tres variantes frente al control es el límite máximo por experimento. Eso es una ventaja, no una restricción contra la que luchar: cada variante extra reparte tu tráfico en porciones más finas y aleja más la significación. Con tres retadoras ya estás dividiendo tu tráfico de tienda en cuatro (control + 3). Para la mayoría de las apps, probar una sola retadora audaz y claramente distinta frente al control llega a una conclusión más rápido de lo que jamás lo harían cuatro variaciones tibias.
Usa las plazas para hipótesis realmente diferentes — un beneficio principal distinto, un estilo visual distinto, formato vertical frente a un diseño multipanel apaisado — no para matices de la misma idea.
Errores frecuentes
- Cambiar más de una variable. Capturas de pantalla nuevas y una descripción corta nueva en la misma prueba = un resultado imposible de interpretar. Aísla la variable.
- Detener la prueba pronto ante un «ganador». Las ventajas tempranas se corrigen con el tiempo. Cerrarla en el día 3 porque una variante va un 8 % por delante es la forma de publicar una ficha peor con toda confianza.
- Ejecutarla menos de 7 días. Capturarás una parte del ciclo semanal y te perderás el resto.
- Estadística demasiado exigente en una app de poco tráfico. Exigir un 99 % / MDE del 0,5 % con instalaciones modestas garantiza una prueba inconclusa y cara en tiempo.
- Ignorar la retención a 1 día. Una captura de pantalla que promete de más puede elevar las instalaciones y hundir la retención. Vigila ambos números.
- Olvidar la división entre predeterminado y localizado. Un experimento de gráficos predeterminados no afecta a los usuarios de fichas localizadas — si tu audiencia es mayoritariamente localizada, prueba ahí.
- Probar siempre solo la última captura de pantalla. Los primeros 2-3 paneles hacen la mayor parte del trabajo de convencer en Play Store. Prueba esos primero. (Más sobre en qué difiere Play de Apple aquí: Diferencias entre capturas de pantalla en Play Store y App Store.)
Dónde encaja Mokbi
Mokbi no ejecuta la prueba A/B — eso lo hace Play Console, y es gratis. Lo que ralentiza a la mayoría de los equipos es producir las variantes en primer lugar: una retadora creíble significa un conjunto completo de capturas de pantalla, con las dimensiones correctas de Play, con el texto y el diseño realmente cambiados. En Mokbi diseñas un conjunto en el navegador, luego lo duplicas y cambias el texto principal, el diseño o el fondo para crear la variante B — y traduces los textos con un clic si ejecutas experimentos localizados en varios mercados. El diseño es gratuito con vista previa marcada con marca de agua; la exportación sin marca de agua ilimitada y la publicación vienen con una suscripción — Solo a €29.99/mo (1 app) o Studio a €49.99/mo (hasta 5 apps), sin compra única. Construye las candidatas rápido; Play Console decide cuál gana.