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 für die Visualisierung und benutzerdefinierte Dashboards mit Looker Studio verwenden.

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.

Hier sind einige Beispiele für die Verwendung der exportierten Crashlytics-Daten:

• Abfragen ausführen
  Sie können Abfragen für Ihre Crashlytics-Daten ausführen, 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. Weiter unten auf dieser Seite finden Sie eine Auswahl von Beispielabfragen.

• Looker Studio-Vorlage verwenden
  Crashlytics bietet eine vorgefertigte Looker Studio-Vorlage für die Visualisierung Ihrer exportierten Daten.

• Ansichten erstellen
  Über die BigQuery-Benutzeroberfläche können Sie eine Ansicht erstellen. Das ist eine virtuelle Tabelle, die durch eine SQL-Abfrage definiert wird. Eine ausführliche Anleitung zu den verschiedenen Ansichtstypen und zum Erstellen von Ansichten finden Sie in der BigQuery-Dokumentation.

• Crashlytics-spezifische Daten mit Firebase-Sitzungsdaten kombinieren
  Sie können auch Firebase-Sitzungsdaten exportieren, wenn Sie den Crashlytics-Datenexport einrichten. Mithilfe dieser Sitzungsdaten können Sie Nutzer ohne Abstürze und Sitzungen ohne Abstürze besser nachvollziehen.

Vorteile des Streaming-Exports nach BigQuery

Standardmäßig werden Daten in einem täglichen Batch-Export nach BigQuery exportiert. Außerdem können Sie Ihre Crashlytics-Daten und Firebase-Sitzungen mit BigQuery-Streaming 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 Arbeitsabläufe auslösen.

Wenn Sie den Streaming-Export nach BigQuery aktivieren, sind zusätzlich zu Batchtabellen auch Echtzeittabellen verfügbar. Beide Tabellentypen haben dasselbe Dataset-Schema. Es gibt jedoch einige wichtige Unterschiede zwischen Batch- und Echtzeittabellen:

Die Batch-Tabelle eignet sich ideal für langfristige Analysen und die Ermittlung von Trends im Zeitverlauf, da Ereignisse dauerhaft gespeichert werden, bevor sie geschrieben werden. Sie können 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 in der 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.}

Export nach BigQuery aktivieren

1. Rufen Sie in der Firebase Console die Seite Einbindungen auf.

2. Klicken Sie auf der Karte BigQuery auf Verknüpfen.

3. Folgen Sie der Anleitung auf dem Bildschirm, um den Export nach BigQuery zu aktivieren. Dazu gehören die folgenden Optionen:

   • Wenn Sie die Messwerte „Nutzer ohne Abstürze“ und „Sitzungen ohne Abstürze“ besser nachvollziehen möchten, aktivieren Sie den Export von Firebase-Sitzungsdaten.

   • Wenn Sie nahezu in Echtzeit auf Ihre Crashlytics-Daten und Firebase-Sitzungsdaten in BigQuery zugreifen möchten, aktivieren Sie den Streaming-Export.

Was passiert, wenn Sie den Export aktivieren?

• Firebase exportiert Daten aus den mit BigQuery verknüpften Apps.

  • Bei der Einrichtung werden standardmäßig alle Apps in Ihrem Projekt mit BigQuery verknüpft. Sie können jedoch festlegen, dass bestimmte Apps bei der Einrichtung nicht verknüpft werden.

  • Alle Apps, die Sie Ihrem Firebase-Projekt später hinzufügen, werden automatisch mit BigQuery verknüpft.

  • Sie können jederzeit festlegen, welche Apps Daten exportieren dürfen.

• Firebase exportiert Daten an den Dataset-Speicherort, den Sie bei der Einrichtung ausgewählt haben.

  • Dieser Speicherort gilt sowohl für das Crashlytics-Dataset als auch für das Firebase-Sitzungsdataset (sofern der Export von Sitzungsdaten aktiviert ist).

  • 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.

  • Nachdem ein Dataset erstellt wurde, kann sein Standort nicht mehr geändert werden. Sie können das Dataset aber an einen anderen Standort kopieren oder es manuell an einen anderen Standort verschieben (neu erstellen). Weitere Informationen finden Sie unter Speicherort für vorhandene Exporte ändern.

• Firebase richtet tägliche Synchronisierungen Ihrer Batchdaten mit BigQuery ein.

  • Nach der Verknüpfung mit BigQuery kann es bis zu 48 Stunden dauern, bis der erste Batch-Datenexport erfolgt.

  • Die tägliche Synchronisierung erfolgt einmal täglich, 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.

  • 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, was 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, nachfüllen.

• Das gilt, wenn Sie den Streaming-Export nach BigQuery aktivieren.

  • Für jede verknüpfte App gibt es auch eine eigene Echtzeittabelle mit ständig aktualisierten Daten (zusätzlich zur Batchtabelle der App für den täglichen Batchexport).

  • Nachdem Sie das Streaming aktiviert haben, kann es bis zu einer Stunde dauern, bis die Daten gestreamt werden.

  Sie sehen keine Daten in Ihrer Echtzeittabelle?

  1. Sie müssen mindestens zwei Ereignisse aus Ihrer App an Crashlytics gesendet und einige Minuten gewartet haben, nachdem Sie sie gesendet haben.

  2. 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.

  3. 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.

  4. Wenn Sie weiterhin keine Daten in Ihrer Echtzeittabelle sehen, wenden Sie sich an den Firebase-Support.

Beispielabfragen

Beispiel 1: Messwerte zu Nutzern ohne Abstürze mit Firebase-Sitzungsdaten berechnen

In der neuesten Version haben Sie Ihre App grundlegend überarbeitet, um Abstürze bei einem wichtigen User Flow zu beheben. Sie haben hervorragende Rezensionen von Nutzern erhalten, möchten aber quantitative Beweise dafür, dass Ihre App stabiler als zuvor ist.

Messwerte ohne Abstürze können Ihnen dabei helfen. Diese Messwerte sind wichtig, um den allgemeinen Zustand Ihrer App zu verstehen. Mit Firebase-Sitzungsdaten und Crashlytics-Ereignissen können Sie diese Messwerte mit einer einfachen Abfrage berechnen.

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

Nutzer ohne Abstürze für eine bestimmte Version:

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT installation_uuid) / COUNT (DISTINCT instance_id))) AS CFU
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL"
  AND crashlytics.application.display_version="APP_VERSION"
  AND sessions.application.display_version = "APP_VERSION"
GROUP BY
  event_date
ORDER BY
  event_date

Sitzungen ohne Abstürze in der letzten Woche (letzte 168 Stunden):

SELECT
  TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY) AS event_date,
  (1 - (COUNT (DISTINCT crashlytics.event_id) / COUNT (DISTINCT sessions.session_id))) AS CFS
FROM
  `PROJECT_ID.firebase_sessions.PACKAGE_NAME_ANDROID` AS sessions
LEFT JOIN
  `PROJECT_ID.firebase_crashlytics.PACKAGE_NAME_ANDROID` AS crashlytics
ON
  TIMESTAMP_TRUNC(_PARTITIONTIME,DAY) = TIMESTAMP_TRUNC(crashlytics.event_timestamp,DAY)
WHERE
  crashlytics.error_type="FATAL" AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 168 HOUR)
  AND _PARTITIONTIME < CURRENT_TIMESTAMP()
GROUP BY
  event_date
ORDER BY
  event_date

Beispiel 2: 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 3: 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 4: Die 10 Geräte mit den meisten 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. 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 5: Nach benutzerdefiniertem Schlüssel filtern

Sie sind Spieleentwickler und möchten wissen, auf welchem Level Ihr Spiel am häufigsten abstürzt.

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.

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

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 6: 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 7: 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 8: 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:

1. Export von Google Analytics-Daten nach BigQuery aktivieren. Weitere Informationen finden Sie unter Projektdaten in BigQuery exportieren.

2. 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");
   

3. 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 9: Die fünf häufigsten Probleme 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 10: 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Exportierte Crashlytics-Daten mit Looker Studio visualisieren

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

Weitere Informationen zur Verwendung von Looker Studio finden Sie im Willkommensleitfaden.

Crashlytics-Berichtsvorlage verwenden

Looker Studio bietet einen Beispielbericht für Crashlytics. Dieser enthält umfassende Dimensionen und Messwerte des exportierten Crashlytics-Schemas BigQuery. Wenn Sie den Crashlytics-Streaming-Export nach BigQuery aktiviert haben, können Sie sich die Daten auf der Seite Echtzeittrends der Looker 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:

1. Öffnen Sie die Crashlytics Looker Studio-Dashboard-Vorlage.

2. Klicken Sie rechts oben auf Vorlage verwenden.

3. Wählen Sie im Drop-down-Menü Neue Datenquelle die Option Neue Datenquelle erstellen aus.

4. Klicken Sie auf der Karte BigQuery auf Auswählen.

5. 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.

6. Setzen Sie unter Konfiguration die Option Crashlytics-Vorlagenebene auf Standard.

7. Klicken Sie auf Verbinden, um die neue Datenquelle zu erstellen.

8. Klicken Sie auf Zum Bericht hinzufügen, um zur Vorlage Crashlytics zurückzukehren.

9. Klicken Sie abschließend auf Bericht erstellen, um eine Kopie der Dashboardvorlage Crashlytics Looker Studio zu erstellen.

Schema in BigQuery

Firebase erstellt in BigQuery neue Datasets für Ihre exportierten Daten:

• Crashlytics-Dataset

• Firebase-Sitzungsdatensatz (wenn der Export von Sitzungsdaten aktiviert ist)

Crashlytics Dataset

Crashlytics-Daten werden in ein BigQuery-Dataset mit dem Namen firebase_crashlytics exportiert. Das Dataset deckt das gesamte Projekt ab, selbst wenn dieses mehrere Apps umfasst.

Tabellen

Standardmäßig erstellt Firebase für jede App in Ihrem Projekt, die mit BigQuery verknüpft ist, separate Tabellen im Dataset Crashlytics.

Die Tabellen werden nach der ID der App benannt. Die in der ID enthaltenen Punkte werden in Unterstriche umgewandelt und am Ende wird die Plattform der App (_IOS oder _ANDROID) 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.

• Wenn der Streaming-Export nach BigQuery aktiviert ist, werden Daten auch in Echtzeit in eine Tabelle gestreamt, an die _REALTIME angehängt wird (z. B. 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 ANR-Fehlern.

• Die 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 Streaming-Export nach BigQuery aktiviert ist, hat die Echtzeittabelle dieselben Spalten wie die Batchtabelle.

• Möglicherweise haben Sie Spalten in Zeilen, die Ereignisse ohne Stacktraces darstellen.

Hier sind die Spalten in der Tabelle für die exportierten Crashlytics-Daten aufgeführt:

Firebase-Dataset für Sitzungen

Firebase-Sitzungsdaten werden in ein BigQuery-Dataset mit dem Namen firebase_sessions exportiert. Das Dataset deckt das gesamte Projekt ab, selbst wenn dieses mehrere Apps umfasst.

Tabellen

Standardmäßig erstellt Firebase für jede App in Ihrem Projekt, die mit BigQuery verknüpft ist, separate Tabellen im Dataset „Firebase-Sitzungen“.

Die Tabellen werden nach der ID der App benannt. Die in der ID enthaltenen Punkte werden in Unterstriche umgewandelt und am Ende wird die Plattform der App (_IOS oder _ANDROID) 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.

Zeilen

Jede Zeile in einer Tabelle steht für ein Sitzungsereignis.

Spalten

Wenn der Streaming-Export nach BigQuery aktiviert ist, hat die Echtzeittabelle dieselben Spalten wie die Batchtabelle.

Die Spalten in der Tabelle für die exportierten Firebase-Sitzungsdaten sind:

Auf die neue Exportinfrastruktur umstellen

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 Batchexport aktualisiert. 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 nutzen

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 Ihr Projekt verwendet: Rufen Sie die Google Cloud-Konsole auf. Wenn Ihre Konfiguration für die Datenübertragung mit Firebase Crashlytics with Multi-Region Support gekennzeichnet ist, verwendet Ihr Projekt die neue Exportinfrastruktur.

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 Paket-IDs oder Paketnamen im Binärcode 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.

Schritt 1: Voraussetzungen für das Upgrade

1. Prüfen Sie, ob in Ihren vorhandenen BigQuery-Batchtabellen dieselben Kennungen wie die Paket-IDs oder Paketnamen verwendet werden, die für Ihre registrierten Firebase-Apps in Ihrem Firebase-Projekt festgelegt sind. 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 settings 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.

   Hier sind einige Beispiele für ideale Zustände, in denen beim Upgrade keine Probleme auftreten:

   • Sie haben eine Batchtabelle 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.

2. 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 des Batchexports 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:

1. Rufen Sie in der Firebase Console die Seite Einbindungen auf.

2. Klicken Sie auf der Karte BigQuery auf Verwalten.

3. Deaktivieren Sie den Schieberegler Crashlytics, um den Export zu deaktivieren. Bestätige, dass du den Datenexport beenden möchtest.

4. Aktivieren Sie den Schieberegler Crashlytics sofort wieder, um den Export wieder zu aktivieren. Bestätige, dass du Daten exportieren möchtest.

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

Der Name Ihrer vorhandenen Batchtabelle stimmt nicht mit Ihrer Firebase-App-ID überein