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, zu einem anderen Cloud-Anbieter exportieren und mit Google Data Studio visualisieren und benutzerdefinierte Dashboards erstellen.

Export nach BigQuery aktivieren

Rufen Sie in der Firebase Console die Seite Einbindungen auf.
Klicken Sie auf der Karte BigQuery auf Verknüpfen.
Folgen Sie der Anleitung auf dem Bildschirm, um den Export nach BigQuery zu aktivieren.

Wenn Sie nahezu in Echtzeit auf Ihre Crashlytics-Daten in BigQuery zugreifen möchten, sollten Sie ein Upgrade auf den Streaming-Export in Betracht ziehen.

Was passiert, wenn Sie den Export aktivieren?

Sie wählen den Speicherort des Datasets aus. Nachdem das Dataset erstellt wurde, kann der Standort nicht mehr geändert werden. Sie können das Dataset aber an einen anderen Standort kopieren oder es manuell verschieben, d. h. an einem anderen Standort neu erstellen. Weitere Informationen finden Sie unter Speicherort für vorhandene Exporte ändern.

Dieser Speicherort gilt nur für die in BigQuery exportierten Daten und hat keine Auswirkungen auf den Speicherort von Daten, die für die Verwendung im Crashlytics-Dashboard der Firebase-Konsole oder in Android Studio gespeichert werden.

Hinweis :Die Möglichkeit, den Speicherort für den Datenexport auszuwählen und zu ändern, ist nur verfügbar, wenn Sie den Export nach Mitte Oktober 2024 aktiviert haben oder wenn Sie auf die neue Exportinfrastruktur umgestellt haben.
Standardmäßig werden alle Apps in Ihrem Projekt mit BigQuery verknüpft. Alle Apps, die Sie dem Projekt später hinzufügen, werden ebenfalls automatisch mit BigQuery verknüpft. Sie können festlegen, welche Apps Daten senden.
Firebase richtet tägliche Synchronisierungen Ihrer Daten mit BigQuery ein.
- Nachdem Sie Ihr Projekt verknüpft haben, müssen Sie in der Regel bis zur Synchronisierung am nächsten Tag warten, bis Ihre ersten Daten nach BigQuery exportiert werden.
- Die tägliche Synchronisierung erfolgt einmal pro Tag, unabhängig von geplanten Exporten, die Sie in BigQuery eingerichtet haben. Das Timing und die Dauer des Synchronisierungsjobs können sich ändern. Wir empfehlen daher nicht, Downstream-Vorgänge oder ‑Jobs auf Grundlage eines bestimmten Timings des Exports zu planen.
Firebase exportiert eine Kopie Ihrer vorhandenen Daten nach BigQuery. Die erste Übertragung von Daten für den Export kann bis zu 48 Stunden dauern.
- Für jede verknüpfte App enthält dieser Export eine Batch-Tabelle mit den Daten aus der täglichen Synchronisierung.
- Sie können Daten-Backfills für die Batch-Tabelle manuell planen, und zwar für die letzten 30 Tage oder für das letzte Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, welches Datum aktueller ist).
Wenn Sie den Export von Crashlytics-Daten vor Mitte Oktober 2024 aktiviert haben, können Sie auch Daten für 30 Tage vor dem Tag, an dem Sie den Export aktiviert haben, nachträglich einfügen.
Wenn Sie den Crashlytics-Streaming-Export nach BigQuery aktivieren, enthalten alle verknüpften Apps auch eine Echtzeittabelle mit ständig aktualisierten Daten.

Wenn Sie den Export nach BigQuery deaktivieren möchten, heben Sie die Verknüpfung Ihres Projekts in der Firebase-Konsole auf.

Welche Daten werden nach BigQuery exportiert?

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

Daten für eine Android-App mit dem Paketnamen com.google.test befinden sich beispielsweise in einer Tabelle mit dem Namen com_google_test_ANDROID. Diese Batchtabelle wird einmal täglich aktualisiert. Wenn Sie den Crashlytics-Streaming-Export nach BigQuery aktivieren, werden Crashlytics-Daten auch in Echtzeit in eine Tabelle mit dem Namen com_google_test_ANDROID_REALTIME gestreamt.

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

Crashlytics-Streaming-Export nach BigQuery

Mit BigQuery-Streaming können Sie Ihre Crashlytics-Daten in Echtzeit streamen. Sie können es für jeden Zweck verwenden, der Live-Daten erfordert, z. B. zum Präsentieren von Informationen in einem Live-Dashboard, zum Beobachten eines Rollouts in Echtzeit oder zum Überwachen von Anwendungsproblemen, die Benachrichtigungen und benutzerdefinierte Workflows auslösen.

Wenn Sie den Crashlytics-Streaming-Export nach BigQuery aktivieren, haben Sie zusätzlich zur Batchtabelle auch eine Echtzeittabelle. Hier sind die Unterschiede zwischen den Tabellen, die Sie kennen sollten:

Batch-Tabelle	Echtzeittabelle
Die Daten werden einmal täglich exportiert. Ereignisse werden dauerhaft gespeichert, bevor sie im Batchverfahren in BigQuery geschrieben werden. Daten können bis zu 30 Tage rückwirkend nachgetragen werden*.	Die Daten werden in Echtzeit exportiert. Es ist kein Backfilling verfügbar.

Die Batchtabelle eignet sich ideal für langfristige Analysen und die Ermittlung von Trends im Zeitverlauf, da Ereignisse dauerhaft gespeichert werden, bevor sie geschrieben werden. Außerdem können sie bis zu 30 Tage* lang in die Tabelle eingefügt werden. Wenn wir Daten in Ihre Echtzeittabelle schreiben, werden sie sofort in BigQuery geschrieben. Daher ist sie 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 beträgt die Ablaufzeit von Partitionen für die Echtzeittabelle 30 Tage. Informationen zum Ändern dieser Einstellung finden Sie in der BigQuery-Dokumentation unter Partitionsablauf festlegen.

^{* Details zur Unterstützung von Backfills finden Sie unter Auf die neue Exportinfrastruktur umstellen.}

Crashlytics-Streaming-Export nach BigQuery aktivieren

Rufen Sie in der Firebase Console die Seite Einbindungen 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.

Sie sehen keine Daten in Ihrer Echtzeittabelle?

Sie müssen mindestens zwei Ereignisse aus Ihrer App an Crashlytics gesendet und einige Minuten gewartet haben, nachdem Sie sie gesendet haben.
Ihr Firebase-Projekt muss den Blaze-Tarif (Pay as you go) verwenden.
Sie können dies überprüfen, indem Sie unten links in der Firebase-Konsole nachsehen.
Wenn nach dem Senden von zwei Ereignissen und einigen Minuten Wartezeit immer noch keine Daten in der Echtzeittabelle angezeigt werden, gehen Sie so vor:
1. Rufen Sie in der Firebase-Konsole die Karte BigQuery auf.
2. Deaktiviere den Streaming-Export und aktiviere ihn dann wieder.
3. Achten Sie darauf, dass das Dienstkonto service-PROJECT_NUMBER@gcp-sa-crashlytics.iam.gserviceaccount.com in Ihrem Firebase-Projekt vorhanden ist und die Rolle Firebase Crashlytics Service Agent hat.
  Sie können dies auf der Seite IAM der Google Cloud-Konsole prüfen. Achten Sie darauf, dass das Kästchen Von Google bereitgestellte Rollenzuweisungen einschließen angeklickt ist.
4. Senden Sie mindestens zwei Ereignisse an Crashlytics und warten Sie einige Minuten.
Wenn Sie weiterhin keine Daten in Ihrer Echtzeittabelle sehen, wenden Sie sich an den Firebase-Support.

Was kann ich mit den exportierten Daten tun?

Exporte nach BigQuery enthalten Rohdaten zu Abstürzen, darunter Gerätetyp, Betriebssystem, Ausnahmen (Android-Apps) oder Fehler (Apple-Apps) und Crashlytics-Logs sowie andere Daten.

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

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 in der BigQuery-Dokumentation unter Ansichten erstellen.

Abfragen ausführen

Die folgenden Beispiele zeigen Abfragen, die Sie für Ihre Crashlytics-Daten ausführen können, um Berichte zu erstellen, in denen Daten zu Absturzereignissen übersichtlicher zusammengefasst werden. Da diese Arten von Berichten 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 Programmfehler wie möglich behoben haben, ist Ihr Team der Meinung, dass die Foto-Sharing-App jetzt herausgebracht werden kann. Zuvor möchten Sie jedoch noch die Anzahl der täglichen Abstürze im vergangenen Monat überprüfen. Sie möchten sichergehen, dass die App aufgrund der Fehlerbehebungen im Lauf der Zeit stabiler geworden ist.

Hier ist ein Beispiel für eine Anfrage für eine Android-App. Verwenden Sie für eine 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 häufigsten Abstürze finden

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 ein Beispiel für eine Anfrage 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: Die 10 Geräte, auf denen die App am häufigsten abstürzt

Im Herbst kommen die neuen Smartphones auf den Markt! Ihr Unternehmen weiß, dass dadurch auch neue gerätespezifische Probleme auftreten – insbesondere bei Android. 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 ein Beispiel für eine Anfrage 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 Ihr Spiel am häufigsten abstürzt.

Um diese Statistik zu erfassen, legen Sie einen benutzerdefinierten Crashlytics-Schlüssel mit dem Namen 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 Werte für current_level zu protokollieren.

Hier ist ein Beispiel für eine Anfrage für eine Android-App. Verwenden Sie für eine 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 extrahieren

Sie haben eine Android-App im Early Access-Programm. Die meisten Nutzer sind begeistert, während bei dreien ungewöhnlich viele Abstürze aufgetreten sind. Zur Ermittlung der Ursache schreiben Sie eine Abfrage, mit der alle Absturzereignisse der betroffenen Nutzer anhand ihrer Nutzer-IDs abgerufen werden.

Hier ist ein Beispiel für eine Anfrage für eine Android-App. Verwenden Sie für eine 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 mit einem bestimmten Absturzproblem finden

Ihr Team hat versehentlich einen kritischen Fehler für eine Gruppe von Betatestern freigegeben. Ihr Team konnte die Abfrage aus dem Beispiel „Häufigste Abstürze finden“ oben verwenden, um die spezifische Absturzproblem-ID zu ermitteln. Ihr Team möchte nun eine Abfrage ausführen, um die Liste der App-Nutzer zu extrahieren, die von diesem Absturz betroffen waren.

Hier ist ein Beispiel für eine Anfrage 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 während der Einführung eines neuen Releases einen kritischen Fehler erkannt. Sie konnten die Abfrage aus dem Beispiel „Häufigste Abstürze finden“ oben verwenden, um die spezifische Absturzproblem-ID zu ermitteln. Ihr Team möchte nun herausfinden, ob dieser Absturz auch bei Nutzern in anderen Ländern aufgetreten ist.

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

Export von Google Analytics-Daten nach BigQuery aktivieren. Weitere Informationen finden Sie unter 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");

Schreiben Sie eine Abfrage, mit der Ereignisse im Dataset Google Analytics mit Abstürzen im Dataset Crashlytics verknüpft werden. Verwenden Sie dazu das Feld „user_id“.

Hier ist ein Beispiel für eine Anfrage 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 fünf häufigsten Probleme bisher heute

Hier ist ein Beispiel für eine Anfrage 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: Die fünf wichtigsten 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 DISTINCT event_id verwenden, um gemeinsame Ereignisse aus den beiden Tabellen zu deduplizieren.

Hier ist ein Beispiel für eine Anfrage 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 Ereignissen, die bis zu zwei Tage vor der Verknüpfung aufgetreten sind. Sie haben die Möglichkeit, bis zu 30 Tage lang 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

Mit Crashlytics wird ein neues Dataset in BigQuery für Crashlytics-Daten erstellt. Das Dataset deckt das gesamte Projekt ab, selbst wenn dieses mehrere Apps umfasst.

Tabellen

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

Daten für eine Android-App mit dem Paketnamen com.google.test befinden sich beispielsweise in einer Tabelle mit dem Namen com_google_test_ANDROID und Echtzeitdaten (sofern aktiviert) in einer Tabelle mit dem Namen com_google_test_ANDROID_REALTIME.

Tabellen enthalten einen Standardsatz von Crashlytics-Daten sowie alle benutzerdefinierten Crashlytics-Schlüssel, die Sie in Ihrer App definiert haben.

Zeilen

Jede Zeile der Tabelle stellt einen Fehler der Anwendung dar.

Spalten

Die Spalten der Tabelle sind für Abstürze, nicht schwerwiegende Fehler und ANRs identisch. Wenn der Crashlytics-Streamingexport nach BigQuery aktiviert ist, hat die Echtzeittabelle dieselben Spalten wie die Batchtabelle. Beachten Sie, dass es in Zeilen Spalten geben kann, die Ereignisse ohne Stacktraces darstellen.

Die Spalten innerhalb des Exports sind in dieser Tabelle aufgeführt:

Feldname	Datentyp	Beschreibung
`platform`	STRING	Die Plattform der App, wie sie im Firebase-Projekt registriert ist (gültige Werte: `IOS` oder `ANDROID`)
`bundle_identifier`	STRING	Die eindeutige Kennung der App, wie sie im Firebase-Projekt registriert ist (z. B. `com.google.gmail`) Bei Apps für Apple-Plattformen ist dies die Bundle-ID der App. Bei Android-Apps ist dies der Paketname der App.
`event_id`	STRING	Die eindeutige ID für das Ereignis
`is_fatal`	BOOLEAN	Dieses Feld wurde eingestellt. Verwenden Sie stattdessen `error_type`. Gibt an, 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 verknüpfte Problem
`variant_id`	STRING	Die mit diesem Ereignis verknüpfte Problemvariante Hinweis: Nicht alle Ereignisse haben eine zugehörige Problemvariante.
`event_timestamp`	TIMESTAMP	Zeitpunkt des Ereignisses
`device`	DATENSATZ	Das Gerät, auf dem das Ereignis aufgetreten ist
`device.manufacturer`	STRING	Der Gerätehersteller
`device.model`	STRING	Das Gerätemodell
`device.architecture`	STRING	Beispiel: `X86_32`, `X86_64`, `ARMV7`, `ARM64`, `ARMV7S` oder `ARMV7K`
`memory`	DATENSATZ	Speicherstatus des Geräts
`memory.used`	INT64	Verwendete Arbeitsspeicher-Bytes
`memory.free`	INT64	Verbleibende Arbeitsspeicherbytes
`storage`	DATENSATZ	Der nichtflüchtige Speicher des Geräts
`storage.used`	INT64	Genutzter Speicherplatz in Bytes
`storage.free`	INT64	Verbleibende Bytes des Speicherplatzes
`operating_system`	DATENSATZ	Details 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	Gibt an, ob das Gerät manipuliert wurde (z. B. 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`, `MACOS` usw.)
`operating_system.device_type`	STRING	Der Gerätetyp (z. B. `MOBILE`, `TABLET`, `TV` usw.), auch als „Gerätekategorie“ bezeichnet
`application`	DATENSATZ	Die App, durch die das Ereignis hervorgerufen wurde
`application.build_version`	STRING	Die Build-Version der App
`application.display_version`	STRING
`user`	DATENSATZ	(Optional) Informationen, die über den Nutzer der App erhoben werden
`user.name`	STRING	Dieses Feld wurde eingestellt. Verwenden Sie es nicht. (Optional): Name des Nutzers
`user.email`	STRING	Dieses Feld wurde eingestellt. Verwenden Sie es nicht. (Optional) Die E-Mail-Adresse des Nutzers
`user.id`	STRING	(Optional) Eine appspezifische ID, die mit dem Nutzer verknüpft ist
`custom_keys`	WIEDERHOLTE AUFZEICHNUNG	Von Entwicklern 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 Crashlytics SDK-Version, 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`	WIEDERHOLTE AUFZEICHNUNG	Zeitgestempelte Logmeldungen, die vom Crashlytics-Logger generiert werden, sofern aktiviert
`logs.timestamp`	TIMESTAMP	Wann das Log erstellt wurde
`logs.message`	STRING	Die protokollierte Nachricht
`breadcrumbs`	WIEDERHOLTE AUFZEICHNUNG	Zeitstempel für Google Analytics-Navigationspfade, sofern aktiviert
`breadcrumbs.timestamp`	TIMESTAMP	Der Zeitstempel für den Breadcrumb
`breadcrumbs.name`	STRING	Der Name, der mit dem Breadcrumb verknüpft ist
`breadcrumbs.params`	WIEDERHOLTE AUFZEICHNUNG	Parameter, die mit dem Breadcrumb verknüpft sind
`breadcrumbs.params.key`	STRING	Ein Parameterschlüssel, der dem Breadcrumb zugeordnet ist
`breadcrumbs.params.value`	STRING	Ein Parameterwert, der dem Breadcrumb zugeordnet ist
`blame_frame`	DATENSATZ	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 Frame-Datei
`blame_frame.symbol`	STRING	Das gerenderte Symbol oder das Rohsymbol, wenn es nicht gerendert werden kann
`blame_frame.offset`	INT64	Der Byte-Offset im binären Image, das den Code enthält Für Java-Ausnahmen nicht festgelegt
`blame_frame.address`	INT64	Die Adresse im Binärbild, die den Code enthält. Für Java-Frames nicht festgelegt.
`blame_frame.library`	STRING	Der Anzeigename der Bibliothek, die den Frame enthält
`blame_frame.owner`	STRING	Beispiel: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` oder `SYSTEM`
`blame_frame.blamed`	BOOLEAN	Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers ist.
`exceptions`	WIEDERHOLTE AUFZEICHNUNG	(Nur Android) Ausnahmen, die während dieses Ereignisses aufgetreten sind. Verschachtelte Ausnahmen werden in umgekehrter chronologischer Reihenfolge dargestellt. Das bedeutet, dass der letzte Datensatz die erste ausgelöste Ausnahme ist.
`exceptions.type`	STRING	Der Ausnahmetyp (z. B. `java.lang.IllegalStateException)`)
`exceptions.exception_message`	STRING	Eine Nachricht, die mit der Ausnahme verknüpft ist
`exceptions.nested`	BOOLEAN	Wahr für alle außer der zuletzt ausgelösten Ausnahme (d. h. dem ersten Datensatz)
`exceptions.title`	STRING	Der Titel des Threads
`exceptions.subtitle`	STRING	Der Untertitel des Threads
`exceptions.blamed`	BOOLEAN	Wahr, wenn Crashlytics feststellt, dass die Ausnahme für den Fehler oder Absturz verantwortlich ist.
`exceptions.frames`	WIEDERHOLTE AUFZEICHNUNG	Die mit der Ausnahme verknüpften Frames
`exceptions.frames.line`	INT64	Die Zeilennummer der Datei des Frames
`exceptions.frames.file`	STRING	Der Name der Frame-Datei
`exceptions.frames.symbol`	STRING	Das gerenderte Symbol oder das Rohsymbol, wenn es nicht gerendert werden kann
`exceptions.frames.offset`	INT64	Der Byte-Offset im binären Image, das den Code enthält Für Java-Ausnahmen nicht festgelegt
`exceptions.frames.address`	INT64	Die Adresse im Binärbild, die den Code enthält. Für Java-Frames nicht festgelegt.
`exceptions.frames.library`	STRING	Der Anzeigename der Bibliothek, die den Frame enthält
`exceptions.frames.owner`	STRING	Beispiel: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` oder `SYSTEM`
`exceptions.frames.blamed`	BOOLEAN	Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers ist.
`error`	WIEDERHOLTE AUFZEICHNUNG	(Nur Apple-Apps) Nicht schwerwiegende Fehler
`error.queue_name`	STRING	Die Warteschlange, in der der Thread ausgeführt wurde
`error.code`	INT64	Fehlercode, der dem benutzerdefinierten protokollierten NSError der App zugeordnet ist
`error.title`	STRING	Der Titel des Threads
`error.subtitle`	STRING	Der Untertitel des Threads
`error.blamed`	BOOLEAN	Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist.
`error.frames`	WIEDERHOLTE AUFZEICHNUNG	Die Frames des Stacktrace
`error.frames.line`	INT64	Die Zeilennummer der Datei des Frames
`error.frames.file`	STRING	Der Name der Frame-Datei
`error.frames.symbol`	STRING	Das gerenderte Symbol oder das Rohsymbol, wenn es nicht gerendert werden kann
`error.frames.offset`	INT64	Der Byte-Offset in das binäre Image, das den Code enthält
`error.frames.address`	INT64	Die Adresse im Binärbild, die den Code enthält
`error.frames.library`	STRING	Der Anzeigename der Bibliothek, die den Frame enthält
`error.frames.owner`	STRING	Beispiel: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` oder `SYSTEM`
`error.frames.blamed`	BOOLEAN	Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Fehlers ist.
`threads`	WIEDERHOLTE AUFZEICHNUNG	Threads, die zum Zeitpunkt des Ereignisses vorhanden waren
`threads.crashed`	BOOLEAN	Ob der Thread abgestürzt ist
`threads.thread_name`	STRING	Der 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. Ist nur bei abgestürzten nativen Threads vorhanden.
`threads.signal_code`	STRING	Der Code des Signals, das zum Absturz der App geführt hat. Ist nur bei abgestürzten nativen Threads vorhanden.
`threads.crash_address`	INT64	Die Adresse des Signals, das den Absturz der Anwendung verursacht hat. Ist nur bei abgestürzten nativen Threads vorhanden.
`threads.code`	INT64	(Nur Apple-Apps) Fehlercode des benutzerdefinierten protokollierten NSError der Anwendung
`threads.title`	STRING	Der Titel des Threads
`threads.subtitle`	STRING	Der Untertitel des Threads
`threads.blamed`	BOOLEAN	Gibt an, ob Crashlytics festgestellt hat, dass dieser Frame die Ursache des Absturzes oder Fehlers ist.
`threads.frames`	WIEDERHOLTE AUFZEICHNUNG	Die Frames des Threads
`threads.frames.line`	INT64	Die Zeilennummer der Datei des Frames
`threads.frames.file`	STRING	Der Name der Frame-Datei
`threads.frames.symbol`	STRING	Das gerenderte Symbol oder das Rohsymbol, wenn es nicht gerendert werden kann
`threads.frames.offset`	INT64	Der Byte-Offset in das binäre Image, das den Code enthält
`threads.frames.address`	INT64	Die Adresse im Binärbild, die den Code enthält
`threads.frames.library`	STRING	Der Anzeigename der Bibliothek, die den Frame enthält
`threads.frames.owner`	STRING	Beispiel: `DEVELOPER`, `VENDOR`, `RUNTIME`, `PLATFORM` oder `SYSTEM`
`threads.frames.blamed`	BOOLEAN	Gibt an, 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	Prozessortyp
`unity_metadata.processor_count`	INT64	Anzahl der Prozessoren (Kerne)
`unity_metadata.processor_frequency_mhz`	INT64	Die Frequenz des Prozessors bzw. der Prozessoren in MHz
`unity_metadata.system_memory_size_mb`	INT64	Größe des Systemspeichers in MB
`unity_metadata.graphics_memory_size_mb`	INT64	Der Grafikspeicher in MB
`unity_metadata.graphics_device_id`	INT64	Die Kennung des Grafikgeräts
`unity_metadata.graphics_device_vendor_id`	INT64	Die Kennung des Anbieters des Grafikprozessors
`unity_metadata.graphics_device_name`	STRING	Der Name des Grafikgeräts
`unity_metadata.graphics_device_vendor`	STRING	Der Anbieter des Grafikgeräts
`unity_metadata.graphics_device_version`	STRING	Die Version des Grafikgeräts
`unity_metadata.graphics_device_type`	STRING	Der Typ des Grafikgeräts
`unity_metadata.graphics_shader_level`	INT64	Die Shader-Ebene der Grafik
`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 Grafiktexturen gemäß der Unity API
`unity_metadata.graphics_max_texture_size`	INT64	Maximale Größe für das Rendern von Texturen
`unity_metadata.screen_size_px`	STRING	Die Größe des Bildschirms in Pixeln im Format „Breite × Höhe“
`unity_metadata.screen_resolution_dpi`	STRING	Die DPI des Bildschirms als Gleitkommazahl
`unity_metadata.screen_refresh_rate_hz`	INT64	Die Aktualisierungsrate des Displays in Hz

Exportierte Crashlytics-Daten mit Data Studio visualisieren

Mit Google Data Studio lassen sich Ihre Crashlytics-Datensätze in BigQuery in Berichte umwandeln, die übersichtlicher sind, sich einfacher teilen lassen und vollständig angepasst werden können.

Weitere Informationen zur Verwendung von Data Studio finden Sie in der Kurzanleitung zu Data Studio.

Crashlytics-Berichtsvorlage verwenden

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

Öffnen Sie die Crashlytics Data Studio-Dashboardvorlage.
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 Batchtabelle ist immer verfügbar. Wenn der Crashlytics-Streaming-Export nach BigQuery aktiviert ist, können Sie stattdessen Ihre Echtzeittabelle auswählen.
Setzen Sie unter Konfiguration die Option Crashlytics-Vorlagenebene auf Standard.
Klicken Sie auf Verbinden, um die neue Datenquelle zu erstellen.
Klicken Sie auf Zum Bericht hinzufügen, um zur Vorlage Crashlytics zurückzukehren.
Klicken Sie abschließend auf Bericht erstellen, um eine Kopie der Vorlage für das Crashlytics-Data Studio-Dashboard zu erstellen.

Upgrade auf die neue Exportinfrastruktur

Mitte Oktober 2024 hat Crashlytics eine neue Infrastruktur für den Batch-Export von Crashlytics-Daten in BigQuery eingeführt.

Alle Firebase-Projekte werden bereits am 15. September 2025 automatisch auf die neue Infrastruktur für den Batch-Export umgestellt. Sie können vor diesem Datum ein Upgrade durchführen. Achten Sie jedoch darauf, dass Ihre BigQuery-Batchtabellen die Voraussetzungen für ein Upgrade erfüllen.

Sie können ein Upgrade auf die neue Infrastruktur durchführen. Achten Sie jedoch darauf, dass Ihre BigQuery-Batchtabellen die Voraussetzungen für das Upgrade erfüllen.

Prüfen, ob Sie die neue Infrastruktur verwenden

Wenn Sie den Batch-Export Mitte Oktober 2024 oder später aktiviert haben, wird in Ihrem Firebase-Projekt automatisch die neue Exportinfrastruktur verwendet.

So können Sie prüfen, welche Infrastruktur für Ihr Projekt verwendet wird: Rufen Sie die Google Cloud-Konsole auf. Wenn Ihre Konfiguration für die Datenübertragung mit Firebase Crashlytics with Multi-Region Support gekennzeichnet ist, wird für Ihr Projekt die neue Exportinfrastruktur verwendet.

Wichtige Unterschiede zwischen der alten und der neuen Exportinfrastruktur

Die neue Infrastruktur unterstützt Crashlytics-Dataset-Standorte außerhalb der USA.
- Der Export wurde vor Mitte Oktober 2024 aktiviert und auf die neue Exportinfrastruktur aktualisiert: Sie können jetzt optional den Speicherort für den Datenexport ändern.
- Export ab Mitte Oktober 2024 aktiviert: Bei der Einrichtung wurden Sie aufgefordert, einen Speicherort für den Datenexport auszuwählen.
Die neue Infrastruktur unterstützt keine Backfills von Daten aus der Zeit vor der Aktivierung des Exports.
- In der alten Infrastruktur war ein Backfill bis zu 30 Tage vor dem Datum möglich, an dem Sie den Export aktiviert haben.
- Die neue Infrastruktur unterstützt Backfills bis zu den letzten 30 Tagen oder bis zum letzten Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was zuletzt war).
Die neuen Infrastrukturnamen BigQuery Batch-Tabellen mit den Kennungen, die für Ihre Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.
- In der alten Infrastruktur wurden Daten in Batchtabellen mit Namen geschrieben, die auf den Bundle-IDs oder Paketnamen in der Firebase-Konfiguration in der Codebasis Ihrer App basierten.
- In der neuen Infrastruktur werden Daten in Batchtabellen geschrieben, deren Namen auf den Paket-IDs oder Paketnamen basieren, die für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind.
Wichtig :Wenn Sie den Batch-Export vor Mitte Oktober 2024 aktiviert haben, müssen Ihre vorhandenen Batch-Tabellen die Voraussetzung in Bezug auf Bundle-IDs und Paketnamen erfüllen, bevor Sie manuell auf die neue Exportinfrastruktur umstellen oder vor dem 15. September 2025 (wenn alle Projekte automatisch aktualisiert werden).

Schritt 1: Voraussetzungen für das Upgrade

Prüfen Sie, ob in den vorhandenen BigQuery-Batchtabellen dieselben Kennungen wie die für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegten Paket-IDs oder Paketnamen verwendet werden. Wenn sie nicht übereinstimmen, kann es zu Unterbrechungen bei den exportierten Batchdaten kommen. Die meisten Projekte sind in einem geeigneten und kompatiblen Zustand. Es ist jedoch wichtig, dies vor dem Upgrade zu prüfen.
- Alle in Ihrem Firebase-Projekt registrierten Firebase-Apps finden Sie in der Firebase Console: Rufen Sie die Projekteinstellungen auf und scrollen Sie dann zur Karte Ihre Apps, um alle Ihre Firebase-Apps und die zugehörigen Informationen zu sehen.
- Alle Ihre BigQuery-Batchtabellen finden Sie in der BigQuery-Seite der Google Cloud-Konsole.
Hinweis: BigQuery-Streamingtabellen, die mit REALTIME enden, sind von der neuen Exportinfrastruktur nicht betroffen und können ignoriert werden.

Hier sind einige Beispiele für ideale Zustände, in denen beim Upgrade keine Probleme auftreten:
- Sie haben eine Batch-Tabelle mit dem Namen com_yourcompany_yourproject_IOS und eine Firebase iOS+-App mit der Bundle-ID com.yourcompany.yourproject, die in Ihrem Firebase-Projekt registriert ist.
- Sie haben eine Batchtabelle mit dem Namen com_yourcompany_yourproject_ANDROID und eine Firebase-Android-App mit dem Paketnamen com.yourcompany.yourproject, die in Ihrem Firebase-Projekt registriert ist.
Wenn Sie Batchtabellennamen haben, die nicht mit den für Ihre registrierten Firebase-Apps festgelegten Kennungen übereinstimmen, folgen Sie der Anleitung auf dieser Seite vor dem manuellen Upgrade oder vor dem 15. September 2025, um Unterbrechungen beim Batchexport zu vermeiden.

Schritt 2: Manuelles Upgrade auf die neue Infrastruktur

Wenn Sie den Batch-Export vor Mitte Oktober 2024 aktiviert haben, können Sie manuell auf die neue Infrastruktur umstellen, indem Sie den Crashlytics-Datenexport in der Firebase-Konsole deaktivieren und dann wieder aktivieren.

So gehts:

Rufen Sie in der Firebase Console die Seite Einbindungen auf.
Klicken Sie auf der Karte BigQuery auf Verwalten.
Deaktivieren Sie den Schieberegler Crashlytics, um den Export zu deaktivieren. Bestätige, dass du den Datenexport beenden möchtest.
Aktivieren Sie den Schieberegler Crashlytics sofort wieder, um den Export zu reaktivieren. Bestätige, dass du Daten exportieren möchtest.

Ihr Crashlytics-Datenexport nach BigQuery erfolgt jetzt über die neue Exportinfrastruktur.

Der Name der vorhandenen Batchtabelle stimmt nicht mit der Kennung Ihrer Firebase-App überein.

Wenn der Name der vorhandenen Batchtabelle nicht mit der Paket-ID oder dem Paketnamen übereinstimmt, die für Ihre registrierte Firebase-App festgelegt sind, maximieren Sie diesen Abschnitt und implementieren Sie eine der Optionen, um Unterbrechungen bei den exportierten Batchdaten zu vermeiden.

Wenn Sie vorhandene BigQuery-Batchtabellen in diesem Status haben, sind sie nicht mit der neuen Firebase-Infrastruktur für den Batch-Export nach BigQuery kompatibel. Alle Firebase-Projekte werden bereits am 15. September 2025 automatisch zur neuen Exportinfrastruktur migriert.

Folgen Sie der Anleitung in diesem Abschnitt vor dem manuellen Upgrade oder vor dem 15. September 2025, um Unterbrechungen beim Batch-Export Ihrer Crashlytics-Daten nach BigQuery zu vermeiden.

Zu den Anleitungen für Optionen zur Vermeidung von Unterbrechungen springen

So werden mit der Exportinfrastruktur Kennungen verwendet, um Daten in BigQuery-Tabellen zu schreiben

So werden Crashlytics-Daten in BigQuery-Batchtabellen geschrieben:

Alte Exportinfrastruktur: Daten werden in eine Tabelle mit einem Namen geschrieben, der auf der Paket-ID oder dem Paketnamen in der Firebase-Konfiguration im Code Ihrer App basiert (normalerweise aus Ihrer GoogleService-Info.plist-Datei oder google-services.json-Datei).
Neue Exportinfrastruktur: Daten werden in eine Tabelle mit einem Namen geschrieben, der auf der Paket-ID oder dem Paketnamen basiert, die für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt sind.

Leider stimmt die Paket-ID oder der Paketname in der Konfiguration in Ihrer Codebasis manchmal nicht mit der Paket-ID oder dem Paketnamen überein, die für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt sind. Das passiert normalerweise, wenn jemand die Konfigurationsdatei in der Codebasis Ihrer App manuell geändert oder bei der App-Registrierung nicht die tatsächliche Kennung eingegeben hat.

Was passiert, wenn das Problem nicht behoben wird, bevor ich ein Upgrade durchführe?

Wenn die Kennungen an diesen beiden Stellen nicht übereinstimmen, passiert nach der Umstellung auf die neue Exportinfrastruktur Folgendes:

Ihre Crashlytics-Daten werden in eine neue BigQuery-Batchtabelle geschrieben. Das ist eine neue Tabelle mit einem Namen, der auf der Paket-ID oder dem Paketnamen basiert, die für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegt sind.
In alle vorhandenen „Legacy“-Tabellen mit einem Namen, der auf der ID in der Konfiguration in Ihrem Code basiert, werden keine Daten mehr geschrieben.

Beispielszenarien für nicht übereinstimmende Kennzeichnungen

BigQuery-Batchtabellennamen wird automatisch _IOS oder _ANDROID angehängt, um die Plattform der App anzugeben.

Kennungen im Code Ihrer App	Für Ihre Firebase-App(s) festgelegte Kennung(en)	Legacy-Verhalten	Verhalten nach dem Upgrade auf die neue Exportinfrastruktur	Lösung
`foo`	`bar`	Schreibt in eine einzelne Tabelle, die nach dem Bezeichner in der Codebasis der App benannt ist (`foo`).	Erstellt dann eine einzelne Tabelle, die nach der für die Firebase-App festgelegten ID (`bar`) benannt ist, und schreibt Daten in diese Tabelle.	Implementieren Sie entweder Option 1 oder Option 2, die unten beschrieben werden.
`foo`	`bar`, `qux` usw.	Schreibt in eine einzelne Tabelle, die nach dem Bezeichner in der Codebasis der App benannt ist (`foo`).	Erstellt* und schreibt dann in mehrere Tabellen, die nach den für Firebase-Apps festgelegten Kennungen benannt sind (`bar`, `qux` usw.).	Implementieren Sie Option 2, die unten beschrieben wird.
`foo`, `baz` usw.	`bar`	Schreibt in mehrere Tabellen, die nach den verschiedenen Kennungen im Code der App benannt sind (`foo`, `baz` usw.)	Erstellt** dann werden die Daten jeder App in eine einzelne Tabelle geschrieben, die nach der für die Firebase-App festgelegten Kennung (`bar`) benannt ist.	Keine der Optionen kann implementiert werden. Sie können die Daten der einzelnen Apps in der Tabelle weiterhin anhand der `bundle_identifier` der App unterscheiden, die zusammen mit den Daten exportiert wird.

^{* Wenn die ID in der Codebasis Ihrer App mit einer der IDs übereinstimmt, die für eine Firebase-App festgelegt sind, wird durch die neue Exportinfrastruktur keine neue Tabelle für diese ID erstellt. Stattdessen werden weiterhin Daten für diese App darauf geschrieben. Alle anderen Apps werden in neue Tabellen geschrieben.}

^{** Wenn einer der Bezeichner in der Codebasis Ihrer App mit dem für die Firebase-App festgelegten Bezeichner übereinstimmt, wird durch die neue Exportinfrastruktur keine neue Tabelle erstellt. Stattdessen wird die Tabelle beibehalten und es werden Daten für alle Apps in sie geschrieben.}

Optionen zur Vermeidung von Unterbrechungen

Folgen Sie der Anleitung für eine der unten beschriebenen Optionen bevor Sie ein manuelles Upgrade durchführen oder bevor der 15. September 2025.

OPTION 1:
Verwenden Sie die neue Tabelle, die von der neuen Exportinfrastruktur erstellt wurde. Sie kopieren Daten aus der vorhandenen Tabelle in die neue Tabelle.
1. Führen Sie in der Firebase-Konsole ein Upgrade auf die neue Exportinfrastruktur durch, indem Sie den Export für die verknüpfte App deaktivieren und dann wieder aktivieren.
  
  Dadurch wird eine neue Batchtabelle mit einem Namen erstellt, der auf der für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegten Bundle-ID oder dem Paketnamen basiert.
2. Kopieren Sie alle Daten aus der alten Tabelle in die gerade erstellte neue Tabelle in der Google Cloud-Konsole.
3. Wenn Sie Downstream-Abhängigkeiten haben, die von Ihrer Batch-Tabelle abhängen, ändern Sie sie so, dass die neue Tabelle verwendet wird.
Hinweis :Nach dem Upgrade werden neue Daten nicht in Ihre Legacy-Tabelle geschrieben. Alle zuvor in die alte Tabelle geschriebenen Daten werden nicht gelöscht.
OPTION 2:
In die vorhandene Tabelle schreiben. Dazu müssen Sie einige Standardeinstellungen in einer BigQuery-Konfiguration überschreiben.
1. Suchen Sie in der Firebase Console nach der Firebase-App-ID (z. B. 1:1234567890:ios:321abc456def7890) der App mit dem nicht übereinstimmenden Batchtabellennamen und ‑bezeichner und notieren Sie sie sich:
  Rufen Sie die Projekteinstellungen auf und scrollen Sie dann zur Karte Meine Apps, um alle Ihre Firebase-Apps und die zugehörigen Informationen zu sehen.
2. Führen Sie in der Firebase-Konsole ein Upgrade auf die neue Exportinfrastruktur durch, indem Sie den Export für die verknüpfte App deaktivieren und dann wieder aktivieren.
  
  Diese Aktion hat zwei Auswirkungen:
  - Erstellt eine neue Batchtabelle mit einem Namen, der auf der für Ihre registrierte Firebase-App in Ihrem Firebase-Projekt festgelegten Bundle-ID oder dem Paketnamen basiert. Sie werden diese Tabelle später löschen, aber noch nicht.
  - Erstellt eine BigQuery-Datenübertragungskonfiguration mit der Quelle Firebase Crashlytics with Multi-Region Support.
3. Ändern Sie in der Google Cloud-Konsole die neue Datenübertragungskonfiguration so, dass Daten weiterhin in Ihre vorhandene Tabelle geschrieben werden:
  1. Rufen Sie BigQuery > Datenübertragungen auf, um Ihre Datenübertragungskonfiguration anzusehen.
  2. Wählen Sie die Konfiguration mit der Quell-Firebase Crashlytics with Multi-Region Support aus.
  3. Klicken Sie rechts oben auf Bearbeiten.
  4. Suchen Sie im Abschnitt Details zur Datenquelle nach einer Liste für gmp_app_id und einer Liste für client_namespace.
    
    In BigQuery wird die Firebase-App-ID als gmp_app_id bezeichnet. Standardmäßig ist der client_namespace-Wert in BigQuery die entsprechende eindeutige Paket-ID / der entsprechende Paketname der App. Sie überschreiben jedoch diese Standardkonfiguration.
    
    BigQuery verwendet den Wert client_namespace für den Namen der Batchtabelle, in die jede verknüpfte Firebase-App schreibt.
  5. Suchen Sie die gmp_app_id der Firebase-App, für die Sie die Standardeinstellungen überschreiben möchten. Ändern Sie den client_namespace-Wert in den Namen der Tabelle, in die die Firebase-App stattdessen schreiben soll. In der Regel ist das der Name der alten Tabelle, in die die App mit der alten Exportinfrastruktur geschrieben hat.
    
    Hinweis: Wenn Sie zuvor in eine einzelne Tabelle geschrieben haben und nach dem Upgrade mehrere Tabellen haben, können Sie für jede anwendbare gmp_app_id dieselbe client_namespace verwenden. BigQuery werden im Wesentlichen alle Tabellen zusammengeführt und alle Daten für alle Firebase-Apps in diese eine Tabelle geschrieben.
  6. Speichern Sie die Konfigurationsänderung.
4. Planen Sie ein Backfill für die Tage, für die in Ihrer vorhandenen Tabelle Daten fehlen.
5. Wenn der Backfill abgeschlossen ist, löschen Sie die neue Tabelle, die automatisch von der neuen Exportinfrastruktur erstellt wurde.

Firebase Crashlytics-Daten nach BigQuery exportieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Export nach BigQuery aktivieren

Was passiert, wenn Sie den Export aktivieren?

Welche Daten werden nach BigQuery exportiert?

Crashlytics-Streaming-Export nach BigQuery

Crashlytics-Streaming-Export nach BigQuery aktivieren

Was kann ich mit den exportierten Daten tun?

Data Studio-Vorlage verwenden

Ansichten erstellen

Abfragen ausführen

Beispiel 1: Abstürze nach Tag

Beispiel 2: Die häufigsten Abstürze finden

Beispiel 3: Die 10 Geräte, auf denen die App am häufigsten abstürzt

Beispiel 4: Nach benutzerdefiniertem Schlüssel filtern

Swift

Objective-C

Java

Beispiel 5: User-ID extrahieren

Beispiel 6: Alle Nutzer mit einem bestimmten Absturzproblem finden

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

Swift

Objective-C

Java

Beispiel 8: Die fünf häufigsten Probleme bisher heute

Beispiel 9: Die fünf wichtigsten Probleme seit DATE (einschließlich heute)

Crashlytics-Schema in BigQuery

Datasets

Tabellen

Zeilen

Spalten

Exportierte Crashlytics-Daten mit Data Studio visualisieren

Crashlytics-Berichtsvorlage verwenden

Upgrade auf die neue Exportinfrastruktur

Prüfen, ob Sie die neue Infrastruktur verwenden

Wichtige Unterschiede zwischen der alten und der neuen Exportinfrastruktur

Schritt 1: Voraussetzungen für das Upgrade

Schritt 2: Manuelles Upgrade auf die neue Infrastruktur

Der Name der vorhandenen Batchtabelle stimmt nicht mit der Kennung Ihrer Firebase-App überein.

So werden mit der Exportinfrastruktur Kennungen verwendet, um Daten in BigQuery-Tabellen zu schreiben

Was passiert, wenn das Problem nicht behoben wird, bevor ich ein Upgrade durchführe?

Beispielszenarien für nicht übereinstimmende Kennzeichnungen

Optionen zur Vermeidung von Unterbrechungen

Firebase Crashlytics-Daten nach BigQuery exportieren