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

Après avoir exporté vos données de sessions Crashlytics et (facultativement) Firebase vers BigQuery, vous pouvez commencer à les utiliser :

  • 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ésumés personnalisés. Comme 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 de plantage. Consultez la collection d'exemples de requêtes plus loin sur cette page.

  • Associer des données 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 des 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'interface utilisateur de 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 leur création, consultez la documentation sur 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 et vos données de sessions Firebase exportées.

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

Dans votre dernière version, vous avez lancé une refonte majeure de votre application pour résoudre les plantages dans un parcours utilisateur critique. Vous avez reçu d'excellents avis de la part des utilisateurs, mais vous aimeriez disposer de preuves quantitatives que votre application est plus stable qu'auparavant.

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 passée (les 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 dernier, pour vous assurer que votre chasse aux bugs a rendu l'application plus stable au fil du temps.

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 souhaitez identifier les 10 plantages les plus fréquents dans votre application. Vous produisez 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 qui plantent

L'automne est la saison idéale pour changer de téléphone ! Votre entreprise sait que cela signifie également que de nouveaux problèmes spécifiques aux appareils vont apparaître, en particulier pour Android. Pour anticiper les problèmes de compatibilité imminents, vous créez une requête qui identifie les 10 appareils ayant rencontré le plus de plantages au cours de la semaine passé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 un développeur de jeux et vous souhaitez savoir quel niveau de votre jeu subit 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);

Avec cette clé dans votre exportation vers BigQuery, vous pouvez ensuite écrire une requête pour signaler 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 les ID utilisateur

Vous avez une application Android en accès anticipé. La plupart de vos utilisateurs l'adorent, mais trois d'entre eux ont rencontré un nombre inhabituel de plantages. Pour aller au fond du problème, vous écrivez une requête qui extrait tous les événements de plantage pour ces utilisateurs, à l'aide de 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 7 : Rechercher tous les utilisateurs confrontés à un problème de plantage particulier

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 "Rechercher 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é affecté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, 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 "Rechercher 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 étendu aux utilisateurs de 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 des données de 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. É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 9 : Les 5 principaux 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 : Les 5 principaux problèmes depuis DATE, aujourd'hui inclus

Vous pouvez également combiner les tables de traitement par lot et en temps réel avec une requête d'assemblage pour ajouter des informations en temps réel aux données de traitement par lot fiables. Comme 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 >= PARSE_TIMESTAMP("%Y_%m_%d", "YYYY_MM_DD")
GROUP BY
  issue_id
ORDER BY
  events DESC
LIMIT
  5;

Étape suivante