Google Play Console: guía práctica para desarrolladores

Google Play Console es la herramienta web desde la que publicas una app en Google Play, la pruebas con usuarios, editas su ficha y mides lo que pasa después. Cuesta 25 USD una sola vez y la cuenta vale para todas tus apps.

Esta guía sigue el orden en que te vas a encontrar las cosas: alta, menú, creación de la app, declaraciones, pruebas, versiones, ficha y estadísticas. Con los nombres de menú tal como salen en la consola en español y los límites vigentes en octubre de 2026, comprobados en la ayuda oficial de Google.

Qué es Google Play Console y quién la necesita

Google Play Console es la consola web de Google desde la que un desarrollador da de alta su cuenta, sube el app bundle, gestiona las pruebas, publica la ficha de Play Store y mide instalaciones, fallos y reseñas. Está en play.google.com/console y tiene una app móvil (Play Console para Android) que sirve para mirar datos y, en cuentas personales nuevas, para verificar el dispositivo.

La necesitas si vas a publicar en Google Play, aunque sea una app gratuita y sin anuncios. Y desde 2026 también tiene un papel fuera de la tienda: es donde Google registra los nombres de paquete para la verificación de desarrolladores de Android, el sistema que identifica a quién está detrás de cada app instalable en móviles certificados.

Lo que no es: no es un entorno de desarrollo (eso es Android Studio), no es Firebase (aunque se pueden enlazar) y no es Google Ads. Las campañas de instalación se montan en Google Ads; Play Console solo te dice que el tráfico vino de anuncios.

Darse de alta: cuota, tipo de cuenta y verificaciones

El alta se hace en play.google.com/console/signup con una cuenta de Google. Recomendamos crear una cuenta de Google solo para esto (por ejemplo, apps@tuempresa.es) y no la personal del programador: la cuenta de desarrollador no se mueve de propietario con facilidad, y la transferencia por vías no oficiales está prohibida.

La cuota se paga con tarjeta de crédito o débito; Google no acepta prepago y, si los datos de identidad no son válidos, no devuelve los 25 USD. El perfil de pagos que enlazas en el alta es el que «representa tu identidad real», así que el nombre legal y la dirección tienen que coincidir con tus documentos.

Error típico: pagar a una gestoría por el número D-U-N-S. La propia ayuda de Google avisa de que pedirlo a Dun & Bradstreet es gratuito y de que hay terceros que cobran tarifas altas por el mismo trámite. Tarda unos días: pídelo antes de abrir la cuenta de organización.

Tienes el detalle paso a paso, con qué documentos piden en cada caso, en la guía de la cuenta de desarrollador de Google Play.

El menú de la consola, sección a sección

Al entrar ves Todas las aplicaciones. Dentro de cada app, el menú lateral se organiza así (nombres tal como salen en la consola en español):

Google reorganiza este menú cada cierto tiempo; si un nombre no coincide, el buscador de la parte superior de la consola encuentra cualquier página por su título.

Crear la app en la consola

1. En Inicio, pulsa Crear aplicación.
2. Elige el idioma predeterminado y el nombre (máximo 30 caracteres). Ambos se pueden cambiar luego.
3. Indica si es aplicación o juego y si es gratis o de pago.
4. Pon un correo de contacto para usuarios. Es obligatorio; web y teléfono son opcionales.
5. En Declaraciones, acepta las políticas del programa, las leyes de exportación de EE. UU. y los términos de Firma de aplicaciones de Play.
6. Pulsa Crear aplicación.

Al crearla, Google registra el nombre de paquete y lo vincula a tu cuenta. Si ya lo usa otro desarrollador, la consola te pide otro. Elige el applicationId con cuidado (es.tuempresa.app): no se puede cambiar una vez publicada.

Nuestro criterio: la casilla «gratis o de pago» tiene trampa. Una app de pago puede pasar a gratuita, pero una gratuita ya no puede volver a ser de pago: tendrías que crear otra app con un nombre de paquete nuevo. Aun así, casi siempre elegimos gratis con compra integrada o suscripción, porque una app nueva sin marca rara vez vende descargas de pago en España y así no cierras ninguna puerta de monetización.

Las tareas de «Contenido de la aplicación» que bloquean la publicación

El Panel de control te lleva por una serie de declaraciones que van a la página Contenido de la aplicación. Sin ellas no puedes enviar a revisión:

• Política de privacidad: URL pública, no un PDF ni un enlace a Google Drive. Es obligatoria también para rellenar Seguridad de los datos.
• Acceso a la aplicación: si hay login, deja un usuario y contraseña de demostración que funcionen. La falta de credenciales de prueba es motivo de rechazo según los requisitos de Play Console.
• Anuncios: si la app muestra publicidad (también la de SDK de terceros).
• Clasificación del contenido: cuestionario que asigna PEGI en Europa.
• Público objetivo y contenido: si incluyes menores de 13 años entras en los requisitos de Familias.
• Seguridad de los datos: qué datos recoges y compartes. Se rellena aunque no recojas nada; solo se libran las apps que solo están en prueba interna.
• Declaraciones específicas cuando toca: apps financieras, de salud, gubernamentales, permisos sensibles (ubicación en segundo plano, SMS, accesibilidad).

Error típico: declarar en Seguridad de los datos que no recoges nada y llevar Firebase Analytics, AdMob o un SDK de crash reporting. Esos SDK recogen identificadores y datos de uso, y la declaración tiene que reflejarlo. Revisa la documentación de cada SDK: la mayoría publica qué declarar.

Pruebas interna, cerrada y abierta

Todo se gestiona en Probar y publicar > Pruebas. Cada canal tiene un uso distinto:

Los testers necesitan una cuenta de Google. En la primera publicación de un canal, el enlace de participación puede tardar varias horas en funcionar: no lo mandes a tus testers nada más pulsar el botón.

La prueba cerrada obligatoria para cuentas personales

Si tu cuenta es personal y se creó después del 13 de noviembre de 2023, no puedes pedir acceso a producción hasta que al menos 12 testers hayan estado apuntados a una prueba cerrada durante 14 días seguidos. Quien se da de baja antes del día 14 no cuenta.

Después, en el Panel de control pulsas Solicitar acceso a producción y respondes tres bloques de preguntas: sobre la prueba (cómo captaste testers, si usaron todas las funciones, qué te dijeron), sobre la app (público, propuesta de valor, instalaciones estimadas el primer año) y sobre si está lista (qué cambiaste tras la prueba). Google suele responder en siete días o menos.

Nuestro criterio: recluta 20 testers, no 12. Siempre hay quien se borra sin querer o quien acepta la invitación con otra cuenta de Google. Y guarda los comentarios con fecha desde el día 1: te los piden resumidos en la solicitud, y una respuesta vaga del tipo «a todos les gustó» es una mala señal para quien revisa.

Lo explicamos con calendario en la guía para publicar una app en Google Play.

Subir una versión y lanzarla a producción

Desde agosto de 2021 las apps nuevas se publican como Android App Bundle (.aab), no como APK. La firma la gestiona Google con Firma de aplicaciones de Play, que configuras en la primera versión.

1. Ve a Probar y publicar > Producción (o al canal de prueba que toque) y pulsa Crear nueva versión.
2. Sube el .aab. Si el versionCode ya existe, la consola lo rechaza: súbelo siempre.
3. Pon un nombre de versión (solo lo ves tú) y las notas de la versión: hasta 500 caracteres por idioma.
4. Guardar como borrador y Siguiente. Si sale un resumen de errores, corrígelos; las advertencias no bloquean.
5. En actualizaciones, elige el porcentaje de lanzamiento (no existe en la primera versión).
6. Iniciar lanzamiento a producción. Los cambios van a revisión desde el Resumen de publicación.

Dos requisitos técnicos vigentes a la fecha de esta guía:

• Nivel de API objetivo: desde el 31 de agosto de 2026, apps nuevas y actualizaciones deben apuntar a Android 16 (API 36) o superior; Wear OS y Automotive, API 35; Android TV y XR, API 34. Se podía pedir prórroga hasta el 1 de noviembre de 2026.
• Tamaño: lo que descarga el usuario para instalar (APK base + APK de configuración, comprimidos) no puede pasar de 4 GB. Por encima de 200 MB tendrás que usar Play Feature Delivery o Play Asset Delivery.

Error típico: mandar una actualización mientras otra está en revisión. El plazo cuenta desde el último cambio enviado, así que vuelves al final de la cola. Si preparas un lanzamiento con fecha, activa la publicación gestionada: Google revisa, tú publicas cuando quieras.

Cuánto tarda la revisión

Google habla de «unas horas o hasta siete días (o más en casos excepcionales)». Las cuentas nuevas suelen ir a la parte larga de esa horquilla, y la ayuda recomienda dejar al menos una semana entre el envío y la fecha de lanzamiento.

En la práctica, para planificar una primera publicación con cuenta personal nueva cuenta así: 14 días de prueba cerrada como mínimo, hasta 7 días de respuesta a la solicitud de producción y hasta 7 días de revisión de la versión. Casi un mes desde que tienes la app lista. Con cuenta de organización te ahorras la prueba obligatoria.

La ficha de Play Store desde la consola

La ficha se edita en Aumentar usuarios > Presencia en Google Play Store > Fichas de Play Store. Estos son los límites que vas a necesitar:

La categoría y las etiquetas no están en la ficha sino en Aumentar usuarios > Presencia en Google Play Store > Configuración de la tienda, igual que el correo, la web y el teléfono de contacto que se muestran en la ficha.

Cada elemento tiene su guía con ejemplos: icono, gráfico de funciones, capturas y descripción.

Estadísticas y rendimiento de la ficha: qué mirar cada semana

Hay dos sitios distintos y conviene no confundirlos. Estadísticas sirve para el negocio (instalaciones, usuarios activos, ingresos). Los informes de rendimiento de la ficha de Play Store, dentro de Aumentar usuarios, son los del ASO.

Desde julio de 2026 esos informes giran alrededor de la intención: cuentan clics únicos en Instalar, Abrir y Registro previo, y el antiguo porcentaje de conversión pasa a llamarse porcentaje de clics (CTR). Las adquisiciones siguen disponibles en Estadísticas y en los informes descargables.

Lo que nosotros miramos cada lunes:

1. Visitantes de la ficha por fuente: Búsqueda en Google Play, Exploración en Google Play y Anuncios y referencias. Si casi todo es búsqueda con tu marca, nadie te está encontrando por la categoría.
2. Términos de búsqueda: qué buscó la gente antes de llegar. Es el único dato de palabras clave que te da Google gratis.
3. CTR frente a apps similares: la consola compara con la mediana y los percentiles 25 y 75 cuando filtras por país, idioma o fuente. Por debajo del 25 % de tu grupo, el problema está en la ficha.
4. Android vitals: tasa de fallos percibidos y de ANR, que también afectan a la visibilidad.

Error típico: mirar el CTR global y sacar conclusiones. Quien llega buscando tu marca convierte muchísimo más que quien te encuentra explorando; mezclados, la cifra no dice nada. Filtra siempre por fuente de tráfico.

Un detalle: Play Console no muestra impresiones ni conversiones de Google Ads. Eso está en la cuenta de Ads.

Android vitals: los umbrales que te restan visibilidad

En Monitorizar y mejorar > Android vitals > Información general Google publica dos umbrales de mal comportamiento. Si los superas, puede reducir la visibilidad de la app y mostrar una advertencia en la ficha:

Se calcula con los últimos 28 días. Por eso, cuando arreglas un fallo, la advertencia no desaparece al día siguiente sino cuando mejora la media de esas cuatro semanas.

Experimentos y fichas personalizadas

Desde Fichas de Play Store, en la columna Experimento, pulsas Configurar. Puedes tener a la vez un experimento de gráficos de la ficha predeterminada o hasta cinco experimentos localizados, con hasta dos variantes frente a la ficha actual. Se paran solos a los seis meses.

Las fichas personalizadas (hasta 50) enseñan otro nombre, icono, descripciones o gráficos según el país, una URL con parámetro &listing=, una campaña de Google Ads, los usuarios que desinstalaron o los que llevan 28 días sin abrir la app. Lo contamos con ejemplos en la guía de experimentos de ficha.

Políticas: lo que más rechazos provoca

Lo que vemos repetirse en apps pequeñas y en apps hechas con IA:

• Metadatos: «N.º 1», «la mejor», «gratis por tiempo limitado» o emojis en el nombre. La política de metadatos no admite rankings, precios ni promociones en nombre, icono o nombre de desarrollador, ni bloques de palabras clave ni testimonios sin atribuir en la descripción.
• Acceso a la aplicación sin credenciales de prueba, o con credenciales que caducan durante la revisión.
• Seguridad de los datos que no coincide con lo que hacen los SDK.
• Permisos sensibles sin declaración ni uso justificado (ubicación en segundo plano, SMS, registro de llamadas, accesibilidad).
• Funcionalidad mínima: una web metida en un WebView sin nada propio tiene muchas papeletas de rechazo.

Si te rechazan, el correo indica la política y a menudo la pantalla. Corrige, explica el cambio en la apelación si procede y vuelve a enviar. No reenvíes la misma versión cambiando solo el número.

Errores típicos en Play Console y cómo salir de ellos

Lista de comprobación antes de enviar a revisión

• Cuenta verificada (identidad, correo y teléfono) y, si es personal, dispositivo verificado.
• Prueba cerrada cumplida (12 testers, 14 días seguidos) si aplica.
• .aab firmado, versionCode nuevo, targetSdkVersion al día.
• Política de privacidad en una URL pública que hable de tu app.
• Seguridad de los datos coherente con todos los SDK.
• Credenciales de prueba que funcionen sin verificación por SMS.
• Nombre de 30 caracteres o menos, sin emojis ni «mejor».
• Descripción breve de 80 caracteres o menos que diga para qué sirve.
• Icono 512 × 512, gráfico 1.024 × 500 y al menos 4 capturas de 1.080 px.
• Categoría y etiquetas elegidas en Configuración de la tienda.
• Publicación gestionada activada si hay fecha de lanzamiento.

Si quieres que lo revisemos

Publicar es la parte mecánica. Lo que decide si alguien encuentra tu app es la ficha y las palabras que usa. Puedes pasar la tuya por la auditoría ASO gratuita y ver qué falla, o ver cómo trabajamos la optimización de fichas de Google Play.