Absturzrate Ihrer App zu hoch? Crashlytics und Google Play Grenzwerte

Stellen Sie sich eine Kundin vor, die Ihre App öffnet, den Warenkorb füllt und an der Kasse plötzlich auf dem Startbildschirm landet. Diese Person versucht es daher selten ein zweites Mal. Zudem hinterlässt sie womöglich eine schlechte Bewertung. Deshalb empfehlen wir, Abstürze nicht nur als Ticket zu sehen, sondern als verlorenen Umsatz und verlorenes Vertrauen.

Wir, Talha Aslan und Team, betrachten die ersten Wochen nach einem Release als die heikelste Phase jedes mobilen Projekts. Dieser Leitfaden erklärt die Grenzwerte bei Google Play, den Umgang von Apple mit Abstürzen, die Überwachung mit Crashlytics, die richtige Priorisierung und eine Checkliste für die Zeit nach dem Release.

Worin unterscheiden sich Absturz, ANR und Hänger?

Ein Absturz (Crash) bedeutet, dass die App wegen eines unerwarteten Fehlers sofort schließt. Der Nutzer sieht dann, wie die App verschwindet, und landet wieder auf dem Startbildschirm. Zum Beispiel kann eine Codezeile, die einen fehlenden Wert aus einer Serverantwort liest, die gesamte App beenden.

ANR steht für "Application Not Responding" und betrifft nur Android. Laut der Android Entwicklerdokumentation tritt ein ANR auf, wenn der UI Thread einer App zu lange blockiert bleibt. Der Nutzer sieht also einen eingefrorenen Bildschirm, der nicht auf Berührungen reagiert.

Ein Hänger (Hang) ist der allgemeinere Begriff, den Sie auch unter iOS finden. Er beschreibt eine Oberfläche, die eine Weile nicht reagiert. Aus Sicht des Nutzers ist der Unterschied allerdings gering, denn in allen drei Fällen kann er seine Aufgabe nicht abschließen.

• Absturz: Die App schließt, und der Nutzer muss von vorne beginnen.
• ANR: Die App bleibt offen, friert aber ein; das System bietet Warten oder Schließen an.
• Nicht fataler Fehler: Die App läuft weiter, aber eine Aktion schlägt still fehl.

Bei der Qualitätsbewertung der Stores zählen also Absturzrate und ANR Rate am meisten. Nicht fatale Fehler fließen nicht in die Grenzwerte ein. Trotzdem stören sie das Nutzererlebnis, daher sollten Sie diese ebenfalls verfolgen.

Welche Absturzrate gilt bei Google Play als zu hoch?

Google veröffentlicht zwei getrennte Grenzwerte für schlechtes Verhalten (Bad Behavior Thresholds): einen Gesamtwert und einen Wert pro Gerät. Die folgenden Zahlen stammen von der Android vitals Seite bei Android Developers, Stand zum Zeitpunkt dieses Beitrags. Google kann sie allerdings ändern; prüfen Sie den aktuellen Wert deshalb immer auf der offiziellen Seite.

Der Gesamtgrenzwert betrachtet den Anteil der täglich aktiven Nutzer über alle Gerätemodelle, die einen Absturz erlebt haben. Der Grenzwert pro Gerät betrachtet dagegen jedes Smartphonemodell einzeln. Das heißt: Ihre App kann im Durchschnitt gesund wirken und trotzdem auf einem bestimmten Modell die Grenze überschreiten.

Für Smartwatch Apps nennt Google zudem eigene, strengere Werte. Außerdem gelten die Grenzwerte nur für Abstürze, die der Nutzer wahrnimmt. Abstürze im Hintergrund zählen nicht mit, mit Ausnahme von Wear OS.

Was passiert, wenn Ihre App einen Grenzwert überschreitet?

Laut der Android vitals Seite kann Play die Sichtbarkeit Ihres Titels verringern, wenn Ihre App einen Grenzwert überschreitet. Zudem kann Play Nutzern einen Warnhinweis auf Ihrem Store Eintrag anzeigen. Beide Folgen schaden also gleichzeitig der Auffindbarkeit und der Installationsentscheidung.

Konkret hängt die Wirkung davon ab, welchen Grenzwert Ihre Absturzrate überschreitet. Laut der Absturzseite von Google ist eine App über dem Gesamtgrenzwert wahrscheinlich auf allen Geräten schlechter auffindbar. Eine App über dem Grenzwert pro Gerät ist auf diesen Geräten schlechter auffindbar, und ihr Eintrag kann eine Warnung zeigen.

• Bewertungszeitraum: Play nutzt die Daten der letzten 28 Tage und prüft Ihre Kennzahlen täglich anhand dieses 28 Tage Durchschnitts.
• Neue Probleme: Android vitals markiert Absturz und ANR Probleme, die Geräte länger als 7 Tage betreffen, und gibt Ihnen 21 Tage für die Behebung.
• Erholung: Sobald sich der Durchschnitt verbessert, verschwinden die Warnungen in Android vitals; Warnungen im Store Eintrag können schneller verschwinden, wenn Play die Verbesserung erkennt.

Die Lehre daraus ist einfach. Am Tag des Bugfixes sehen Sie noch kein Ergebnis. Stattdessen erholt sich der Durchschnitt, während sich die neue Version im 28 Tage Fenster verbreitet. Daher kostet frühes Erkennen deutlich weniger als spätes Reparieren.

Wie geht der App Store mit abstürzenden Apps um?

Apple veröffentlicht keinen öffentlichen Prozentwert wie Google Play. Stattdessen behandelt Apple Abstürze in der Prüfung. Richtlinie 2.1 der App Store Review Guidelines verlangt, dass Sie Ihre App vor dem Einreichen auf einem echten Gerät auf Fehler und Stabilität testen. Dieselbe Richtlinie sagt klar, dass Apple Builds ablehnt, die abstürzen oder offensichtliche technische Probleme zeigen.

Unter iOS liegt das Risiko also vor allem vor dem Start. Stürzt die App beim Prüfer schon auf dem Anmeldebildschirm ab, lehnt Apple den Build ab, und Ihr Termin verschiebt sich. Die häufigsten Gründe haben wir in unserem Beitrag warum Apps abgelehnt werden gesammelt.

Der Designteil der Richtlinien hält außerdem fest, dass Apple Apps, die nicht mehr funktionieren oder ein verschlechtertes Erlebnis bieten, jederzeit entfernen kann. Somit ist die Überwachung nach dem Start auch unter iOS keine Option, sondern Pflicht.

Bei Apple verfolgen Sie Absturzdaten im Fenster Organizer in Xcode. Laut der Apple Dokumentation zu Absturzberichten zeigt es Berichte von Kunden, die dem Teilen von Diagnosedaten zugestimmt haben. TestFlight Tester teilen Absturzberichte dagegen unabhängig von dieser Geräteeinstellung.

Wie berechnet Google die wahrgenommene Absturzrate?

Die Absturzseite von Google definiert die vom Nutzer wahrgenommene Absturzrate als Prozentsatz der täglich aktiven Nutzer, die während der aktiven Nutzung mindestens einen Absturz erlebt haben. Als aktiv gilt eine App, wenn sie eine Activity anzeigt oder einen Vordergrunddienst ausführt.

Zunächst ist dabei die Definition des täglich aktiven Nutzers wichtig. Öffnet eine Person Ihre App am selben Tag auf zwei Geräten, zählt jedes Gerät als eigener Nutzer. Teilen sich dagegen mehrere Personen ein Gerät, zählt dieses Gerät als ein aktiver Nutzer.

Außerdem misst Android vitals pro täglich aktivem Nutzer und nicht pro Sitzung. Google nennt dazu ein anschauliches Beispiel: Ein Nutzer öffnet an einem Tag drei Sitzungen, und eine davon stürzt ab. Android vitals zeigt dann 100 %, ein sitzungsbasiertes Tool dagegen eventuell 33 %.

Beispielrechnung: Nehmen Sie eine App mit 20.000 aktiven Geräten an einem Tag. Erleben 160 davon mindestens einen Absturz, liegt die Tagesrate bei 160 / 20.000 = 0,8 %. Das liegt unter dem Gesamtgrenzwert. Entfallen aber 120 dieser Abstürze auf ein einziges Modell mit 1.000 aktiven Nutzern, liegt dessen Absturzrate bei 12 %. Damit überschreitet Ihre App den Grenzwert pro Gerät.

Das Beispiel zeigt, warum der Gesamtdurchschnitt allein nicht genügt. Deshalb empfehlen wir, die Geräteaufschlüsselung in der Play Console jede Woche zu öffnen.

Was ist Crashlytics und wofür nutzen Sie es?

Firebase Crashlytics ist das Werkzeug für Absturzberichte in Echtzeit auf der Firebase Plattform von Google. Laut der Firebase Dokumentation unterstützt es iOS, Android, Android NDK, Flutter und Unity. Stürzt Ihre App ab, sendet es den Stacktrace und Geräteinformationen an das Dashboard. Ein Stacktrace ist die Liste der Codezeilen, die zum Fehler geführt haben.

Die größte Stärke ist vor allem die Gruppierung. Crashlytics bündelt tausende Abstürze mit derselben Ursache zu einem Problem (Issue) und wertet dafür Stackframes, Fehlermeldungen und Fehlercodes aus. Folglich arbeiten Sie einige Dutzend Probleme ab statt tausender Einzelberichte.

• Warnungen in Echtzeit: Sie erhalten Hinweise zu neuen, wiederkehrenden und wachsenden Problemen.
• Varianten: Sie unterscheiden verschiedene Ursachen innerhalb desselben Problems.
• Nicht fatale Fehler: Sie können auch Fehler erfassen, die eine Aktion stören, ohne die App zu schließen.
• Eigene Schlüssel und Logs: Sie hängen den Zustand der App kurz vor dem Absturz an.

Android vitals und Crashlytics sind keine Konkurrenten. Android vitals zeigt, wie der Store Ihre App sieht; Crashlytics liefert dagegen die Details, die Sie zur Fehlersuche brauchen. Zudem bietet Crashlytics dasselbe Dashboard für iOS, sodass Sie beide Plattformen an einem Ort beobachten.

Welche Schritte braucht die Einrichtung von Crashlytics?

Die technischen Details hängen von Ihrer Technologie ab. Native Android Apps, native iOS Apps, Flutter und React Native folgen jeweils etwas anderen Schritten. Der grobe Ablauf ist allerdings überall ähnlich:

1. Legen Sie in der Firebase Konsole ein Projekt an und registrieren Sie dort Ihre Android App und Ihre iOS App.
2. Fügen Sie die Konfigurationsdatei der Plattform hinzu und nehmen Sie das Crashlytics Paket in die Abhängigkeiten auf.
3. Richten Sie den automatischen Upload der Symboldateien beim Build ein: die Mappingdatei unter Android und die dSYM Datei unter iOS.
4. Lösen Sie in einem Testbuild bewusst einen Testabsturz aus und prüfen Sie, ob der Bericht im Dashboard ankommt.
5. Aktualisieren Sie Datenschutzerklärung und Einstellungen zur Datenerhebung; aktivieren Sie bei Bedarf die einwilligungsbasierte Berichterstattung.
6. Leiten Sie Warnungen in einen Kanal, den Ihr Team tatsächlich liest.

Überspringen Sie also Schritt vier nicht. Viele Teams halten die Einrichtung für abgeschlossen und stoßen dann beim ersten echten Absturz auf einen unlesbaren Stacktrace, weil die Symboldateien fehlen. Den allgemeinen Testansatz beschreibt unsere Checkliste für Tests vor dem Livegang; die Logik gilt auch für mobile Releases.

Was sagen absturzfreie Nutzer und absturzfreie Sitzungen aus?

Im Crashlytics Dashboard sehen Sie zwei zentrale Werte. Laut der Firebase Seite zu absturzfreien Kennzahlen beschreibt der Anteil absturzfreier Nutzer, wie viele Nutzer die App im gewählten Zeitraum ohne Absturz verwendet haben. Absturzfreie Sitzungen sind der Anteil der Sitzungen, die nicht mit einem Absturz endeten.

Firebase berechnet beide Werte als Summe über den Zeitraum und nicht als Durchschnitt. Daher rät Firebase davon ab, unterschiedlich lange Zeiträume zu vergleichen, denn längere Zeiträume liefern meist niedrigere Werte. Zum Beispiel führt der Vergleich eines 7 Tage Werts mit einem 30 Tage Wert leicht zu falschen Schlüssen.

Zwei weitere Punkte verdienen Aufmerksamkeit. Erstens berücksichtigen diese Werte nur fatale Ereignisse; filtern Sie das Dashboard auf nicht fatale Fehler oder ANRs, bleiben die Diagramme leer. Zweitens stammen die Daten bei einwilligungsbasierter Berichterstattung nur von zustimmenden Nutzern und bilden Ihr Publikum dann eventuell nicht vollständig ab.

Ist die Absturzrate also dasselbe wie der Anteil absturzfreier Nutzer? Nicht ganz. Android vitals arbeitet mit eigener Definition von täglich aktiven Nutzern und aktiver Nutzung, Crashlytics mit eigener Nutzer und Sitzungslogik. Somit stimmen die Zahlen beider Dashboards selten exakt überein.

Wie unterscheiden sich Android vitals, Crashlytics und Xcode Organizer?

Konkret beantwortet jedes Werkzeug eine andere Frage. Wer das weiß, beendet die Diskussion im Team, welche Zahl gerade gilt. Die Tabelle fasst den Vergleich auf Basis der offiziellen Dokumentation zusammen:

In der Praxis empfehlen wir, alle drei gemeinsam zu nutzen. Android vitals warnt vor dem Risiko im Store, Crashlytics zeigt die Ursache, und Organizer liefert unter iOS die Daten von Apple selbst.

Welchen Absturz sollten Sie zuerst beheben?

Sie können nicht alle Abstürze gleichzeitig beheben, also brauchen Sie eine klare Reihenfolge. Die Empfehlung von Google in Android vitals ist eindeutig: Beheben Sie zuerst die Abstürze und ANRs, die die meisten Nutzer betreffen. Für bessere Qualität auf bestimmten Geräten nehmen Sie sich die größten Gruppen auf diesen Geräten vor. Bei beiden Problemen konzentrieren Sie sich zunächst auf die größten Gesamtcluster.

Zudem ergänzen wir diese Empfehlung um die geschäftliche Wirkung. Betreffen zwei Fehler gleich viele Nutzer, hat der Fehler an der Kasse immer Vorrang vor dem in den Einstellungen.

1. Betroffene Nutzer: Zählen Sie die Zahl der verschiedenen betroffenen Nutzer, nicht die Gesamtzahl der Abstürze.
2. Nähe zum Grenzwert: Ein Problem, das ein Smartphonemodell an den Grenzwert pro Gerät heranführt, gefährdet die Sichtbarkeit.
3. Kritische Abläufe: Stellen Sie Abstürze bei Anmeldung, Registrierung, Warenkorb und Kasse nach vorne.
4. Neu oder zurückgekehrt: Ein Problem aus der neuesten Version hängt meist mit der letzten Änderung zusammen und lässt sich deshalb oft schnell lösen.
5. Wachstumstempo: Ein täglich wachsendes Problem kann dringender sein als ein großes, das stabil bleibt.

Wiederholen Sie diese Rangfolge nach jedem Release. So investiert Ihr Team Zeit in den Fehler mit dem größten Schaden und nicht in den lautesten.

Wie machen Sie einen unlesbaren Stacktrace lesbar?

Buildwerkzeuge verkleinern und verschleiern den Code in Releasebuilds meist. Unter Android werden Klassen und Methodennamen dadurch zu kurzen Buchstaben. Unter iOS enthalten Absturzberichte dagegen rohe Speicheradressen. Ohne Zuordnungsdaten besteht Ihr Stacktrace also aus sinnlosen Zeilen wie "a.b.c".

Die Lösung: Bewahren Sie die Symboldatei jedes Builds auf und laden Sie sie in das passende Werkzeug. Unter Android geben Sie die Mappingdatei sowohl der Play Console als auch Crashlytics. Unter iOS übersetzt die dSYM Datei Adressen in Funktionsnamen und Zeilennummern.

• Binden Sie den Symbolupload an Ihre Buildpipeline, statt sich auf manuelle Uploads zu verlassen.
• Archivieren Sie die Symboldatei für jede Versionsnummer, denn Abstürze alter Versionen kommen oft noch Monate später.
• Prüfen Sie bei plattformübergreifenden Frameworks wie Flutter oder React Native die Symbole der nativen Schicht und des Frameworks getrennt.

Ein unlesbarer Stacktrace kostet Ihr Team Stunden voller Raterei, und die Absturzrate sinkt in dieser Zeit nicht. Machen Sie den Symbolupload daher zum Pflichtpunkt Ihrer Einrichtungscheckliste.

Warum sind eigene Schlüssel, Logs und Breadcrumbs wichtig?

Ein Stacktrace zeigt, wo der Fehler passiert ist, aber nicht immer warum. Laut der Firebase Anleitung zum Anpassen von Absturzberichten können Sie Crashlytics eigene Schlüssel, eigene Lognachrichten und eine Nutzerkennung hinzufügen. Breadcrumbs zeigen außerdem die Interaktionen, die zum Absturz geführt haben.

Schlüssel wie "gewählte Sprache", "Artikel im Warenkorb" oder "aktive Zahlungsart" zeigen zum Beispiel schnell, dass ein Fehler nur unter einer Bedingung auftritt. Dadurch dauert das Nachstellen nur Minuten statt Tage.

Achten Sie allerdings auf die Grenze zum Datenschutz. Schreiben Sie keine Namen, Telefonnummern, E-Mail Adressen oder Kartendaten in Absturzberichte. Brauchen Sie eine Nutzerkennung, verwenden Sie eine anonyme Kennung aus Ihrem eigenen System. Halten Sie außerdem die Datenerhebung im Einklang mit Ihrer Datenschutzerklärung und den Datenschutzangaben der Stores. Dies ist keine Rechtsberatung; besprechen Sie Ihre Datenverarbeitung mit Ihrer Rechtsberatung.

Denken Sie schließlich an Fehler auf der Serverseite. Oft ist die eigentliche Ursache eines Absturzes eine Serverantwort in unerwarteter Form. Diesen Zusammenhang erklären wir im Beitrag was eine API ist.

Was sind die häufigsten Ursachen für Abstürze?

Jedes Projekt hat sein eigenes Fehlerprofil. Dennoch ähneln sich die Muster, die wir in der Praxis am häufigsten sehen. Die folgende Liste ist keine Statistik, sondern eine Startcheckliste aus unserer Praxiserfahrung:

• Leere oder unerwartete Daten: Der Server liefert ein fehlendes Feld, und der Code rechnet nicht damit.
• Speicherdruck: Große Bilder ohne Verkleinerung beenden die App auf Geräten mit wenig Arbeitsspeicher.
• Fehler im Lebenszyklus: Eine späte Antwort will einen Bildschirm aktualisieren, den der Nutzer bereits geschlossen hat.
• Berechtigungen und Systemversionen: Eine neue Betriebssystemversion ändert das Verhalten von Berechtigungen und bricht älteren Code.
• Bibliotheken von Drittanbietern: Ein veraltetes SDK funktioniert mit einer neuen Systemversion nicht mehr.
• Gerätevielfalt: Die Softwareschicht eines Herstellers verursacht Abstürze nur auf dessen Modellen.

Der letzte Punkt erklärt, warum der Grenzwert pro Gerät so wichtig ist. Gerade unter Android mit hunderten Modellen sollten Sie Ihre Testgeräte nach der echten Verteilung Ihrer Nutzer auswählen.

Wie senken Sie die ANR Rate?

Laut der ANR Seite von Google zählen derzeit nur ANRs vom Typ "Input dispatching timed out" als vom Nutzer wahrgenommen. Dieser Wert steigt also, wenn Ihre App nicht rechtzeitig auf eine Berührung reagiert. Solche ANRs passieren immer während der aktiven Nutzung und stören deshalb am stärksten.

Gemeinsam ist allen ANRs ein Hauptthread, der zu lange beschäftigt ist. Prüfen Sie daher zuerst, welche Arbeit außer dem Zeichnen der Oberfläche auf dem Hauptthread läuft.

• Verlagern Sie Netzwerkaufrufe sowie Lese und Schreibzugriffe auf Dateien in Hintergrundthreads.
• Reduzieren Sie die Arbeit beim App Start und verschieben Sie alles Optionale.
• Laden Sie lange Listen und Bilder schrittweise.
• Prüfen Sie gemeinsam genutzte Ressourcen, die Wartezeiten durch Sperren verursachen.

Caching senkt das ANR Risiko ebenfalls, weil Sie dieselben Daten nicht immer wieder neu berechnen. Die serverseitige Seite des Themas erklärt unser Leitfaden Caching erklärt.

Wie senkt ein gestaffelter Rollout das Absturzrisiko?

Ein gestaffelter Rollout bedeutet, dass Sie eine neue Version zuerst nur einem kleinen Teil der Nutzer ausliefern. Google Play nennt das Staged Rollout, App Store Connect spricht von Phased Release. So erreicht ein Absturz in der neuen Version nur eine kleine Gruppe statt aller Nutzer.

Der Wert liegt vor allem im Entscheidungspunkt, denn Sie sehen die Absturzrate der neuen Version früh. Während die neue Version bei einer kleinen Gruppe läuft, beobachten Sie in Crashlytics neue Probleme und die Entwicklung des Anteils absturzfreier Nutzer. Sieht es schlechter aus als erwartet, pausieren Sie den Rollout, bereiten die Korrektur vor und machen dann weiter.

Beispielszenario: Eine E-Commerce App führt eine neue Kasse per gestaffeltem Rollout ein. Am ersten Tag zeigt Crashlytics ein neues Problem an der Kasse für eine bestimmte Androidversion. Das Team pausiert den Rollout und nimmt die Korrektur in den nächsten Build. Somit schließt sich das Problem, bevor es die meisten Nutzer erreicht, und der 28 Tage Durchschnitt bleibt weitgehend stabil.

Nutzen Sie außerdem interne Testkanäle vor jedem öffentlichen Rollout. Die Rolle der Testautomatisierung in diesem Prozess beschreiben wir im Beitrag was ein Testautomatisierer macht.

Ist die Absturzüberwachung bei plattformübergreifenden Apps anders?

Apps mit Flutter oder React Native haben zwei Schichten: den Frameworkcode und darunter die native Android und iOS Schicht. Ein Absturz kann also aus zwei verschiedenen Quellen stammen. Crashlytics unterstützt Flutter offiziell; trotzdem sollten Sie die Fehlererfassung in jeder Schicht einzeln prüfen.

Ein nicht abgefangener Fehler in der Dart oder JavaScript Schicht kann zum Beispiel einen leeren Bildschirm hinterlassen, ohne die App zu schließen. Der Nutzer erlebt das wie einen Absturz, die Kennzahlen im Store zählen es aber eventuell nicht als solchen. Deshalb empfehlen wir, Fehler auf Frameworkebene als nicht fatale Ereignisse zu melden.

Denken Sie zudem daran, dass sich mit einem Frameworkupdate auch native Abhängigkeiten ändern. Liefern Sie das erste Release nach einem solchen Update daher gestaffelt aus und beobachten Sie die Geräteaufschlüsselung genau.

Checkliste zur Überwachung nach dem Release

Die ersten Tage nach dem Start einer neuen Version sind für die Absturzrate am kritischsten. Die folgende Liste können Sie bei jedem Release wiederverwenden:

1. Erste Stunden: Prüfen Sie in Crashlytics die Probleme und Warnungen der neuen Version.
2. Tag eins: Vergleichen Sie den Anteil absturzfreier Nutzer mit der Vorversion über einen gleich langen Zeitraum.
3. Tag zwei und drei: Öffnen Sie die Geräteaufschlüsselung in Android vitals und suchen Sie nach einem Modell mit steigender Rate.
4. Ende der ersten Woche: Sehen Sie sich nicht fatale Fehler und die ANR Liste an.
5. Wöchentlich: Lesen Sie Bewertungen im Store und ordnen Sie Beschwerden wie "schließt sich" oder "friert ein" Ihrer Absturzliste zu.
6. Monatlich: Prüfen Sie die Versionen der Drittanbieter SDKs und Änderungen bei den Anforderungen an das Zielsystem.
7. Bei jedem Release: Bestätigen Sie, dass die Symboldateien hochgeladen sind.

Die Liste wirkt lang, passt aber als Routine in eine kurze wöchentliche Runde, in der Sie die Absturzrate gemeinsam prüfen. Entscheidend ist, dass eine Person klar die Verantwortung dafür trägt.

Halten Sie außerdem das Ergebnis jeder Prüfung in einer kurzen Notiz fest. Schon eine Zeile wie "Version 3.2, Tag eins, keine neuen Probleme" hilft Ihnen Monate später herauszufinden, wann eine Verschlechterung begann.

Wie wirkt sich die Absturzrate auf Bewertungen und das Entfernungsrisiko aus?

Eine abstürzende App fällt meist zuerst in den Bewertungen auf, oft bevor jemand im Team die Absturzrate im Dashboard prüft. Nutzer schreiben "öffnet nicht" oder "schließt an der Kasse", und die Bewertung sinkt. Eine schlechtere Bewertung drückt dann die Conversion im Store, sodass Abstürze Sie indirekt auch Installationen kosten.

Andererseits sind Abstürze nicht immer ein direkter Grund für eine Entfernung. Bei Google Play geht es dabei meist um Richtlinienverstöße; den Ablauf erklärt unser Beitrag Google Play App entfernt. Die Richtlinien von Apple sagen dagegen klar, dass Apple nicht mehr funktionierende Apps aus dem Store entfernen kann.

Kurz gesagt: Betrachten Sie die Absturzrate nicht als reine Kennzahl der Entwicklung. Stürzt die App ab, während Ihr Marketing Werbebudget ausgibt, verschwinden die beworbenen Nutzer schon in der ersten Sitzung.

Welche Absturzrate sollten Sie anstreben?

Eine Antwort für alle Apps gibt es allerdings nicht. Der Grenzwert des Stores ist eine Untergrenze und kein Ziel. Eine App knapp darunter entgeht zwar der Abwertung im Store, verliert aber trotzdem jeden Tag einen Teil ihrer Nutzer.

Wir empfehlen, das Ziel über den Trend festzulegen statt über eine absolute Zahl. Der Anteil absturzfreier Nutzer jeder Version sollte nicht unter dem der Vorversion liegen, und kein Smartphonemodell sollte sich dem Grenzwert pro Gerät nähern. Das ist verlässlicher als Branchendurchschnitte mit unklarer Quelle.

Ziehen Sie daher eine eigene Basislinie: Notieren Sie die Absturzrate Ihrer letzten drei Versionen und vergleichen Sie jedes neue Release damit. Ein deutlicher Abfall unter diese Linie ist ein ausreichendes Signal, um einen Rollout zu pausieren.

Wann lohnt sich professionelle Hilfe bei einer hohen Absturzrate?

Hilfe von außen lohnt sich, wenn Sie keinen eigenen Mobilentwickler haben, wenn ein anderes Unternehmen die App gebaut und übergeben hat oder wenn eine Warnung in Android vitals seit Wochen bleibt. Die Diagnose dauert außerdem länger, wenn Symboldateien fehlen, der Zugang zum Quellcode begrenzt ist oder die plattformübergreifende Schicht komplex ist.

Mit unserer App Entwicklung entwickeln wir Ihre App und bringen sie für Sie in die Stores. Crashlytics, die Pipeline für den Symbolupload und die Überwachung nach dem Release richten wir dabei als festen Teil des Projekts ein. Stabilitätsprobleme bestehender Apps behandeln wir im selben Rahmen.

Haben Sie ein anderes Problem wie eine Ablehnung im Store, hilft eventuell unser Beitrag zur Ablehnung nach Richtlinie 4.3. Möchten Sie Stabilität und Releaseprozess Ihrer App gemeinsam angehen, können Sie auf unserer Seite zur App Entwicklung ein Angebot anfordern. Im Angebot klären wir den aktuellen Stand, die Zielplattformen und den Zeitplan.