Respuesta rápida
Según el Informe anual de transparencia de Google de 2025, la proporción de envíos rechazados en Google Play es de alrededor del 7.89%: 1,692,467 envíos rechazados entre 21,461,250 revisados. Es un cálculo hecho con las cifras que publica Google, no una tasa del año completo 2026 ni la probabilidad de que una app nueva no supere su primer intento. Las cifras de aplicación de las políticas que Google publica aparte miden resultados distintos.
Fuente: Informe anual de transparencia de Google Play de 2025 (PDF), publicado el 31 de marzo de 2026, de alcance global. El informe de 2024 da un 10.13% sobre la misma base.
Esta guía explica las cifras recientes de envíos y de aplicación de las políticas que publica Google, sus límites y las comprobaciones prácticas que te ayudan a responder a un rechazo. El conjunto de datos anuales de transparencia, las revisiones de seguridad y todas las páginas de políticas enlazadas allí donde se usan se revisaron el 12 de septiembre de 2026.
Cómo leer las etiquetas de esta guía
- Informe de GoogleUna cifra publicada en un informe de transparencia de Google o en una revisión anual de seguridad, citada junto al número.
- CálculoOperación aritmética que esta guía hace con las cifras que publica Google. Google no publica el resultado.
- Política de GoogleUn requisito o un proceso descrito en la Ayuda de Play Console o en las Políticas del Programa para Desarrolladores.
- Comprobación prácticaUna prueba que recomendamos a partir de los envíos en los que damos soporte. No es una regla de Google ni una frecuencia de rechazo medida.
- EjemploUna ilustración creada para mostrar qué forma tiene un registro. No es el caso de un cliente ni una estadística de la plataforma.
En esta página
¿Cuál es la tasa de rechazo de apps de Google Play en 2026?
Google no publica ningún porcentaje con la etiqueta «tasa de rechazo». Lo que sí publica, una vez al año, son las dos cifras que hacen falta para calcularla: cuántos envíos de apps revisó y cuántos rechazó. El último año completo es 2025, informado el 31 de marzo de 2026, así que una guía de 2026 trabaja con la actividad de 2025.
Los últimos datos anuales completos de envíos
Informe de Google| Año de actividad | Envíos revisados | Envíos rechazados | Rechazados ÷ revisados | Publicación del informe |
|---|---|---|---|---|
| 2024 | 19,292,647 | 1,955,305 | 10.13% | 31 de marzo de 2025 · informe |
| 2025 | 21,461,250 | 1,692,467 | 7.89% | 31 de marzo de 2026 · informe |
Dónde están las fuentes: informe de 2025, página impresa 3; informe de 2024, páginas impresas 3-4. Los porcentajes se calculan a partir de las cifras publicadas (rechazados ÷ revisados × 100) y se redondean a dos decimales. Ambos informes describen su alcance como global. Datos revisados el 12 de septiembre de 2026.
Consulta el cálculo por año
Porcentaje rechazado sobre el total de envíos revisados
En 2025 se rechazaron cerca de 8 de cada 100 envíos revisados.
Cómo se calcula la proporción y qué no puede predecir
La proporción compara las cifras globales anuales de envíos de apps revisados y rechazados que informa Google. Los informes no definen una cohorte de primeros intentos ni ofrecen un desglose por intento de envío, así que este agregado no debería usarse para predecir el resultado de una app nueva concreta.
Lo que la proporción no demuestra
- Las probabilidades de tu app. El complemento (alrededor del 92%) no es la probabilidad de que una app nueva se apruebe al primer intento.
- Una cifra de 2026. Todavía no hay datos del año completo 2026. Etiqueta el número como datos de 2025 disponibles en 2026.
- Una tasa de aprobación final. El informe de 2025 también recoge las aprobaciones posteriores a un rechazo, pero no el recuento por cohortes que haría falta para obtener una tasa de aprobación tras la corrección, así que esta guía no la calcula.
- Una tasa de aprobación de la prueba cerrada o del acceso a producción. Las decisiones de acceso para las cuentas personales nuevas son otro proceso y no se informan en estas tablas.
- Una tendencia en el nivel de exigencia. La caída del 10.13% al 7.89% es un cambio en la proporción, no una prueba de que las políticas se hayan relajado, de que la calidad de la revisión haya cambiado o de que el riesgo de un desarrollador concreto haya bajado.
Por qué cada sitio web cita cifras distintas
Algunas páginas dicen que Google no publica el denominador; eso era cierto en la serie de las revisiones de seguridad, no en los informes de transparencia. Otras dividen el recuento de «apps cuya publicación se impidió» de una revisión de seguridad entre el denominador del informe de transparencia, y así mezclan dos series.
Las estadísticas de rechazo y de aplicación de las políticas de Google
Google informa sobre la seguridad de la plataforma en dos lugares fáciles de confundir: el Informe anual de transparencia, una tabla con los recuentos de envíos y de medidas de aplicación, y la revisión anual de seguridad de los blogs de Google, un texto narrativo con cifras destacadas redondeadas.
Envíos revisados y rechazados
Informe de GoogleAdemás de los envíos revisados y rechazados de la tabla anterior, el informe de transparencia de 2025 recoge 2,012,981 retiradas y 125,550 cuentas de desarrollador canceladas. Una retirada actúa sobre una app que ya estaba disponible; un rechazo es una decisión sobre un envío antes de que llegue a publicarse.
Fuente: Informe anual de transparencia de 2025, página impresa 3.
Apps cuya publicación se impidió, de 2023 a 2025
Informe de Google| Año de actividad | Apps infractoras cuya publicación se impidió | Cuentas de desarrollador maliciosas bloqueadas | Fuente |
|---|---|---|---|
| 2023 | 2.28 millones | 333,000 | revisión de seguridad de 2023 (29 de abril de 2024) |
| 2024 | 2.36 millones | Más de 158,000 | revisión de seguridad de 2024 (29 de enero de 2025) |
| 2025 | Más de 1.75 millones | Más de 80,000 | revisión de seguridad de 2025 (19 de febrero de 2026) |
Las mismas revisiones añaden contexto que no es un recuento de rechazos. En 2023, cerca de 200,000 envíos fueron rechazados o subsanados por permisos sensibles como la ubicación en segundo plano y los SMS. En 2024 se impidió que 1.3 millones de apps obtuvieran acceso innecesario o excesivo a datos sensibles de los usuarios; en 2025 esa cifra fue de más de 255,000, junto con 160 millones de valoraciones y reseñas de spam bloqueadas. Estas medidas no se suman entre sí ni con las de la tabla.
Google también describe que ejecuta más de 10,000 comprobaciones de seguridad sobre las apps antes y después de su lanzamiento. Esa cifra no significa que cada pequeño defecto sea un rechazo automático, ni que todas esas comprobaciones sean filtros previos a la publicación.
Por qué los recuentos de rechazos, retiradas y publicaciones impedidas no coinciden
| Fuente | Métrica | Unidad | Periodo | Lo que no cubre |
|---|---|---|---|---|
| Informe anual de transparencia | Envíos rechazados | Envíos, no una cohorte declarada de apps únicas | Año calendario | Si esa misma app se aprobó más tarde |
| Informe anual de transparencia | Retiradas | Apps retiradas después de publicarse | Año calendario | Los envíos que nunca llegaron a publicarse |
| Revisión anual de seguridad | Apps cuya publicación se impidió | Apps, en cifras redondeadas | Año calendario | Un denominador; no se puede convertir en una tasa |
| Revisión anual de seguridad | Cuentas de desarrollador bloqueadas | Cuentas | Año calendario | Los rechazos de apps concretas |
El informe anual de transparencia y la revisión anual de seguridad de Google usan etiquetas de métrica distintas e informan totales distintos. Mantén cada número unido a su fuente y a su definición. Los informes revisados no explican ninguna conversión directa entre las dos series, así que no deberían combinarse para calcular una única tasa de rechazo.
Un agregado de la plataforma y el resultado medido por un proveedor pueden ser ciertos a la vez. La tasa de finalización de pruebas gestionadas de PrimeTestLab describe las pruebas cerradas que ejecuta y mantiene con testers hasta su fecha de cierre; la proporción de Google describe los recuentos de envíos de apps que la propia empresa publica. Ninguna predice la otra.
¿Qué tipo de decisión de Google Play recibiste?
Antes de corregir nada, identifica qué decisión tienes delante. «Rechazada» se usa de forma laxa para al menos cinco situaciones, y el siguiente paso es distinto en cada una. El estado en Play Console y el correo al propietario de la cuenta la nombran con precisión.
Política de GoogleToca el aviso que recibiste
| Decisión o bloqueo | Tu situación | Siguiente paso |
|---|---|---|
| App o actualización rechazada | Los cambios enviados no se aceptaron. El rechazo de una actualización corriente deja disponible la versión publicada anteriormente mientras corriges la actualización. | Lee el aviso, corrige el envío afectado y vuelve a enviarlo. Consulta qué hacer después de un rechazo. |
| Acceso a producción denegado, o «More testing required» | Tu solicitud para llevar a producción la app de una cuenta personal nueva necesita más trabajo; es una decisión sobre la preparación de la prueba cerrada. | Sigue los pasos de pruebas y preparación y después mira cómo resolver un rechazo del acceso a producción por las pruebas. |
| App retirada | La ficha ya no está disponible. La app estaba publicada y la aplicación de las políticas actuó sobre ella después. | Sigue el aviso de aplicación de las políticas y envía una actualización que cumpla, por la vía que indique. |
| App suspendida o cuenta cancelada | Medidas más severas a nivel de app o de cuenta, cada una con su propio aviso y sus propias consecuencias. | Usa el proceso de apelación que indique el aviso. No abras otra cuenta para volver a publicar: eso se considera una infracción. |
| Bloqueo de subida o de compatibilidad | El envío no puede seguir adelante tal como está preparado: por ejemplo, un nivel de API objetivo por debajo del mínimo actual o un bundle que Play Console no acepta. | Resuelve el requisito técnico que se indica y vuelve a enviar. Todavía no ha habido ninguna revisión. |
Qué significa cada estado: Ayuda de Play Console, Publicar tu app y Proceso de aplicación de las políticas.
Lo que un estado no te dice
Que una app no esté disponible no significa que la hayan rechazado por políticas: puede que la hayas dejado de publicar tú o que una regla de compatibilidad la esté frenando. Y un rechazo del acceso a producción puede tener más de una causa, así que la fila de arriba es una ruta, no un diagnóstico. Una versión del segmento cerrado también puede pasar por una revisión de políticas; la solicitud de acceso a producción es la decisión aparte sobre la preparación de las pruebas.
Riesgos de rechazo documentados y soluciones prácticas
Google no publica una lista de motivos de rechazo ordenada por frecuencia, y esta guía no se inventa ninguna. Las ocho comprobaciones siguientes van en el orden en que puedes hacerlas, desde la compilación hacia fuera, cada una con su fuente en las políticas. Los puntos de la prueba cerrada están en la sección de pruebas: son condiciones de elegibilidad para las cuentas personales nuevas, no rechazos por políticas.
Estabilidad y funcionalidad útil
Cierres inesperados, cuelgues e instalaciones fallidas
- El problema
- La política de funcionalidad de Google prohíbe las apps que fallan, se cierran de forma forzosa, se cuelgan o funcionan de manera anómala, incluidas las que no se instalan, las que se instalan pero no cargan y las que cargan pero no responden.
- Una comprobación observable
- Instalación limpia de la versión candidata exacta en dos dispositivos físicos: abre la app, inicia sesión, completa el flujo principal, pásala a segundo plano y vuelve a ella. Después revisa el informe previo al lanzamiento en busca de cierres inesperados y ANR (la app no responde).
- La corrección
- Corrige los cierres al arrancar y los ANR antes de enviar, y repite el mismo flujo con la compilación reconstruida.
Contenido estático sin funcionalidad propia de una app
- El problema
- La misma política cubre la funcionalidad o el contenido limitados: contenido estático sin utilidad propia de una app, muy poco contenido o una app diseñada para no hacer nada. El formato por sí solo no determina si se cumple la política; la app necesita igualmente utilidad y contenido suficientes.
- Una comprobación observable
- Demuestra la función principal de la app y explica el resultado útil que aporta. Comprueba que tiene contenido suficiente y funcionalidad significativa, y no solo material estático en pantalla.
- La corrección
- Añade la funcionalidad o el contenido que den a la app una utilidad suficiente para el uso al que se destina.
Acceso del revisor
El revisor no puede llegar a la funcionalidad restringida o principal
- El problema
- Google pide credenciales de acceso que funcionen e instrucciones para cualquier función que esté detrás de un inicio de sesión, una restricción por ubicación o una autenticación poco habitual. Sin ellas, el revisor se topa con un muro, y una app que no se puede revisar no se aprueba.
- Una comprobación observable
- Instala la versión que vas a enviar en un dispositivo sin historial y usa solo las credenciales y las instrucciones que pusiste en la página Contenido de la app. Si tú necesitaste algo más para entrar, el revisor también lo necesitará.
- La corrección
- Facilita una cuenta de revisión específica que no caduque e instrucciones paso a paso para cada función restringida. No todas las apps necesitan inicio de sesión; y una cuenta que funcione es un requisito previo para la revisión, no una garantía de aprobación.
Permisos, privacidad y Seguridad de los datos
Alcance de los permisos y declaraciones
- El problema
- Los permisos sensibles, como la ubicación en segundo plano y los SMS, necesitan un caso de uso que la app ofrezca de forma visible y, cuando existe un formulario de declaración, este debe coincidir con lo que la app hace. La revisión de seguridad de Google de 2023 informó de cerca de 200,000 envíos rechazados o subsanados exactamente por esto.
- Una comprobación observable
- Enumera todos los permisos peligrosos del manifiesto y, para cada uno, señala la pantalla en la que el usuario ve por qué hace falta.
- La corrección
- Quita todo lo que no tenga un caso de uso visible y haz que las declaraciones de Play Console describan el comportamiento que el revisor va a observar. Un motivo relacionado con una función no basta por sí solo: revisa las restricciones de permisos aplicables y la divulgación destacada y el consentimiento que se exijan antes del acceso.
Fuente Política de Datos de usuario · revisión de seguridad de 2023
Política de privacidad y eliminación de la cuenta
- El problema
- Indica la URL de la política de privacidad en Play Console y añade un enlace o el texto de la política dentro de la app. La página tiene que ser pública, sin restricción geográfica, no puede ser un PDF ni permitir que la editen los visitantes, debe identificar la app o al desarrollador y describir los datos que realmente se recopilan. Si los usuarios pueden crear una cuenta desde la app, ofrece formas fáciles de encontrar para pedir la eliminación desde dentro de la app y también fuera de ella, e informa de la retención necesaria.
- Una comprobación observable
- Abre la URL desde un dispositivo sin sesión iniciada y, si puedes, desde otro país, y léela comparándola con el formulario de Seguridad de los datos.
- La corrección
- Publica una página de política que controles tú, indícala en Play Console y dentro de la app, y añade las vías para pedir la eliminación allí donde la app cree cuentas.
Fuente Política de Datos de usuario
Seguridad de los datos y coherencia con los SDK
- El problema
- La declaración de Seguridad de los datos debe reflejar lo que recopilan y comparten la app y cada SDK de terceros que lleva dentro. Los SDK de publicidad, de analítica y de registro de fallos pueden recopilar o compartir datos sin ningún permiso en tiempo de ejecución, así que una app «sin permisos» no es automáticamente una app «sin datos», y que la página de privacidad esté activa no demuestra que el formulario sea correcto. Revisa la versión concreta del SDK, su configuración y su comportamiento real.
- Una comprobación observable
- Exporta la lista de dependencias de la versión, busca la declaración de datos de cada SDK y compárala con cada respuesta del formulario. Observa la red en el primer arranque para ver qué sale del dispositivo antes de que el usuario haga nada.
- La corrección
- Corrige el formulario para que coincida con el comportamiento observado, o quita el SDK. La declaración es responsabilidad tuya, también en lo que respecta al código que no escribiste.
Fuente Proporcionar información para la sección Seguridad de los datos
Ficha de la tienda, declaraciones y pagos
Ficha de la tienda, anuncios, público y declaraciones de contenido
- El problema
- La sección Contenido de la app pregunta si la app incluye anuncios y a qué público se dirige, y pide el cuestionario de clasificación de contenido y las demás declaraciones aplicables. Una ficha que muestra funciones que la compilación no tiene, o una declaración que no concuerda con la app, es por sí sola motivo de rechazo.
- Una comprobación observable
- Repasa cada respuesta de Contenido de la app con la versión abierta al lado y contrasta todas las capturas con la interfaz actual.
- La corrección
- Actualiza las declaraciones y los recursos de la ficha para que correspondan a la compilación que describen; corregir la ficha puede no exigir un binario nuevo.
Pagos y condiciones del programa que te corresponde
- El problema
- El sistema de facturación de Google Play es obligatorio para determinadas compras dentro de la app de bienes y servicios digitales. Los bienes físicos, los servicios del mundo real y algunas otras categorías quedan fuera, y los programas de facturación alternativa o de ofertas externas se aplican en regiones concretas y con sus propias condiciones.
- Una comprobación observable
- Para cada flujo de compra, decide si vende contenido digital que se consume dentro de la app; si es así, confirma que pasa por Play Billing o por un programa en el que de verdad estés inscrito.
- La corrección
- Lleva las compras digitales a Play Billing, o documenta tu inscripción en el programa. No trates un programa regional como una exención global.
Fuente Política de pagos
Las comprobaciones previas no son la revisión
Las comprobaciones previas a la revisión de Play Console señalan algunas de estas cosas antes de que envíes (credenciales que faltan, declaraciones de permisos, un enlace de privacidad roto), y el informe previo al lanzamiento ejecuta la app en dispositivos de prueba. Merece la pena usar los dos; superarlos no garantiza la aprobación en la revisión formal de la app, y ninguno de los dos mide cómo usaron la app los participantes de una prueba cerrada.
Fuentes: Detectar pronto los problemas de la app con las comprobaciones previas a la revisión · Usar un informe previo al lanzamiento para detectar problemas
Cómo influyen las pruebas cerradas en el acceso a producción
¿Quién tiene que cumplir el requisito de pruebas?
Política de GoogleLas cuentas personales de desarrollador creadas después del 13 de noviembre de 2023 tienen que realizar una prueba cerrada con al menos 12 testers que hayan aceptado participar de forma continua durante los últimos 14 días antes de poder solicitar el acceso a producción. Cumplir el mínimo te hace elegible para solicitarlo; no aprueba la app. Las cuentas de organización y las cuentas personales creadas antes de esa fecha no están sujetas al requisito.
Las pruebas internas no sustituyen a la prueba cerrada, por mucho que duren: los 12 testers tienen que haber aceptado participar en un segmento cerrado. Los detalles de configuración están en la guía de requisitos de las pruebas cerradas de Google Play.
Fuente: Requisitos de prueba de apps para las cuentas personales de desarrollador nuevas.
Evidencias, preparación y el siguiente paso
De la prueba que califica a la versión de producción
- 1Completa la prueba cerrada que califica. Al menos 12 testers que hayan aceptado participar durante los últimos 14 días sin interrupción.
- 2Solicita el acceso a producción. La solicitud pregunta cómo usaron la app los testers, qué comentarios recibiste y qué cambió a raíz de ellos.
- 3Google revisa la solicitud, normalmente en 7 días o menos, a veces más, y concede el acceso o pide más pruebas. Esa estimación corresponde a esta revisión, no a todo el calendario de tu lanzamiento.
- 4Con el acceso concedido, prepara la versión de producción. Su revisión y su despliegue son pasos aparte de esta decisión; el acceso es elegibilidad, no publicación.
Si un tester deja de participar, se interrumpe su periodo válido y sus días dejan de contar. Los demás testers no se ven afectados. Lo que importa en el momento de solicitarlo es si sigues teniendo 12 que cumplan, no si alguien se fue por el camino.
Google pregunta qué aprendiste; no fija un número mínimo de actualizaciones. La declaración de preparación que deberías poder hacer con honestidad es: He revisado los comentarios de los testers, he resuelto los problemas donde hacía falta y puedo explicar qué aprendí y por qué la app está lista. Si la respuesta sincera es que nadie usó la app, es probable que la revisión llegue a la misma conclusión.
Tener unos cuantos testers por encima de 12 te da margen frente a las bajas y comentarios más variados; no afirmamos que eso mejore de forma medible la aprobación. Cubre dispositivos físicos representativos como decisión de control de calidad. Los criterios publicados no dicen nada sobre cómo se cuentan los emuladores, así que esta guía no afirma nada en ningún sentido. Relacionado: planificar un colchón de testers, las preguntas de la solicitud de acceso a producción y qué revisar tras un rechazo.
Qué hacer cuando rechazan una app o una actualización
El aviso nombra la decisión, el envío afectado y la política o el requisito implicado. Trabaja a partir de él, en este orden.
Política de Google- 1Lee la decisión exacta y el envío afectado. Qué versión, qué segmento, qué política o qué requisito.
- 2Reproduce o inspecciona el problema citado en la compilación que se revisó, no en la que tienes en tu escritorio.
- 3Corrige el problema y revisa los requisitos relacionados de esa misma área, para que la siguiente revisión no encuentre al vecino.
- 4Valida la compilación o la declaración afectada: vuelve a hacer la comprobación observable del punto correspondiente de más arriba.
- 5Envía la corrección que corresponda, o usa la vía de apelación si crees que la decisión es errónea. Cuando haga falta, abre Descripción general de la publicación y selecciona Enviar a revisión; guardar una corrección no siempre la envía automáticamente.
- 6Guarda las evidencias y vigila el resultado. Aviso, versión, problema, corrección, validación, decisión.
Corregir y volver a enviar, o apelar
Si la observación es correcta, corrígela y vuelve a enviar. Las directrices de aplicación de las políticas de Google dicen de forma explícita que volver a enviar sin corregir la infracción es en sí mismo un problema. No vuelvas a enviar mientras la infracción citada siga sin resolverse; algunas correcciones cambian la ficha o las declaraciones sin tocar el binario. Si crees que la decisión es errónea, sigue las instrucciones de apelación del aviso e incluye el nombre del paquete, la versión afectada, la política citada, por qué crees que la decisión es errónea y capturas de pantalla o pasos reproducibles que demuestren que cumples. No intentes volver a publicar desde otra cuenta.
Fuentes: Proceso de aplicación de las políticas · Controlar cuándo se revisan y se publican los cambios de la app.
¿Corrección del binario o de la declaración?
Corregir la ficha o una declaración puede no exigir un binario nuevo. Hace falta una compilación nueva cuando la corrección cambia el código empaquetado, los recursos, los permisos o la configuración. A veces, los cambios en el sitio web o en el servidor resuelven el problema sin reconstruir nada. Sigue el aviso y valida el envío afectado.
Google describe el procesamiento general de los cambios de una app como algo que va de unas horas a siete días, y a veces más. Ese no es un tiempo de resolución garantizado para tu rechazo o tu apelación, y la revisión del acceso a producción es un proceso aparte; consulta el tiempo de revisión de Google Play. No se publica ningún número de rechazos permitidos ni ninguna probabilidad de éxito en las apelaciones, y aquí tampoco se promete nada de eso.
Cómo es un registro de rechazo útil
EjemploDos registros ilustrativos, construidos para mostrar qué forma tienen las evidencias que conviene guardar: uno para el rechazo de una actualización y otro para una elegibilidad de pruebas incompleta. No son casos de clientes ni estadísticas. Guarda el ID de envío que aparece en la actividad de envíos de Play Console junto con el aviso y la versión afectada, para que el equipo de asistencia pueda identificar el envío exacto.
| Aviso | Actualización rechazada, política de Datos de usuario |
|---|---|
| Versión afectada | 2.4.1 (compilación 241), segmento de producción |
| Problema | El enlace a la política de privacidad de la ficha devolvía un error 404 |
| Corrección | Se restauró la página de la política de privacidad en la misma URL que ya se usaba en Play Console y en la app. No cambió ninguna URL incrustada, así que no hizo falta un binario nuevo. |
| Validación | La URL se abrió desde un dispositivo sin sesión iniciada en dos países; el formulario de Seguridad de los datos se releyó comparándolo con la página |
| Decisión | Se volvió a enviar; actualización aprobada |
| Aviso | Elegibilidad de pruebas incompleta |
|---|---|
| Versión afectada | 1.0.3, segmento cerrado |
| Problema | Se añadieron 12 testers; solo 9 siguieron participando durante los 14 días |
| Corrección | Se buscaron tres testers de repuesto; cada uno empezó su propio periodo de 14 días |
| Validación | El panel mostraba 12 testers participando durante los últimos 14 días |
| Decisión | Quedó en condiciones de solicitarlo cuando los testers de repuesto completaron los periodos exigidos |
Lista de comprobación antes de enviar
Hazla con la versión exacta que estás a punto de enviar, no con la que probaste la semana pasada. Los puntos marcados como cuando corresponda dependen de lo que haga la app.
Compilación y comportamiento
Acceso del revisor y declaraciones
Privacidad y datos
Pagos
Requisito de pruebas, solo cuentas personales nuevas
Preguntas y respuestas
¿La proporción anual predice el resultado de la primera revisión de mi app?
No. La proporción del 7.89% compara las cifras globales de envíos de apps revisados y rechazados que Google informó para 2025. Los informes no definen una cohorte de primeros intentos, así que ni la proporción ni su complemento son una probabilidad para una app nueva concreta.
¿Por qué la cifra de la revisión de seguridad es distinta de la del informe de transparencia?
Miden cosas distintas. La revisión anual de seguridad informa de recuentos redondeados de apps infractoras cuya publicación se impidió; el informe de transparencia cuenta los envíos rechazados y las retiradas. Google no publica ninguna equivalencia entre las dos series, así que no pueden combinarse en una sola tasa.
¿Una actualización rechazada afecta a la versión ya publicada?
El rechazo de una actualización corriente no retira la versión publicada; la versión anterior sigue disponible mientras corriges la actualización. La retirada, la suspensión y la cancelación de la cuenta son estados distintos de aplicación de las políticas, cada uno con su propio aviso, y esos sí afectan a la app publicada.
¿Que te denieguen el acceso a producción es un rechazo por políticas?
No. La decisión sobre el acceso a producción de una cuenta personal nueva revisa la prueba cerrada que ejecutaste y las respuestas que diste. «More testing required» significa que la solicitud necesita más trabajo; no es una sanción por políticas contra la app, y más testers no resuelven un rechazo real por políticas.
¿Apelo o envío una corrección?
No vuelvas a enviar mientras la infracción citada siga sin resolverse. Algunas correcciones cambian la ficha o las declaraciones sin tocar el binario. Si crees que la decisión es errónea, sigue las instrucciones de apelación del aviso y aporta pruebas de que cumples. No crees otra cuenta para volver a publicar: eso se considera una infracción.
Fuentes y notas sobre los datos
Adónde ir ahora depende de a qué vinieras. Para citar la tasa, cita el 7.89% con su año (actividad de 2025) y su denominador (envíos revisados). Para actuar sobre un aviso, busca su fila en la tabla de decisiones y sigue esa ruta. Si lo que te frena es el requisito de pruebas, la guía de requisitos de las pruebas cerradas cubre la configuración de principio a fin.
En resumen
La proporción de envíos rechazados en Google Play en 2025 es de alrededor del 7.89%, calculada a partir de 1,692,467 envíos rechazados y 21,461,250 revisados en el Informe anual de transparencia de Google de 2025. Es una cifra histórica de toda la plataforma, no las probabilidades de tu app. Un aviso de rechazo nombra una decisión concreta: corrige lo que indica, vuelve a enviar o apela, y trata el requisito de pruebas de las cuentas personales nuevas como un paso de preparación aparte.
Informes anuales de transparencia
Revisiones anuales de seguridad
Políticas y Ayuda de Play Console
Historial de actualizaciones
28 de febrero de 2026: publicado solo con la serie de las revisiones anuales de seguridad. 12 de septiembre de 2026: se añadieron el cálculo del informe de transparencia y sus límites, se separaron las dos series de Google, se añadieron la tabla de decisiones y las secciones de acceso del revisor, Seguridad de los datos y qué hacer tras un rechazo, y se eliminó el enfoque de motivos ordenados por frecuencia; una segunda pasada ese mismo día corrigió la redacción sobre el reenvío, la funcionalidad y los tiempos de revisión. La próxima actualización anual llegará cuando Google publique el informe de 2026, prevista para 2027.