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 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 dans BigQuery en temps quasi réel, envisagez de passer à l'exportation en flux continu.

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éé, l'emplacement ne peut plus être modifié, mais vous pouvez copier l'ensemble de données 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.

  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.

• 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 des synchronisations quotidiennes de vos données vers BigQuery.

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

  • 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. La propagation initiale des données à exporter peut prendre jusqu'à 48 heures.

  • Pour chaque application associée, cette exportation inclut une table 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 à laquelle 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 constamment mises à jour.

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 dans un ensemble de données BigQuery nommé firebase_crashlytics. Par défaut, des tables individuelles seront 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 trouveraient dans une table nommée com_google_test_ANDROID. Cette table de lots 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 dans 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 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 les 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 Crashlytics vers BigQuery, vous disposez d'une table en temps réel en plus de la table par lot. Voici les différences à connaître entre les tableaux :

Le tableau par lot est idéal pour les analyses à long terme et l'identification des tendances au fil du temps, car nous stockons durablement les événements 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 en flux continu de Crashlytics vers BigQuery

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

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

3. Cochez la case Inclure le streaming.

Cette action permet 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), les journaux Crashlytics et d'autres données.

Consultez plus loin sur cette page les données Crashlytics exportées et le schéma de leur 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 Créer des vues dans la documentation BigQuery.

Exécuter des requêtes

Les exemples suivants montrent comment 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. É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 sur les plantages.

Exemple 1 : 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 2 : 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 3 : Top 10 des appareils générant le plus de 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 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 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 5 : 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 6 : 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 7 : Nombre d'utilisateurs concernés par un problème de plantage, répartis 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 8 : Top 5 des problèmes rencontrés jusqu'à présent 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 9 : Cinq 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 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 >= "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 ceux survenus jusqu'à deux jours avant l'association, avec la possibilité de remplir les données manquantes 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 dans l'ensemble de données pour chaque application de votre projet, à moins que vous n'ayez désactivé l'exportation des données pour cette application. Firebase nomme les tables en fonction de 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 trouveraient dans une table nommée com_google_test_ANDROID, et les données en temps réel (si elles sont activées) se trouveraient dans une table nommée com_google_test_ANDROID_REALTIME.

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 Crashlytics vers BigQuery est activée, la table en temps réel aura les mêmes colonnes que la table par lot. Notez que vous pouvez avoir des colonnes dans des lignes qui représentent des événements sans trace 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 pour les données exportées depuis Crashlytics. Si vous avez activé l'exportation en flux 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 Crashlytics Data 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 Data Studio Crashlytics.

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 mis à niveau vers la nouvelle infrastructure d'exportation par lot dès le 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 des données 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 la configuration Firebase du codebase 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 de 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 console Firebase, 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 réactivant 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 de lot existante ne correspond pas à l'identifiant de votre application Firebase