Monitoraggio dei crash e delle prestazioni di un'app mobile
Il monitoraggio dei crash fa vedere i guasti prima che gli utenti si lamentino: quali metriche seguire, quali strumenti usare e come dare priorità.
Team rabbitclipPubblicato: 6 min di lettura
In breve
Il monitoraggio dei crash di un'app mobile è una configurazione che, ogni volta che l'app si chiude sul telefono di un utente, raccoglie automaticamente dove è avvenuto il guasto, su quale dispositivo e in quale versione, e lo segnala a lei. Il monitoraggio delle prestazioni misura allo stesso modo i problemi più sfumati: tempo di avvio, scatti e consumo di memoria. Con entrambi vede la salute reale dell'app nelle mani degli utenti. Senza, decide solo in base alle recensioni degli store, e quelle recensioni sono la voce di una piccola parte delle persone che hanno incontrato il problema.
Chi vede crashare la propria app di solito non le scrive. La chiude, riprova una volta, poi la elimina. Un'app che funziona bene sui suoi telefoni di prova può comportarsi diversamente su un dispositivo di tre anni fa o con una connessione debole. Il monitoraggio è l'unico modo per rendere visibile quel gruppo invisibile.
Il monitoraggio dei crash e quello delle prestazioni sono la stessa cosa?
No, rispondono a domande diverse. Il monitoraggio dei crash cattura il momento in cui l'app si chiude: su quale riga di codice, su quale dispositivo, con quale versione del sistema e che cosa stava facendo l'utente in quel momento. Quello delle prestazioni misura ciò che si percepisce male anche quando l'app non si chiude: una schermata lenta, uno scorrimento a scatti, una memoria che si gonfia.
Su Android esiste un terzo tipo di guasto, l'applicazione che non risponde, nota come ANR. L'app non va in crash ma si blocca, e il sistema offre all'utente la possibilità di chiuderla. Una buona configurazione di monitoraggio mostra separatamente questi tre gruppi: crash, mancata risposta e lentezza.
Quali metriche conviene seguire?
Pochi indicatori significativi sono meglio di un muro di grafici. Il primo è il tasso di sessioni senza crash: la probabilità che una sessione termini senza guasti una volta che l'utente ha aperto l'app. Lo confronti tra le versioni; se scende nella nuova versione, questa ha introdotto una regressione.
Il secondo gruppo sono gli indicatori di prestazione. Anche i pannelli degli store offrono i propri dati di salute. Google Play Console e gli strumenti per sviluppatori di Apple mostrano gratuitamente dati su crash e mancata risposta raccolti dagli utenti, e per la maggior parte delle aziende è il punto di partenza.
- Tasso di sessioni senza crash, confrontato versione per versione
- Tempo di avvio a freddo: quanto velocemente si apre l'app quando era completamente chiusa
- Frequenza di fotogrammi lenti e bloccati: la fluidità di scorrimento e transizioni
- Eventi di mancata risposta (ANR) e modelli di dispositivo interessati
Quali strumenti e dati conviene raccogliere?
Esistono servizi già pronti, molto diffusi, per la segnalazione dei crash; Firebase Crashlytics e Sentry sono esempi noti. La scelta dipende dall'infrastruttura che il team già usa e da ciò che deve monitorare. Più del nome dello strumento, fa la differenza la correttezza della configurazione.
La parte della configurazione più spesso saltata è rendere leggibile il rapporto. Il codice di un'app pubblicata è offuscato e privato dei nomi; per rendere leggibile un rapporto di crash, a ogni versione deve caricare sul servizio di monitoraggio i file di simboli e di mappatura corrispondenti. Se non lo fa, il rapporto è un elenco di indirizzi privi di significato e nessuno può dire dove sia il guasto.
I rapporti portano anche un contesto: gli ultimi passaggi dell'utente, il numero di versione, il modello del dispositivo, lo stato della rete. Faccia attenzione che questo contesto non contenga dati personali; nomi, indirizzi e-mail e dati della carta non devono mai entrare in un rapporto. Come i dati personali finiscano nei registri è bene discuterne con un avvocato o con un responsabile della protezione dei dati.
Come si dà priorità ai guasti che arrivano?
Una volta avviato il monitoraggio, la prima settimana produce un elenco di decine di guasti, e inseguirli tutti è impossibile. La priorità poggia su due verifiche: quanti utenti sono coinvolti e in quale punto del loro percorso accade. Un singolo crash durante il pagamento, l'accesso o la registrazione viene prima di uno frequente ma innocuo nella schermata delle impostazioni.
Un guasto che compare con una nuova versione si tratta a parte, perché è una regressione e di solito il tipo più rapido da correggere. Quando possibile, distribuire una nuova versione agli utenti per fasi permette di fermare il rilascio se emerge un problema.
- Numero di utenti coinvolti e frequenza con cui si ripete
- Il momento in cui avviene: prima pagamento, accesso e registrazione
- Se è iniziato con la nuova versione, cioè se è una regressione
- Il gruppo di dispositivo e versione del sistema interessato
Quali errori sono comuni nel monitoraggio di crash e prestazioni?
L'errore più comune è configurare il monitoraggio dopo il lancio, così la prima ondata di crash passa inosservata. Il secondo è raccogliere rapporti che nessuno legge. Una persona o un ruolo deve esaminare regolarmente i guasti e sorvegliare da vicino i primi giorni dopo ogni versione.
Il terzo è testare solo sui telefoni più recenti. La base reale di utenti comprende dispositivi più vecchi e connessioni lente, ed è lì che i problemi di prestazione tendono a emergere.
- Configurare il monitoraggio dopo il lancio
- Non caricare i file di simboli e di mappatura, lasciando i rapporti illeggibili
- Raccogliere rapporti senza che nessuno li esamini con regolarità
- Scrivere dati personali nei rapporti o nei registri
Quando il monitoraggio delle prestazioni è inutile o prematuro?
Per un'app non ancora lanciata e senza utenti, un pannello dettagliato delle prestazioni è prematuro; non ci sono dati da interpretare. In quella fase basta configurare la segnalazione dei crash, perché dai primi utenti reali offre una protezione quasi gratuita che richiede poca manutenzione.
Una struttura di monitoraggio complessa è superflua anche per una semplice app aziendale, con pochi utenti e aperta di rado; i dati di salute gratuiti nei pannelli degli store possono bastare. Il criterio è questo: se il monitoraggio non cambia una decisione che lei prenderebbe, è di troppo.
Il monitoraggio di crash e prestazioni è il modo per vedere l'app come gli utenti la vivono davvero, mentre le recensioni degli store mostrano solo la parte più rumorosa del problema. Configuri il monitoraggio prima del lancio, carichi a ogni versione i file che mantengono leggibili i rapporti, esamini con regolarità poche metriche significative e ordini i guasti in base a quanti utenti coinvolgono. Se desidera un aiuto per capire come monitorare la salute della sua app, può fissare un colloquio di scoperta con rabbitclip.
Domande frequenti
Che cos'è il tasso di sessioni senza crash?
È la quota di sessioni che vanno dall'avvio dell'app alla sua chiusura senza un crash. Confrontato tra le versioni, offre una lettura rapida della stabilità di una nuova versione.
Devo usare uno strumento già pronto per il monitoraggio dei crash?
Per la maggior parte delle aziende, sì. Servizi molto diffusi come Firebase Crashlytics e Sentry offrono una soluzione pronta, e costruirne una propria raramente aggiunge valore. La vera differenza sta nel configurarla correttamente e caricare i file di simboli.
I pannelli degli store bastano da soli?
Spesso bastano per cominciare, perché mostrano gratuitamente dati su crash e mancata risposta. Per vedere dove e in quale passaggio avviene un guasto, e per confrontare le versioni, di solito serve uno strumento di monitoraggio separato.
I dati di monitoraggio contano come dati personali?
Possono, se un rapporto include informazioni che identificano l'utente. Faccia attenzione a non aggiungere ai rapporti nomi, indirizzi e-mail o dati di pagamento, e chieda a un avvocato quale sia la posizione legale della sua app.
