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 (facultativement) 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 personnalisés et des résumés. Étant donné que ces types de rapports personnalisés ne sont pas disponibles dans le Crashlytics tableau de bord de la Firebase console, 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 provenant de différents ensembles de données
    Par exemple, si vous choisissez d'exporter les données de sessions Firebase lorsque vous configurez l'exportation des données Crashlytics, vous pouvez mieux comprendre les utilisateurs et les sessions sans plantage (voir l'exemple de requête). Vous pouvez également exporter des données à partir de différents produits Firebase (comme Performance Monitoring) ou à partir de Google Analytics et ensuite associer et analyser ces données 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 constitue 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 BigQuery documentation.

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 quelques exemples de situations et de requêtes qui montrent comment utiliser BigQuery SQL avec vos données Crashlytics exportées et vos données de sessions Firebase.

Exemple 1 : Calculer les métriques d'utilisation sans plantage à l'aide des données de sessions 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 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. Avec les données de sessions Firebase et Crashlytics événements, 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 sans 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 dernière (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, afin de 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 pervasifs

Afin de hiérarchiser correctement les plans de production, vous souhaitez identifier les 10 plantages les plus pervasifs de votre application. Vous générez 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 : 10 principaux appareils qui plantent

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é imminents, vous créez une requête qui identifie les 10 appareils ayant connu le plus de plantages au cours de la semaine dernière (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 vidéo et vous souhaitez savoir quel niveau de votre jeu connaît le plus de plantages.

Pour vous aider à 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 pouvez 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 les ID utilisateur

Vous disposez d'une application Android en accès anticipé. La plupart de vos utilisateurs l'apprécient, mais trois d'entre eux ont rencontré 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 : Identifier 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 bêta-testeurs. Elle a pu utiliser la requête de l'exemple "Identifier les plantages les plus pervasifs" ci-dessus pour identifier l'ID du problème de plantage spécifique. Elle souhaite maintenant exécuter une requête pour extraire la liste des utilisateurs de l'application 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, 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' "Identifier les plantages les plus pervasifs" exemple ci-dessus pour identifier l'ID du problème de plantage spécifique. Votre équipe souhaite maintenant vérifier si ce plantage s'est propagé aux utilisateurs de différents pays du monde.

Pour rédiger cette requête, votre équipe doit procéder comme suit :

  1. Activer l'exportation des données Google Analytics vers BigQuery. Consultez Exporter des données de projet vers BigQuery.

  2. Mettre à jour votre application pour transmettre un ID utilisateur au Google Analytics SDK et au Crashlytics SDK.

    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édiger une requête qui utilise le champ d'ID utilisateur pour associer les événements de l' Google Analytics ensemble de données aux plantages de l'Crashlytics ensemble de données.

    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 : Cinq principaux problèmes depuis le début de la journée

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
  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 : Cinq principaux problèmes depuis DATE, y compris aujourd'hui

Crashlytics

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 par lot fiables. Étant donné que 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