Firebase Crashlytics-Daten nach BigQuery exportieren

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 in BigQuery aktivieren

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

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

3. Folgen Sie der Anleitung auf dem Bildschirm, um den Export in BigQuery zu aktivieren.

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

Was passiert, wenn ich die Funktion „Exportieren“ aktiviere?

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

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

• 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 eine tägliche Synchronisierung 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 die ersten Daten nach BigQuery exportiert werden.

  • Die tägliche Synchronisierung erfolgt einmal pro Tag, unabhängig von geplanten Exporten, die Sie unter BigQuery eingerichtet haben. Beachten Sie, dass sich Zeitpunkt und Dauer des Synchronisierungsjobs ändern können. Wir empfehlen daher nicht, Downstream-Vorgänge oder ‑Jobs basierend auf einem bestimmten Zeitpunkt des Exports zu planen.

• Firebase exportiert eine Kopie Ihrer vorhandenen Daten zu BigQuery. Die Erstübertragung der Daten für den Export kann bis zu 48 Stunden dauern.

  • Dieser Export enthält für jede verknüpfte App eine Batchtabelle mit den Daten aus der täglichen Synchronisierung.

  • Sie können Daten-Backfills für die Batchtabelle bis zu den letzten 30 Tagen manuell planen oder für das Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was jünger ist).

  Wenn Sie den Export von Crashlytics-Daten vor Mitte Oktober 2024 aktiviert haben, können Sie auch 30 Tage vor dem Tag, an dem Sie den Export aktiviert haben, ein Backfill durchführen.

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

Daten für eine Android-App mit dem Paketnamen com.google.test würden beispielsweise in einer Tabelle mit dem Namen com_google_test_ANDROID gespeichert. Diese Batch-Tabelle wird einmal täglich aktualisiert. Wenn Sie den Streaming-Export von Crashlytics 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 steht für ein Ereignis, das in der App aufgetreten ist, einschließlich Abstürzen, nicht schwerwiegenden Fehlern und ANRs.

Crashlytics-Streaming-Export 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. zur Präsentation von Informationen in einem Live-Dashboard, zum Live-Überwachen eines Roll-outs oder zum Überwachen von Anwendungsproblemen, die Benachrichtigungen und benutzerdefinierte Workflows auslösen.

Wenn Sie den Streaming-Export von Crashlytics nach BigQuery aktivieren, haben Sie zusätzlich zur Batchtabelle auch eine Echtzeittabelle. Die Tabellen unterscheiden sich in folgenden Punkten:

Die Batch-Tabelle eignet sich ideal für langfristige Analysen und die Erkennung von Trends im Zeitverlauf, da Ereignisse dauerhaft gespeichert werden, bevor sie geschrieben werden, und bis zu 30 Tage lang in die Tabelle zurückgefüllt werden können*. 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. Weitere Informationen zum Ändern finden Sie in der BigQuery-Dokumentation unter Partitionsablauf festlegen.

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

Crashlytics-Streamingexport nach BigQuery aktivieren

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

2. Klicken Sie auf der Karte BigQuery auf Verwalten.

3. Klicken Sie das Kästchen Streaming einschließen an.

Dadurch wird das Streaming für alle verknüpften Apps aktiviert.

Was kann ich mit den exportierten Daten tun?

Exporte nach BigQuery enthalten Rohabsturzdaten wie 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 in der BigQuery-Dokumentation unter Ansichten erstellen.

Abfragen ausführen

Die folgenden Beispiele zeigen Abfragen, die Sie mit Ihren Crashlytics-Daten ausführen können, um Berichte zu generieren, in denen Daten zu Absturzereignissen übersichtlicher zusammengefasst werden. 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, die 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 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: Häufigste 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: Die zehn 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 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 Ihres Spiels die meisten Abstürze auftreten.

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 current_level-Werte zu protokollieren.

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

Sie haben eine Android-App im Early Access. Die meisten Nutzer sind begeistert, bei dreien sind jedoch ungewöhnlich viele Abstürze aufgetreten. Zur Ermittlung der Ursache schreiben Sie eine Abfrage, mit der alle Absturzereignisse der betroffenen Nutzer anhand ihrer Nutzer-IDs abgerufen 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 *
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 versehentlich einen kritischen Fehler in einer Gruppe von Betatestern veröffentlicht. Ihr Team konnte die Abfrage aus dem Beispiel „Häufigste 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 Absturz betroffen sind, aufgeschlüsselt nach Land

Ihr Team hat beim Roll-out eines neuen Release einen kritischen Fehler festgestellt. Sie konnten 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 nun wissen, ob sich dieser Absturz auf Nutzer in verschiedenen Ländern ausgeweitet hat.

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

1. Aktivieren Sie den Export von Google Analytics-Daten nach BigQuery. Weitere Informationen finden Sie unter Projektdaten nach 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. 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 fünf häufigsten 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: Die fünf häufigsten 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 gemeinsame Ereignisse aus den beiden Tabellen deduplizieren.DISTINCT event_id

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 ein neues Dataset in BigQuery für Crashlytics-Daten. Das Dataset deckt das gesamte Projekt ab, selbst wenn dieses mehrere Anwendungen umfasst.

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.

Daten für eine Android-App mit dem Paketnamen com.google.test würden beispielsweise in einer Tabelle mit dem Namen com_google_test_ANDROID gespeichert. Realtime-Daten (falls aktiviert) würden in einer Tabelle mit dem Namen com_google_test_ANDROID_REALTIME gespeichert.

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 Streamingexport von Crashlytics nach BigQuery aktiviert ist, hat die Echtzeittabelle dieselben Spalten wie die Batchtabelle. Es kann sein, dass Zeilen Spalten enthalten, die Ereignisse darstellen, die keine Stack-Traces haben.

Die Spalten im Export sind in dieser Tabelle aufgeführt:

Exportierte Crashlytics-Daten mit Data Studio visualisieren

Google Data Studio wandelt Ihre Crashlytics-Datensätze in BigQuery in Berichte um. Die vollständig anpassbaren Berichte sind übersichtlich und lassen sich einfach teilen.

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

1. Öffnen Sie die Crashlytics-Data 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 Batch-Tabelle kann jederzeit ausgewählt werden. Wenn der Streaming-Export von Crashlytics nach BigQuery aktiviert ist, können Sie stattdessen Ihre Echtzeittabelle auswählen.

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

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

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

9. Klicken Sie abschließend auf Bericht erstellen, um eine Kopie der Vorlage „Crashlytics Data Studio-Dashboard“ zu erstellen.

Auf die neue Exportinfrastruktur umstellen

Mitte Oktober 2024 hat Crashlytics eine neue Infrastruktur für den Export von Crashlytics-Daten in BigQuery eingeführt. Ein Upgrade auf diese neue Infrastruktur ist derzeit optional.

Diese neue Infrastruktur unterstützt Crashlytics Speicherorte für Datensätze außerhalb der USA.

• Wenn Sie den Export vor Mitte Oktober 2024 aktiviert haben, können Sie jetzt optional den Speicherort für den Datenexport in einen beliebigen von BigQuery unterstützten Speicherort für Datasets ändern.

• Wenn Sie den Export Mitte Oktober 2024 oder später aktiviert haben, können Sie bei der Einrichtung einen beliebigen von BigQuery unterstützten Speicherort für den Datensatz auswählen.

Ein weiterer Unterschied bei der neuen Infrastruktur besteht darin, dass sie keine Backfills von Daten aus der Zeit vor der Aktivierung des Exports unterstützt. Mit der alten Infrastruktur war es möglich, bis zu 30 Tage vor dem Aktivierungsdatum Backfills durchzuführen. Die neue Infrastruktur unterstützt Backfills bis zu den letzten 30 Tagen oder bis zum Datum, an dem Sie den Export nach BigQuery aktiviert haben (je nachdem, was zuletzt eingetreten ist).

Voraussetzung für das Upgrade

Bevor Sie auf die neue Infrastruktur umstellen, prüfen Sie, ob Sie die folgende Voraussetzung erfüllen: Die Tabellen des aktuellen Batches BigQuery haben dieselben Kennungen wie die für Ihre registrierten Firebase-Apps festgelegten Paket-IDs oder Paketnamen.

Beispiel:

• Wenn Sie eine BigQuery-Tabelle mit dem Namen com_yourcompany_yourproject_IOS haben, sollte in Ihrem Firebase-Projekt eine Firebase-iOS-App mit der Bundle-ID com.yourcompany.yourproject registriert sein.

• Wenn Sie eine BigQuery-Tabelle mit dem Namen com_yourcompany_yourproject_ANDROID haben, sollte in Ihrem Firebase-Projekt eine Firebase-Android-App mit dem Paketnamen com.yourcompany.yourproject registriert sein.

So rufen Sie alle in Ihrem Firebase-Projekt registrierten Firebase-Apps auf:

1. Rufen Sie in der Firebase Console die settings Projekteinstellungen auf.

2. Scrollen Sie nach unten zur Karte Meine Apps und klicken Sie auf die gewünschte Firebase App, um die Informationen zur App einschließlich ihrer Kennung aufzurufen.

Mit der neuen Exportinfrastruktur werden die Daten jeder App basierend auf dem Paketnamen oder der Paket-ID exportiert, die für die registrierte Firebase-App festgelegt wurde. Damit Ihr BigQuery-Workflow nicht unterbrochen wird, müssen Ihre aktuellen Batchtabellen bereits die richtigen Namen haben, damit die neue Infrastruktur alle neuen Daten an die vorhandenen Tabellen anhängen kann. Wenn die Namen Ihrer Batchtabellen nicht mit Ihren registrierten Firebase-Apps übereinstimmen, Sie aber trotzdem umstellen möchten, wenden Sie sich an den Firebase-Support.

So führen Sie ein Upgrade auf die neue Infrastruktur durch

Wenn Sie den Export bereits aktiviert haben, können Sie auf die neue Infrastruktur umstellen, indem Sie den Crashlytics-Datenexport in der Firebase-Konsole einfach deaktivieren und wieder aktivieren.

So gehts:

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

2. Klicken Sie auf der Karte BigQuery auf Verwalten.

3. Deaktivieren Sie den Schieberegler Crashlytics, um den Export zu deaktivieren. Bestätigen Sie auf Nachfrage, dass der Datenexport beendet werden soll.

4. Aktivieren Sie den Schieberegler Crashlytics sofort wieder, um den Export zu aktivieren. Bestätigen Sie auf Nachfrage, dass Sie Daten exportieren möchten.

   Für den Datenexport von Crashlytics nach BigQuery wird jetzt die neue Exportinfrastruktur verwendet.