Risposta rapida
In base al Report annuale sulla trasparenza 2025 di Google, il rapporto di rifiuto degli invii su Google Play è di circa il 7,89%: 1.692.467 invii rifiutati divisi per 21.461.250 invii esaminati. È un calcolo sui conteggi pubblicati da Google, non un tasso riferito all’intero 2026 e non la probabilità che una nuova app non superi il primo tentativo. I dati di Google sui provvedimenti sono una serie distinta e misurano esiti diversi.
Fonte: Report annuale sulla trasparenza di Google Play 2025 (PDF), pubblicato il 31 marzo 2026, ambito globale. Il report 2024 dà il 10,13% sulla stessa base.
Questa guida spiega i dati recenti di Google su invii e provvedimenti, i loro limiti e le verifiche pratiche che ti aiutano a rispondere a un rifiuto. I dati annuali sulla trasparenza, le analisi sulla sicurezza e ogni pagina delle norme citata nel punto in cui serve sono stati controllati il 12 settembre 2026.
Come leggere le etichette di questa guida
- Report GoogleUn dato riportato in un report sulla trasparenza di Google o in un’analisi annuale sulla sicurezza, con la fonte citata accanto al numero.
- CalcoloUn’operazione che questa guida esegue sui conteggi pubblicati da Google. Il risultato non è pubblicato da Google.
- Norme GoogleUn requisito o una procedura descritti nella Guida di Play Console o nelle Norme del programma per gli sviluppatori.
- Verifica praticaUna verifica che consigliamo, sulla base degli invii che seguiamo. Non è una regola di Google e non è una frequenza di rifiuto misurata.
- EsempioUn’illustrazione costruita per mostrare com’è fatta una scheda. Non è il caso di un cliente e non è una statistica della piattaforma.
In questa pagina
Qual è il tasso di rifiuto delle app su Google Play nel 2026?
Google non pubblica una percentuale chiamata «tasso di rifiuto». Pubblica però, una volta all’anno, i due conteggi che servono per calcolarla: quanti invii di app ha esaminato e quanti ne ha rifiutati. L’ultimo anno completo è il 2025, con i dati pubblicati il 31 marzo 2026, quindi una guida del 2026 lavora sull’attività del 2025.
I dati annuali più recenti sugli invii
Report Google| Anno di attività | Invii esaminati | Invii rifiutati | Rifiutati ÷ esaminati | Report pubblicato |
|---|---|---|---|---|
| 2024 | 19.292.647 | 1.955.305 | 10,13% | 31 marzo 2025 · report |
| 2025 | 21.461.250 | 1.692.467 | 7,89% | 31 marzo 2026 · report |
Dove si trovano i dati: report 2025, pagina stampata 3; report 2024, pagine stampate 3-4. Le percentuali sono calcolate sui conteggi pubblicati (rifiutati ÷ esaminati × 100) e arrotondate a due decimali. Entrambi i report dichiarano una copertura globale. Dati controllati il 12 settembre 2026.
Vedi il calcolo, anno per anno
Quota di invii rifiutati sul totale degli invii esaminati
Nel 2025 sono stati rifiutati circa 8 invii esaminati su 100.
Come si calcola il rapporto e che cosa non può prevedere
Il rapporto mette a confronto i conteggi annuali globali che Google riporta per gli invii di app esaminati e per quelli rifiutati. I report non definiscono un insieme di primi tentativi né un dettaglio per singolo tentativo di invio, quindi questo dato aggregato non va usato per prevedere l’esito di una specifica app nuova.
Che cosa il rapporto non dimostra
- Le probabilità della tua app. Il complemento (circa il 92%) non è la probabilità che una nuova app venga approvata al primo tentativo.
- Un dato del 2026. I dati sull’intero 2026 non sono ancora disponibili. Presenta il numero come dato del 2025 disponibile nel 2026.
- Un tasso di approvazione finale. Il report 2025 elenca anche le approvazioni arrivate dopo un rifiuto, ma non il conteggio per insiemi che servirebbe per un tasso di approvazione dopo la correzione: questa guida non lo calcola.
- Un tasso di approvazione del test chiuso o dell’accesso alla produzione. Le decisioni sull’accesso per i nuovi account personali seguono un processo diverso e non compaiono in queste tabelle.
- Una tendenza nel rigore dei controlli. Il calo dal 10,13% al 7,89% è una variazione del rapporto, non la prova che le norme siano diventate più permissive, che la qualità della revisione sia cambiata o che il rischio del singolo sviluppatore sia diminuito.
Perché in rete si leggono numeri diversi
Alcune pagine sostengono che Google non pubblichi alcun denominatore: era vero per la serie delle analisi sulla sicurezza, non per i report sulla trasparenza. Altre dividono un conteggio di «app bloccate» tratto da un’analisi sulla sicurezza per un denominatore preso da un report sulla trasparenza, e in questo modo mescolano due serie.
Le statistiche di Google su rifiuti e provvedimenti
Google rendiconta la sicurezza della piattaforma in due sedi che è facile confondere: il Report annuale sulla trasparenza, una tabella di conteggi su invii e provvedimenti, e l’analisi annuale sulla sicurezza pubblicata sui blog di Google, un testo discorsivo con cifre arrotondate in evidenza.
Invii esaminati e rifiutati
Report GoogleOltre ai conteggi di invii esaminati e rifiutati della tabella qui sopra, il report sulla trasparenza 2025 riporta 2.012.981 rimozioni e 125.550 account sviluppatore chiusi. Una rimozione colpisce un’app già disponibile; un rifiuto è una decisione su un invio prima che vada online.
Fonte: Report annuale sulla trasparenza 2025, pagina stampata 3.
App bloccate prima della pubblicazione, dal 2023 al 2025
Report Google| Anno di attività | App che violano le norme bloccate prima della pubblicazione | Account sviluppatore dannosi banditi | Fonte |
|---|---|---|---|
| 2023 | 2,28 milioni | 333.000 | analisi sulla sicurezza 2023 (29 aprile 2024) |
| 2024 | 2,36 milioni | Più di 158.000 | analisi sulla sicurezza 2024 (29 gennaio 2025) |
| 2025 | Più di 1,75 milioni | Più di 80.000 | analisi sulla sicurezza 2025 (19 febbraio 2026) |
Le stesse analisi aggiungono elementi di contesto che non sono conteggi di rifiuti. Nel 2023 quasi 200.000 invii sono stati rifiutati o corretti a causa di autorizzazioni sensibili come la posizione in background e gli SMS. Nel 2024 a 1,3 milioni di app è stato impedito di ottenere un accesso non necessario o eccessivo a dati sensibili degli utenti; nel 2025 lo stesso dato è stato di più di 255.000, insieme a 160 milioni di valutazioni e recensioni spam bloccate. Queste misure non si sommano tra loro né con la tabella.
Google dichiara inoltre di eseguire più di 10.000 controlli di sicurezza sulle app, prima e dopo la pubblicazione. Quel numero non significa che ogni piccolo difetto porti a un rifiuto automatico, né che tutti quei controlli siano sbarramenti precedenti alla pubblicazione.
Perché i conteggi di rifiuti, rimozioni e blocchi sono diversi
| Fonte | Metrica | Unità | Periodo | Che cosa non copre |
|---|---|---|---|---|
| Report annuale sulla trasparenza | Invii rifiutati | Invii, non un insieme dichiarato di app uniche | Anno solare | Se la stessa app sia stata approvata in seguito |
| Report annuale sulla trasparenza | Rimozioni | App rimosse dopo la pubblicazione | Anno solare | Gli invii che non sono mai andati online |
| Analisi annuale sulla sicurezza | App bloccate prima della pubblicazione | App, in cifra arrotondata | Anno solare | Un denominatore: non si può trasformare in un tasso |
| Analisi annuale sulla sicurezza | Account sviluppatore banditi | Account | Anno solare | I rifiuti delle singole app |
Il report annuale sulla trasparenza e l’analisi annuale sulla sicurezza di Google usano etichette di metrica diverse e riportano totali diversi. Tieni ogni numero legato alla sua fonte e alla sua definizione. I documenti consultati non spiegano alcuna conversione diretta fra le due serie, quindi non vanno combinati per ricavare un unico tasso di rifiuto.
Un dato aggregato di piattaforma e il risultato misurato di un fornitore possono essere veri entrambi. Il tasso di completamento dei test gestiti da PrimeTestLab descrive i test chiusi che l’azienda conduce e mantiene coperti di tester fino alla data di fine; il rapporto di Google descrive i conteggi riportati degli invii di app. Nessuno dei due prevede l’altro.
Che tipo di decisione hai ricevuto da Google Play?
Prima di correggere qualsiasi cosa, individua quale decisione hai davanti. «Rifiutata» si usa genericamente per almeno cinque situazioni diverse, e il passo successivo cambia per ognuna. A dirti di quale si tratta sono lo stato in Play Console e l’email inviata al titolare dell’account.
Norme GoogleTocca la comunicazione che hai ricevuto
| Decisione o blocco | La tua situazione | Passo successivo |
|---|---|---|
| App o aggiornamento rifiutato | Le modifiche inviate non sono state accettate. Il rifiuto di un normale aggiornamento lascia disponibile la versione pubblicata in precedenza mentre lo correggi. | Leggi la comunicazione, correggi l’invio interessato e invialo di nuovo. Vedi dopo un rifiuto. |
| Accesso alla produzione negato, oppure «More testing required» | La tua richiesta di portare in produzione l’app di un nuovo account personale ha bisogno di altro lavoro: è una decisione sulla prontezza, riferita al test chiuso. | Segui i passaggi su test e prontezza, poi vedi come correggere un rifiuto del test per l’accesso alla produzione. |
| App rimossa | La scheda dello Store non è più disponibile. L’app era stata pubblicata e il provvedimento è intervenuto a posteriori. | Segui la comunicazione del provvedimento e invia un aggiornamento conforme attraverso il canale che indica. |
| App sospesa, oppure account chiuso | Un provvedimento più severo a livello di app o di account, ciascuno con la propria comunicazione e le proprie conseguenze. | Usa la procedura di ricorso indicata nella comunicazione. Non aprire un altro account per ripubblicare: viene considerata una violazione. |
| Blocco al caricamento o di compatibilità | L’invio non può procedere così com’è preparato: per esempio un livello API target sotto la soglia attuale, oppure un bundle che la Console non accetta. | Risolvi il requisito tecnico indicato, poi invia di nuovo. La revisione non è ancora avvenuta. |
Significato degli stati: Guida di Play Console, Pubblicare l’app e Procedura di applicazione delle norme.
Che cosa uno stato non ti dice
Un’app non disponibile non è stata per forza rifiutata per violazione delle norme: puoi averla ritirata tu, oppure può essere trattenuta da una regola di compatibilità. E un rifiuto dell’accesso alla produzione può avere più di una causa, quindi la riga qui sopra indica un percorso, non una diagnosi. Anche una versione su un canale chiuso può essere sottoposta alla revisione delle norme; la richiesta di accesso alla produzione è invece la decisione separata sulla prontezza dei test.
Rischi di rifiuto documentati e correzioni pratiche
Google non pubblica una classifica dei motivi di rifiuto, e questa guida non se la inventa. Le otto verifiche qui sotto seguono l’ordine in cui puoi eseguirle, partendo dalla build e allargandoti da lì, ciascuna con la propria fonte normativa. Le voci sul test chiuso stanno nella sezione dedicata ai test: sono condizioni di idoneità per i nuovi account personali, non rifiuti per violazione delle norme.
Stabilità e funzionalità utile
Arresti anomali, blocchi e installazioni non riuscite
- Il problema
- Le norme di Google sulle funzionalità vietano le app che si arrestano in modo anomalo, si chiudono forzatamente, si bloccano o comunque non funzionano normalmente, comprese quelle che non si installano, che si installano ma non si avviano, o che si avviano ma non rispondono.
- Una verifica osservabile
- Installazione da zero della release candidate esatta su due dispositivi fisici: apri l’app, accedi, completa il flusso principale, mandala in background e riprendila. Poi leggi il report pre-lancio in cerca di arresti anomali e ANR (application not responding).
- La correzione
- Correggi gli arresti anomali all’avvio e gli ANR prima di inviare, poi ripeti lo stesso flusso sul binario ricompilato.
Contenuti statici senza funzionalità proprie dell’app
- Il problema
- Le stesse norme riguardano funzionalità o contenuti limitati: contenuti statici privi di un’utilità propria dell’app, contenuti molto scarsi o un’app progettata per non fare nulla. Il formato da solo non determina la conformità: all’app servono comunque un’utilità e contenuti adeguati.
- Una verifica osservabile
- Mostra la funzione principale dell’app e spiega il risultato utile che produce. Verifica che abbia contenuti adeguati e funzionalità significative, invece di limitarsi a mostrare materiale statico.
- La correzione
- Aggiungi le funzionalità o i contenuti che danno all’app un’utilità adeguata all’uso previsto.
Accesso per chi esamina l’app
Chi esamina l’app non riesce a raggiungere le funzionalità riservate o principali
- Il problema
- Google chiede credenziali di accesso funzionanti e istruzioni per ogni funzionalità protetta da un accesso, da una restrizione geografica o da un’autenticazione fuori dal comune. Senza, chi esamina l’app trova un muro, e un’app che non si può esaminare non viene approvata.
- Una verifica osservabile
- Installa la versione che stai inviando su un dispositivo senza precedenti, e usa soltanto le credenziali e le istruzioni della pagina Contenuti dell’app. Se a te è servito altro per entrare, servirà anche a chi esamina l’app.
- La correzione
- Fornisci un account dedicato alla revisione che non scada, e istruzioni passo per passo per ogni funzionalità protetta. Non tutte le app hanno bisogno di un accesso; e un account funzionante è una condizione preliminare della revisione, non una garanzia di approvazione.
Autorizzazioni, privacy e Sicurezza dei dati
Ambito delle autorizzazioni e dichiarazioni
- Il problema
- Le autorizzazioni sensibili come la posizione in background e gli SMS richiedono un caso d’uso che l’app realizzi in modo visibile e, dove esiste un modulo di dichiarazione, questo deve corrispondere a ciò che l’app fa. L’analisi sulla sicurezza 2023 di Google ha riportato quasi 200.000 invii rifiutati o corretti esattamente per questo.
- Una verifica osservabile
- Elenca tutte le autorizzazioni pericolose presenti nel manifest e, per ognuna, indica la schermata in cui l’utente vede perché serve.
- La correzione
- Elimina tutto ciò che non ha un caso d’uso visibile, e assicurati che le dichiarazioni nella Console descrivano il comportamento che chi esamina l’app osserverà. Un motivo legato a una funzionalità non basta da solo: controlla le restrizioni che valgono per quell’autorizzazione e l’eventuale informativa in evidenza e il consenso richiesti prima dell’accesso.
Informativa sulla privacy ed eliminazione dell’account
- Il problema
- Indica in Play Console l’URL dell’informativa sulla privacy e inserisci nell’app un link o il testo dell’informativa. La pagina deve essere pubblica, non limitata per area geografica, non un PDF e non modificabile dai visitatori, deve identificare l’app o lo sviluppatore e descrivere i dati effettivamente raccolti. Se gli utenti possono creare un account dall’interno dell’app, offri modi facilmente individuabili per chiedere l’eliminazione sia nell’app sia dall’esterno, e dichiara la conservazione dei dati necessaria.
- Una verifica osservabile
- Apri l’URL da un dispositivo senza accesso effettuato, se puoi da un altro Paese, e leggilo confrontandolo con il modulo Sicurezza dei dati.
- La correzione
- Pubblica una pagina dell’informativa che controlli tu, indicala in Play Console e nell’app, e aggiungi i percorsi per richiedere l’eliminazione dove l’app crea account.
Fonte Norme sui dati utente
Coerenza tra Sicurezza dei dati e SDK
- Il problema
- La dichiarazione Sicurezza dei dati deve rispecchiare ciò che raccolgono e condividono l’app e ogni SDK di terze parti al suo interno. Gli SDK di pubblicità, analisi e segnalazione degli arresti anomali possono raccogliere o condividere dati senza alcuna autorizzazione in fase di esecuzione, quindi un’app «senza autorizzazioni» non è automaticamente un’app «senza dati», e una pagina della privacy online non dimostra che il modulo sia corretto. Controlla la versione specifica dell’SDK, la sua configurazione e il comportamento reale.
- Una verifica osservabile
- Esporta l’elenco delle dipendenze della versione, cerca la dichiarazione sui dati di ogni SDK e confrontala con ogni risposta del modulo. Osserva il traffico di rete al primo avvio per vedere che cosa esce dal dispositivo prima che l’utente faccia qualsiasi cosa.
- La correzione
- Correggi il modulo perché corrisponda al comportamento osservato, oppure rimuovi l’SDK. La dichiarazione è una tua responsabilità, anche per il codice che non hai scritto.
Fonte Fornire informazioni per la sezione Sicurezza dei dati
Scheda dello Store, dichiarazioni e pagamenti
Scheda dello Store, annunci, pubblico e dichiarazioni sui contenuti
- Il problema
- La sezione Contenuti dell’app chiede se l’app contiene annunci e a quale pubblico si rivolge, e richiede il questionario per la classificazione dei contenuti e le altre dichiarazioni applicabili. Una scheda che mostra funzionalità assenti dalla build, o una dichiarazione in contrasto con l’app, è già di per sé un motivo di rifiuto.
- Una verifica osservabile
- Ripercorri una per una le risposte in Contenuti dell’app tenendo aperta accanto la versione da inviare, e confronta ogni screenshot con l’interfaccia attuale.
- La correzione
- Aggiorna le dichiarazioni e i materiali della scheda insieme alla build che descrivono; una correzione della scheda può non richiedere un nuovo binario.
Pagamenti e condizioni dei programmi applicabili
- Il problema
- Il sistema di fatturazione di Google Play è obbligatorio per determinati acquisti in-app di beni e servizi digitali. Beni fisici, servizi del mondo reale e alcune altre categorie sono esclusi, mentre i programmi di fatturazione alternativa o di offerte esterne valgono in aree geografiche specifiche, ciascuno alle proprie condizioni.
- Una verifica osservabile
- Per ogni flusso di acquisto, stabilisci se vende contenuti digitali fruiti nell’app; in tal caso verifica che passi da Play Billing o da un programma a cui sei davvero iscritto.
- La correzione
- Sposta gli acquisti digitali su Play Billing, oppure documenta l’iscrizione al programma. Non considerare un programma valido in una sola area geografica come un’esenzione globale.
Fonte Norme sui pagamenti
I controlli pre-revisione non sono la revisione
I controlli pre-revisione di Play Console segnalano alcuni di questi problemi prima dell’invio (credenziali mancanti, dichiarazioni sulle autorizzazioni, un link alla privacy non funzionante), e il report pre-lancio mette alla prova l’app su dispositivi di test. Vale la pena eseguirli entrambi; superarli non garantisce l’approvazione nella revisione formale dell’app, e nessuno dei due misura come i partecipanti a un test chiuso hanno usato l’app.
Fonti: Individuare in anticipo i problemi dell’app con i controlli pre-revisione · Usare un report pre-lancio per individuare i problemi
Come il test chiuso incide sull’accesso alla produzione
Chi deve soddisfare il requisito di test?
Norme GoogleGli account sviluppatore personali creati dopo il 13 novembre 2023 devono svolgere un test chiuso con almeno 12 tester attivati senza interruzioni negli ultimi 14 giorni prima di poter richiedere l’accesso alla produzione. Raggiungere il minimo ti rende idoneo a presentare la richiesta; non approva l’app. Gli account dell’organizzazione e gli account personali creati prima di quella data non sono soggetti al requisito.
Il test interno non sostituisce il test chiuso, per quanto a lungo venga svolto: i 12 tester devono essere attivati su un canale di test chiuso. I dettagli sulla configurazione sono nella guida ai requisiti del test chiuso di Google Play.
Fonte: Requisiti di test delle app per i nuovi account sviluppatore personali.
Prove, prontezza e passo successivo
Dal test valido alla versione di produzione
- 1Completa il test chiuso valido. Almeno 12 tester, attivati negli ultimi 14 giorni senza interruzioni.
- 2Richiedi l’accesso alla produzione. La richiesta chiede come i tester hanno usato l’app, quali feedback hai ricevuto e che cosa è cambiato di conseguenza.
- 3Google esamina la richiesta, in genere al massimo in 7 giorni, a volte in più tempo, e concede l’accesso oppure chiede altri test. Quella stima riguarda questa revisione, non l’intera tabella di marcia del tuo lancio.
- 4Ottenuto l’accesso, prepara la versione di produzione. La sua revisione e la sua distribuzione sono passaggi distinti da questa decisione: l’accesso è idoneità, non pubblicazione.
Se un tester si disattiva, il suo periodo valido si interrompe e i suoi giorni non contano più. Gli altri tester non ne risentono. Al momento della richiesta conta se hai ancora 12 tester che soddisfano il requisito, non se qualcuno se ne è andato.
Google chiede che cosa hai imparato; non fissa un numero minimo di aggiornamenti. La dichiarazione di prontezza che devi poter fare in modo onesto è: Ho esaminato i feedback dei tester, ho risolto i problemi dove serviva e so spiegare che cosa ho imparato e perché l’app è pronta. Se la risposta onesta è che nessuno ha usato l’app, è probabile che la revisione arrivi alla stessa conclusione.
Qualche tester in più rispetto a 12 ti dà un margine contro gli abbandoni e feedback più ampi; non sosteniamo che da questo derivi un aumento misurato delle approvazioni. Copri dispositivi fisici rappresentativi come scelta di controllo qualità. I criteri pubblicati non dicono nulla su come vengano conteggiati gli emulatori, quindi questa guida non si pronuncia in alcuna direzione. Vedi anche: come pianificare un margine di tester, le domande della richiesta di accesso alla produzione e che cosa controllare dopo un rifiuto.
Che cosa fare dopo il rifiuto di un’app o di un aggiornamento
La comunicazione indica la decisione, l’invio interessato e la norma o il requisito coinvolti. Parti da lì, in questo ordine.
Norme Google- 1Leggi con precisione la decisione e l’invio interessato. Quale versione, quale canale, quale norma o requisito.
- 2Riproduci o esamina il problema citato sulla build che è stata esaminata, non su quella che hai sulla scrivania.
- 3Correggi il problema e controlla i requisiti collegati nella stessa area, così la revisione successiva non trova quello accanto.
- 4Convalida la build o la dichiarazione interessata: ripeti la verifica osservabile del controllo corrispondente qui sopra.
- 5Invia la correzione appropriata, oppure segui la via del ricorso se ritieni che la decisione sia sbagliata. Dove serve, apri Panoramica sulla pubblicazione e seleziona Invia per la revisione: salvare una correzione non sempre la invia in automatico.
- 6Conserva le prove e controlla l’esito. Comunicazione, versione, problema, correzione, convalida, decisione.
Correggere e inviare di nuovo, oppure presentare ricorso
Se il rilievo è fondato, correggilo e invia di nuovo. Le indicazioni di Google sull’applicazione delle norme sono esplicite: inviare di nuovo senza risolvere la violazione è già di per sé un problema. Non inviare di nuovo finché la violazione citata resta irrisolta; alcune correzioni cambiano la scheda dello Store o le dichiarazioni senza toccare il binario. Se ritieni che la decisione sia sbagliata, segui le istruzioni per il ricorso contenute nella comunicazione e indica il nome del pacchetto, la versione interessata, la norma citata, il motivo per cui ritieni sbagliata la decisione, e screenshot o passaggi riproducibili che dimostrino la conformità. Non provare a ripubblicare tramite un altro account.
Fonti: Procedura di applicazione delle norme · Controllare quando le modifiche a un’app vengono esaminate e pubblicate.
Correzione del binario o della dichiarazione?
Una correzione della scheda dello Store o di una dichiarazione può non richiedere un nuovo binario. Serve una nuova build quando la correzione modifica il codice, le risorse, le autorizzazioni o la configurazione inclusi nel pacchetto. A volte gli interventi sul sito o lato server risolvono il problema senza ricompilare. Segui la comunicazione e convalida l’invio interessato.
Google descrive l’elaborazione generale delle modifiche a un’app come un’operazione che richiede da poche ore a sette giorni, a volte di più. Non è un tempo di risoluzione garantito per il tuo rifiuto o per il tuo ricorso, e la revisione dell’accesso alla produzione è un processo a parte; vedi i tempi di revisione di Google Play. Non viene pubblicato alcun numero di rifiuti consentiti né alcuna probabilità di successo del ricorso, e qui non se ne promette nessuna.
Com’è fatta una scheda utile del rifiuto
EsempioDue schede di esempio, costruite per mostrare la forma delle prove che conviene conservare: una per il rifiuto di un aggiornamento e una per un’idoneità ai test incompleta. Non sono casi di clienti e non sono statistiche. Conserva l’ID dell’invio, che trovi in Attività di invio di Play Console, insieme alla comunicazione e alla versione interessata, così l’assistenza può individuare l’invio esatto.
| Comunicazione | Aggiornamento rifiutato, Norme sui dati utente |
|---|---|
| Versione interessata | 2.4.1 (build 241), canale di produzione |
| Problema | Il link all’informativa sulla privacy nella scheda restituiva un errore 404 |
| Correzione | Ripristinata la pagina dell’informativa sulla privacy all’URL esistente, già indicato in Play Console e nell’app. Nessun URL incorporato è cambiato, quindi non è servito un nuovo binario. |
| Convalida | URL aperto da un dispositivo senza accesso effettuato, in due Paesi; modulo Sicurezza dei dati riletto a confronto con la pagina |
| Decisione | Inviato di nuovo; aggiornamento approvato |
| Comunicazione | Idoneità ai test incompleta |
|---|---|
| Versione interessata | 1.0.3, canale di test chiuso |
| Problema | 12 tester aggiunti; solo 9 sono rimasti attivati per tutti i 14 giorni |
| Correzione | Reclutati tre tester sostitutivi; ciascuno ha avviato il proprio periodo di 14 giorni |
| Convalida | La Dashboard mostrava 12 tester attivati negli ultimi 14 giorni |
| Decisione | Idoneo a presentare la richiesta dopo che i tester sostitutivi hanno completato i periodi richiesti |
Checklist prima dell’invio
Eseguila sulla versione esatta che stai per inviare, non su quella che hai testato la settimana scorsa. Le voci contrassegnate con dove applicabile dipendono da ciò che fa l’app.
Build e comportamento
Accesso per chi esamina l’app e dichiarazioni
Privacy e dati
Pagamenti
Requisito di test, solo per i nuovi account personali
Domande e risposte
Il rapporto annuo tra invii rifiutati ed esaminati prevede l’esito della prima revisione della mia app?
No. Il rapporto del 7,89% mette a confronto i conteggi globali che Google riporta per gli invii di app esaminati e rifiutati nel 2025. I report non definiscono un insieme di primi tentativi, quindi né il rapporto né il suo complemento sono una probabilità riferita a una specifica app nuova.
Perché il conteggio dell’analisi sulla sicurezza è diverso da quello del report sulla trasparenza?
Misurano cose diverse. L’analisi annuale sulla sicurezza riporta conteggi arrotondati di app che violano le norme bloccate prima della pubblicazione; il report sulla trasparenza conta gli invii rifiutati e le rimozioni. Google non pubblica alcuna riconciliazione fra le due serie, quindi non si possono combinare in un unico tasso.
Un aggiornamento rifiutato incide sulla versione già pubblicata?
Il rifiuto di un normale aggiornamento non rimuove la versione pubblicata: la versione precedente resta disponibile mentre correggi l’aggiornamento. Rimozione, sospensione e chiusura dell’account sono stati distinti di applicazione delle norme, ciascuno con la propria comunicazione, e quelli sì che incidono sull’app online.
Il rifiuto dell’accesso alla produzione è un rifiuto per violazione delle norme?
No. Per un nuovo account personale, la decisione sull’accesso alla produzione esamina il test chiuso che hai svolto e le risposte che hai dato. «More testing required» significa che la richiesta ha bisogno di altro lavoro; non è un provvedimento contro l’app per violazione delle norme, e aumentare i tester non risolve un vero rifiuto per violazione delle norme.
Conviene presentare ricorso o inviare una correzione?
Non inviare di nuovo finché la violazione citata resta irrisolta. Alcune correzioni cambiano la scheda dello Store o le dichiarazioni senza toccare il binario. Se ritieni che la decisione sia sbagliata, segui le istruzioni per il ricorso contenute nella comunicazione e fornisci prove della conformità. Non creare un altro account per ripubblicare: viene considerata una violazione.
Fonti e note sui dati
Dove andare adesso dipende da che cosa cercavi. Per citare il tasso, cita il 7,89% con il suo anno (attività 2025) e il suo denominatore (invii esaminati). Per agire su una comunicazione, trova la sua riga nella tabella delle decisioni e segui quel percorso. Se ciò che ti blocca è il requisito di test, la guida ai requisiti del test chiuso copre la configurazione dall’inizio alla fine.
In sintesi
Il rapporto di rifiuto degli invii su Google Play per il 2025 è di circa il 7,89%, calcolato su 1.692.467 invii rifiutati e 21.461.250 invii esaminati nel Report annuale sulla trasparenza 2025 di Google. È un dato storico riferito a tutta la piattaforma, non alle probabilità della tua app. Una comunicazione di rifiuto indica una decisione precisa: correggi ciò che indica, invia di nuovo oppure presenta ricorso, e tratta il requisito di test per i nuovi account personali come un passaggio di prontezza a parte.
Report annuali sulla trasparenza
Analisi annuali sulla sicurezza
Norme e Guida di Play Console
Cronologia degli aggiornamenti
28 febbraio 2026: pubblicato con la sola serie delle analisi annuali sulla sicurezza. 12 settembre 2026: aggiunti il calcolo basato sul report sulla trasparenza e i suoi limiti, separate le due serie di Google, aggiunte la tabella delle decisioni e le sezioni su accesso per chi esamina l’app, Sicurezza dei dati e cosa fare dopo il rifiuto, ed eliminata l’impostazione a classifica dei motivi; una seconda lettura lo stesso giorno ha corretto il testo su nuovo invio, funzionalità e tempi della revisione. Prossimo aggiornamento annuale quando Google pubblicherà il report 2026, atteso nel 2027.