Exporter des données Firebase Crashlytics vers BigQuery

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 BigQuery SQL, de les exporter vers un autre fournisseur de cloud et de les utiliser pour la visualisation et les tableaux de bord personnalisés avec Looker Studio.

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), les journaux Crashlytics et d'autres données. Vous pourrez consulter les données Crashlytics exportées et le schéma de leur table plus loin sur cette page.

Voici quelques exemples de ce que vous pouvez faire avec vos données Crashlytics exportées :

• Exécuter des requêtes
  Vous pouvez exécuter des requêtes 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. Comme 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 sur les plantages. Vous trouverez une sélection d'exemples de requêtes plus loin sur cette page.

• Utiliser un modèle Looker Studio
  Crashlytics fournit un modèle Looker Studio prédéfini pour visualiser vos données exportées.

• Créer des vues
  L'interface utilisateur BigQuery vous permet de créer une vue, qui est une table virtuelle définie par une requête SQL. Pour obtenir des instructions détaillées sur les différents types de vues et sur la façon de les créer, consultez la documentation BigQuery.

• Combiner les données spécifiques à Crashlytics avec les données de sessions Firebase
  Vous pouvez également exporter les données de sessions Firebase lorsque vous configurez l'exportation des données Crashlytics. Utilisez ces données de sessions pour mieux comprendre les utilisateurs et les sessions sans plantage.

Avantages de l'exportation en streaming vers BigQuery

Par défaut, les données sont exportées vers BigQuery dans une exportation par lot quotidienne. De plus, vous pouvez diffuser vos données Crashlytics et vos sessions Firebase en temps réel avec le streaming 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, suivre 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 flux continu vers BigQuery, vous disposez également de tables en temps réel (en plus des tables par lot). Les deux types de tables auront le même schéma de jeu de données, mais voici quelques différences importantes entre les tables par lots et les tables en temps réel :

Le tableau par lot est idéal pour les analyses à 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. Ils peuvent être complétés dans le tableau pendant 30 jours maximum*. Lorsque nous écrivons des données dans votre tableau 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 avec une requête de couture pour profiter des avantages des deux.

Par défaut, le délai d'expiration des partitions de la table en temps réel est de 30 jours. Pour savoir comment modifier ce paramètre, consultez Définir le délai d'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 vers BigQuery

1. Dans la consoleFirebase, 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, y compris les options suivantes :

   • Pour mieux comprendre les utilisateurs et les sessions sans plantage, activez l'exportation des données de sessions Firebase.

   • Pour accéder en temps quasi réel à vos données Crashlytics et à vos données de sessions Firebase dans BigQuery, activez l'exportation en flux continu.

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

• Firebase exporte les données des applications associées à BigQuery.

  • Lors de la configuration, toutes les applications de votre projet sont associées à BigQuery par défaut, mais vous pouvez choisir de ne pas associer certaines applications lors de la configuration.

  • Toutes les applications que vous ajouterez ultérieurement à votre projet Firebase seront automatiquement associées à BigQuery.

  • Vous pouvez à tout moment gérer les applications qui exportent des données.

• Firebase exporte les données vers l'emplacement de l'ensemble de données que vous avez sélectionné lors de la configuration.

  • Cet emplacement s'applique à l'ensemble de données Crashlytics et à l'ensemble de données des sessions Firebase (si l'exportation des données de sessions est activée).

  • Cet emplacement ne s'applique qu'aux données exportées dans BigQuery. Il 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.

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

• Firebase configure des synchronisations quotidiennes de vos données par lot vers BigQuery.

  • Une fois l'association à BigQuery établie, l'exportation initiale des données par lot peut prendre jusqu'à 48 heures.

  • La synchronisation quotidienne a lieu une fois par jour, quels que soient les exports planifiés que vous avez configurés dans BigQuery. Notez que le timing et la durée du job de synchronisation peuvent changer. Nous vous déconseillons donc de planifier des opérations ou des jobs en aval en fonction d'un timing d'exportation spécifique.

• Firebase exporte une copie de vos données existantes vers BigQuery.

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

  • Vous pouvez planifier manuellement des remplissages de données pour le tableau par lot jusqu'aux 30 derniers jours ou pour 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 remplir les données 30 jours avant la date d'activation de l'exportation.

• Les informations suivantes s'appliquent si vous activez l'exportation en flux continu vers BigQuery.

  • Chaque application associée disposera également de son propre tableau en temps réel contenant des données constamment mises à jour (en plus du tableau par lot de l'application pour l'exportation quotidienne par lot).

  • Une fois le streaming activé, il peut s'écouler jusqu'à une heure avant que les données ne commencent à être diffusées.

  Vous ne voyez pas de données dans votre tableau en temps réel ?

  1. Assurez-vous d'avoir envoyé au moins deux événements depuis votre application vers Crashlytics et d'avoir attendu quelques minutes après les avoir envoyés.

  2. Assurez-vous que votre projet Firebase bénéficie du forfait Blaze avec paiement à l'usage.
     Vous pouvez le vérifier en regardant en bas à gauche de la console Firebase.

  3. Si aucune donnée ne s'affiche toujours dans votre tableau "Temps réel" après l'envoi de deux événements et quelques minutes d'attente :

     1. Accédez à la carte BigQuery dans la console Firebase.

     2. Désactivez, puis réactivez l'exportation en flux continu.

     3. Assurez-vous que le compte de service service-PROJECT_NUMBER@gcp-sa-crashlytics.iam.gserviceaccount.com se trouve dans votre projet Firebase et qu'il dispose du rôle Agent de service Firebase Crashlytics.
        Vous pouvez vérifier cela sur la page IAM de la console Google Cloud (assurez-vous de cocher la case Inclure les attributions de rôles fournies par Google).

     4. Envoyez au moins deux événements à Crashlytics et patientez quelques minutes.

  4. Si vous ne voyez toujours pas de données dans votre tableau en temps réel, contactez l'assistance Firebase.

Exemples de requêtes

Exemple 1 : Calculer les métriques sans plantage à l'aide des données de session Firebase

Dans votre dernière version, vous avez complètement remanié votre application pour résoudre les plantages dans un parcours utilisateur critique. Vous avez reçu d'excellents avis d'utilisateurs, mais vous aimeriez obtenir des preuves quantitatives que votre application est plus stable qu'avant.

Les métriques d'utilisation sans plantage peuvent vous aider à obtenir ces informations. Ces métriques sont des mesures importantes qui vous aident à comprendre l'état général de votre application. Grâce aux données de session Firebase et aux événements Crashlytics, vous pouvez calculer ces métriques à l'aide d'une requête de base.

Voici des exemples de requêtes pour une application Android. Pour une application iOS, utilisez son ID de bundle et IOS (au lieu du nom du package et de ANDROID).

Utilisateurs n'ayant pas subi de plantage pour une version spécifique :

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

Sessions sans plantage au cours de la semaine écoulée (168 dernières heures) :

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

Exemple 2 : Plantages par jour

Après avoir corrigé 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 3 : Trouver les plantages les plus fréquents

Pour hiérarchiser correctement les plans de production, vous devez identifier les 10 plantages les plus fréquents 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 4 : Top 10 des appareils présentant des plantages

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 5 : 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 définissez une clé Crashlytics personnalisée appelée current_level et la mettez à 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 n'avez plus qu'à rédiger une requête indiquant 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 6 : Extraction de l'ID utilisateur

Vous disposez d'une application Android en accès anticipé. La plupart de vos utilisateurs adorent cette application, mais trois d'entre eux ont subi un nombre inhabituel de plantages. Afin d'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 les ID utilisateur concernés.

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 7 : Rechercher tous les utilisateurs confrontés à un problème de plantage spécifique

Votre équipe a accidentellement déployé 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 fréquents" ci-dessus pour identifier l'ID du problème de plantage spécifique. Votre équipe souhaite maintenant exécuter une requête pour extraire la liste des utilisateurs de l'application qui ont été 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 8 : Nombre d'utilisateurs concernés par un problème de plantage, réparti 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 "Identifier les plantages les plus fréquents" ci-dessus pour identifier l'ID du problème de plantage spécifique. Votre équipe souhaite maintenant savoir si ce plantage s'est propagé aux utilisateurs dans différents pays du monde.

Pour écrire cette requête, votre équipe devra 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 aux SDK Google Analytics et 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. Rédigez une requête qui utilise le champ "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 9 : Top 5 des problèmes rencontrés aujourd'hui

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 10 : Top 5 des 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 d'assemblage pour ajouter des informations en temps réel aux données fiables par lot. Comme event_id est une clé primaire, vous pouvez utiliser DISTINCT event_id pour dédupliquer les événements courants 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

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

Looker 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 Looker Studio, consultez son guide de bienvenue.

Utiliser un modèle de rapport Crashlytics

Looker Studio propose un exemple de rapport pour Crashlytics qui comprend un ensemble complet de dimensions et de métriques issues du schéma BigQuery pour les données exportées depuis Crashlytics. Si vous avez activé l'exportation en flux continu Crashlytics vers BigQuery, vous pouvez afficher ces données sur la page Tendances en temps réel du modèle Looker Studio.Vous pouvez utiliser l'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 Crashlytics Looker Studio.

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

3. Dans le menu déroulant Nouvelle source de données, sélectionnez Créer une source de données.

4. Cliquez sur Sélectionner sur 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 tableau de lot. Si l'exportation en flux continu de 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 le rapport pour créer votre copie du modèle de tableau de bord Crashlytics Looker Studio.

Comprendre le schéma dans BigQuery

Firebase crée des ensembles de données dans BigQuery pour vos données exportées :

• Ensemble de données Crashlytics

• Ensemble de données des sessions Firebase (si l'exportation des données de sessions est activée)

Crashlytics ensemble de données

Les données Crashlytics sont exportées dans un ensemble de données BigQuery nommé firebase_crashlytics. L'ensemble de données couvre la totalité de votre projet, même si celui-ci comporte plusieurs applications.

Tables

Par défaut, Firebase crée des tables individuelles dans l'ensemble de données Crashlytics pour chaque application de votre projet associée à BigQuery.

Les tables sont nommées d'après l'identifiant de l'application (en remplaçant les points par des traits de soulignement) et en ajoutant la plate-forme de l'application (_IOS ou _ANDROID). Par exemple, les données d'une application Android dont le nom de package est com.google.test se trouveront dans une table nommée com_google_test_ANDROID.

• Si l'exportation en flux continu vers BigQuery est activée, les données seront également diffusées en temps réel dans une table à laquelle _REALTIME est ajouté (par exemple, 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 ANR.

• Les tables contiennent un ensemble standard de données Crashlytics, en plus des 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 ANR.

• Si l'exportation en flux continu vers BigQuery est activée, la table en temps réel aura les mêmes colonnes que la table par lot.

• Il est possible que certaines colonnes de lignes représentant des événements ne contiennent pas de traces de pile.

Voici les colonnes du tableau pour les données Crashlytics exportées :

Ensemble de données des sessions Firebase

Les données de sessions Firebase sont exportées dans un ensemble de données BigQuery nommé firebase_sessions. L'ensemble de données couvre la totalité de votre projet, même si celui-ci comporte plusieurs applications.

Tables

Par défaut, Firebase crée des tables individuelles dans l'ensemble de données "Sessions Firebase" pour chaque application de votre projet associée à BigQuery.

Les tables sont nommées d'après l'identifiant de l'application (en remplaçant les points par des traits de soulignement) et en ajoutant la plate-forme de l'application (_IOS ou _ANDROID). Par exemple, les données d'une application Android dont le nom de package est com.google.test se trouveraient dans une table nommée com_google_test_ANDROID.

Lignes

Chaque ligne d'un tableau représente un événement de session qui s'est produit.

Colonnes

Si l'exportation en flux continu vers BigQuery est activée, la table en temps réel aura les mêmes colonnes que la table par lot.

Voici les colonnes du tableau des données de sessions Firebase exportées :

Passer à la nouvelle infrastructure d'exportation

À la mi-octobre 2024, Crashlytics a lancé une nouvelle infrastructure pour l'exportation par lot des données Crashlytics vers BigQuery.

Tous les projets Firebase seront automatiquement migrés vers la nouvelle infrastructure d'exportation par lot à partir du 15 septembre 2025. Vous pouvez effectuer la mise à niveau avant cette date, mais assurez-vous que vos tables de lots BigQuery remplissent les conditions préalables pour la mise à niveau.

Vous pouvez migrer vers la nouvelle infrastructure, mais assurez-vous que vos tables par lot BigQuery répondent aux conditions préalables à la migration.

Déterminer si vous utilisez la nouvelle infrastructure

Si vous avez activé l'exportation par lot mi-octobre 2024 ou après, votre projet Firebase utilise automatiquement la nouvelle infrastructure d'exportation.

Pour vérifier l'infrastructure utilisée par votre projet : Accédez à la console Google Cloud. Si votre configuration de transfert de données est libellée Firebase Crashlytics with Multi-Region Support, cela signifie que votre projet utilise la nouvelle infrastructure d'exportation.

Différences importantes entre l'ancienne et la nouvelle infrastructure d'exportation

• La 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 et que vous avez migré vers la nouvelle infrastructure d'exportation, vous pouvez désormais modifier l'emplacement d'exportation des données (facultatif).

  • L'exportation a été activée mi-octobre 2024 ou plus tard : lors de la configuration, vous avez été invité à sélectionner un emplacement pour l'exportation des données.

• La nouvelle infrastructure n'est pas compatible avec le remplissage des données antérieures à l'activation de l'exportation.

  • L'ancienne infrastructure permettait le remplissage jusqu'à 30 jours avant la date à laquelle vous avez activé l'exportation.

  • La nouvelle infrastructure est compatible avec les remplissages 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).

• La nouvelle infrastructure nomme les tables de traitement par lot BigQuery à l'aide des identifiants définis pour vos applications Firebase dans votre projet Firebase.

  • L'ancienne infrastructure écrivait les données dans des tables par lot dont les noms étaient basés sur les ID de bundle ou les noms de package dans le binaire de votre application.

  • La nouvelle infrastructure écrit les données dans des tables par lot dont les noms sont basés sur les ID de bundle ou les noms de package définis pour vos applications Firebase enregistrées dans votre projet Firebase.

Étape 1 : Prérequis pour la mise à niveau

1. Vérifiez que vos tables de lot BigQuery existantes utilisent des identifiants correspondant aux ID de bundle ou aux noms de package définis pour vos applications Firebase enregistrées dans votre projet Firebase. Si ce n'est pas le cas, vous risquez de rencontrer des problèmes avec vos données exportées par lot. La plupart des projets seront dans un état approprié et compatible, mais il est important de vérifier avant de mettre à niveau.

   • Vous trouverez toutes les applications Firebase enregistrées dans votre projet Firebase dans la console Firebase : accédez à Paramètres du projet, puis faites défiler la page jusqu'à la fiche Vos applications pour afficher toutes vos applications Firebase et leurs informations.settings

   • Vous trouverez tous vos tableaux de lots BigQuery sur la page BigQuery de la console Google Cloud.

   Par exemple, voici des états idéaux dans lesquels vous ne rencontrerez aucun problème lors de la mise à niveau :

   • Vous disposez d'une table de lot nommée com_yourcompany_yourproject_IOS et d'une application Firebase iOS+ avec l'ID de bundle com.yourcompany.yourproject enregistrée dans votre projet Firebase.

   • Vous disposez d'une table par lot nommée com_yourcompany_yourproject_ANDROID et d'une application Android Firebase avec le nom de package com.yourcompany.yourproject enregistrée dans votre projet Firebase.

2. Si les noms de vos tables par lot ne correspondent pas aux identifiants définis pour vos applications Firebase enregistrées, suivez les instructions plus loin sur cette page avant de procéder à la mise à niveau manuelle ou avant le 15 septembre 2025 pour éviter toute interruption de votre exportation par lot.

Étape 2 : Mettre à niveau manuellement vers la nouvelle infrastructure

Si vous avez activé l'exportation par lot avant la mi-octobre 2024, vous pouvez passer manuellement à la nouvelle infrastructure en désactivant, puis en réactivant l'exportation des données Crashlytics dans la console Firebase.

Voici la procédure détaillée :

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

2. Sur 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 l'exportation en appuyant de nouveau sur le bouton Crashlytics. 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.

Le nom de votre table par lot existante ne correspond pas à l'identifiant de votre application Firebase