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 à 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 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 associer 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 au format 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 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(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 des sept derniers jours (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é le plus de bugs 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 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 générant le plus de plantages

L'automne est la saison idéale pour changer de téléphone ! Votre entreprise sait que cela signifie également que c'est la saison des nouveaux problèmes spécifiques aux appareils, en particulier pour Android. Pour anticiper les problèmes de compatibilité qui se profilent, vous élaborez une requête qui identifie les 10 appareils ayant rencontré 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 un développeur de jeux et vous souhaitez savoir quel niveau de votre jeu rencontre 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 générer un rapport sur 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 l'adorent, mais trois d'entre eux ont rencontré un nombre inhabituel de plantages. Pour résoudre le 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 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, ventilé 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 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 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. É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 : 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 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 de couture 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