Stabilität des neuesten App-Release im Blick behalten

Die Einführung einer neuen Version Ihrer mobilen App in der Produktionsversion ist einer der spannendsten Teile der App-Entwicklung, kann aber auch einer der stressigsten sein. Ihr Team muss unter anderem die Akzeptanz der Version, neue Fehler und deren Auswirkungen sowie einen Vergleich mit früheren Releases im Blick behalten.

Auf dieser Seite werden mehrere Firebase-Tools beschrieben, mit denen Sie die Daten überwachen können, die Sie für die Veröffentlichung Ihrer App benötigen.

Mit dem Dashboard Release-Monitoring können Sie Ihre releasebezogenen Daten analysieren.

Das Release-Monitoring-Dashboard in der Firebase-Konsole basiert auf Firebase Crashlytics. Auf einem einzigen Dashboard können Sie Ihren neuesten Produktionsrelease im Blick behalten. Das Dashboard wird nahezu in Echtzeit aktualisiert und bietet einen Überblick über die wichtigsten Release-Messwerte, einschließlich Messwerten für fehlerfreie Nutzung, Versionsnutzung, Vergleiche mit früheren Releases und alle neuen Probleme im Zusammenhang mit dem Release.

Dieses neue Dashboard ist eine Weiterentwicklung der Seite Neueste Version in der Console. Im Vergleich zu dieser Seite enthält das Dashboard Release Monitoring mehr Informationen, zeigt nützliche Daten ohne Google Analytics an und wird schneller geladen.

Funktionen des Dashboards

  • Echtzeitberichte
    Alle Diagramme werden nahezu in Echtzeit aktualisiert. Kurz nach der Bereitstellung der neuesten Version können Sie beobachten, wie Nutzer mit diesem Release interagieren. Wenn bei einigen dieser Nutzer Abstürze auftreten, sehen Sie die Auswirkungen sofort anhand der Diagramme mit Messwerten zu Nutzern ohne Abstürze.

  • Vergleich und Benchmarking anhand früherer Releases
    Sie können die Stabilität Ihres letzten Releases im Kontext Ihrer früheren Releases ansehen. Im Dashboard können Sie die Live-Messwerte Ihres letzten Releases mit bis zu zwei zuvor veröffentlichten Builds vergleichen.

  • Top-neue Probleme
    Sie können sich neue Abstürze für Ihren neuesten Release ansehen, sobald sie auftreten. In der Tabelle Top-neue Probleme können Sie die Auswirkungen der Probleme beobachten, die in Ihrem letzten Release zuerst erkannt wurden. So können Sie schnell entscheiden, ob Sie den Release beenden oder ein Rollback durchführen möchten.

Anforderungen an das Dashboard

So rufen Sie Ihren neuesten Release im Dashboard Release-Monitoring auf:

  1. Ihre App muss mindestens die folgenden Versionen des Crashlytics SDK verwenden:
    Apple-Plattformen: Version 10.8.0 oder höher | Android: Version 18.6.0 oder höher (BoM Version 32.6.0 oder höher) | Flutter: Version 3.4.5 oder höher | Unity: 11.7.0 oder höher

  2. Veröffentlichen Sie eine neue Version der App als Produktionsversion, damit Sie eine ausreichende Anzahl aktiver Nutzer mit Ihrer neuesten Version haben.

Häufig gestellte Fragen zum Dashboard

Damit ein Build im Dashboard angezeigt wird, müssen mindestens die folgenden Versionen des Crashlytics SDK verwendet werden:
Apple-Plattformen: Version 10.8.0 oder höher | Android: Version 18.6.0 oder höher (BoM Version 32.6.0 oder höher) | Flutter: Version 3.4.5 oder höher | Unity: 11.7.0 oder höher

Diese Versionen des SDK werden oft als „sitzungsfähige“ SDK-Versionen bezeichnet, da sie Sitzungsdaten an Crashlytics senden können. Dies ist für viele der neuen Funktionen in Crashlytics erforderlich, z. B. für das Dashboard für die Release-Überwachung.

Damit ein Build im Dashboard angezeigt wird, muss er alle folgenden Anforderungen erfüllen:

  • Für den Build werden mindestens die folgenden Versionen des Crashlytics SDK verwendet:
    Apple-Plattformen: Version 10.8.0 oder höher | Android: Version 18.6.0 oder höher (BoM Version 32.6.0 oder höher) | Flutter: Version 3.4.5 oder höher | Unity: 11.7.0 oder höher

  • Die Build-Version hat in den letzten 3 Tagen eine ausreichende Anzahl von Nutzern:

    • Der Build muss mindestens 500 verschiedene Nutzer haben ODER

    • Die Version hat mindestens 1% der Gesamtzahl der Nutzer und mindestens zwei einzelne Nutzer.

Das Dashboard Release Monitoring soll Ihnen bei Ihren Produktionsveröffentlichungen helfen, also bei Builds, die eine große Anzahl von Nutzern haben.

Damit ein Build im Dashboard angezeigt wird, muss er alle folgenden Anforderungen erfüllen:

  • Für den Build werden mindestens die folgenden Versionen des Crashlytics SDK verwendet:
    Apple-Plattformen: Version 10.8.0 oder höher | Android: Version 18.6.0 oder höher (BoM Version 32.6.0 oder höher) | Flutter: Version 3.4.5 oder höher | Unity: 11.7.0 oder höher

  • Die Build-Version hat in den letzten 3 Tagen eine ausreichende Anzahl von Nutzern:

    • Der Build muss mindestens 500 verschiedene Nutzer haben ODER

    • Die Version hat mindestens 1% der Gesamtzahl der Nutzer und mindestens zwei einzelne Nutzer.

(Für über Google Play bereitgestellte Apps) Wenn eine App einen Google Play-Link hat, werden im Dashboard alle im Play-Produktions-Track aufgeführten Builds angezeigt, auch wenn Crashlytics keine Sitzungsprotokolle erhalten oder keine aktiven Nutzer für diesen Build erkannt hat.

Damit Sie im Dashboard Daten für Vergleiche oder den Prozentsatz der aktiven Nutzer sehen können, müssen Sie mindestens zwei Builds veröffentlicht haben, die die oben genannten Anforderungen erfüllen.

Zuerst ist es hilfreich, einige der Begriffe zu verstehen, die im Diagramm Aktive Nutzer verwendet werden:

  • Eine Sitzung ist ein kontinuierlicher Zeitraum, in dem ein Nutzer mit einer Anwendung interagiert. Eine neue Sitzung beginnt, wenn die App kalt gestartet wird oder nach mindestens 30 Minuten im Hintergrund in den Vordergrund gebracht wird.

  • Die aktiven Nutzer für einen bestimmten Build sind die Anzahl der Nutzer, die mit diesem Build eine Sitzung gestartet haben, gruppiert nach Stunden.

  • Nutzer insgesamt (aktiv) ist die Anzahl der Nutzer, die eine Sitzung in einem beliebigen Build der App gestartet haben, die eine sitzungsfähige SDK-Version verwendet. Die Daten sind nach Stunde gruppiert.

Im Diagramm Aktive Nutzer werden der Prozentsatz und die Anzahl der aktiven Nutzer, die immer im Diagramm angezeigt werden, aus den letzten 60 Minuten berechnet. Falls in den letzten 60 Minuten keine aktiven Nutzer vorhanden waren, werden die Daten der letzten Stunde verwendet, für die Daten verfügbar sind. Im Beispielscreenshot gab es beispielsweise in den letzten 60 Minuten 90 aktive Nutzer für den Build 6.0.0 (600), was 22,1% der Gesamtzahl der (aktiven) Nutzer der App entspricht.

Screenshot eines Beispieldiagramms „Aktive Nutzer“ aus dem Dashboard <i>Release-Monitoring</i>

Wenn Sie den Mauszeiger auf die Linien im Diagramm Aktive Nutzer bewegen, wird der Prozentsatz der aktiven Nutzer anhand der Anzahl der aktiven Nutzer im entsprechenden Stundenzeitraum berechnet.

Damit Sie den Prozentsatz der aktiven Nutzer sehen können, müssen Sie mindestens zwei Builds veröffentlicht haben, die den in den FAQs unter „Welche Builds können im Dashboard Release Monitoring angezeigt werden?“ beschriebenen Anforderungen entsprechen.

Der Prozentsatz der aktiven Nutzer basiert auf empfangenen Sitzungsdaten und nicht auf anderen Daten wie Google Play-Daten oder Absturzberichten.

Wenn Sie Ihre App zum ersten Mal mit einer kompatiblen Crashlytics SDK-Version veröffentlicht haben, gibt es für Crashlytics keine vorherigen Sitzungsdaten, mit denen ein Vergleich möglich wäre.

Warnungen einrichten

Mehrere Firebase-Produkte, darunter Crashlytics, können aus verschiedenen produktspezifischen Gründen Benachrichtigungen senden. Damit Sie Benachrichtigungen erhalten, benötigen Sie die erforderlichen Berechtigungen.

Sie können Benachrichtigungen sowohl über Performance Monitoring als auch über Crashlytics einrichten, um die Stabilität Ihres letzten Release im Blick zu behalten. Für Crashlytics können Sie speziell die folgenden Benachrichtigungen einrichten:

  • Mit Geschwindigkeitswarnungen können Sie Ihr Team benachrichtigen, wenn ein einzelnes Problem in Ihrer App einen Grenzwert überschreitet, den Sie in der Firebase-Konsole festlegen.

  • Sie können Benachrichtigungen zu neuen oder wieder aufgetretenen Problemen an Ihren bevorzugten Benachrichtigungskanal senden:

Für einen reibungslosen Release sorgen

Bevor Sie Ihre neueste Version veröffentlichen, sollten Sie einige der folgenden Dienste und Funktionen nutzen, um einen reibungslosen Release zu ermöglichen.

Dienste für Vorabtests verwenden

Firebase bietet zwei Produkte, die bei Pre-Release-Tests helfen können: Test Lab und App Distribution. Beide Dienste können in Ihre CI/CD-Abläufe eingebunden werden.

Firebase Test Lab ist eine cloudbasierte App-Testinfrastruktur, mit der Sie Ihre App auf einer Vielzahl von Geräten und Konfigurationen testen können, um frühzeitig ein Gefühl dafür zu bekommen, wie sie sich in der Praxis bei echten Nutzern schlägt.

Wenn Sie Ihren neuesten Build an vertrauenswürdige menschliche Tester übergeben möchten, verwenden Sie Firebase App Distribution. Sie können sowohl die Bereitstellungen für die Apple-Plattform als auch die Android-Pre-Release-Versionen an einem zentralen Ort verwalten.

Dienste für die Einführung und eingeschränkte Tests verwenden

Mit Firebase Remote Config können Sie neue Funktionen mit einem prozentualen Roll-out-Mechanismus einführen oder diese Funktionen in einer eingeschränkten Testgruppe testen.

Firebase bietet auch A/B Testing, mit denen Sie Änderungen an der Benutzeroberfläche, den Funktionen oder den Interaktionen Ihrer App testen können, um zu sehen, wie sich diese auf wichtige Messwerte wie Umsatz und Nutzerbindung auswirken, bevor Sie sie einführen.