Exporter des données Firebase Crashlytics vers BigQuery

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Vous pouvez exporter vos données Firebase Crashlytics vers BigQuery pour une analyse plus approfondie. BigQuery vous permet d'analyser les données à l'aide de SQL BigQuery, de les exporter vers un autre fournisseur de services cloud et de les utiliser pour la visualisation et les tableaux de bord personnalisés avec Google Data Studio.

Activer l'exportation vers BigQuery

1. Dans la console Firebase, accédez à la page Intégrations.

2. Sur la fiche BigQuery, cliquez sur Associer.

3. Suivez les instructions à l'écran pour activer l'exportation vers BigQuery.

   Si vous souhaitez accéder à vos données Crashlytics en quasi temps réel dans BigQuery, envisagez de passer à l'exportation en streaming.

Que se passe-t-il lorsque vous activez l'exportation ?

• Vous sélectionnez l'emplacement de l'ensemble de données. Une fois l'ensemble de données créé, son emplacement ne peut plus être modifié, mais vous pouvez le copier dans un autre emplacement ou le déplacer manuellement (recréer) dans un autre emplacement. Pour en savoir plus, consultez Modifier l'emplacement des exportations existantes.

  Cet emplacement ne s'applique qu'aux données exportées vers BigQuery et n'a aucune incidence sur l'emplacement des données stockées pour être utilisées dans le tableau de bord Crashlytics de la console Firebase ou dans Android Studio.

• Par défaut, toutes les applications de votre projet sont associées à BigQuery. Si vous en ajoutez d'autres ensuite, elles seront également automatiquement associées à BigQuery. Vous pouvez gérer les applications qui envoient des données.

• Firebase configure la synchronisation quotidienne de vos données avec BigQuery.

  • Une fois votre projet associé, vous devez généralement attendre la synchronisation du jour suivant pour que votre premier ensemble de données soit exporté vers BigQuery.

  • La synchronisation quotidienne a lieu une fois par jour, quelle que soit l'exportation planifiée que vous avez peut-être configurée dans BigQuery. Notez que le calendrier et la durée de la tâche de synchronisation peuvent changer. Nous vous recommandons donc de ne pas planifier d'opérations ou de tâches en aval en fonction d'un calendrier spécifique d'exportation.

• Firebase exporte une copie de vos données existantes vers BigQuery. La propagation initiale des données à exporter peut prendre jusqu'à 48 heures.

  • Pour chaque application associée, cette exportation inclut un tableau de lot contenant les données de la synchronisation quotidienne.

  • Vous pouvez planifier manuellement le remplissage des données pour le tableau par lot jusqu'aux 30 derniers jours ou jusqu'à la date la plus récente à laquelle vous avez activé l'exportation vers BigQuery (selon la date la plus récente).

  Notez que si vous avez activé l'exportation des données Crashlytics avant la mi-octobre 2024, vous pouvez également effectuer un remplissage rétroactif 30 jours avant le jour où vous avez activé l'exportation.

• Si vous activez l'exportation en flux continu Crashlytics vers BigQuery, toutes les applications associées disposeront également d'un tableau en temps réel contenant des données en constante évolution.

Pour désactiver l'exportation vers BigQuery, dissociez votre projet dans la console Firebase.

Quelles données sont exportées vers BigQuery ?

Les données Firebase Crashlytics sont exportées vers un ensemble de données BigQuery nommé firebase_crashlytics. Par défaut, des tables individuelles sont créées dans l'ensemble de données Crashlytics pour chaque application de votre projet. Firebase nomme les tables d'après l'identifiant de l'application, en remplaçant les points par des traits de soulignement et en ajoutant un nom de plate-forme à la fin.

Par exemple, les données d'une application Android dont le nom de package est com.google.test se trouvent dans une table nommée com_google_test_ANDROID. Cette table de lot est mise à jour une fois par jour. Si vous activez l'exportation en flux continu Crashlytics vers BigQuery, les données Crashlytics seront également diffusées en temps réel vers une table nommée com_google_test_ANDROID_REALTIME.

Chaque ligne d'un tableau représente un événement qui s'est produit dans l'application, y compris les plantages, les erreurs non fatales et les erreurs ANR.

Exportation en flux continu de Crashlytics vers BigQuery

Vous pouvez diffuser vos données Crashlytics en temps réel avec la diffusion BigQuery. Vous pouvez l'utiliser à toutes fins nécessitant des données en direct, par exemple pour présenter des informations dans un tableau de bord en direct, regarder un déploiement en direct ou surveiller les problèmes d'application qui déclenchent des alertes et des workflows personnalisés.

Lorsque vous activez l'exportation en streaming Crashlytics vers BigQuery, en plus de la table par lot, vous disposez également d'une table en temps réel. Voici les différences à prendre en compte entre les tableaux:

Le tableau par lot est idéal pour l'analyse à long terme et l'identification des tendances au fil du temps, car nous stockons les événements de manière durable avant de les écrire, et ils peuvent être renseignés dans le tableau jusqu'à 30 jours*. Lorsque nous écrivons des données dans votre table en temps réel, nous les écrivons immédiatement dans BigQuery. Il est donc idéal pour les tableaux de bord en direct et les alertes personnalisées. Ces deux tables peuvent être combinées à une requête de couture pour profiter des avantages des deux.

Par défaut, la table en temps réel a un délai d'expiration de partition de 30 jours. Pour savoir comment modifier ce paramètre, consultez la section Définir l'expiration de la partition dans la documentation BigQuery.

^{* Pour en savoir plus sur la prise en charge du remplissage, consultez Passer à la nouvelle infrastructure d'exportation.}

Activer l'exportation en streaming Crashlytics vers BigQuery

1. Dans la console Firebase, accédez à la page Intégrations.

2. Sur la fiche BigQuery, cliquez sur Gérer.

3. Cochez la case Inclure le streaming.

Cette action active le streaming pour toutes vos applications associées.

Que pouvez-vous faire avec les données exportées ?

Les exportations vers BigQuery contiennent des données brutes sur les plantages, y compris le type d'appareil, le système d'exploitation, les exceptions (applications Android) ou les erreurs (applications Apple), ainsi que des journaux Crashlytics et d'autres données.

Consultez plus loin sur cette page les données Crashlytics exportées et le schéma de la table.

Utiliser un modèle Data Studio

Pour activer les données en temps réel dans votre modèle Data Studio, suivez les instructions de la section Visualiser les données Crashlytics exportées avec Data Studio.

Créer des vues

Vous pouvez transformer des requêtes en vues à l'aide de l'interface utilisateur BigQuery. Pour obtenir des instructions détaillées, consultez la section Créer des vues dans la documentation BigQuery.

Exécuter des requêtes

Les exemples suivants illustrent les requêtes que vous pouvez exécuter sur vos données Crashlytics pour générer des rapports qui agrègent les données d'événement de plantage sous une forme synthétique plus facilement exploitable. Étant donné que ces types de rapports ne sont pas disponibles dans le tableau de bord Crashlytics de la console Firebase, ils peuvent compléter votre analyse et votre compréhension des données de plantage.

Exemple 1: Accidents par jour

Après avoir travaillé pour corriger autant de bugs que possible, vous pensez que votre équipe est enfin prête à lancer votre nouvelle application de partage de photos. Avant de le faire, vous souhaitez vérifier le nombre de plantages par jour au cours du mois écoulé afin de vous assurer que vos actions de débogage ont progressivement réussi à stabiliser l'application.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 2: Trouver les plantages les plus courants

Pour hiérarchiser correctement les plans de production, vous souhaitez identifier les 10 plantages les plus courants dans votre application. Vous créez une requête qui fournit les points de données pertinents.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 3: Top 10 des appareils qui plantent

L'automne est la saison idéale pour changer de téléphone ! Votre entreprise sait que cette saison annonce également une foule de problèmes inédits liés à tous ces nouveaux appareils, en particulier pour Android. Pour anticiper les problèmes de compatibilité à venir, vous avez mis en place une requête qui identifie les 10 appareils ayant subi le plus de plantages au cours de la semaine écoulée (168 heures).

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 4: Filtrer par clé personnalisée

Vous êtes développeur de jeux vidéo et vous souhaitez savoir quel niveau de votre jeu connaît le plus de plantages.

Pour suivre cette statistique, vous devez définir une clé Crashlytics personnalisée appelée current_level et la mettre à jour chaque fois que l'utilisateur atteint un nouveau niveau.

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

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Crashlytics.setInt("current_level", 3);

Une fois cette clé incluse dans votre exportation vers BigQuery, vous pouvez rédiger une requête pour indiquer la distribution des valeurs current_level associées à chaque événement de plantage.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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

Exemple 5: Extraction de l'ID utilisateur

Vous disposez d'une application Android en accès anticipé. La plupart de vos utilisateurs l'adorent, mais trois d'entre eux ont subi un nombre inhabituel de plantages. Pour aller au fond du problème, vous rédigez une requête qui extrait tous les événements de plantage qu'ont connu ces utilisateurs en s'appuyant sur leurs ID utilisateur.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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
 

Exemple 6: Rechercher tous les utilisateurs confrontés à un problème de plantage spécifique

Votre équipe a accidentellement publié un bug critique auprès d'un groupe de testeurs bêta. Votre équipe a pu utiliser la requête de l'exemple "Trouver les plantages les plus courants" ci-dessus pour identifier l'ID de problème de plantage spécifique. Votre équipe souhaite maintenant exécuter une requête pour extraire la liste des utilisateurs de l'application concernés par ce plantage.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 7: Nombre d'utilisateurs concernés par un problème de plantage, par pays

Votre équipe a détecté un bug critique lors du déploiement d'une nouvelle version. Vous avez pu utiliser la requête de l'exemple "Trouver les plantages les plus courants" ci-dessus pour identifier l'ID de problème de plantage spécifique. Votre équipe souhaite maintenant savoir si ce plantage s'est propagé aux utilisateurs de différents pays du monde.

Pour écrire cette requête, votre équipe doit procéder comme suit:

1. Activez l'exportation des données Google Analytics vers BigQuery. Consultez Exporter les données du projet vers BigQuery.

2. Mettez à jour votre application pour transmettre un ID utilisateur au SDK Google Analytics et au 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. Écrivez une requête qui utilise le champ d'ID utilisateur pour joindre les événements de l'ensemble de données Google Analytics aux plantages de l'ensemble de données Crashlytics.

   Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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

Exemple 8: Top 5 des problèmes jusqu'à présent

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Exemple 9: 5 principaux problèmes depuis DATE, y compris aujourd'hui

Vous pouvez également combiner les tables par lot et en temps réel avec une requête de couture pour ajouter des informations en temps réel aux données par lot fiables. Étant donné que event_id est une clé primaire, vous pouvez utiliser DISTINCT event_id pour dédupliquer les événements communs des deux tables.

Voici un exemple de requête pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de 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;

Comprendre le schéma Crashlytics dans BigQuery

Lorsque vous configurez l'exportation des données Crashlytics vers BigQuery, Firebase exporte les événements récents (plantages, erreurs non fatales et erreurs ANR), y compris les événements remontant jusqu'à deux jours avant l'association, avec la possibilité de remplir jusqu'à 30 jours.

À partir de ce moment et jusqu'à ce que vous désactiviez l'exportation, Firebase exporte quotidiennement les événements Crashlytics. Plusieurs minutes peuvent être nécessaires pour que les données soient disponibles dans BigQuery après chaque exportation.

Ensembles de données

Crashlytics crée un ensemble de données dans BigQuery pour les données Crashlytics. Cet ensemble de données couvre la totalité de votre projet, même si celui-ci comporte plusieurs applications.

Tables

Crashlytics crée une table distincte dans l'ensemble de données pour chacune des applications de votre projet, à l'exception de celles pour lesquelles vous avez désactivé les exportations de données. Firebase nomme les tables d'après l'identifiant de l'application, en remplaçant les points par des traits de soulignement et en ajoutant un nom de plate-forme à la fin.

Par exemple, les données d'une application Android dont le nom de package est com.google.test se trouvent dans une table nommée com_google_test_ANDROID, et les données en temps réel (si elles sont activées) se trouvent dans une table nommée com_google_test_ANDROID_REALTIME.

Les tables contiennent un ensemble standard de données Crashlytics en plus de toutes les clés Crashlytics personnalisées que vous avez définies dans votre application.

Lignes

Chaque ligne d'une table représente une erreur rencontrée par l'application.

Colonnes

La table comprend les mêmes colonnes pour les plantages, les erreurs non fatales et les erreurs ANR. Si l'exportation en streaming Crashlytics vers BigQuery est activée, la table en temps réel aura les mêmes colonnes que la table par lot. Notez que des colonnes de lignes peuvent représenter des événements qui ne comportent pas de traces de pile.

Les colonnes incluses dans l'exportation sont répertoriées dans ce tableau:

Visualiser les données Crashlytics exportées avec Data Studio

Google Data Studio transforme vos ensembles de données Crashlytics dans BigQuery en rapports plus faciles à lire et à partager, et entièrement personnalisables.

Pour en savoir plus sur l'utilisation de Data Studio, consultez le guide de démarrage rapide intitulé Bienvenue dans Data Studio.

Utiliser un modèle de rapport Crashlytics

Data Studio propose un exemple de rapport pour Crashlytics qui comprend un ensemble complet de dimensions et de métriques issues du schéma BigQuery Crashlytics exporté. Si vous avez activé l'exportation de streaming Crashlytics vers BigQuery, vous pouvez afficher ces données sur la page Tendances en temps réel du modèle Data Studio.Vous pouvez utiliser cet exemple comme modèle pour créer rapidement des rapports et des visualisations basés sur les données de plantage brutes de votre propre application:

1. Ouvrez le modèle de tableau de bord Data Studio Crashlytics.

2. Cliquez sur Utiliser le modèle dans l'angle supérieur droit.

3. Dans la liste déroulante Nouvelle source de données, sélectionnez Créer une source de données.

4. Cliquez sur Sélectionner dans la fiche BigQuery.

5. Sélectionnez une table contenant des données Crashlytics exportées en accédant à Mes projets > PROJECT_ID > firebase_crashlytics > TABLE_NAME.

   Vous pouvez toujours sélectionner votre table de lot. Si l'exportation en flux continu Crashlytics vers BigQuery est activée, vous pouvez sélectionner votre table en temps réel à la place.

6. Sous Configuration, définissez le champ Niveau du modèle Crashlytics sur Par défaut.

7. Cliquez sur Associer pour créer la source de données.

8. Cliquez sur Ajouter au rapport pour revenir au modèle Crashlytics.

9. Enfin, cliquez sur Créer un rapport pour créer votre copie du modèle de tableau de bord Data Studio Crashlytics.

Passer à la nouvelle infrastructure d'exportation

Mi-octobre 2024, Crashlytics a lancé une nouvelle infrastructure pour exporter les données Crashlytics vers BigQuery. Pour le moment, la migration vers cette nouvelle infrastructure est facultative.

Cette nouvelle infrastructure est compatible avec les emplacements d'ensembles de données Crashlytics en dehors des États-Unis.

• Si vous avez activé l'exportation avant la mi-octobre 2024, vous pouvez désormais modifier l'emplacement de l'exportation des données vers n'importe quel emplacement d'ensemble de données compatible avec BigQuery.

• Si vous avez activé l'exportation à la mi-octobre 2024 ou plus tard, vous pouvez sélectionner n'importe quel emplacement d'ensemble de données compatible avec BigQuery lors de la configuration.

Autre différence de la nouvelle infrastructure : elle n'est pas compatible avec le remplissage des données avant l'activation de l'exportation. (Avec l'ancienne infrastructure, vous pouviez effectuer un remplissage jusqu'à 30 jours avant la date d'activation.) La nouvelle infrastructure prend en charge les remplissages jusqu'aux 30 derniers jours ou à la date la plus récente à laquelle vous avez activé l'exportation vers BigQuery (selon la date la plus récente).

Prérequis pour la mise à niveau

Avant de passer à la nouvelle infrastructure, vérifiez que vous remplissez la condition préalable suivante: vos tables BigQuery de lot actuelles disposent d'identifiants correspondant aux ID de bundle ou aux noms de package définis pour vos applications Firebase enregistrées.

Exemple :

• Si vous disposez d'une table BigQuery nommée com_yourcompany_yourproject_IOS, vous devez disposer d'une application Firebase iOS+ enregistrée dans votre projet Firebase avec l'ID de bundle com.yourcompany.yourproject.

• Si vous disposez d'une table BigQuery nommée com_yourcompany_yourproject_ANDROID, vous devez disposer d'une application Android Firebase enregistrée dans votre projet Firebase avec le nom de package com.yourcompany.yourproject.

Voici comment trouver toutes les applications Firebase enregistrées dans votre projet Firebase:

1. Dans la console Firebase, accédez à vos Paramètres du projet settings.

2. Faites défiler la page jusqu'à la fiche Vos applications, puis cliquez sur l'application Firebase souhaitée pour afficher ses informations, y compris son identifiant.

La nouvelle infrastructure d'exportation exportera les données de chaque application en fonction du nom du package ou de l'ID de bundle défini pour l'application Firebase enregistrée. Pour ne pas perturber votre workflow BigQuery, il est important de vous assurer que vos tables de lot actuelles portent déjà les noms appropriés afin que la nouvelle infrastructure puisse ajouter toutes les nouvelles données aux tables existantes. Si les noms de tables de lot ne correspondent pas à vos applications Firebase enregistrées, mais que vous souhaitez tout de même effectuer la mise à niveau, contactez l'assistance Firebase.

Mettre à niveau vers la nouvelle infrastructure

Si vous avez déjà activé l'exportation, vous pouvez passer à la nouvelle infrastructure en désactivant, puis en réactivant l'exportation de données Crashlytics dans la console Firebase.

Voici la procédure détaillée:

1. Dans la console Firebase, accédez à la page Intégrations.

2. Dans la fiche BigQuery, cliquez sur Gérer.

3. Désactivez le curseur Crashlytics pour désactiver l'exportation. Lorsque vous y êtes invité, confirmez que vous souhaitez arrêter l'exportation des données.

4. Réactivez immédiatement le curseur Crashlytics pour réactiver l'exportation. Lorsque vous y êtes invité, confirmez que vous souhaitez exporter les données.

   L'exportation de vos données Crashlytics vers BigQuery utilise désormais la nouvelle infrastructure d'exportation.