Decoding Play Policy AMA

Okay.

Grazie a tutti per aver partecipato a questo panel sulla decodifica delle norme di Google Play.

Sono Jan Kleinert, Developer Relations Engineer del team di Android for Cars.

Oggi sarò il moderatore del panel.

Passo la parola ai nostri relatori, Bohdan e Paul, per presentarsi.

Bohdan, iniziamo da te.

Ciao!

Sono Bohdan e lavoro nel team per l'affidabilità e la sicurezza di Google Play.

Lavoro qui da oltre quattro anni e nel settore della fiducia e della sicurezza tecnologica da oltre un decennio.

Mi piace vedere come interagiscono tecnologia, settore e cultura e come gli eventi incoraggiano lo sviluppo di nuove app. Mi piacciono eventi come questi in cui possiamo fare del nostro meglio per aiutare gli sviluppatori come voi a raggiungere il successo.

Ciao,

Mi chiamo Paul.

Lavoro nello stesso team di Bohdan e mi occupo di Trust and Safety da circa lo stesso periodo di Bohdan, ormai un decennio, e la maggior parte di questo tempo l'ho trascorsa nel team Trust and Safety di Google Play.

Sono molto felice di essere qui oggi. Iniziamo.

Ok, grazie.

Quindi, per preparare il terreno prima di dare il via al panel, ripasso la parola a Paul.

Inizierà con una breve panoramica delle risorse relative alle norme, informazioni sulle best practice e cose simili per aiutarti a preparare la tua app per una revisione secondo le norme più fluida ed efficiente.

Sì.

Ma cosa si intende per norme di Google Play?

Queste sono le regole fondamentali che gli sviluppatori devono rispettare durante la pubblicazione e la manutenzione delle applicazioni mobile sul Google Play Store.

Abbiamo fornito alcuni link brevi sullo schermo per le risorse relative alle norme di Google Play.

Il primo link rimanda al Centro norme per gli sviluppatori.

Se fai clic su Aggiornamenti recenti nella parte superiore della pagina, puoi leggere i dettagli sulle nuove norme relative alle notizie, nonché gli aggiornamenti o i chiarimenti relativi alle norme esistenti.

Se preferisci un approccio più visivo o audio, il secondo link breve ti indirizzerà a una playlist dei nostri Policy Bytes.

Si tratta di video in cui illustriamo gli aggiornamenti delle norme.

Infine, il terzo link ti indirizzerà a una pagina in cui potrai scoprire di più su Play Policy Insights in Android Studio, una funzionalità pensata per fornire utili indicazioni pre-revisione sotto forma di controlli lint in Android Studio.

Okay.

Inoltre, è disponibile una skill Android per facilitare l'audit delle app per Android rispetto a queste norme di Google Play, per aiutarti a verificare la conformità in termini di autorizzazioni, eliminazione dell'account e sicurezza dei dati.

Puoi installare questa skill utilizzando la CLI Android, proprio come qualsiasi altra skill.

android skills list
android skills add play-policy-insights

Infine, prima di iniziare con alcune delle domande del panel di Jan, volevamo condividere alcune best practice per lavorare con le norme di Google Play e le revisioni delle app.

Il primo consiste nel fornire le credenziali di accesso ai revisori.

Sembra un problema semplice, ma una causa molto comune di ritardi o rifiuti è l'inaccessibilità dei contenuti.

Se la tua app richiede l'accesso o include contenuti a pagamento, crediti o abbonamenti, devi fornire le credenziali di test.

Per alcune app, significa fornire le credenziali di accesso solo all'inizio dell'app, mentre per altre potrebbero esserci sezioni diverse, come i contenuti a pagamento che ho menzionato.

Puoi farlo in Play Console, quindi fornire queste credenziali di accesso ai nostri revisori.

In precedenza si chiamava Accesso alle app, ma ora si chiama Dettagli di accesso e si trova nella sezione Contenuti app.

E poi vuoi assicurarti che le credenziali bypassino qualsiasi tipo di autenticazione a due fattori, captcha, paywall, ecc.

Sì, disattiva i codici di versione precedenti.

Quindi, gli sviluppatori spesso sperimentano quelli che chiamiamo, colloquialmente, loop di rifiuto, perché caricano una build di produzione pulita e conforme, ma spesso dimenticano che una versione precedente non conforme è ancora attiva su Play Console su un altro canale, che si tratti di test aperti, test chiusi e così via. Quindi, anche se si tratta di un app bundle in un vecchio canale di test, è soggetto alla revisione secondo le norme di Play, alle norme di Play.

Pertanto, se richiede autorizzazioni limitate o utilizza SDK vulnerabili obsoleti, sarà comunque soggetta a revisione.

Quindi, assicurati di sostituire o disattivare tutti i codici di versione obsoleti in tutti i canali prima di premere il pulsante di invio.

Terzo, concedi un tempo sufficiente per le revisioni e utilizza la pubblicazione gestita.

Pertanto, le revisioni e le pubblicazioni delle app possono richiedere sette giorni o, a volte, più tempo per essere pubblicate, soprattutto se si tratta di una nuova app o di un'app che richiede un'autorizzazione sensibile.

Quindi, è necessario dare un tempo di risposta sufficiente.

Se hai un lancio importante, assicurati di inviare la nuova app almeno un paio di settimane prima della data di lancio effettiva.

Puoi quindi collegare questa funzionalità alla pubblicazione gestita.

La pubblicazione gestita è una funzionalità che consente di trattenere gli aggiornamenti approvati finché non è tutto pronto per il rilascio, evitando ritardi imprevisti durante le campagne di marketing o altri lanci sensibili.

Inoltre, assicurati di non inviare nuovamente l'app una volta che è già stata inviata per la revisione.

In caso contrario, il periodo di tempo ricomincia da capo.

Penso che a volte gli sviluppatori se ne dimentichino e, quando hanno un'app a metà, si dimenticano di dover apportare una piccola modifica.

Se lo inviano di nuovo, l'app torna all'inizio della procedura di revisione.

Esatto, controlla le tue dichiarazioni.

Pertanto, le dichiarazioni relative ai contenuti dell'app, ad esempio la sezione Sicurezza dei dati, le norme sulla privacy o le autorizzazioni per foto/video, devono corrispondere al file manifest dell'app dei bundle o dei codici di versione attivi in tutti i canali.

Ad esempio, se il file manifest della tua app richiede l'accesso alla posizione esatta, ma il modulo Dichiarazione delle autorizzazioni non ne divulga lo scopo, l'app potrebbe essere soggetta a provvedimenti, cosa che molto probabilmente accadrà.

Pertanto, assicurati che gli SDK di terze parti non esfiltrino dati che non hai dichiarato.

Anche se la tua app non utilizza un dato specifico, se scegli di integrare un SDK che lo fa, potrebbe essere soggetta a un'applicazione.

Quindi, consulta Google Play SDK Index per visualizzare informazioni su oltre 100 SDK commerciali tra quelli più comunemente utilizzati.

Vorrei interromperti con una breve domanda prima di andare avanti.

Quando parli di applicazioni, cosa intendi nello specifico?

Cosa significa questo termine?

Le applicazioni possono essere qualsiasi azione avversa, quindi possono variare da avvisi a rifiuti, fino ad applicazioni ancora più gravi come rimozioni, sospensioni o persino divieti di utilizzo dell'account.

Quindi, quando parlo di applicazioni, mi riferisco a queste azioni avverse.

Perfetto.

Grazie.

Sì.

Infine, utilizza i ricorsi.

Non limitarti a inviare nuovamente la stessa versione dopo un rifiuto.

Inoltre, i rifiuti ripetuti per lo stesso problema in un breve periodo di tempo potrebbero attivare un flag algoritmico che porta alle applicazioni più severe menzionate da Paul, come rimozioni o sospensioni.

Quindi, se un'app viene rifiutata, non limitarti a inviarla di nuovo, sai, subito senza apportare modifiche, indovinare o rispondere al feedback.

Riceverai comunicazioni sia nella posta in arrivo della console sia nelle email associate che hai fornito per la violazione esatta e le indicazioni.

Se non sei d'accordo o magari non capisci, ma diciamo che non sei d'accordo con un rifiuto, fai ricorso, giusto?

Se ritieni che si tratti di un falso positivo, puoi utilizzare il link fornito nelle comunicazioni per presentare ricorso.

Questo è un primo passo migliore rispetto alla semplice ripresentazione senza apportare modifiche.

Lo stesso vale se ricevi le comunicazioni e non ti sembrano del tutto chiare, magari sono troppo prolisse, forse ci sono troppi paragrafi, qualunque sia il problema, puoi tranquillamente tornare ai ricorsi.

In questo modo, comunicherai via email con una persona reale.

Anche se potrebbero esserci dei limiti su ciò che possono comunicare, spesso puoi ottenere ulteriori dettagli sul motivo del rifiuto.

Altre volte, il team dei ricorsi comprende che le comunicazioni possono essere piuttosto lunghe.

In questo modo, potranno evidenziare o mettere in grassetto le sezioni specificamente applicabili a te e alla tua app.

Quindi, sì.

Passo la parola a Jan.

Okay.

Grazie.

Abbiamo quindi raccolto le domande degli sviluppatori da diversi canali e fonti.

Quindi, le domande che abbiamo oggi rappresentano alcuni dei problemi che sentiamo spesso dagli sviluppatori quando si tratta di norme.

Iniziamo con questo.

Quali sono alcuni dei motivi più comuni per cui un'app potrebbe essere rifiutata in relazione alle autorizzazioni?

E come possono gli sviluppatori evitare i rifiuti correlati, ad esempio, alle violazioni delle norme sulle autorizzazioni?

Okay.

Autorizzazioni, scelgo questa.

Quindi, sì, le autorizzazioni, in particolare quelle sensibili, devono essere fondamentali per lo scopo principale pubblicizzato della tua app.

Quindi, se hai una funzionalità secondaria o una funzionalità che non è nemmeno nell'app e non è nemmeno pubblicizzata, è molto probabile che l'app venga rifiutata.

Pertanto, assicurati che la dichiarazione corrisponda al caso d'uso dell'app.

Inoltre, spesso un'app viene rifiutata perché i link ai video forniti nelle dichiarazioni non sono accessibili.

Il nostro team di revisori deve poter accedere all'app, ai link dei video che fornisci e a tutto ciò che si trova all'interno dell'app per poterla esaminare completamente.

Quindi, assicurati che tutto sia accessibile nell'app, nel file manifest e nella dichiarazione.

Quindi, assicurati che questi tre elementi siano stati completati e molto probabilmente, beh, non voglio dire molto probabilmente, ma il processo sarà più semplice.

Perfetto.

Okay.

Quindi, sempre più sviluppatori di app stanno iniziando a utilizzare piattaforme di terze parti per i contenuti generati con l'AI all'interno delle loro app, giusto?

Se queste piattaforme producono contenuti inappropriati, oggettivamente errati o simili, questo può portare al rifiuto dell'app dello sviluppatore? E chi è effettivamente responsabile in casi come questo?

Sì.

Sì, questo può portare a un rifiuto.

Fin dall'inizio del Play Store, la posizione è sempre stata che tutto ciò che uno sviluppatore ha nell'app o tutto ciò a cui un utente può accedere nell'app è responsabilità dello sviluppatore.

Quindi, anche se l'AI generativa è un'area nuova, vale lo stesso principio.

Penso che un buon parallelo con l'AI generativa siano i contenuti generati dagli utenti, perché per entrambe le norme è necessario avere molti degli stessi tipi di, sai, devi avere, segnalazioni, sai, se appare qualcosa che non è del tutto appropriato.

Deve essere presente un meccanismo di filtro.

Penso che ci siano, voglio dire, ci sono altre norme, ovviamente, che si applicherebbero, ma il modo in cui mi piace vederlo è che se hai contenuti di AI generativa, hai Google che esamina l'app, hai utenti che fanno clic su Segnala se vedono qualcosa di inappropriato e poi hai i tuoi meccanismi di filtro.

Quindi, Google, lo sviluppatore e gli utenti collaborano per contribuire a mantenere l'app il più sicura possibile per tutti.

Ok.

Ottimo.

Ma in generale, consigliamo che, oltre ad avere meccanismi per consentire agli utenti di segnalare i contenuti, gli sviluppatori debbano inserire una sorta di… È questo che intendi per meccanismo di filtro?

Ad esempio, per impedire che determinati tipi di contenuti vengano mostrati agli utenti?

risposta esatta.

Sì.

Quindi, durante la procedura di revisione, i nostri team non andranno a scavare nel tuo codice o a fare il reverse engineering del tuo meccanismo di filtro esatto.

Vogliono solo vedere se possono accedere a contenuti inappropriati.

Se possono, invieremo delle comunicazioni e poi sarà compito del tuo team capire come rendere più efficace il meccanismo di filtro.

Ok.

Perfetto, grazie.

Una delle norme esistenti riguarda il furto d'identità o l'imitazione, giusto?

Quindi, se un'app viene rifiutata ai sensi delle norme relative al furto d'identità, ma lo sviluppatore ritiene che si tratti di un errore, per qualsiasi motivo, cosa deve fare?

Come possono evitare in modo proattivo questo tipo di rifiuto?

Ricorso.

Sì, questa è una delle, credo sia la quinta best practice che abbiamo elencato: se la tua richiesta viene rifiutata per questo motivo, devi presentare ricorso.

Quindi, cosa dovresti fare? Beh, gli scenari più comuni sono che il brand di cui stai assumendo l'identità è il tuo, giusto?

Oppure, stai creando un'app per conto di qualcun altro, e direi che questo è probabilmente il caso più comune, in cui hai sviluppatori di etichette vuote che creano app per, ad esempio, le loro strutture di fitness, SaaS, sai, una sorta di soluzione SaaS.

Quindi, è più facile pubblicarle con il tuo account sviluppatore, giusto?

Puoi presentare un ricorso e il nostro team cercherà quella che viene chiamata prova dell'autorizzazione.

Supponiamo che tu abbia un cliente di nome Joe's Chicken, che vende il miglior pollo a ovest del Mississippi.

Ti daranno una lettera di autorizzazione su carta intestata ufficiale dell'azienda con il loro logo che dice: "Noi, Joe's Chicken, autorizziamo ABC Developer a utilizzare le nostre immagini e la nostra somiglianza nella sua app". È meglio se inseriscono il nome dell'app e il nome del pacchetto applicativo.

Ad esempio, com.joeschicken.app o qualcosa del genere. Poi, puoi rispondere allo sviluppatore e fornirgli questa documentazione.

Ok.

E poi, credo che la seconda parte fosse…

C'è qualcosa che possono fare in modo proattivo per evitare questo problema?

Ad esempio, è possibile caricare, non ricordo come si chiama, la prova di qualcosa, al momento del primo invio?

Sì.

Infatti,

In Play Console è presente il modulo di preavviso che puoi inviare e caricare, ad esempio, questi moduli di documentazione che associano il tuo account all'altra entità.

In questo modo, puoi proteggere preventivamente l'invio della tua app da questo tipo di provvedimenti negativi.

Proprio così.

Perfetto.

Okay.

Hai accennato all'utilizzo di SDK di terze parti nella sezione sulle best practice, ma vorrei approfondire l'argomento.

Quindi, quando le app utilizzano SDK di terze parti, sembra che gli sviluppatori di app siano responsabili del modo in cui questi SDK di terze parti utilizzano elementi come i dati utente.

In che modo gli sviluppatori possono sapere se gli SDK sono conformi alle norme relative alla sicurezza dei dati e ai dati utente?

Come possono orientarsi in questo panorama?

Sì, è un'ottima domanda.

Ho lavorato molto con gli SDK in Google nei miei primi 2 anni qui e questo si ricollega alla domanda precedente, in cui parlavamo di AI generativa e contenuti generati dagli utenti, nel senso che tutto ciò che è presente nella tua app, sai, è in ultima analisi responsabilità dello sviluppatore.

Penso che Paul abbia accennato brevemente nell'introduzione che abbiamo qualcosa chiamato Google Play SDK Index, che puoi trovare semplicemente digitandolo su Google.

Dovrebbe essere il primo o il secondo risultato, Google Play SDK Index, e ciò che otterrai è una pagina web che contiene più di cento, forse diverse centinaia di SDK divisi per SDK per la monetizzazione, per gli annunci, per la salute o per qualcos'altro.

Questa pagina estrae semplicemente i dati disponibili pubblicamente.

È un evento organizzato da Google.

Ma noterai che, mentre scorri questi SDK, accanto ad alcuni di essi sarà presente un badge con la dicitura "Registrato in SDK Console".

Quindi, proprio come voi sviluppatori avete una Play Console per le vostre app, gli sviluppatori di SDK hanno la possibilità di accedere a una SDK Console.

Inoltre, devono essere sottoposti a una procedura di revisione simile.

Ci inviano il loro SDK.

Google esegue un paio di controlli diversi, ma se l'attività è conforme, riceve il badge.

Per voi sviluppatori, questo significa che potete consultare l'indice e vedere quali SDK hanno superato la procedura.

Questo non garantisce che l'app venga approvata o che l'SDK non sia mai non conforme, ma direi che offre due punti di fiducia.

La prima è che esiste una probabilità molto più elevata che l'app non venga rifiutata se utilizzi l'SDK.

Solo una probabilità.

La seconda, che è un aspetto che mi piace molto di tutto questo processo, è che se finiamo per scoprire che l'SDK contiene qualcosa di non conforme, adottiamo un approccio su due fronti.

Il primo approccio consiste nel contattare lo sviluppatore dell'SDK e dirgli: "Abbiamo notato che il tuo SDK invia i dati utente in modo non conforme".

In questo modo, potranno adoperarsi per rendere conforme la loro app o il loro SDK.

E poi, più o meno nello stesso momento o forse un po' dopo, il secondo aspetto è che i nostri team invieranno notifiche o avvisi agli sviluppatori.

La notifica dirà qualcosa come: "Abbiamo notato che la tua app invia questi dati in modo non conforme e che questo avviene nell'SDK ABC".

Quindi, i passaggi che puoi seguire come sviluppatore consistono semplicemente nell'aggiornare l'SDK alla versione conforme fornita.

Se vuoi adottare un approccio più drastico, puoi rimuovere l'SDK o sostituirlo, ma so che questo richiede un grande sforzo e molto lavoro.

Ma è proprio questo che mi piace di Google Play SDK Index.

Sì.

Nell'indice non è indicato esattamente quali norme sono conformi o meno, ma ricevi il badge e questo è un po' come un voto di fiducia.

Ok.

Sì.

Ok, va bene.

E mi sembra di capire, da quello che hai detto, che se inviamo messaggi agli sviluppatori dicendo, ad esempio, "Stai utilizzando questo SDK e c'è un problema",

Se devono eseguire l'aggiornamento, diciamo loro quale versione? Se lo sviluppatore risolve il problema, diciamo loro: "Ehi, una versione migliore è questa"?

O devono fare un po' di ricerca per conto loro?

Penso che contenga effettivamente il codice della versione.

Sì, non ne sono sicuro, ma credo che lì sia indicato il codice della versione a cui possono eseguire l'aggiornamento.

Sì, e per la massima trasparenza, non sono uno sviluppatore, non sono un ingegnere, ma parlando con gli sviluppatori, quello che capisco è che a volte è facile come fare clic su un pulsante o un paio di pulsanti, e poi avviare il processo di aggiornamento dell'SDK all'interno dell'app.

Bello!

Perfetto.

Grazie.

Okay.

Hai parlato un po' delle credenziali di accesso, un argomento che conosco almeno un po', e di quanto sia importante avere queste informazioni.

Hai menzionato cose come l'elusione dell'autenticazione a due fattori e la garanzia di un modo per superare i paywall o l'accesso ai contenuti basati su abbonamento.

Ma quali altre situazioni comuni dovrebbero considerare gli sviluppatori?

Ad esempio, mi è capitato di vedere app con contenuti accessibili solo in determinati paesi o aree geografiche, o magari un'app di messaggistica che richiede due accessi per poter essere testata.

Ci sono altre situazioni simili in cui, oltre a fornire un accesso, gli sviluppatori potrebbero dover fare qualcosa in più?

Sì.

Inizierei e finirei sempre con le credenziali di accesso che fornisci al team di revisione, assicurandoti che consentano di accedere a tutte le funzionalità dell'app.

Quella sezione di Play Console si chiamava Accesso alle app e penso che circa un mese fa sia stata rinominata Dettagli di accesso.

Quindi sì, c'è un posto in cui puoi inserire il nome utente, la password e poi credo che sotto ci sia un campo di testo in formato libero.

Quindi, puoi fornire istruzioni su come accedere se non è molto semplice.

Se vuoi, puoi anche fornire un secondo, un terzo e un quarto accesso agli utenti.

Per darti un'idea di come i nostri team esaminano le app, non c'è una persona seduta in una stanza che dà un'occhiata e poi fa clic su approva o rifiuta.

Ci sono molti team che esaminano le diverse norme e i flussi di lavoro, quindi è molto probabile che più persone possano accedere alla tua app da più dispositivi, a volte da regioni diverse.

E capisco la difficoltà, perché molti meccanismi di sicurezza dicono: "Oh, se vediamo un gruppo di accessi", allora, per la sicurezza dell'utente, li bloccano.

Ma qualunque cosa tu scelga di fare, tieni presente che esaminiamo l'app in molti flussi di lavoro diversi, quindi potresti finire per vedere questo.

Pertanto, fornire questi accessi multipli può essere utile.

Sì.

Perfetto.

Sì, devo sottolineare l'importanza di utilizzare il testo in formato libero nella dichiarazione.

Quindi, se il tuo account demo non è semplicemente un nome utente e una password, ma sono necessari altri passaggi, devi assicurarti che il nostro team di revisori capisca come accedere alla tua app.

Potresti, ad esempio, fornire un video per mostrare come fare, per assicurarti che il nostro team capisca come fare se è più complesso di, ad esempio, nome utente e password.

Sì.

A volte guardiamo noi stessi le app e ci sono alcuni accessi piuttosto elaborati.

Ad esempio, ne ho visti alcuni in cui, e non sto scherzando, devi toccare questo pulsante 17 volte, poi disegnare una X sullo schermo, poi viene visualizzata la modalità sviluppatore e poi devi seguire altri 11 passaggi, quindi non farlo.

Perché questo rende le cose un po' difficili.

Uno scenario di cui ho sentito parlare è, ad esempio, che alcune app ti consentono di avere solo X, ad esempio, accessi successivi o accessi contemporanei con un'app prima di dire: "Oh, devi rimuoverne uno".

Quindi, se la tua app supporta questa funzionalità, penso che sia utile includere informazioni su come trovare la pagina in cui è possibile rimuovere l'accesso, ad esempio, agli accessi precedenti.

Sì.

Perfetto.

Quindi, quando aggiorniamo le norme o ne introduciamo di nuove, a volte gli sviluppatori devono apportare modifiche alla loro app che, a seconda della natura, potrebbero richiedere un po' di tempo per l'implementazione.

A volte, queste offerte hanno una scadenza, giusto?

Ad esempio, entro questa data devi aver eseguito XYZ per rispettare alcune nuove norme.

Se la scadenza si avvicina, ma uno sviluppatore sa che avrà bisogno di più tempo per conformarsi, quali sono le sue opzioni?

Sì, sembra un avvertimento.

Sì, sembra un avviso.

Sì.

Sì, quindi, con gli avvisi, voglio dire, quello semplice è tipo, questo: basta chiedere più tempo, giusto?

In genere, il processo funziona così: pubblichiamo nuove norme, aggiornamenti di norme esistenti o anche solo chiarimenti.

Inoltre, penso che Google sia generalmente abbastanza brava a dare un tempo di risposta.

E queste norme potrebbero essere annunciate pubblicamente 6 mesi prima di iniziare a prendere provvedimenti.

E poi, sì, verranno inviati gli avvisi e diremo: "Ehi, la tua app viola questa norma annunciata", sai, "6 o 12 mesi fa" o quello che è.

Ma una cosa che, e Paul e io a volte ci opponiamo, è che potrebbero dire che hai 7 giorni per apportare questa modifica.

Lo sviluppo richiede molto tempo.

Lo sappiamo.

Quindi, quello che farei è semplicemente rispondere.

Puoi farlo tramite un ricorso e puoi dire qualcosa come: "Ehi, comprendiamo le norme e il motivo per cui la nostra app non è conforme.

Ci stiamo già lavorando o questi sono i passaggi che seguiremo per risolvere il problema relativo alle norme, ma abbiamo bisogno di più tempo."

Di solito, quindi, ti concedono un po' più di tempo.

Se passano altri 7 giorni e ti stai avvicinando alla fine di questo periodo, puoi richiederlo di nuovo.

Ovviamente non è infinito.

Ma, come ho detto, Paul e io ci opponiamo, ma questo avviene sia a livello individuale sia a un livello più alto.

Ad esempio, quando sappiamo che sono in arrivo nuove norme e magari sappiamo chi ci sta lavorando, diciamo: "Senti, è possibile dare un preavviso di 28 giorni anziché di 7 o almeno di 14?".

Sì.

Infatti,

Se dimostri di essere in buona fede, ad esempio apportando modifiche per garantire la conformità, Google Play collaborerà con te per, ad esempio, stabilire una nuova scadenza.

Una cronologia migliore per te.

Ok.

Quindi, sembra che i ricorsi siano uno strumento versatile per aiutare in molte di queste situazioni, purché vengano utilizzati in modo appropriato.

Ad esempio, presentare un ricorso quando ha senso e fornire dettagli sufficienti sul motivo per cui lo stai presentando può essere un buon modo per ottenere questa considerazione e questo aiuto.

Okay.

Quindi, se uno sviluppatore ha più app in un unico account sviluppatore, cosa che so che accade continuamente.

E un'app viene sospesa per un qualche tipo di violazione delle norme, cosa significa per l'intero account sviluppatore?

Questo mette a rischio l'account o altre app conformi?

Come funziona?

Potrebbe.

Sarebbe come i tuoi sviluppatori di etichette vuote.

Prima parlavo di Joe's Chicken, giusto?

E magari hai clienti che operano tutti in quel settore.

È un po' come quando giochi a baseball e vieni eliminato, giusto?

Purtroppo ci sono malintenzionati che cercano di entrare nel Play Store ed è uno dei motivi per cui abbiamo questo tipo di applicazione, che va da quella leggera a quella più severa, come rimozioni, sospensioni e persino divieti di accesso agli account.

Quindi, se hai uno di questi scenari in cui hai un sacco di app sul Play Store che sono tutte simili e una di queste viene sospesa, diciamo che…

Mm-hm.

Sei un malintenzionato, giusto?

Quindi lo correggi e un mese dopo provi a inserirlo di nuovo.

Poi i nostri team se ne accorgono e l'account viene sospeso di nuovo, giusto?

Poi lo rimuovi dall'app e lo reinserisci un mese dopo. Ok, ora abbiamo uno schema di comportamento ripetitivo e tu sei in battuta, hai subito tre strikeout e ora sei fuori, giusto?

Ma supponiamo che tu stia creando un'app per un ristorante di pollo, che non conterrà contenuti dannosi o altro, stai solo cercando di far conoscere cibo delizioso alle persone.

Quindi, supponiamo che tu stia inviando tutte queste app contemporaneamente con una pipeline CI/CD o qualcosa del genere e che tu riceva 10 app che ricevono tutte questo rifiuto o questa sospensione contemporaneamente. Lo considereremmo come un solo strike perché capiamo che stai creando molte app contemporaneamente.

Mm-hm.

Interessante.

Penso che questa sia la risposta alla domanda.

Sì, adorabile.

Grazie.

E ne ho un'altra per noi qui.

Questa domanda è un po' diversa dalle altre, che erano più rivolte agli sviluppatori affermati. Questa riguarda più la configurazione iniziale in Play Console.

Quindi, supponiamo che il tuo profilo pagamenti di Google Play sia stato verificato, identifica… Oh, è un po' complicato.

Gli errori di verifica dell'identità non sono più presenti e rimane solo la verifica del numero di telefono.

Ad esempio, cosa fa uno sviluppatore in questo caso specifico per assicurarsi che il suo account sviluppatore sia pronto per pubblicare app?

A volte è come se si raccogliessero i singoli pezzi del puzzle. Se non sanno come completare la procedura in un caso del genere, cosa possono fare?

Sì, non molto tempo fa mi è stata posta una domanda simile in un altro evento, ma penso che, sebbene questo sia ovviamente vero per i nuovi sviluppatori, credo che molti degli sviluppatori esistenti abbiano dovuto ripetere la verifica.

È passato circa un anno, giusto?

Non riesco a ricordare.

Molti sono stati verificati automaticamente, ma alcuni non lo sono stati e hanno dovuto farlo.

Ok.

O magari se l'indirizzo e il profilo Dun & Bradstreet non corrispondono, ad esempio…

Infatti,

Infatti,

Il profilo Google.

Ok.

Sì, quindi diciamo che si tratta del numero di telefono.

Risponderò alla domanda in due modi.

Ok.

Innanzitutto, spesso, quando esegui questi passaggi, riceverai delle notifiche in Play Console.

In questo modo, riceverai una notifica che ti invita a registrare il tuo numero di telefono.

E questo è piuttosto semplice.

Inserisci un numero di telefono in formato internazionale, ad esempio +1 408, seguito dal numero.

Dovrai eseguire una verifica tramite SMS o telefonata e seguire i passaggi indicati.

A volte, però, potresti aver provato a farlo e aver ricevuto un messaggio di errore o qualcosa del genere, perché è successo anche ad alcuni sviluppatori, oppure non hanno ricevuto il codice SMS.

Ti indicherò i passaggi per contattare il team per i ricorsi.

Questo è un team, ma in realtà ce ne sono altri, non so se una mezza dozzina o due dozzine, che…

Will.

Rispondi alle domande su Play Console a cui hai effettivamente accesso tramite il menu Guida.

Ora che la UI è cambiata un po'.

In precedenza si trovava in un menu sul lato sinistro della schermata Home.

In basso, c'era un pulsante di assistenza.

che è stato rimosso, ma se ora scorri fino alla fine di una pagina nel piè di pagina, vedrai il pulsante della guida.

Quando fai clic, vedrai un piccolo pulsante blu con la dicitura Crea ticket di assistenza.

Penso che sia questo il significato.

Mm-hm.

Sì.

Poi vengono visualizzati alcuni menu a discesa in cui puoi porre domande.

In realtà, c'è una serie di menu a discesa che ti porteranno direttamente al numero di telefono, che penso di aver quasi memorizzato, ma è come verificare il tuo account sviluppatore, il secondo menu a discesa è abbastanza simile, riceverai un gruppo di pulsanti di opzione.

Uno di questi è specifico per la verifica del numero di telefono.

E poi magari hai un codice di verifica via SMS o c'è un bug che appare sullo schermo quando provi a eseguire la procedura.

Puoi farlo per la verifica del numero di telefono, ma anche per molte altre domande che potresti avere in merito al tuo account sviluppatore Google Play.

La maggior parte delle volte, Play Console è molto efficace nel mostrare i passaggi successivi per la verifica, quindi basta seguirli e il gioco è fatto.

Fantastico.

Perfetto.

Siamo quasi alla fine, quindi grazie mille per aver partecipato a questo panel.