Exporter les données Firebase Crashlytics vers BigQuery

Vous pouvez exporter vos données Crashlytics dans 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 cloud et de les utiliser pour la visualisation et des tableaux de bord personnalisés avec Google Data Studio.

Activer l'exportation BigQuery

1. Accédez à la page Intégrations dans la console Firebase.
2. Dans la fiche BigQuery , cliquez sur Associer .
3. Suivez les instructions à l'écran pour activer BigQuery.

Lorsque vous associez votre projet à BigQuery :

• Firebase configure des synchronisations quotidiennes de vos données de votre projet Firebase vers BigQuery.
• Par défaut, toutes les applications de votre projet sont liées à BigQuery et toutes les applications que vous ajoutez ultérieurement au projet sont automatiquement liées à BigQuery. Vous pouvez gérer les applications qui envoient des données .
• Firebase exporte une copie de vos données existantes vers BigQuery. Pour chaque application liée, cela inclut une table de lot contenant les données de la synchronisation quotidienne.
• Si vous activez l'exportation en continu Crashlytics BigQuery, toutes les applications liées auront également un tableau en temps réel contenant des données constamment mises à jour.

Pour désactiver l'exportation 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 en fonction de l'identifiant de bundle de l'application, avec des points convertis en traits de soulignement et un nom de plate-forme ajouté à la fin.

Par exemple, les données d'une application avec l'ID com.google.test seraient 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 continu Crashlytics BigQuery, les données Firebase Crashlytics seront également diffusées en temps réel sur 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.

Activer l'exportation de flux Crashlytics BigQuery

Vous pouvez diffuser vos données Crashlytics en temps réel avec BigQueryStreaming . Vous pouvez l'utiliser à toutes fins nécessitant des données en direct, telles que la présentation d'informations dans un tableau de bord en direct, la surveillance d'un déploiement en direct ou la surveillance de problèmes d'application qui déclenchent des alertes et des workflows personnalisés.

L'exportation en continu Crashlytics BigQuery n'est pas disponible pour le bac à sable BigQuery.

Lorsque vous activez l'exportation en continu Crashlytics BigQuery, en plus de la table des lots, vous disposez d'une table en temps réel. Voici les différences que vous devez connaître entre les tables :

La table de lot est idéale pour l'analyse à long terme et l'identification des tendances dans le temps car nous stockons durablement les événements avant de les écrire, et ils peuvent être remplis dans la table jusqu'à 90 jours. 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 d'assemblage pour obtenir les avantages des deux. Voir l'exemple de requête 9 ci-dessous.

Par défaut, la table en temps réel a un délai d'expiration de partition de 30 jours. Pour savoir comment modifier cela, consultez Mise à jour de l'expiration de la partition .

Activer la diffusion Crashlytics BigQuery

Pour activer le streaming, accédez à la section Crashlytics de la page des intégrations BigQuery et cochez la case Inclure le streaming .

Modèle de studio de données

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

Vues

Vous pouvez transformer les exemples de requêtes ci-dessous en vues à l'aide de l'interface utilisateur de BigQuery. Voir Création de vues pour des instructions détaillées.

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

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

Utilisation des données Firebase Crashlytics dans BigQuery

Les exemples suivants illustrent les requêtes que vous pouvez exécuter sur vos données Crashlytics. Ces requêtes génèrent des rapports qui ne sont pas disponibles dans le tableau de bord Crashlytics.

Exemples de requêtes Crashlytics

Les exemples suivants montrent comment générer des rapports qui regroupent les données d'événements de plantage dans des résumés plus faciles à comprendre.

Exemple 1 : Plantages par jour

Après avoir travaillé pour corriger autant de bugs que possible, un développeur principal pense que son équipe est enfin prête à lancer sa nouvelle application de partage de photos. Avant de le faire, ils souhaitent vérifier le nombre de plantages par jour au cours du mois écoulé, pour s'assurer que leur bug-bash a rendu l'application plus stable au fil du temps :

SELECT
  COUNT(DISTINCT event_id) AS number_of_crashes,
  FORMAT_TIMESTAMP("%F", event_timestamp) AS date_of_crashes
FROM
 `projectId.firebase_crashlytics.package_name_ANDROID`
GROUP BY
  date_of_crashes
ORDER BY
  date_of_crashes DESC
LIMIT 30;

Exemple 2 : Rechercher les plantages les plus répandus

Pour hiérarchiser correctement les plans de production, un chef de projet réfléchit à la manière d'identifier les 10 plantages les plus répandus dans son produit. Ils produisent une requête qui fournit les points de données pertinents :

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
  `projectId.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 : 10 principaux appareils en panne

L'automne est la nouvelle saison des téléphones ! Un développeur sait que cela signifie également que c'est la nouvelle saison des problèmes spécifiques à l'appareil. Pour anticiper les problèmes de compatibilité imminents, ils ont mis en place une requête qui identifie les 10 appareils qui ont connu le plus de plantages au cours de la semaine dernière :

SELECT
  device.model,
COUNT(DISTINCT event_id) AS number_of_crashes
FROM
  `projectId.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

Un développeur de jeux souhaite savoir quel niveau de son jeu subit le plus de plantages. Pour les aider à suivre cette statistique, ils définissent une clé Crashlytics personnalisée current_level et la mettent à jour chaque fois que l'utilisateur atteint un nouveau niveau.

CrashlyticsKit setIntValue:3 forKey:@"current_level";

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

Crashlytics.setInt("current_level", 3);

Avec cette clé dans leur exportation BigQuery, ils écrivent ensuite une requête pour signaler la distribution des valeurs current_level associées à chaque événement de plantage :

SELECT
COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `projectId.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

Un développeur a une application en accès anticipé. La plupart de leurs utilisateurs l'adorent, mais trois ont connu un nombre inhabituel de plantages. Pour aller au fond du problème, ils écrivent une requête qui récupère tous les événements de plantage pour ces utilisateurs, à l'aide de leurs ID utilisateur :

SELECT *
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  user.id IN ("userid1", "userid2", "userid3")
ORDER BY
  user.id
 

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

Un développeur a communiqué un bogue critique à un groupe de bêta-testeurs. L'équipe a pu utiliser la requête de l'exemple 2 ci-dessus pour identifier l'ID de problème de plantage spécifique. Maintenant, ils aimeraient exécuter une requête pour extraire la liste des utilisateurs de l'application qui ont été touchés par ce plantage :

SELECT user.id as user_id
FROM
  `projectId.firebase_crashlytics.package_name_ANDROID`
WHERE
  issue_id = "YOUR_ISSUE_ID"
  AND application.display_version = ""
  AND user.id != ""
ORDER BY
  user.id;

Exemple 7 : nombre d'utilisateurs touchés par un problème de plantage, ventilé par pays

Maintenant, l'équipe a détecté un bogue critique lors du déploiement d'une nouvelle version. Ils ont pu utiliser la requête de l'exemple 2 ci-dessus pour identifier l'ID de problème de plantage spécifique. L'équipe aimerait maintenant voir si ce crash s'est propagé aux utilisateurs dans différents pays du monde.

Pour rédiger cette requête, l'équipe devra :

1. Activez les exportations BigQuery pour Google Analytics. Consultez Exporter des données de projet vers BigQuery .

2. Mettez à jour leur application pour transmettre un ID utilisateur à la fois au SDK Google Analytics et au SDK Crashlytics.

   Objectif c

   CrashlyticsKit setUserIdentifier:@"123456789";
   FIRAnalytics setUserID:@"12345678 9";
   

   Rapide

   Crashlytics.sharedInstance().setUserIdentifier("123456789");
   Analytics.setUserID("123456789");
   

   Java

   Crashlytics.setUserIdentifier("123456789");
   mFirebaseAnalytics.setUserId("123456789");
   

3. Écrivez une requête qui utilise le champ ID utilisateur pour joindre des événements dans l'ensemble de données Google Analytics BigQuery avec des plantages dans l'ensemble de données Crashlytics BigQuery :

   SELECT DISTINCT c.issue_id, a.geo.country, COUNT(DISTINCT c.user.id) as num_users_impacted
   FROM `projectId.firebase_crashlytics.package_name_ANDROID` c
   INNER JOIN  `projectId.analytics_YOUR_TABLE.events_*` a on c.user.id = a.user_id
   WHERE
    c.issue_id = "YOUR_ISSUE_ID"
    AND a._TABLE_SUFFIX BETWEEN '20190101'
    AND '20200101'
   GROUP BY
    c.issue_id,
    a.geo.country,
    c.user.id
   

Exemple 8 : 5 principaux problèmes jusqu'à présent aujourd'hui

Nécessite l'activation de l'exportation en continu Crashlytics BigQuery

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM
  `your_project.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 problèmes les plus fréquents depuis le DATE, y compris aujourd'hui

Nécessite l'activation de l'exportation en continu Crashlytics BigQuery.

Dans cet exemple, nous combinons des tables de lot et en temps réel pour ajouter des informations en temps réel aux données de lot fiables. Étant donné que event_id est une clé primaire, nous pouvons utiliser DISTINCT event_id pour dédupliquer tous les événements communs des deux tables.

SELECT
  issue_id,
  COUNT(DISTINCT event_id) AS events
FROM (
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `your_project.firebase_crashlytics.package_name_ANDROID_REALTIME`
  UNION ALL
  SELECT
    issue_id,
    event_id,
    event_timestamp
  FROM
    `your_project.firebase_crashlytics.package_name_ANDROID`)
WHERE
  event_timestamp >= "2020-01-13"
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Comprendre le schéma Firebase Crashlytics dans BigQuery

Lorsque vous associez Crashlytics à BigQuery, Firebase exporte les événements récents (plantages, erreurs non fatales et ANR), y compris les événements survenus jusqu'à deux jours avant l'association, avec la possibilité de remplir jusqu'à quatre-vingt-dix jours.

À partir de ce moment et jusqu'à ce que vous désactiviez le lien, Firebase exporte quotidiennement les événements Crashlytics. La disponibilité des données dans BigQuery peut prendre quelques minutes après chaque exportation.

Jeux de données

Firebase Crashlytics crée un nouvel ensemble de données dans BigQuery pour les données Crashlytics. L'ensemble de données couvre l'intégralité de votre projet, même s'il comporte plusieurs applications.

les tables

Firebase Crashlytics crée une table dans l'ensemble de données pour chaque application de votre projet, sauf si vous avez désactivé l'exportation des données pour cette application. Firebase nomme les tables en fonction de l'identifiant de bundle de l'application, avec des points convertis en traits de soulignement et un nom de plate-forme ajouté à la fin.

Par exemple, les données d'une application Android avec l'ID com.google.test seraient dans une table nommée com_google_test_ANDROID et les données en temps réel (si activées) seraient 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 définies par les développeurs.

Lignes

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

Colonnes

Les colonnes d'un tableau sont identiques pour les plantages, les erreurs non fatales et les ANR. Si l'exportation en continu Crashlytics BigQuery est activée, la table en temps réel aura les mêmes colonnes que la table par lots. Les colonnes de l'exportation sont répertoriées ci-dessous.

Sans traces de pile

Colonnes présentes dans des lignes qui représentent des événements sans traces de pile.

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

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

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

Utiliser un modèle de rapport Crashlytics

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

1. Ouvrez le modèle de tableau de bord Crashlytics Data Studio .
2. Cliquez sur Utiliser le modèle dans le coin supérieur droit.
3. Dans la liste déroulante Nouvelle source de données , sélectionnez Créer une nouvelle 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 choisissant Mes projets > [your-project-name] > firebase_crashlytics > [your-table-name] . Votre table de lot est toujours disponible pour être sélectionnée ; si l'exportation en continu Crashlytics BigQuery est activée, vous pouvez sélectionner votre table en temps réel à la place.
6. Sous Configuration , définissez le niveau du modèle Crashlytics sur Par défaut .
7. Cliquez sur Connecter pour créer la nouvelle 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 Crashlytics Data Studio.