App-Absturzüberwachung und Performance-Tracking mobil
Mit Absturzüberwachung sehen Sie Fehler vor den Beschwerden der Nutzer: welche Kennzahlen wichtig sind, welche Werkzeuge es gibt und wie Sie priorisieren.
rabbitclip-TeamVeröffentlicht: 6 Min. Lesezeit
Kurz gesagt
Absturzüberwachung für eine mobile App ist ein Aufbau, der jedes Mal, wenn sich die App auf dem Telefon eines Nutzers schließt, automatisch erfasst, wo der Fehler auftrat, auf welchem Gerät und in welcher Version, und ihn an Sie meldet. Die Performance-Überwachung misst die weicheren Probleme auf dieselbe Weise: Startzeit, Ruckeln und Speicherverbrauch. Mit beidem sehen Sie den tatsächlichen Zustand der App in den Händen der Nutzer. Ohne sie entscheiden Sie allein nach Store-Bewertungen, und diese Bewertungen sind die Stimme nur eines kleinen Teils der Menschen, die auf das Problem gestoßen sind.
Wessen App abstürzt, der schreibt Ihnen meist nicht. Er schließt sie, versucht es noch einmal und löscht sie dann. Eine App, die auf Ihren Testtelefonen einwandfrei läuft, kann sich auf einem drei Jahre alten Gerät oder bei schwacher Verbindung anders verhalten. Die Überwachung ist der einzige Weg, diese unsichtbare Gruppe sichtbar zu machen.
Sind Absturzüberwachung und Performance-Überwachung dasselbe?
Nein, sie beantworten unterschiedliche Fragen. Die Absturzüberwachung erfasst den Moment, in dem sich die App schließt: in welcher Codezeile, auf welchem Gerät, unter welcher Systemversion und was der Nutzer gerade tat. Die Performance-Überwachung misst, was sich schlecht anfühlt, auch wenn die App sich nicht schließt: ein langsamer Bildschirm, ruckelndes Scrollen, anschwellender Speicher.
Unter Android gibt es eine dritte Fehlerart, die nicht reagierende Anwendung, bekannt als ANR. Die App stürzt nicht ab, sondern friert ein, und das System bietet dem Nutzer an, sie zu schließen. Ein gutes Überwachungs-Setup zeigt diese drei Gruppen, Abstürze, Nichtreagieren und Langsamkeit, getrennt an.
Welche Kennzahlen sollten Sie beobachten?
Wenige aussagekräftige Indikatoren sind besser als eine Wand aus Diagrammen. Der erste ist die absturzfreie Sitzungsrate: die Wahrscheinlichkeit, dass eine Sitzung ohne Fehler endet, sobald der Nutzer die App öffnet. Vergleichen Sie sie über die Versionen hinweg; sinkt sie im neuen Release, hat das Release einen Rückschritt eingeführt.
Die zweite Gruppe sind Performance-Indikatoren. Auch die Dashboards der Stores bieten eigene Gesundheitswerte. Die Google Play Console und die Entwicklerwerkzeuge von Apple zeigen kostenlos Absturz- und Nichtreagieren-Daten, die bei den Nutzern erhoben wurden, und für die meisten Unternehmen ist das der Ausgangspunkt.
- Absturzfreie Sitzungsrate, Version für Version verglichen
- Kaltstartzeit: wie schnell sich die App öffnet, wenn sie vollständig geschlossen war
- Langsame und eingefrorene Frames: wie flüssig Scrollen und Übergänge wirken
- Ereignisse mit Nichtreagieren (ANR) und die betroffenen Gerätemodelle
Welche Werkzeuge und Daten sollten Sie einsetzen?
Für das Crash-Reporting gibt es weit verbreitete Fertigdienste; Firebase Crashlytics und Sentry sind bekannte Beispiele. Die Wahl hängt von der Infrastruktur ab, die das Team ohnehin nutzt, und davon, was Sie überwachen müssen. Mehr als der Name des Werkzeugs macht die Korrektheit der Einrichtung den Unterschied.
Der Teil der Einrichtung, der am häufigsten übersprungen wird, ist die Lesbarkeit der Berichte. Der Code einer veröffentlichten App ist verschleiert und von Namen befreit; um einen Absturzbericht lesbar zu machen, müssen Sie bei jedem Release die passenden Symbol- und Mapping-Dateien in den Überwachungsdienst hochladen. Tun Sie das nicht, ist der Bericht eine Liste bedeutungsloser Adressen, und niemand kann sagen, wo der Fehler liegt.
Berichte tragen außerdem Kontext: die letzten Schritte des Nutzers, die Versionsnummer, das Gerätemodell, den Netzwerkzustand. Achten Sie darauf, dass dieser Kontext keine personenbezogenen Daten enthält; Namen, E-Mail-Adressen und Kartendaten dürfen nie in einen Bericht gelangen. Wie personenbezogene Daten in Protokolle geraten, sollten Sie mit einem Juristen oder einem Datenschutzbeauftragten besprechen.
Wie priorisieren Sie die eingehenden Fehler?
Sobald die Überwachung läuft, liefert die erste Woche eine Liste von Dutzenden Fehlern, und allen nachzugehen ist unmöglich. Die Priorität stützt sich auf zwei Prüfungen: wie viele Nutzer betroffen sind und an welcher Stelle ihrer Reise es geschieht. Ein einzelner Absturz bei Zahlung, Anmeldung oder Registrierung geht einem häufigen, aber harmlosen auf dem Einstellungsbildschirm vor.
Ein Fehler, der mit einem neuen Release auftaucht, wird gesondert behandelt, denn er ist ein Rückschritt und meist die am schnellsten zu behebende Art. Wo möglich, lässt sich durch eine stufenweise Auslieferung einer neuen Version an die Nutzer der Release stoppen, wenn ein Problem auftaucht.
- Zahl der betroffenen Nutzer und Häufigkeit der Wiederholung
- Der Zeitpunkt des Auftretens: Zahlung, Anmeldung und Registrierung zuerst
- Ob es mit dem neuen Release begann, also ob es ein Rückschritt ist
- Die betroffene Gruppe aus Gerät und Systemversion
Welche Fehler passieren bei Absturz- und Performance-Überwachung häufig?
Der häufigste Fehler ist, die Überwachung erst nach dem Start einzurichten, sodass die erste Absturzwelle unbemerkt vorüberzieht. Der zweite ist, Berichte zu sammeln, die niemand liest. Eine Person oder Rolle sollte die Fehler regelmäßig prüfen und in den ersten Tagen nach jedem Release genau hinsehen.
Der dritte ist, nur auf den neuesten Telefonen zu testen. Der tatsächliche Nutzerstamm umfasst ältere Geräte und langsame Verbindungen, und dort zeigen sich Performance-Probleme gewöhnlich.
- Die Überwachung erst nach dem Start einrichten
- Symbol- und Mapping-Dateien nicht hochladen und Berichte damit unlesbar lassen
- Berichte sammeln, ohne dass sie jemand regelmäßig prüft
- Personenbezogene Daten in Berichte oder Protokolle schreiben
Wann ist Performance-Überwachung überflüssig oder verfrüht?
Für eine App, die noch nicht gestartet ist und keine Nutzer hat, ist ein detailliertes Performance-Dashboard verfrüht; es gibt keine Daten zu deuten. In dieser Phase genügt es, das Crash-Reporting einzurichten, denn es gibt Ihnen ab den ersten echten Nutzern eine fast kostenlose Absicherung, die wenig Pflege braucht.
Auch für eine einfache Unternehmens-App mit wenigen Nutzern, die selten geöffnet wird, ist ein komplexer Überwachungsaufbau unnötig; die kostenlosen Gesundheitsdaten in den Store-Dashboards können genügen. Der Test lautet: Verändert die Überwachung keine Entscheidung, die Sie treffen würden, ist sie überflüssig.
Absturz- und Performance-Überwachung ist der Weg, die App so zu sehen, wie Nutzer sie wirklich erleben, während Store-Bewertungen nur den lautesten Teil des Problems zeigen. Richten Sie die Überwachung vor dem Start ein, laden Sie bei jedem Release die Dateien hoch, die Berichte lesbar halten, prüfen Sie regelmäßig einige aussagekräftige Kennzahlen und ordnen Sie Fehler danach, wie viele Nutzer sie betreffen. Wenn Sie Hilfe dabei möchten, den Zustand Ihrer App zu überwachen, können Sie mit rabbitclip ein Erstgespräch vereinbaren.
Häufige Fragen
Was ist die absturzfreie Sitzungsrate?
Es ist der Anteil der Sitzungen, die vom Start der App bis zum Schließen ohne Absturz verlaufen. Über die Versionen hinweg verglichen, liefert sie eine schnelle Einschätzung der Stabilität eines neuen Releases.
Sollte ich für die Absturzüberwachung ein fertiges Werkzeug nutzen?
Für die meisten Unternehmen ja. Weit verbreitete Dienste wie Firebase Crashlytics und Sentry bieten eine fertige Lösung, und ein Eigenbau bringt selten Mehrwert. Der eigentliche Unterschied liegt darin, es richtig einzurichten und die Symboldateien hochzuladen.
Genügen die Dashboards der Stores allein?
Zum Einstieg genügen sie oft, denn sie zeigen kostenlos Absturz- und Nichtreagieren-Daten. Um zu sehen, wo und in welchem Schritt ein Fehler auftritt, und um Versionen zu vergleichen, braucht es meist ein eigenes Überwachungswerkzeug.
Zählen Überwachungsdaten als personenbezogene Daten?
Das können sie, wenn ein Bericht Angaben enthält, die den Nutzer identifizieren. Achten Sie darauf, keine Namen, E-Mail-Adressen oder Zahlungsdaten in Berichte aufzunehmen, und fragen Sie einen Juristen nach der rechtlichen Lage Ihrer App.
