Tenere in ordine la conformità di dieci app

Un’app è una checklist. Dieci app sono un sistema, e il modo in cui le cose vanno storte cambia: nulla è difficile, ma qualcosa è sempre un po’ non aggiornato, e lo scopri da un rifiuto sull’app che hai toccato meno di recente.

Cosa deve essere per singola app

Non negoziabile, perché ogni app ha la propria scheda dello store e il proprio comportamento sui dati:

• La privacy policy. Insiemi di SDK diversi significano informative diverse. Una policy condivisa che copre “le nostre app” è il classico errore di chi gestisce più app: vedi sotto.
• La pagina di eliminazione dell’account, e un percorso che arrivi a te, per ogni app.
• Le dichiarazioni Data safety e App Privacy. Compilate per ogni scheda, a partire dall’elenco delle dipendenze di quella specifica app.
• app-ads.txt, se l’app mostra annunci: viene individuato tramite il sito web indicato nella scheda di quella app.
• Gli URL stessi, perché ogni scheda ha i propri campi.

Cosa si può davvero condividere

• Il modello. Una struttura per ogni privacy policy, una per i termini, compilate per ogni app.
• Lo schema di hostname. Un indirizzo prevedibile per ogni app è meglio di una cartella di URL improvvisati.
• L’indirizzo di supporto, se una sola casella serve davvero tutte le app.
• Ciò che sai sugli SDK. Ciò che raccolgono Crashlytics o AdMob è lo stesso fatto in ogni app; cambia solo quali app li includono.
• Il processo: la checklist di rilascio, la cadenza delle revisioni, il registro descritto sotto.

I due errori tipici di chi gestisce più app

Una sola policy per tutte le app. È il risparmio più ovvio e fallisce in entrambe le direzioni: la policy elenca dati che la piccola app di utilità non tocca mai, e tralascia qualcosa che l’app più recente ha aggiunto il mese scorso. Entrambe sono incongruenze con un modulo Data safety che hai compilato onestamente, e un revisore che confronta i due vede una policy che non parla di questa app.

Una casella condivisa per le richieste di eliminazione, senza attribuzione. Arrivano richieste che dicono “per favore eliminate il mio account” senza indicare quale delle tue dieci app intendono. Non puoi dare seguito a ciò che non riesci a identificare, e il tempo previsto dal GDPR scorre mentre lo capisci. Instrada le richieste di ogni app in modo che l’app sia evidente dalla notifica.

Il registro

Ciò che rende gestibile un portafoglio di app è un’unica tabella che mantieni davvero: un foglio di calcolo va benissimo. Una riga per app, e queste colonne:

Colonna	Perché
Nome dell’app, bundle / application id	Identità
Store in cui è pubblicata	Determina quante console aggiornare
URL della privacy policy	Quello che incolli e reincolli
URL di eliminazione dell’account	Idem
Indirizzo / pagina di supporto	Idem
Sito web dello sviluppatore dichiarato	Dove viene cercato app-ads.txt
Mostra annunci?	Se app-ads.txt si applica
Ha account?	Se l’eliminazione si applica
SDK principali	L’elenco delle dipendenze, in sintesi
Ultima revisione della policy	La data che ti dice cosa è obsoleto

L’ultima colonna è quella che si guadagna il posto. Entrambi gli store richiedono che le dichiarazioni restino accurate (non solo che lo fossero al lancio), e “ultima revisione” è il modo per trovare le tre app che si sono discostate senza rileggerle tutte e dieci.

Una cadenza che funziona

• A ogni rilascio, per ogni app: è cambiata qualche dipendenza? Se sì, ricontrolla la policy di quell’app ed entrambi i moduli sui dati. Mettilo nella checklist di rilascio, non nella tua memoria.
• Ogni trimestre, su tutto il portafoglio: apri il registro, ordina per “ultima revisione”, controlla le più vecchie. Verifica che ogni URL restituisca ancora 200 senza aver effettuato l’accesso.
• Ogni volta che un URL si sposta: aggiorna ogni console per ogni app interessata, e mantieni il vecchio indirizzo con un redirect. Con dieci app è il cambiamento che più probabilmente viene fatto per nove decimi.

Uno script di dieci righe che esegue curl su ogni URL del registro e segnala quelli che non restituiscono 200 è il lavoro di un pomeriggio, e intercetta l’errore che succede davvero: un hosting che è sparito in silenzio.

Cosa fa AppFoyer

Ogni app è un’app a sé: il proprio sottodominio, le proprie cinque pagine, il proprio app-ads.txt, i propri canali di notifica, la propria checklist. Non c’è una policy condivisa da sbagliare, e le richieste di eliminazione di ogni app arrivano identificate per app.

La checklist della dashboard è la metà dal vivo del registro: per ogni app, dice quale campo dello store è ancora vuoto e perché conta, così “cosa è obsoleto” è una schermata e non una colonna di un foglio di calcolo che ti sei dimenticato di aggiornare. I piani differiscono per quante app puoi pubblicare: una con Free, dieci con Pro, cinquanta con Advanced.

Siamo onesti sui limiti di tutto questo: la modifica in blocco e i gruppi di app non esistono ancora. Aggiungere oggi una riga di rete pubblicitaria a quindici app significa quindici modifiche. Quel lavoro è pianificato e non è stato rilasciato, e una pagina che ti vende uno strumento per gestire più app dovrebbe dire quale parte è reale.

Le fonti ufficiali

• Provide information for Google Play’s Data safety section — Guida di Google Play Console, sul mantenere accurate le dichiarazioni
• App privacy details on the App Store — Apple, sul mantenere aggiornate le risposte
• Set up app-ads.txt — Guida di AdMob