Sì: gli ultimi 14 giorni
Un tratto ininterrotto che termina quando richiediGoogle conta i tuoi ultimi 14 giorni consecutivi con almeno 12 tester attivati, che terminano nel momento in cui richiedi l’accesso in produzione. Non sono 14 giorni qualsiasi e non sono 14 giorni sommati: è un’unica finestra attuale e ininterrotta.
14 giorni sparsi o sommati non contano.
5 giorni ora, 4 la prossima settimana e 5 dopo fanno 14 in totale, ma zero finestre valide. Nel momento in cui il conteggio dei partecipanti scende sotto 12, la sequenza si interrompe e l’orologio riparte dal giorno uno.
Risposta rapida
I 14 giorni devono essere consecutivi e i più recenti, non 14 giorni sparsi o sommati. Almeno 12 tester devono restare attivati per tutta quella finestra ininterrotta, che termina quando richiedi l’accesso in produzione. La regola vale per il test chiuso (closed testing) sugli account sviluppatore personali Google Play creati dopo il 13 novembre 2023. Un tester che attiva il test, esce e poi si riattiva non riceve credito per i giorni precedenti: il conteggio ricomincia. Disinstallare non è la stessa cosa che uscire dal test, ma indebolisce comunque l’engagement che Google analizza. Il percorso sicuro è reclutare più di 12, così le uscite non ti portano mai sotto la soglia.
Questa è la domanda più comune sulla regola del test chiuso di Google Play, e fa inciampare gli sviluppatori di continuo. Qui sotto trovi esattamente cosa esige Google, cosa azzera l’orologio e come proteggere la finestra ininterrotta di 14 giorni per soddisfare il requisito. Aggiornato al 30 giugno 2026. Due strumenti interattivi ti permettono di testare qualsiasi scenario prima di rischiare sull’account reale.
In questa guida
Cosa esige davvero Google?
Risposta breve: almeno 12 tester attivati nel tuo test chiuso negli ultimi 14 giorni in modo continuo. Entrambi i numeri devono essere veri allo stesso tempo, e la finestra deve essere attuale quando richiedi l’accesso in produzione.
Se hai creato un account sviluppatore personale su Google Play dopo il 13 novembre 2023, non puoi pubblicare in produzione finché non completi un test chiuso. Il requisito di Google è che l’app esegua un test chiuso con almeno 12 tester che, nelle parole di Google, siano stati "opted-in for at least the last 14 days continuously". Solo allora il pulsante Richiedi l’accesso in produzione si attiva in Play Console.
Due numeri definiscono la regola, e funzionano insieme:
12 tester devono essere attivati nel tuo test chiuso.
14 giorni consecutivi è quanto devono restare attivati, terminando quando fai la richiesta.
Il requisito vale solo per gli account personali creati dopo la data di taglio del 13 novembre 2023. Gli account dell’organizzazione (quelli che richiedono un numero D-U-N-S e la verifica aziendale) sono esenti, e lo sono anche gli account personali creati in quella data o prima. Confrontiamo i due nella nostra guida account personale vs. organizzazione. Il minimo di tester era 20. Google lo ha ridotto a 12 l’11 dicembre 2024 dopo il feedback degli sviluppatori, ma ha lasciato intatta la durata di 14 giorni. Qualsiasi guida che ti dica ancora di trovare 20 tester è obsoleta (in inglese). Quella finestra di 14 giorni resta il vero punto di attrito, ed è dove vive questa guida.
I 14 giorni devono essere i 14 giorni più recenti?
Sì. La formulazione di Google è "opted-in for at least the last 14 days continuously" / "gli ultimi 14 giorni". Non sono 14 giorni qualsiasi e non sono 14 giorni in totale: sono gli ultimi 14, ininterrotti, che terminano quando invii la richiesta di produzione.
La parola che regge la policy è "ultimi" / "last". La stessa FAQ di Google elimina ogni dubbio su una lettura accumulata: il sistema non conta i tester che hanno attivato il test, testato per meno di 14 giorni e poi uscito, e anche se quel tester si riattiva in modo che il tempo totale arrivi a due settimane, quei 14 giorni devono essere consecutivi per contare.
In italiano chiaro: non puoi cucire 5 giorni ora, 4 la prossima settimana e 5 la settimana dopo. Un tester che interrompe la partecipazione avvia un conteggio fresco di 14 giorni, e i giorni precedenti vengono scartati. La finestra è un unico tratto ininterrotto. Lo strumento qui sotto lo rende concreto: segna i giorni in cui hai tenuto almeno 12 tester attivati e vedi quale sequenza Google conterebbe davvero.
Tocca un giorno per segnarlo di verde (quel giorno, 12 o più tester attivati). L’ultima cella è oggi: il giorno in cui richiedi l’accesso in produzione. Google conta solo la tua sequenza ininterrotta più recente che termina lì.
Un modello didattico della regola dei giorni consecutivi, non una lettura live di Play Console. Google misura la sequenza ininterrotta più recente con 12+ tester attivati, che termina quando fai la richiesta.
Prova il preset Giorni sparsi: segna 13 giorni separati, ma poiché non formano mai una sequenza ininterrotta che termina oggi, la finestra che conta è minuscola. Questa è la trappola dei giorni accumulati in un clic: tanta attività, nessuna sequenza che si qualifica.
Consecutivi vs. accumulati: la distinzione che fa inciampare tutti
I giorni accumulati qui non valgono nulla. Google non somma i tuoi giorni di test. Cerca una sequenza continua, quindi 17 giorni a intermittenza possono ancora equivalere a zero finestre valide.
Questo è il modello mentale con cui parte quasi ogni sviluppatore, e perché fallisce:
Sommare tratti interrotti non funziona. Ogni interruzione scarta i giorni precedenti, quindi 17 giorni in totale possono ancora significare zero finestre che si qualificano.
Una sequenza ininterrotta di 14 giorni con 12+ tester, attuale quando fai la richiesta. Meno giorni in totale, ma è l’unico schema che soddisfa il requisito.
La distinzione che conta di più è quali schemi esatti Google accredita. Ecco come si risolvono gli scenari comuni:
Lo schema è coerente: solo un tratto ininterrotto dei tuoi ultimi 14 giorni, con almeno 12 tester attivati per tutto il tempo, soddisfa la regola.
Cosa interrompe la serie di 14 giorni?
La parte più difficile di questa regola non è reclutare 12 persone. È tenere intatta la finestra per due settimane intere. Alcuni eventi comuni azzerano l’orologio, e alcuni spesso accusati in realtà no. Qui separiamo fatto e mito.
Cosa interrompe o ferma davvero la sequenza
Il conteggio scende sotto 12
Questo è il nucleo della regola. Se tanti tester escono e scendi a 11, rischi il rifiuto per tester insufficienti e ti serve una finestra fresca di 14 giorni non appena torni a 12 o più. Il fallimento fai-da-te numero uno.
Un tester esce formalmente dal test
Uscire dal test significa che il tester visita la pagina web del test chiuso e clicca per lasciare il programma. Questo interrompe la partecipazione. Se ti porta sotto 12, la continuità si spezza.
Mettere in pausa o depubblicare il canale di test
Se il test non è live, i giorni di partecipazione non si accumulano. Mettere in pausa la release o lasciare scadere il build di test ferma il conteggio. Riprendere avvia una finestra nuova.
Spesso accusati, ma NON sono un reset da soli
Inviare un nuovo build o aggiornamento. La continuità che conta è che i tester restino attivati, non il codice di versione. Un aggiornamento controllato può anche essere un segnale positivo. Vedi la nostra guida sull’aggiornamento durante il test chiuso.
Un tester disinstalla l’app. Disinstallare non lo rimuove formalmente dal test, quindi il timer tecnicamente continua. Il rischio è sull’engagement, non sul conteggio dei giorni.
Tratta con cura la lista dei tester. Se rimuovi persone, o ricarichi una lista che toglie nomi per sbaglio, puoi far scendere il conteggio dei partecipanti sotto 12 senza volerlo. Molti sviluppatori gestiscono i tester con un Google Group collegato invece di ricaricare di continuo le liste di email, proprio per evitare rimozioni accidentali.
Non sei sicuro se un’azione specifica minaccia la tua finestra? Scegli sotto e ricevi un verdetto istantaneo.
Cosa sta per succedere nel tuo test?
Basato sul requisito pubblicato da Google (12 tester attivati × 14 giorni continui) più l’esperienza ampiamente riportata dagli sviluppatori. Mettere in pausa il canale e le sostituzioni tardive sono avvisi della community, non policy documentata.
Uscire dal test vs. disinstallare: qual è la differenza?
Solo uscire dal test rimuove un tester dal tuo conteggio. Disinstallare lascia il timer in corsa, ma un’app non usata non genera engagement, e Google può rifiutare solo per quello.
Queste due azioni sembrano uguali a un tester occasionale, ma non lo sono, e la differenza conta:
Uscire dal test (deliberato)
Il tester apre il link del test chiuso nel browser e sceglie di lasciare il programma. Questo lo rimuove subito dal pool di partecipanti attivati.
Se ti porta sotto 12, la finestra continua si interrompe e l’orologio riparte dal giorno uno.
Disinstallare (solo cancellare)
Cancellare l’app dal telefono. Se il tester non visita mai la pagina web per uscire, il backend di Google lo tratta ancora come attivato, e il timer di 14 giorni continua ad avanzare.
Il rischio qui è l’engagement, non il conteggio dei giorni.
Allora perché non affidarsi solo alle disinstallazioni per tenere alto il conteggio? Perché Google non guarda solo il calendario. Analizza anche se i tuoi tester hanno davvero usato l’app durante il test. Google elenca la mancanza di engagement come motivo diretto di rifiuto, e molti sviluppatori vedono il messaggio "Testers were not engaged with your app during your closed test" anche quando conteggio e date sembravano corretti sulla carta. Un tester che installa una volta, cancella l’app il giorno due e non torna più non genera attività. Sulla carta hai ancora 12. Nella pratica, la revisione può rifiutarti per engagement non autentico: uno dei diversi schemi che dettagliamo in perché il test chiuso viene rifiutato.
L’insegnamento: battere il conteggio è la barra di eleggibilità, ma l’uso reale e ripetuto lungo le due settimane è ciò che ti fa passare la revisione. Tester che aprono davvero l’app, percorrono le schermate principali e tornano lungo i 14 giorni sono ciò che sembra una revisione pulita.
Tutti i 12 tester devono iniziare lo stesso giorno?
Non in senso stretto, ma le due letture convergono sullo stesso comportamento sicuro. Tieni almeno 12 tester attivati lungo gli stessi ultimi 14 giorni consecutivi più recenti, con finestre che si sovrappongono e sono attuali quando fai la richiesta.
Qui la formulazione di Google è genuinamente ambigua, e dovresti saperlo in partenza. Ci sono due letture difendibili:
Ogni tester ha bisogno dei propri 14 ininterrotti
Letta alla lettera, la policy è formulata per tester: scarta i giorni di un tester specifico se esce e rientra. Questo suggerisce che vuoi 12 persone concrete che abbiano, ciascuna, partecipato personalmente agli stessi ultimi 14 giorni consecutivi più recenti, così che le finestre si sovrappongano e siano tutte attuali quando fai la richiesta.
Tenere il pool a 12+ per 14 giorni
Nella pratica, molti sviluppatori la trattano come aggregata: tenere il totale di tester attivati a 12 o più per 14 giorni ininterrotti. In questa visione potresti partire con qualche persona in più, perderne una o due lungo la strada e restare a posto, purché il pool non scenda mai sotto 12.
Le due letture convergono sullo stesso comportamento sicuro
Tieni i tuoi tester originali qualificati attivati per tutta la finestra ininterrotta, e tratta qualsiasi tester aggiunto tardi come qualcuno il cui conteggio personale di 14 giorni sta solo iniziando. Non devi risolvere il dibattito per avere successo: l’approccio conservativo soddisfa entrambe le interpretazioni.
Ciò che Google non ha mai documentato è se puoi sostituire liberamente un tester uscito con uno completamente nuovo a metà finestra senza azzerare l’orologio. Nessuno può citarti una risposta ufficiale, quindi l’assunzione conservativa è quella corretta. Quando i consigli online affermano come fatto il comportamento scambia-e-continua, trattalo come folklore della community, non come policy di Google.
Perché 12 tester è il pavimento, non l’obiettivo
Reclutare in surplus è un’assicurazione di continuità. Dodici è il minimo che ti rende eleggibile. Non è un posto comodo in cui restare 14 giorni, perché una sola uscita al giorno 11 può costarti l’intera finestra.
Quando capisci che il rischio reale è una finestra spezzata, l’argomento per reclutare più di 12 diventa ovvio. Se parti con margine, le disinstallazioni inevitabili e la persona occasionale che perde interesse non ti trascinano sotto la soglia. Ecco come si confrontano i tre pool più comuni per un account personale:
Dimensione del pool
Esattamente 12
Cuscino uscite
Nessuno: una uscita spezza la finestra
Rischio al 1° tentativo
AltoDimensione del pool
15 a 18
Cuscino uscite
Alcuni tester possono uscire in sicurezza
Rischio al 1° tentativo
ModeratoDimensione del pool
20 a 25
Cuscino uscite
Margine comodo per le uscite
Rischio al 1° tentativo
BassoTutte e tre le dimensioni sono eleggibili. L’unica differenza è quanto ti fa male un’uscita a metà finestra, e quella differenza è l’intero gioco.
Il pattern è lo stesso su cui convergono sviluppatori esperti e servizi gestiti: non far partire un test con esattamente il minimo. Costruisci margine così che la principale modalità di fallimento della regola, una discesa sotto 12 a metà finestra, non ti capiti proprio. Facciamo il caso completo in perché ti servono più di 12 tester.
Due note pratiche su come montare quel pool. Primo: i 12 devono essere 12 persone reali e distinte attivate. Non puoi essere il tuo stesso tester su dispositivi extra per gonfiare il conteggio. Secondo: se sei ancora sotto 12, ci sono modi legittimi per ottenere tester che mantengono l’engagement genuino.
Questa regola si inserisce anche in un inasprimento più ampio degli standard di pubblicazione di Google Play nel 2026, quindi il successo al primo tentativo vale più che mai. Superare il test chiuso al primo colpo significa non far ripartire un orologio di 14 giorni mentre le scadenze avanzano. La nostra guida ai requisiti di pubblicazione 2026 segue il calendario completo.
La formulazione esatta di Google (e perché «last» conta)
Se vuoi il linguaggio della fonte, il requisito in sé è breve. La guida di Play Console definisce la soglia del test chiuso come avere tester che siano stati:
opted-in for at least the last 14 days continuously.
Nella formulazione ufficiale italiana di Google, questo compare come tester attivati negli ultimi 14 giorni continuamente e, in un’altra formulazione, che i 12 tester devono aver partecipato per 14 giorni consecutivi. Due idee reggono l’intera regola. «Last» / «ultimi» significa che deve essere la tua finestra più recente, attuale quando richiedi, non un tratto di un mese fa. «Continuously» / «continuamente» significa senza interruzioni: senza buchi, senza pause, senza scendere sotto 12 a metà strada.
La FAQ di Google chiude in modo diretto il buco dei giorni accumulati. Spiega che i tester che si attivano, testano per meno di 14 giorni e poi escono non contano, e che anche se quel tester torna ad attivarsi in modo che il tempo combinato arrivi a due settimane, quei 14 giorni devono comunque essere consecutivi per qualificare. In altre parole: il sistema verifica esplicitamente una sequenza ininterrotta, non una somma.
Le tre idee che decidono tutto
Last / ultimi: più recenti, attuali al momento della richiesta
14 giorni: la durata completa e ininterrotta
Continuously: mai sotto 12, senza buchi
Come PrimeTestLab tiene intatta la tua finestra
PrimeTestLab è costruita esattamente intorno al modo di fallimento che questa regola crea. Invece di lasciarti reclutare sconosciuti e sperare che restino attivati, forniamo un pool gestito di tester umani reali, attivati su dispositivi Android reali, e manteniamo quel pool sopra la soglia per i 14 giorni consecutivi completi. Manteniamo un tasso di successo del 99,9% su 7.400+ app, con test live in 4-6 ore. Ecco come funziona da capo a coda.
Scegli la dimensione di pool che sta nella tua tolleranza al rischio. Per la maggior parte degli sviluppatori, il piano Enterprise è la scelta sensata: 25 tester per il margine più ampio contro una finestra spezzata, per solo pochi dollari in più rispetto al minimo assoluto.
Maggior margine di continuità
Prezzi +5% di commissione di servizio al checkout.
Vedi il dettaglio completo sulla nostra pagina prezzi o leggi la guida completa al requisito dei 12 tester. Quando sei pronto, il pacchetto da 12 tester ti mette in moto, e il nostro servizio di test chiuso copre cosa è incluso.
Domande frequenti
Posso usare 14 giorni di test non consecutivi?
No. Google esige gli ultimi 14 giorni in modo continuo. I giorni completati, interrotti e ripresi dopo non si sommano. I 14 giorni devono essere un unico tratto ininterrotto che termina quando richiedi l’accesso in produzione.
Cosa succede se un tester esce dal test al giorno 10?
Se quell’uscita porta il conteggio degli attivati sotto 12, la tua finestra continua si spezza. Non appena torni ad almeno 12 tester attivati, parte un conteggio fresco di 14 giorni. Partire con esattamente 12 è rischioso, per questo si raccomanda un margine.
Disinstallare l’app azzera i 14 giorni?
Tecnicamente no. Disinstallare non è la stessa cosa che uscire formalmente dal test, quindi il timer continua. Ma un’app disinstallata e non usata non genera engagement, e Google può rifiutare la tua richiesta di produzione se i tester non sono stati attivamente impegnati durante il test.
Tutti i 12 tester devono iniziare lo stesso giorno?
Google non esige in modo stretto una data di inizio identica, ma l’approccio più sicuro è avere i tuoi 12 o più tester tutti attivati lungo gli stessi 14 giorni consecutivi più recenti, con finestre che si sovrappongono e sono attuali quando richiedi.
Posso aggiungere nuovi tester durante i 14 giorni?
Puoi aggiungere tester, ma un tester aggiunto in ritardo inizia il proprio conteggio di 14 giorni da quel momento. Google non ha documentato se un tester tardivo possa sostituire uno uscito senza far ripartire l’orologio, quindi tieni i tester originali qualificati attivati per l’intera finestra.
Inviare un aggiornamento dell’app azzera l’orologio di 14 giorni?
No. Pubblicare una nuova build sul tuo canale di test chiuso non azzera il conteggio dei giorni. La continuità che conta è che i tuoi tester restino attivati. Aggiornare a metà test può essere addirittura un segnale positivo, purché i tester passino alla nuova build.
Quanto tempo dopo i 14 giorni fino all’accesso in produzione?
Dopo la richiesta, Google analizza il tuo test chiuso e il modulo e invia un’email al titolare dell’account. Questo processo di solito richiede fino a sette giorni, ma può richiedere un po’ di più. Le risposte vaghe nel modulo sono un motivo comune di rifiuto.
Questa regola vale per gli account dell’organizzazione?
No. Il requisito di 12 tester e 14 giorni di test chiuso vale solo per gli account sviluppatore personali creati dopo il 13 novembre 2023. Gli account dell’organizzazione sono esenti, e lo sono anche gli account personali creati in quella data o prima.
Conclusione
In sintesi
I 14 giorni non sono accumulati. Google conta solo i tuoi ultimi 14 giorni consecutivi con almeno 12 tester attivati, e quella finestra deve essere intatta quando richiedi l’accesso in produzione. Il modo più rapido di fallire è partire con esattamente 12 e vedere una sola uscita azzerare l’orologio; il modo più rapido di soddisfare il requisito è reclutare in surplus così che la finestra non si spezzi mai e assicurarti che i tuoi tester usino davvero l’app per le due settimane. PrimeTestLab si occupa di entrambi: un pool gestito di tester reali attivati, dimensionato per restare sopra la soglia per i 14 giorni completi, a partire da $19.99 con test live in 4-6 ore. Vedi piani e prezzi →