Exécuter des requêtes SQL sur les données exportées dans BigQuery

Une fois que vous avez exporté vos données Crashlytics et (éventuellement) vos données de sessions Firebase dans BigQuery, vous pouvez commencer à travailler avec les données :

  • Analyser les données à l'aide de requêtes SQL
    Vous pouvez exécuter des requêtes sur vos données Crashlytics pour générer des rapports et des récapitulatifs personnalisés. Étant donné que ces types de rapports personnalisés 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. Consultez la collection d'exemples de requêtes plus loin sur cette page.

  • Joindre des données provenant de différents ensembles de données
    Par exemple, si vous choisissez d'exporter les données des sessions Firebase lorsque vous configurez l'exportation de données Crashlytics, vous pouvez mieux comprendre les utilisateurs sans plantage et les sessions sans plantage (voir l'exemple de requête). Vous pouvez également exporter des données depuis différents produits Firebase (comme Performance Monitoring) ou depuis Google Analytics, puis les joindre et les analyser dans BigQuery avec vos données Crashlytics.

  • Créer des vues
    À l'aide de l'interface utilisateur BigQuery, vous pouvez 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.

Pour en savoir plus sur le schéma de l'ensemble de données, consultez Schéma de l'ensemble de données pour les données exportées dans BigQuery.

En savoir plus sur BigQuery SQL

Exemples de requêtes pour les données Crashlytics

Cette section fournit des exemples de situations et de requêtes qui montrent comment utiliser le langage SQL BigQuery avec vos données Crashlytics exportées et vos données de sessions Firebase.

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 fournir 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(sessions.event_timestamp,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.firebase_session_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(sessions.event_timestamp,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 : Identifier 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 (iOS+ | Android | Flutter | Unity) appelée current_level, et vous la mettez à jour chaque fois que l'utilisateur atteint un nouveau niveau.

Swift

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

Objective-C

CrashlyticsKit setIntValue:3 forKey:@"current_level";

Java

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 : Extraire des 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é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 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;

Étape suivante