La crash-free rate è la metrica principale di stabilità dell'app: la percentuale di sessioni (o utenti) che NON hanno subito un crash dell'app. I crash sono eventi UX catastrofici — l'app si chiude forzatamente, l'utente perde lo stato e la fiducia nell'app si erode. Le app con alti tassi di crash perdono utenti per disinstallazione più velocemente di quanto l'acquisizione possa rimpiazzarli, indipendentemente da quanto sia buono il resto del prodotto.
Due varianti
- Sessioni crash-free: percentuale di tutte le sessioni completate senza crash. Usata per il reporting aggregato della stabilità. Metrica lower-bound — se anche una sola sessione crasha per un utente, l'utente "ha visto un crash" anche se le sue altre sessioni sono andate bene.
- Utenti crash-free: percentuale di utenti che non hanno subito NESSUN crash in una finestra definita (tipicamente ultimi 7 o 30 giorni). Soglia più alta — non appena un utente crasha, è "colpito da crash" fino al reset della finestra.
Riporta entrambe; raccontano storie diverse. Le sessioni crash-free sono la metrica operativa quotidiana; gli utenti crash-free sono la metrica dell'esperienza utente.
Benchmark moderni
- App consumer: 99,5%+ è il baseline operativo. Le app di livello superiore operano al 99,9%+.
- App banking / healthcare / ad alto rischio: minimo 99,9%; gli utenti hanno zero tolleranza per l'instabilità nei workflow critici.
- Giochi hyper-casual: 98-99% è più comune (iterazione rapida, meno QA). Trade-off accettabile data la forma del prodotto a sessioni brevi.
- Sotto il 99%: problema serio. Indaga immediatamente, rilascia hotfix ogni giorno fino alla risoluzione.
- Sotto il 97%: esistenziale. Metti in pausa le nuove feature, concentra l'engineering sulla stabilità fino al recupero.
Un tasso di crash dell'1% non è "solo l'1%" — è catastrofico. Se 1 sessione su 100 crasha e l'utente medio ha 5 sessioni alla settimana, circa il 5% degli utenti crasha in qualsiasi settimana, oltre il 20% in un mese. Ogni evento di crash aumenta significativamente la probabilità di disinstallazione — impatto tipico: un tasso di crash dell'1% (99% crash-free) abbassa la retention D7 del 10-20% e aumenta il tasso di disinstallazione D30 del 15-30% rispetto a un baseline del 99,5%+. Numero assoluto piccolo, impatto enorme sul business.
Strumenti per il crash tracking
- Firebase Crashlytics — crash tracking gratuito di Google. Il market leader per adozione (stimato ~70% delle app Android; quota iOS sostanziale). Symbolication degli stack trace, alert in tempo reale, integrazione BigQuery per analisi approfondite.
- Sentry — solido monitoraggio di crash + errori cross-platform con scope più ampio (non solo crash, anche errori non fatali). Popolare tra i team a guida engineering.
- Bugsnag (ora SmartBear) — funzionalità comparabili a Sentry, comune in ambito enterprise.
- Apple App Store Connect / Google Play Console — dashboard di crash native degli store. Usali come verifica incrociata; non fare affidamento solo su questi (dettagli degli stack trace limitati, aggregazione più lenta).
Disciplina di processo: ogni release dovrebbe avere un gate documentato sulla crash-free rate prima del rollout esteso. I rollout graduali (rollout graduale Google Play, rilascio graduale App Store) ti permettono di individuare una regressione di stabilità nell'1-5% degli utenti prima che colpisca il 100%. Imposta una soglia chiara (es. "blocca il rollout se la crash-free rate scende sotto il 99,3% nel primo 1% degli utenti") e rispettala.