Esporta i dati di Firebase Crashlytics in BigQuery

Puoi esportare i dati di Firebase Crashlytics in BigQuery per ulteriori analisi. BigQuery ti consente di analizzare i dati utilizzando SQL di BigQuery, esportarli in un altro provider cloud e utilizzarli per la visualizzazione e le dashboard personalizzate con Google Data Studio.

Abilita l'esportazione in BigQuery

1. Nella console Firebase, vai alla pagina Integrazioni.

2. Nella scheda BigQuery, fai clic su Collega.

3. Segui le istruzioni sullo schermo per attivare l'esportazione in BigQuery.

   Se vuoi accedere ai dati di Crashlytics in BigQuery quasi in tempo reale, ti consigliamo di eseguire l'upgrade all'esportazione streaming.

Che cosa succede quando attivi l'esportazione?

• Seleziona la posizione del set di dati. Dopo la creazione del set di dati, la località non può essere modificata, ma puoi copiarlo in un'altra posizione o spostarlo (ricrearlo) manualmente in un'altra posizione. Per saperne di più, consulta Modificare la posizione delle esportazioni esistenti.

  Questa posizione è applicabile solo ai dati esportati in BigQuery e non influisce sulla posizione dei dati archiviati per l'utilizzo nella dashboard Crashlytics della console Firebase o in Android Studio.

• Per impostazione predefinita, tutte le app del progetto sono collegate a BigQuery e qualsiasi app che aggiungi in seguito viene collegata automaticamente a BigQuery. Puoi gestire le app che inviano dati.

• Firebase configura la sincronizzazione giornaliera dei tuoi dati con BigQuery.

  • Dopo aver collegato il progetto, in genere devi attendere la sincronizzazione del giorno successivo per esportare il primo set di dati in BigQuery.

  • La sincronizzazione giornaliera avviene una volta al giorno, indipendentemente dall'eventuale esportazione pianificata che potresti aver configurato in BigQuery. Tieni presente che la frequenza e la durata del job di sincronizzazione possono variare, pertanto non consigliamo di pianificare operazioni o job a valle in base a un momento specifico dell'esportazione.

• Firebase esporta una copia dei tuoi dati esistenti in BigQuery. La propagazione iniziale dei dati per l'esportazione può richiedere fino a 48 ore.

  • Per ogni app collegata, questa esportazione include una tabella batch contenente i dati della sincronizzazione giornaliera.

  • Puoi pianificare manualmente i backfill dei dati per la tabella batch fino agli ultimi 30 giorni o per la data più recente quando hai attivato l'esportazione in BigQuery (a seconda di quale sia la più recente).

  Tieni presente che se hai attivato l'esportazione dei dati di Crashlytics prima di metà ottobre 2024, puoi anche eseguire il backfill 30 giorni prima del giorno in cui hai attivato l'esportazione.

• Se attivi l'esportazione streaming di Crashlytics in BigQuery, tutte le app collegate avranno anche una tabella in tempo reale contenente dati in costante aggiornamento.

Per disattivare l'esportazione in BigQuery, scollega il progetto nella console Firebase.

Quali dati vengono esportati in BigQuery?

I dati Firebase Crashlytics vengono esportati in un set di dati BigQuery denominato firebase_crashlytics. Per impostazione predefinita, all'interno del set di dati Crashlytics verranno create singole tabelle per ogni app del progetto. Firebase nomina le tabelle in base all'identificatore dell'app, con i punti convertiti in trattini bassi e un nome della piattaforma aggiunto alla fine.

Ad esempio, i dati di un'app per Android con il nome del pacchetto com.google.test si troverebbero in una tabella denominata com_google_test_ANDROID. Questa tabella batch viene aggiornata una volta al giorno. Se attivi l'esportazione streaming di Crashlytics in BigQuery, i dati di Crashlytics verranno trasmessi in streaming anche in tempo reale in una tabella denominata com_google_test_ANDROID_REALTIME.

Ogni riga di una tabella rappresenta un evento che si è verificato nell'app, inclusi arresti anomali, errori non fatali e ANR.

Esportazione streaming di Crashlytics in BigQuery

Puoi trasmettere in streaming i dati Crashlytics in tempo reale con BigQuery streaming. Puoi utilizzarlo per qualsiasi scopo che richieda dati in tempo reale, ad esempio presentare informazioni in una dashboard in tempo reale, guardare un'implementazione in tempo reale o monitorare i problemi dell'applicazione che attivano avvisi e flussi di lavoro personalizzati.

Quando attivi l'esportazione streaming in Crashlytics in BigQuery, oltre alla tabella batch avrai anche una tabella in tempo reale. Ecco le differenze tra le tabelle che devi conoscere:

La tabella batch è ideale per l'analisi a lungo termine e l'identificazione delle tendenze nel tempo perché memorizziamo in modo duraturo gli eventi prima di scriverli e possono essere sottoposti a backfill nella tabella per un massimo di 30 giorni*. Quando scriviamo i dati nella tabella in tempo reale, li scriviamo immediatamente in BigQuery, quindi sono ideali per dashboard in tempo reale e avvisi personalizzati. Queste due tabelle possono essere combinate con una query di stitching per trarre il meglio da entrambe.

Per impostazione predefinita, la tabella in tempo reale ha una scadenza della partizione di 30 giorni. Per scoprire come modificarlo, consulta Impostare la scadenza della partizione nella documentazione di BigQuery.

^{* Scopri i dettagli sull'assistenza per il backfill in Eseguire l'upgrade alla nuova infrastruttura di esportazione.}

Attiva l'esportazione di Crashlytics in streaming in BigQuery

1. Nella console Firebase, vai alla pagina Integrazioni.

2. Nella scheda BigQuery, fai clic su Gestisci.

3. Seleziona la casella di controllo Includi streaming.

Questa azione attiva lo streaming per tutte le app collegate.

Che cosa puoi fare con i dati esportati?

Le esportazioni in BigQuery contengono dati non elaborati sugli arresti anomali, tra cui tipo di dispositivo, sistema operativo, eccezioni (app per Android) o errori (app per Apple), nonché log di Crashlytics e altri dati.

Esamina esattamente quali dati Crashlytics vengono esportati e il relativo schema della tabella più avanti in questa pagina.

Utilizzare un modello di Data Studio

Per attivare i dati in tempo reale nel modello di Data Studio, segui le istruzioni riportate in Visualizzare i dati Crashlytics esportati con Data Studio.

Creare visualizzazioni

Puoi trasformare le query in visualizzazioni utilizzando l'interfaccia utente di BigQuery. Per istruzioni dettagliate, consulta Creare visualizzazioni nella documentazione di BigQuery.

esegui delle query

Gli esempi riportati di seguito mostrano le query che puoi eseguire sui dati Crashlytics per generare report che aggregano i dati sugli eventi di arresto anomalo in riepiloghi più facilmente comprensibili. Poiché questi tipi di report non sono disponibili nella dashboard Crashlytics della console Firebase, possono integrare la tua analisi e la tua comprensione dei dati sugli arresti anomali.

Esempio 1: arresti anomali per giorno

Dopo aver lavorato per correggere il maggior numero possibile di bug, pensi che il tuo team sia finalmente pronto a lanciare la nuova app di condivisione di foto. Prima di farlo, vuoi controllare il numero di arresti anomali al giorno nell'ultimo mese per assicurarti che la tua app sia diventata più stabile nel tempo.

Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 2: trovare gli arresti anomali più diffusi

Per dare la priorità corretta ai piani di produzione, devi trovare i 10 arresti anomali più comuni nella tua app. Produci una query che fornisca i punti di dati pertinenti.

Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 3: i 10 dispositivi con più arresti anomali

L'autunno è la stagione dei nuovi smartphone. La tua azienda sa che questo significa anche che è iniziata la nuova stagione dei problemi specifici dei dispositivi, in particolare per Android. Per anticipare i problemi di compatibilità imminenti, crei una query che identifichi i 10 dispositivi che hanno registrato il maggior numero di arresti anomali nell'ultima settimana (168 ore).

Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 4: filtro per chiave personalizzata

Sei uno sviluppatore di giochi e vuoi sapere quale livello del tuo gioco presenta più arresti anomali.

Per monitorare questa statistica, imposta una chiave Crashlytics personalizzata chiamata current_level e aggiornala ogni volta che l'utente raggiunge un nuovo livello.

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

Con questa chiave nell'esportazione in BigQuery, puoi scrivere una query per registrare la distribuzione dei valori current_level associati a ogni evento di arresto anomalo.

Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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

Esempio 5: estrazione dell'ID utente

Hai un'app per Android in accesso in anteprima. La maggior parte degli utenti lo adora, ma tre hanno riscontrato un numero insolito di arresti anomali. Per risolvere il problema, scrivi una query che estrae tutti gli eventi di arresto anomalo per questi utenti utilizzando i relativi ID utente.

Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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
 

Esempio 6: trovare tutti gli utenti che hanno riscontrato un determinato problema di arresto anomalo

Il tuo team ha rilasciato accidentalmente un bug critico a un gruppo di beta tester. Il tuo team è stato in grado di utilizzare la query dell'esempio "Trovare gli arresti anomali più diffusi" riportato sopra per identificare l'ID del problema di arresto anomalo specifico. Ora il tuo team vorrebbe eseguire una query per estrarre l'elenco degli utenti dell'app interessati da questo arresto anomalo.

Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 7: numero di utenti interessati da un problema di arresto anomalo, suddiviso per paese

Il tuo team ha rilevato un bug critico durante l'implementazione di una nuova release. Hai potuto utilizzare la query dell'esempio "Trovare gli arresti anomali più diffusi" riportato sopra per identificare l'ID del problema di arresto anomalo specifico. Il tuo team vorrebbe ora sapere se questo arresto anomalo si è diffuso a utenti di diversi paesi in tutto il mondo.

Per scrivere questa query, il team dovrà eseguire i seguenti passaggi:

1. Attiva l'esportazione dei dati di Google Analytics in BigQuery. Consulta Esportare i dati del progetto in BigQuery.

2. Aggiorna l'app in modo da trasmettere un ID utente sia all'SDK Google Analytics sia all'SDK Crashlytics.

   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. Scrivi una query che utilizzi il campo ID utente per unire gli eventi nel set di dati Google Analytics agli arresti anomali nel set di dati Crashlytics.

   Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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

Esempio 8: i 5 problemi principali fino ad oggi

Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Esempio 9: 5 problemi principali dal giorno DATA, incluso oggi

Puoi anche combinare le tabelle batch e in tempo reale con una query di stitching per aggiungere informazioni in tempo reale ai dati batch affidabili. Poiché event_id è una chiave primaria, puoi utilizzarla per deduplicare gli eventi comuni delle due tabelle.DISTINCT event_id

Ecco un esempio di query per un'app per Android. Per un'app per iOS, utilizza l'ID pacchetto e IOS (anziché il nome del pacchetto e 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;

Informazioni sullo schema Crashlytics in BigQuery

Quando configuri l'esportazione dei dati di Crashlytics in BigQuery, Firebase esporta gli eventi recenti (arresti anomali, errori non irreversibili e ANR), inclusi gli eventi fino a due giorni prima del collegamento, con la possibilità di eseguire il backfill fino a 30 giorni.

Da quel momento in poi, fino a quando non disattivi l'esportazione, Firebase esporta gli eventi Crashlytics su base giornaliera. Potrebbero essere necessari alcuni minuti prima che i dati siano disponibili in BigQuery dopo ogni esportazione.

Set di dati

Crashlytics crea un nuovo set di dati in BigQuery per i dati Crashlytics. Il set di dati copre l'intero progetto, anche se contiene più app.

Tabelle

Crashlytics crea una tabella nel set di dati per ogni app del progetto, a meno che tu non abbia disattivato l'esportazione dei dati per l'app. Firebase assegna ai tabella il nome in base all'identificatore dell'app, con i punti convertiti in trattini bassi e un nome della piattaforma aggiunto alla fine.

Ad esempio, i dati di un'app per Android con il nome del pacchetto com.google.test si troverebbero in una tabella denominata com_google_test_ANDROID, mentre i dati in tempo reale (se abilitati) si troverebbero in una tabella denominata com_google_test_ANDROID_REALTIME

Le tabelle contengono un insieme standard di dati Crashlytics, oltre a eventuali chiavi Crashlytics personalizzate che hai definito nella tua app.

Righe

Ogni riga di una tabella rappresenta un errore rilevato dall'app.

Colonne

Le colonne di una tabella sono identiche per arresti anomali, errori non irreversibili e ANR. Se l'esportazione in streaming di Crashlytics in BigQuery è abilitata, la tabella in tempo reale avrà le stesse colonne della tabella batch. Tieni presente che potresti avere colonne nelle righe che rappresentano eventi che non hanno tracce dello stack.

Le colonne dell'esportazione sono elencate in questa tabella:

Visualizzare i dati Crashlytics esportati con Data Studio

Google Data Studio trasforma i tuoi set di dati Crashlytics in BigQuery in report più facili da leggere, condividere e personalizzare.

Per scoprire di più sull'utilizzo di Data Studio, consulta la guida rapida di Data Studio, Ti diamo il benvenuto in Data Studio.

Utilizzare un modello di report Crashlytics

Data Studio ha un report di esempio per Crashlytics che include un insieme completo di dimensioni e metriche dello schema Crashlytics BigQuery esportato. Se hai attivato l'esportazione in streaming di Crashlytics in BigQuery, puoi visualizzare questi dati nella pagina Tendenze in tempo reale del modello di Data Studio.Puoi utilizzare l'esempio come modello per creare rapidamente nuovi report e visualizzazioni in base ai dati non elaborati degli arresti anomali della tua app:

1. Apri il Crashlytics modello di dashboard di Data Studio.

2. Fai clic su Utilizza modello nell'angolo in alto a destra.

3. Nel menu a discesa Nuova origine dati, seleziona Crea nuova origine dati.

4. Fai clic su Seleziona nella scheda BigQuery.

5. Seleziona una tabella contenente i dati Crashlytics esportati scegliendo I miei progetti > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

   La tabella batch è sempre disponibile per la selezione. Se l'esportazione streaming di Crashlytics in BigQuery è attivata, puoi selezionare la tabella in tempo reale.

6. In Configurazione, imposta Crashlytics Livello modello su Predefinito.

7. Fai clic su Connetti per creare la nuova origine dati.

8. Fai clic su Aggiungi al report per tornare al modello Crashlytics.

9. Infine, fai clic su Crea report per creare la tua copia del Crashlytics modello di dashboard di Data Studio.

Eseguire l'upgrade alla nuova infrastruttura di esportazione

A metà ottobre 2024, Crashlytics ha lanciato una nuova infrastruttura per l'esportazione dei dati di Crashlytics in BigQuery. Per il momento, l'upgrade a questa nuova infrastruttura è facoltativo.

Questa nuova infrastruttura supporta le località dei set di dati Crashlytics al di fuori degli Stati Uniti.

• Se hai attivato l'esportazione prima di metà ottobre 2024, ora puoi facoltativamente modificare la posizione di esportazione dei dati in qualsiasi posizione del set di dati supportata da BigQuery.

• Se hai attivato l'esportazione a partire da metà ottobre 2024, puoi selezionare qualsiasi posizione del set di dati supportata da BigQuery durante la configurazione.

Un'altra differenza della nuova infrastruttura è che non supporta il backfill dei dati prima dell'attivazione dell'esportazione. Con la vecchia infrastruttura, potevi eseguire il backfill fino a 30 giorni prima della data di attivazione. La nuova infrastruttura supporta i backfill fino agli ultimi 30 giorni o alla data più recente in cui hai attivato l'esportazione in BigQuery (a seconda di quale sia la più recente).

Prerequisito per l'upgrade

Prima di eseguire l'upgrade alla nuova infrastruttura, verifica di soddisfare il seguente prerequisito: le tabelle batch BigQuery correnti hanno identificatori corrispondenti agli ID bundle o ai nomi dei pacchetti impostati per le tue app Firebase registrate.

Ad esempio:

• Se hai una tabella BigQuery denominata com_yourcompany_yourproject_IOS, devi avere un'app Firebase per iOS registrata nel tuo progetto Firebase con l'ID del bundle com.yourcompany.yourproject.

• Se hai una tabella BigQuery denominata com_yourcompany_yourproject_ANDROID, dovresti avere un'app Android creata in Firebase registrata nel tuo progetto Firebase con il nome del pacchetto com.yourcompany.yourproject.

Ecco come trovare tutte le app Firebase registrate nel tuo progetto Firebase:

1. Nella console Firebase, vai alle Impostazioni del progetto di settings.

2. Scorri verso il basso fino alla scheda Le tue app, quindi fai clic sull'app Firebase che ti interessa per visualizzarne le informazioni, incluso l'identificatore.

La nuova infrastruttura di esportazione esporterà i dati di ogni app in base al nome del pacchetto o all'ID bundle impostato per l'app Firebase registrata. Per non interrompere il flusso di lavoro BigQuery, è importante assicurarsi che le tabelle batch correnti abbiano già i nomi corretti in modo che la nuova infrastruttura possa accodare tutti i nuovi dati alle tabelle esistenti. Se i nomi delle tabelle batch non corrispondono alle tue app Firebase registrate, ma vuoi comunque eseguire l'upgrade, rivolgiti all'assistenza Firebase.

Come eseguire l'upgrade alla nuova infrastruttura

Se hai già attivato l'esportazione, puoi eseguire l'upgrade alla nuova infrastruttura semplicemente disattivando e riattivando l'esportazione dei dati Crashlytics nella console Firebase.

Ecco la procedura dettagliata:

1. Nella console Firebase, vai alla pagina Integrazioni.

2. Nella scheda BigQuery, fai clic su Gestisci.

3. Disattiva il cursore Crashlytics per disattivare l'esportazione. Quando richiesto, conferma che vuoi interrompere l'esportazione dei dati.

4. Riattiva immediatamente il cursore Crashlytics per riattivare l'esportazione. Quando richiesto, conferma di voler esportare i dati.

   L'esportazione dei dati di Crashlytics in BigQuery ora utilizza la nuova infrastruttura di esportazione.