Diese Seite wurde von der Cloud Translation API übersetzt.

Firebase Crashlytics-Daten nach BigQuery exportieren

Sie können Ihre Firebase Crashlytics-Daten zur weiteren Analyse in BigQuery exportieren. Mit BigQuery können Sie die Daten mit BigQuery SQL analysieren, in einen anderen Cloud-Anbieter exportieren und für Visualisierungen und benutzerdefinierte Dashboards mit Google Data Studio verwenden.

Export nach BigQuery aktivieren

Wechseln Sie in der Firebase-Konsole zur Seite „Integrationen“.
Klicken Sie auf der Karte BigQuery auf Verknüpfen.
Folge der Anleitung auf dem Bildschirm, um den Export nach BigQuery zu aktivieren.

Wenn Sie den Export nach BigQuery aktivieren, passiert Folgendes:

Standardmäßig sind alle Apps in Ihrem Projekt mit BigQuery und allen Apps, die Sie dem Projekt später hinzufügen, werden automatisch mit BigQuery Sie können festlegen, welche Apps Daten senden.
Firebase richtet eine tägliche Synchronisierung Ihrer Daten aus Ihrem Firebase-Projekt mit BigQuery ein.
Firebase eine Kopie Ihrer vorhandenen Daten exportiert an BigQuery. Für jede verknüpfte App gibt es eine Batch-Tabelle mit den Daten aus der täglichen Synchronisierung.
Wenn Sie den Streamingexport von Crashlytics nach BigQuery aktivieren, haben alle verknüpften Apps auch eine Echtzeittabelle mit ständig aktualisierten Daten.

Wenn Sie den Export in BigQuery deaktivieren möchten, entkoppeln Sie Ihr Projekt in der Firebase-Konsole.

Welche Daten werden nach BigQuery exportiert?

Firebase Crashlytics-Daten werden in ein BigQuery-Dataset namens firebase_crashlytics exportiert. Standardmäßig werden im Crashlytics-Dataset für jede App in Ihrem Projekt einzelne Tabellen erstellt. Die Tabellen werden in Firebase nach der ID der Anwendung benannt. Die in der ID enthaltenen Punkte werden in Unterstriche umgewandelt und am Ende wird der Plattformname angehängt.

Beispiel: Daten für eine Android-App mit dem Paketnamen com.google.test in einer Tabelle mit dem Namen com_google_test_ANDROID. Diese Batchtabelle wurde aktualisiert einmal täglich. Wenn Sie den Streaming-Export von Crashlytics aktivieren, BigQuery, dann werden Crashlytics-Daten ebenfalls in Echtzeit gestreamt in eine Tabelle mit dem Namen com_google_test_ANDROID_REALTIME.

Jede Zeile in einer Tabelle stellt ein Ereignis dar, das in der App aufgetreten ist, einschließlich Abstürzen, nicht schwerwiegenden Fehlern und ANRs.

Crashlytics-Streamingexport nach BigQuery

Mit BigQuery-Streaming können Sie Ihre Crashlytics-Daten in Echtzeit streamen. Sie können sie für alle Zwecke verwenden, für die Live-Daten erforderlich sind, z. B. für die Präsentation von Informationen in einem Live-Dashboard, für die Live-Überwachung eines Roll-outs oder für die Überwachung von Anwendungsproblemen, die Benachrichtigungen und benutzerdefinierte Workflows auslösen.

Wenn Sie den Crashlytics-Streaming-Export nach BigQuery aktivieren, Neben der Batch-Tabelle haben Sie auch eine Realtime-Tabelle. Hier sind die Unterschiede, die Sie zwischen den Tabellen kennen sollten:

Batch-Tabelle	Echtzeittabelle
Die Daten werden einmal täglich exportiert. Ereignisse werden dauerhaft gespeichert, bevor in den Batch geschrieben wird. BigQuery Daten können bis zu 30 Tage zuvor rückgebucht.	Die Daten werden in Echtzeit exportiert. Es ist kein Backfill verfügbar.

Die Batch-Tabelle eignet sich ideal für die Langzeitanalyse und das Erkennen von Trends im Zeitverlauf. da wir Ereignisse vor dem Schreiben dauerhaft speichern und bis zu 30 Tage lang gespeichert. Wenn wir Daten in Ihre Echtzeittabelle schreiben, werden sie sofort in BigQuery geschrieben. Daher eignet sich BigQuery ideal für Live-Dashboards und benutzerdefinierte Benachrichtigungen. Diese beiden Tabellen können mit einer Stitching-Abfrage kombiniert werden, um die Vorteile beider zu nutzen.

Standardmäßig hat die Echtzeittabelle eine Partitionsablaufzeit von 30 Tagen. Bis Informationen zum Ändern finden Sie unter Ablauf der Partition festlegen in der Dokumentation zu BigQuery.

Streaming-Export von Crashlytics nach BigQuery aktivieren

Rufen Sie in der Firebase Console die Seite Integrationen auf.
Klicken Sie auf der Karte BigQuery auf Verwalten.
Klicken Sie das Kästchen Streaming einschließen an.

Durch diese Aktion wird das Streaming für alle verknüpften Apps aktiviert.

Was kann ich mit den exportierten Daten tun?

Exporte nach BigQuery enthalten Rohabsturzdaten, darunter Gerätetyp, Betriebssystem, Ausnahmen (Android-Apps) oder Fehler (Apple-Apps) und Crashlytics-Protokolle sowie andere Daten.

Weitere Informationen dazu, welche Crashlytics-Daten exportiert werden und wie das Tabellenschema aussieht, finden Sie weiter unten auf dieser Seite.

Data Studio-Vorlage verwenden

Wenn Sie Echtzeitdaten in Ihrer Data Studio-Vorlage aktivieren möchten, folgen Sie der Anleitung unter Exportierte Crashlytics-Daten mit Data Studio visualisieren.

Ansichten erstellen

Sie können Abfragen über die BigQuery-Benutzeroberfläche in Ansichten umwandeln. Eine ausführliche Anleitung finden Sie unter Erstellen Sie Ansichten in der BigQuery-Dokumentation.

Abfragen ausführen

Die folgenden Beispiele zeigen Abfragen, die Sie auf Ihrem Crashlytics-Daten, um Berichte zu erstellen, in denen Absturzereignisdaten zusammengefasst werden leichter verständliche Zusammenfassungen. Da diese Berichtstypen nicht im Crashlytics-Dashboard der Firebase-Konsole verfügbar sind, können sie Ihre Analyse und Ihr Verständnis von Absturzdaten ergänzen.

Beispiel 1: Abstürze nach Tag

Nachdem Sie so viele Fehler wie möglich behoben haben, sind Sie der Meinung, dass Ihr Team endlich bereit ist, Ihre neue Foto-Sharing-App auf den Markt zu bringen. Bevor Sie dies tun, möchten Sie die Anzahl der täglichen Abstürze im letzten Monat prüfen, um sich zu vergewissern, dass die App aufgrund der Fehlerbehebungen im Lauf der Zeit stabiler geworden ist.

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie bei einer iOS-App die Paket-ID. und IOS (anstelle des Paketnamens und ANDROID).

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

Beispiel 2: Die schwerwiegendsten Abstürze ermitteln

Um die Produktionspläne richtig zu priorisieren, möchten Sie die zehn häufigsten Abstürze in Ihrer App ermitteln. Sie erstellen eine Abfrage, die die relevanten Datenpunkte liefert.

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS (anstelle des Paketnamens und ANDROID).

SELECT
  DISTINCT issue_id,
  COUNT(DISTINCT event_id) AS number_of_crashes,
  COUNT(DISTINCT installation_uuid) AS number_of_impacted_user,
  blame_frame.file,
  blame_frame.line
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(),INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  issue_id,
  blame_frame.file,
  blame_frame.line
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Beispiel 3: Top-10-Geräte, die abstürzen

Im Herbst kommen die neuen Smartphones auf den Markt! Ihr Unternehmen weiß, dass dadurch auch neue gerätespezifische Probleme auftreten, insbesondere bei Android-Geräten. Sie erstellen eine Abfrage zur Ermittlung der zehn Geräte, die in der vergangenen Woche (168 Stunden) am häufigsten abgestürzt sind, um sich einen Überblick über die voraussichtlichen Kompatibilitätsprobleme zu verschaffen.

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS (anstelle des Paketnamens und ANDROID).

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND event_timestamp < CURRENT_TIMESTAMP()
GROUP BY
  device.model
ORDER BY
  number_of_crashes DESC
LIMIT 10;

Beispiel 4: Nach benutzerdefiniertem Schlüssel filtern

Sie sind Spieleentwickler und möchten wissen, auf welchem Level mit den meisten Abstürzen.

Sie legen zur Ermittlung der Statistik den benutzerdefinierten Crashlytics-Schlüssel current_level fest und aktualisieren ihn jedes Mal, wenn der Nutzer ein neues Level erreicht.

Swift

Crashlytics.sharedInstance().setIntValue(3, forKey: "current_level");

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

Crashlytics.setInt("current_level", 3);

Mit diesem Schlüssel in Ihrem Export nach BigQuery können Sie dann eine Abfrage schreiben, um die Verteilung der mit jedem Absturzereignis verbundenen current_level-Werte zu protokollieren.

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie bei einer iOS-App die Paket-ID. und IOS (anstelle des Paketnamens und ANDROID).

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

Beispiel 5: User-ID-Extraktion

Du hast eine Android-App in der Early-Access-Phase. Den meisten Nutzern gefällt es, aber drei es zu einer ungewöhnlichen Anzahl von Abstürzen kam. Um zum Ende der schreiben Sie eine Abfrage, mit der alle Absturzereignisse für diese Nutzer anhand ihrer User-IDs.

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie bei einer iOS-App die Paket-ID. und IOS (anstelle des Paketnamens und ANDROID).

SELECT *
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  user.id IN ("USER_ID_1", "USER_ID_2", "USER_ID_3")
ORDER BY
  user.id

Beispiel 6: Alle Nutzer finden, die ein bestimmtes Absturzproblem haben

Ihr Team hat einer Gruppe von Betatestern versehentlich einen kritischen Fehler zur Verfügung gestellt. Ihr Team konnte die Abfrage aus dem Beispiel Die häufigsten Abstürze finden oben verwenden, um die ID des spezifischen Absturzproblems zu ermitteln. Ihr Team möchte jetzt eine Abfrage ausführen, um eine Liste der App-Nutzer zu extrahieren, die von diesem Absturz betroffen waren.

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS (anstelle des Paketnamens und ANDROID).

SELECT user.id as user_id
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`
WHERE
  issue_id = "ISSUE_ID"
  AND application.display_version = "APP_VERSION"
  AND user.id != ""
ORDER BY
  user.id;

Beispiel 7: Anzahl der Nutzer, die von einem Absturzproblem betroffen sind, aufgeschlüsselt nach Land

Ihr Team hat beim Roll-out eines neuen Release einen kritischen Fehler entdeckt. Sie konnten die Abfrage aus dem Beispiel „Häufigste Abstürze finden“ oben verwenden, um die ID des spezifischen Absturzproblems zu ermitteln. Ihr Team möchte nun wissen, ob sich dieser Absturz auf Nutzer in verschiedenen Ländern ausgeweitet hat.

Um diese Abfrage zu schreiben, muss Ihr Team Folgendes tun:

Aktivieren Sie den Export von Google Analytics-Daten nach BigQuery. Siehe Projektdaten in BigQuery exportieren.

Aktualisieren Sie Ihre App, damit eine User-ID sowohl an das Google Analytics SDK als auch an das Crashlytics SDK übergeben wird.

Swift

Crashlytics.sharedInstance().setUserIdentifier("123456789");
Analytics.setUserID("123456789");

Objective-C

CrashlyticsKit setUserIdentifier:@"123456789";
FIRAnalytics setUserID:@"12345678 9";

Java

Crashlytics.setUserIdentifier("123456789");
mFirebaseAnalytics.setUserId("123456789");

Erstellen Sie eine Abfrage, in der Ereignisse im Dataset Google Analytics anhand des Felds „User-ID“ mit Abstürzen im Dataset Crashlytics zusammengeführt werden.

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS (anstelle des Paketnamens und ANDROID).

SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
FROM `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` c
INNER JOIN  `PROJECT_ID.analytics_TABLE_NAME.events_*` a on c.user.id = a.user_id
WHERE
  c.issue_id = "ISSUE_ID"
  AND a._TABLE_SUFFIX BETWEEN '20190101'
  AND '20200101'
GROUP BY
  c.issue_id,
  a.geo.country,
  c.user.id

Beispiel 8: Die 5 bisher größten Probleme heute

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS (anstelle des Paketnamens und ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Beispiel 9: Top-5-Probleme seit DATE, einschließlich heute

Sie können die Batch- und Echtzeittabellen auch mit einer Stitching-Abfrage kombinieren, um den zuverlässigen Batchdaten Echtzeitinformationen hinzuzufügen. Da event_id ein Primärschlüssel ist, können Sie damit alle gemeinsamen Ereignisse aus den beiden Tabellen deduplizieren.

Hier ist eine Beispielabfrage für eine Android-App. Verwenden Sie für eine iOS-App die Paket-ID und IOS (anstelle des Paketnamens und ANDROID).

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID`)
WHERE
  event_timestamp >= "YYYY_MM_DD"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Crashlytics-Schema in BigQuery

Wenn Sie den Crashlytics-Datenexport nach BigQuery einrichten, exportiert Firebase aktuelle Ereignisse (Abstürze, nicht schwerwiegende Fehler und ANRs), einschließlich Ereignisse, die bis zu zwei Tage vor der Verknüpfung aufgetreten sind. Dabei besteht die Möglichkeit, bis zu 30 Tage Backfills durchzuführen.

Der Export der Crashlytics-Ereignisse erfolgt ab diesem Zeitpunkt täglich, bis Sie den Export deaktivieren. Es kann einige Minuten dauern, bis die Daten nach jedem Export in BigQuery verfügbar sind.

Datasets

Crashlytics erstellt in BigQuery ein neues Dataset für Crashlytics Daten. Das Dataset deckt Ihr gesamtes Projekt ab, auch wenn es mehrere Apps enthält.

Tabellen

Crashlytics erstellt für jede Anwendung des Projekts eine Tabelle im Dataset, es sei denn, Sie haben den Datenexport für eine Anwendung deaktiviert. Die Tabellen werden in Firebase nach der ID der Anwendung benannt. Die in der ID enthaltenen Punkte werden in Unterstriche umgewandelt und am Ende wird der Plattformname angehängt.

Beispiel: Daten für eine Android-App mit dem Paketnamen com.google.test in einer Tabelle mit dem Namen com_google_test_ANDROID und Echtzeitdaten (falls aktiviert) in einer Tabelle namens com_google_test_ANDROID_REALTIME enthalten

Tabellen enthalten neben allen Crashlytics-Daten benutzerdefinierte Crashlytics-Schlüssel die Sie in Ihrer App festgelegt haben.

Zeilen

Jede Zeile der Tabelle stellt einen Fehler der Anwendung dar.

Spalten

Die Spalten in einer Tabelle sind für Abstürze, nicht schwerwiegende Fehler und ANRs identisch. Wenn Crashlytics-Streaming-Export nach BigQuery ist aktiviert, dann ist der Echtzeittabelle dieselben Spalten wie die Batchtabelle. Sie können Spalten in Zeilen enthalten, die Ereignisse ohne Stacktraces darstellen.

Die Spalten im Export sind in der folgenden Tabelle aufgeführt:

Feldname	Datentyp	Beschreibung
`platform`	STRING	Plattform der App, die im Firebase-Projekt registriert ist (gültige Werte: `IOS` oder `ANDROID`)
`bundle_identifier`	STRING	Die eindeutige Kennung der App, die im Firebase-Projekt registriert ist (z. B. `com.google.gmail`) Bei Apple-Plattform-Apps ist dies die Bundle-ID der App. Bei Android-Apps ist dies der Paketname der App.
`event_id`	STRING	Die eindeutige ID des Ereignisses
`is_fatal`	BOOLEAN	Dieses Feld wurde eingestellt. Verwenden Sie stattdessen `error_type`. Ob die App abgestürzt ist
`error_type`	STRING	Der Fehlertyp des Ereignisses (z. B. `FATAL`, `NON_FATAL`, `ANR` usw.)
`issue_id`	STRING	Das mit dem Ereignis verbundene Problem
`variant_id`	STRING	Die mit diesem Ereignis verknüpfte Problemvariante Nicht allen Ereignissen ist eine Problemvariante zugeordnet.
`event_timestamp`	TIMESTAMP	Zeitpunkt des Ereignisses
`device`	RECORD	Das Gerät, auf dem das Ereignis aufgetreten ist
`device.manufacturer`	STRING	Gerätehersteller
`device.model`	STRING	Gerätemodell
`device.architecture`	STRING	Beispiel: `X86_32`, `X86_64`, `ARMV7`, `ARM64`, `ARMV7S` oder `ARMV7K`
`memory`	RECORD	Arbeitsspeicherstatus des Geräts
`memory.used`	INT64	Verwendeter Arbeitsspeicher in Byte
`memory.free`	INT64	Verbleibender Arbeitsspeicher (in Byte)
`storage`	RECORD	Nichtflüchtiger Speicher des Geräts
`storage.used`	INT64	Belegter Speicherplatz in Bytes
`storage.free`	INT64	Verbleibender Speicherplatz in Byte
`operating_system`	RECORD	Informationen zum Betriebssystem auf dem Gerät
`operating_system.display_version`	STRING	Die Version des Betriebssystems auf dem Gerät
`operating_system.name`	STRING	Der Name des Betriebssystems auf dem Gerät
`operating_system.modification_state`	STRING	Ob das Gerät geändert wurde Beispiel: Eine App mit Jailbreak ist `MODIFIED` und eine gerootete App ist `UNMODIFIED`)
`operating_system.type`	STRING	(Nur Apple-Apps) Der Typ des Betriebssystems, das auf dem Gerät ausgeführt wird (z. B. `IOS` oder `MACOS`)
`operating_system.device_type`	STRING	Der Gerätetyp (z. B. `MOBILE`, `TABLET`, `TV` usw.); auch als „Gerätekategorie“ bezeichnet
`application`	RECORD	Die App, durch die das Ereignis generiert wurde
`application.build_version`	STRING	Die Build-Version der App
`application.display_version`	STRING
`user`	RECORD	Optional: Informationen, die über den Nutzer der App erfasst wurden
`user.name`	STRING	Optional: Name des Nutzers
`user.email`	STRING	(Optional) E-Mail-Adresse des Nutzers
`user.id`	STRING	Optional: Eine App-spezifische ID, die dem Nutzer zugeordnet ist
`custom_keys`	WIEDERHOLEN DATENSATZ	Vom Entwickler definierte Schlüssel/Wert-Paare
`custom_keys.key`	STRING	Ein vom Entwickler definierter Schlüssel
`custom_keys.value`	STRING	Ein vom Entwickler definierter Wert
`installation_uuid`	STRING	Eine ID, die eine eindeutige App- und Geräteinstallation identifiziert
`crashlytics_sdk_versions`	STRING	Die SDK-Version „Crashlytics“, die das Ereignis generiert hat
`app_orientation`	STRING	Beispiele: `PORTRAIT`, `LANDSCAPE`, `FACE_UP`, `FACE_DOWN` usw.
`device_orientation`	STRING	Beispiele: `PORTRAIT`, `LANDSCAPE`, `FACE_UP`, `FACE_DOWN` usw.
`process_state`	STRING	`BACKGROUND` oder `FOREGROUND`
`logs`	REPEATED RECORD	Zeitstempelbasierte Logeinträge, die vom Crashlytics-Logger generiert wurden, wenn aktiviert
`logs.timestamp`	TIMESTAMP	Wann das Protokoll erstellt wurde
`logs.message`	STRING	Die protokollierte Nachricht
`breadcrumbs`	WIEDERHOLEN DATENSATZ	Mit Zeitstempel Google Analytics Navigationspfade, wenn aktiviert
`breadcrumbs.timestamp`	TIMESTAMP	Der Zeitstempel, der dem Navigationspfad zugeordnet ist
`breadcrumbs.name`	STRING	Der Name, der mit dem Navigationspfad verknüpft ist
`breadcrumbs.params`	REPEATED RECORD	Mit dem Navigationspfad verknüpfte Parameter
`breadcrumbs.params.key`	STRING	Ein Parameterschlüssel, der dem Navigationspfad zugeordnet ist
`breadcrumbs.params.value`	STRING	Parameterwert, der dem Navigationspfad zugeordnet ist
`blame_frame`	RECORD	Der Frame, der als Ursache des Absturzes oder Fehlers identifiziert wurde
`blame_frame.line`	INT64	Die Zeilennummer der Datei des Frames
`blame_frame.file`	STRING	Der Name der Framedatei
`blame_frame.symbol`	STRING	Das Flüssigkeits-Symbol oder das Rohsymbol, wenn es nicht hydriert werden kann
`blame_frame.offset`	INT64	Der Byte-Offset im Binärbild, das den Code enthält Nicht festgelegt für Java-Ausnahmen
`blame_frame.address`	INT64	Die Adresse im Binärbild, das den Code enthält Nicht festgelegt für Java-Frames
`blame_frame.library`	STRING	Der Anzeigename der Bibliothek, die den Frame enthält
`blame_frame.owner`	STRING	Beispiele: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` oder `SYSTEM`
`blame_frame.blamed`	BOOLEAN	Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache für den Absturz oder Fehler ist
`exceptions`	REPEATED RECORD	(Nur Android) Ausnahmen, die während dieses Ereignisses aufgetreten sind. Verschachtelte Daten Ausnahmen werden in umgekehrter chronologischer Reihenfolge aufgeführt, d. h. Der letzte Eintrag ist die erste ausgelöste Ausnahme.
`exceptions.type`	STRING	Der Ausnahmetyp (z. B. `java.lang.IllegalStateException)`)
`exceptions.exception_message`	STRING	Eine mit der Ausnahme verbundene Nachricht
`exceptions.nested`	BOOLEAN	True für alle Einträge außer der zuletzt geworfenen Ausnahme (d. h. dem ersten Datensatz)
`exceptions.title`	STRING	Der Titel des Threads
`exceptions.subtitle`	STRING	Der Untertitel des Threads
`exceptions.blamed`	BOOLEAN	"True", wenn Crashlytics feststellt, dass die Ausnahme für das Ereignis verantwortlich ist Fehler oder Absturz
`exceptions.frames`	REPEATED RECORD	Die mit der Ausnahme verknüpften Frames
`exceptions.frames.line`	INT64	Die Zeilennummer der Datei des Frames
`exceptions.frames.file`	STRING	Der Name der Framedatei
`exceptions.frames.symbol`	STRING	Das Flüssigkeits-Symbol oder das Rohsymbol, wenn es nicht hydriert werden kann
`exceptions.frames.offset`	INT64	Der Byte-Offset im Binärbild, das den Code enthält Nicht festgelegt für Java-Ausnahmen
`exceptions.frames.address`	INT64	Die Adresse im Binärbild, das den Code enthält Nicht festgelegt für Java-Frames
`exceptions.frames.library`	STRING	Der Anzeigename der Bibliothek, die den Frame enthält
`exceptions.frames.owner`	STRING	Beispiele: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` oder `SYSTEM`
`exceptions.frames.blamed`	BOOLEAN	Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache für den Absturz oder Fehler ist
`error`	REPEATED RECORD	(nur Apple-Apps) Nicht schwerwiegende Fehler
`error.queue_name`	STRING	Die Warteschlange, in der der Thread ausgeführt wurde
`error.code`	INT64	Fehlercode, der mit der benutzerdefinierten NSError der App verknüpft ist
`error.title`	STRING	Der Titel des Threads
`error.subtitle`	STRING	Der Untertitel des Threads
`error.blamed`	BOOLEAN	Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist
`error.frames`	REPEATED RECORD	Die Frames des Stack-Traces
`error.frames.line`	INT64	Die Zeilennummer der Datei des Frames
`error.frames.file`	STRING	Der Name der Framedatei
`error.frames.symbol`	STRING	Das Flüssigkeits-Symbol oder das Rohsymbol, wenn es nicht hydriert werden kann
`error.frames.offset`	INT64	Der Byte-Offset in dem Binärbild, das den Code enthält
`error.frames.address`	INT64	Die Adresse im Binär-Image, die den Code enthält
`error.frames.library`	STRING	Der Anzeigename der Bibliothek, die den Frame enthält
`error.frames.owner`	STRING	Beispiele: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` oder `SYSTEM`
`error.frames.blamed`	BOOLEAN	Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist
`threads`	REPEATED RECORD	Threads, die zum Zeitpunkt des Ereignisses vorhanden waren
`threads.crashed`	BOOLEAN	Ob der Thread abgestürzt ist
`threads.thread_name`	STRING	Name des Threads
`threads.queue_name`	STRING	(Nur Apple-Apps) Die Warteschlange, in der der Thread ausgeführt wurde
`threads.signal_name`	STRING	Der Name des Signals, das zum Absturz der App geführt hat; wird nur angezeigt, wenn die App abgestürzt ist native Threads
`threads.signal_code`	STRING	Den Code des Signals, das zum Absturz der App geführt hat nur vorhanden bei Absturz native Threads
`threads.crash_address`	INT64	Adresse des Signals, das zum Absturz der Anwendung geführt hat nur vorhanden in abgestürzten nativen Threads
`threads.code`	INT64	(Nur Apple-Apps) Fehlercode des benutzerdefinierten Protokolls der Anwendung NS-Fehler
`threads.title`	STRING	Der Titel des Threads
`threads.subtitle`	STRING	Der Untertitel des Threads
`threads.blamed`	BOOLEAN	Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache für den Absturz oder Fehler ist
`threads.frames`	WIEDERHOLEN DATENSATZ	Die Frames des Threads
`threads.frames.line`	INT64	Die Zeilennummer der Datei des Frames
`threads.frames.file`	STRING	Der Name der Framedatei
`threads.frames.symbol`	STRING	Das Symbol für hydratisierte oder das Symbol für Rohdaten, wenn das Material nicht hydratisiert werden kann
`threads.frames.offset`	INT64	Der Byte-Offset in dem Binärbild, das den Code enthält
`threads.frames.address`	INT64	Die Adresse im Binär-Image, die den Code enthält
`threads.frames.library`	STRING	Der Anzeigename der Bibliothek, die den Frame enthält
`threads.frames.owner`	STRING	Beispiele: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` oder `SYSTEM`
`threads.frames.blamed`	BOOLEAN	Ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist
`unity_metadata.unity_version`	STRING	Die Unity-Version, die auf diesem Gerät ausgeführt wird
`unity_metadata.debug_build`	BOOLEAN	Wenn es sich um einen Debug-Build handelt
`unity_metadata.processor_type`	STRING	Die Art des Prozessors
`unity_metadata.processor_count`	INT64	Die Anzahl der Prozessoren (Kerne)
`unity_metadata.processor_frequency_mhz`	INT64	Die Frequenz des Prozessors in MHz
`unity_metadata.system_memory_size_mb`	INT64	Die Größe des Arbeitsspeichers des Systems in MB
`unity_metadata.graphics_memory_size_mb`	INT64	Der Grafikspeicher in MB
`unity_metadata.graphics_device_id`	INT64	ID des Grafikgeräts
`unity_metadata.graphics_device_vendor_id`	INT64	Die Kennung des Anbieters des Grafikprozessors
`unity_metadata.graphics_device_name`	STRING	Name des Grafikgeräts
`unity_metadata.graphics_device_vendor`	STRING	Der Anbieter des Grafikgeräts
`unity_metadata.graphics_device_version`	STRING	Version des Grafikgeräts
`unity_metadata.graphics_device_type`	STRING	Der Typ des Grafikgeräts
`unity_metadata.graphics_shader_level`	INT64	Die Shaderebene der Grafiken
`unity_metadata.graphics_render_target_count`	INT64	Die Anzahl der grafischen Rendering-Ziele
`unity_metadata.graphics_copy_texture_support`	STRING	Unterstützung für das Kopieren von Grafiktextur gemäß der Unity API
`unity_metadata.graphics_max_texture_size`	INT64	Die maximale Größe für das Rendering von Texturen
`unity_metadata.screen_size_px`	STRING	Die Größe des Bildschirms in Pixeln, formatiert als Breite x Höhe
`unity_metadata.screen_resolution_dpi`	STRING	Der DPI-Wert des Bildschirms als Gleitkommazahl
`unity_metadata.screen_refresh_rate_hz`	INT64	Die Aktualisierungsrate des Bildschirms in Hz

Exportierte Crashlytics-Daten mit Data Studio visualisieren

Google Data Studio Crashlytics Datasets in BigQuery in Berichte umwandeln, die leichter zu verstehen sind lesbar, leichter zu teilen und vollständig anpassbar.

Weitere Informationen zur Verwendung von Data Studio finden Sie in der Data Studio-Kurzanleitung. Willkommen bei Data Studio.

Crashlytics-Berichtsvorlage verwenden

Data Studio bietet einen Beispielbericht für Crashlytics. Dieser enthält umfassende Dimensionen und Messwerte des exportierten Crashlytics-BigQuery-Schemas. Wenn Sie den Streamingexport von Crashlytics nach BigQuery aktiviert haben, können Sie diese Daten auf der Seite Echtzeittrends der Data Studio-Vorlage aufrufen. Sie können das Beispiel als Vorlage verwenden, um schnell neue Berichte und Visualisierungen auf Grundlage der Rohdaten der Abstürze Ihrer App zu erstellen:

Öffnen Sie das Crashlytics Data Studio-Dashboard-Vorlage.
Klicken Sie rechts oben auf Vorlage verwenden.
Wählen Sie im Drop-down-Menü Neue Datenquelle die Option Neue Datenquelle erstellen aus.
Klicken Sie auf der Karte BigQuery auf Auswählen.
Wählen Sie unter Meine Projekte > PROJECT_ID > firebase_crashlytics > TABLE_NAME eine Tabelle mit exportierten Crashlytics-Daten aus.

Ihre Batch-Tabelle kann jederzeit ausgewählt werden. Wenn Crashlytics-Streaming-Export nach BigQuery aktiviert ist, dann haben Sie können Sie stattdessen Ihre Realtime-Tabelle auswählen.
Legen Sie unter Konfiguration die Option Crashlytics-Vorlagenebene fest auf Standard:
Klicken Sie auf Verbinden, um die neue Datenquelle zu erstellen.
Klicken Sie auf Zum Bericht hinzufügen, um zur Crashlytics-Vorlage zurückzukehren.
Klicken Sie abschließend auf Bericht erstellen, um eine Kopie der Vorlage „Crashlytics Data Studio-Dashboard“ zu erstellen.