Die Crash-Free Rate ist die zentrale App-Stabilitätskennzahl: der Prozentsatz der Sessions (oder Nutzer), bei denen KEIN App-Absturz aufgetreten ist. Abstürze sind katastrophale UX-Ereignisse — die App bricht ab, der Nutzer verliert seinen Zustand und das Vertrauen in die App erodiert. Apps mit hohen Absturzraten verlieren Nutzer durch Deinstallationen schneller, als die Akquisition sie ersetzen kann, egal wie gut der Rest des Produkts ist.
Zwei Varianten
- Crash-Free Sessions: Prozentsatz aller Sessions, die ohne Absturz abgeschlossen wurden. Für aggregiertes Stabilitätsreporting verwendet. Untergrenz-Metrik — wenn eine einzelne Session für einen Nutzer abstürzt, hat er "einen Absturz erlebt", obwohl seine anderen Sessions problemlos sein könnten.
- Crash-Free Users: Prozentsatz der Nutzer, die in einem definierten Zeitfenster (typischerweise letzte 7 oder 30 Tage) KEINEN Absturz erlebt haben. Strengere Messlatte — sobald ein Nutzer einen Absturz hat, gilt er als "absturz-betroffen", bis das Fenster zurückgesetzt wird.
Beide reporten; sie erzählen unterschiedliche Geschichten. Crash-Free Sessions ist die tägliche operative Kennzahl; Crash-Free Users ist die User-Experience-Kennzahl.
Moderne Benchmarks
- Consumer-Apps: 99,5 %+ Crash-Free Rate ist die operative Baseline. Erstklassige Apps laufen mit 99,9 %+.
- Banking / Healthcare / unternehmenskritische Apps: mindestens 99,9 %; Nutzer haben null Toleranz für Instabilität in kritischen Workflows.
- Hyper-Casual-Games: 98–99 % sind häufiger (schnelle Iteration, weniger QA). Akzeptabler Kompromiss angesichts der kurzsessionigen Produktform.
- Unter 99 %: ernstes Problem. Sofort untersuchen, täglich Hotfixes ausliefern bis behoben.
- Unter 97 %: existenzbedrohend. Neue Features pausieren, Engineering auf Stabilität fokussieren bis zur Erholung.
Eine 1 %-Crash-Rate ist nicht "nur 1 %" — sie ist katastrophal. Wenn 1 von 100 Sessions abstürzt und der durchschnittliche Nutzer 5 Sessions pro Woche hat, erleben rund 5 % der Nutzer in jeder Woche einen Absturz, über 20 % innerhalb eines Monats. Jedes Absturzereignis erhöht die Deinstallationswahrscheinlichkeit merklich — typische Auswirkung: Eine 1 %-Crash-Rate (99 % Crash-Free) senkt die D7-Retention um 10–20 % und erhöht die D30-Deinstallationsrate um 15–30 % gegenüber einer 99,5 %-Baseline. Kleine absolute Zahl, riesige geschäftliche Auswirkung.
Crash-Tracking-Tools
- Firebase Crashlytics — Googles kostenloses Crash-Tracking. Der Adoptions-Marktführer (geschätzt ~70 % der Android-Apps; erheblicher iOS-Anteil). Starke Stack-Trace-Symbolisierung, Echtzeit-Alerts, BigQuery-Integration für tiefere Analysen.
- Sentry — starkes Cross-Platform-Crash- + Error-Monitoring mit breiterem Scope (nicht nur Abstürze, auch nicht-fatale Fehler). Beliebt bei engineering-geführten Teams.
- Bugsnag (jetzt SmartBear) — funktional vergleichbar mit Sentry, im Enterprise-Bereich verbreitet.
- Apple App Store Connect / Google Play Console — native Crash-Dashboards der Stores selbst. Als Gegenkontrolle nutzen; nicht allein darauf verlassen (begrenzte Stack-Trace-Details, langsamere Aggregation).
Prozess-Disziplin: Jedes Release sollte vor dem breiten Rollout ein dokumentiertes Crash-Free-Rate-Gate haben. Phasenweise Rollouts (Google Play Staged Rollout, App Store Phased Release) ermöglichen es, eine Stabilitätsregression bei 1–5 % der Nutzer abzufangen, bevor sie 100 % betrifft. Einen klaren Schwellenwert festlegen (z. B. "Rollout stoppen, wenn die Crash-Free Rate bei den ersten 1 % der Nutzer unter 99,3 % fällt") und daran festhalten.