Importer des journaux d'événements Firebase dans BigQuery

Dans ce tutoriel, vous allez découvrir comment exporter des journaux d'événements de Google Analytics pour Firebase et Firebase Crashlytics dans Google BigQuery afin de procéder à une analyse approfondie de leurs données.

Firebase est une plate-forme de création d'applications mobiles offrant des fonctionnalités telles que le stockage de données et de fichiers, la synchronisation en temps réel, l'authentification, etc. Google Analytics pour Firebase vous permet de suivre l'utilisation de vos fonctionnalités Firebase et vous fournit des informations sur l'utilisation des applications et l'engagement des utilisateurs avec celles-ci, tandis que Firebase Crashlytics enregistre les plantages de vos applications pour vous aider à connaître le type de problèmes rencontrés par les utilisateurs et leur fréquence.

BigQuery est un entrepôt de données analytiques à l'échelle du pétaoctet qui vous permet d'exécuter des requêtes de type SQL sur de grandes quantités de données presque en temps réel.

L'importation de vos données Firebase dans BigQuery offre plusieurs avantages :

  • L'agrégation de données provenant de plusieurs sources : si vous suivez les événements utilisateur à l'aide de plusieurs outils, tels que Google Analytics pour Firebase, Firebase Crashlytics, Google Analytics 360 ou encore un service de backend mobile collectant des données analytiques personnalisées, vous pouvez importer les données de toutes ces sources dans BigQuery pour effectuer une analyse produisant une image complète de vos données d'événement.

  • L'accès aux données brutes : lorsque vous importez des données dans BigQuery, vous pouvez accéder aux valeurs des données brutes et vous bénéficiez d'une grande souplesse quant aux modalités d'analyse des événements.

  • Le contrôle des accès : les données que vous exportez vers BigQuery vous appartiennent, et vous pouvez vous servir des listes de contrôle d'accès (LCA) de BigQuery pour gérer les autorisations sur les projets et les ensembles de données. Vous avez ainsi la possibilité de partager des données sans donner accès à votre application Firebase.

  • L'archivage des données inactives : si vous devez conserver des données brutes, vous pouvez les importer dans BigQuery, puis les archiver dans Google Cloud Storage ou dans un autre emplacement de stockage afin de les stocker de façon prolongée à un prix abordable.

  • Les paramètres d'événement personnalisés : dans Google Analytics, vous pouvez définir les événements et les paramètres personnalisés que vous souhaitez suivre. En important les données dans BigQuery, vous bénéficiez d'une analyse approfondie des paramètres d'événement standards et personnalisés.

Objectifs

Dans ce tutoriel, vous allez apprendre à effectuer les opérations suivantes :

  • Associer un projet Firebase à BigQuery, ce qui permet à Firebase Analytics et à Firebase Crashlytics d'exporter quotidiennement des journaux d'événements vers BigQuery
  • Interroger les données stockées dans BigQuery

Coûts

Pour transmettre des données Firebase à BigQuery, vous devez faire passer votre projet au niveau de service Blaze. Pour en savoir plus, consultez la page relative aux tarifs de Firebase.

Par ailleurs, le stockage et l'interrogation des données dans BigQuery sont payants. Pour en savoir plus, consultez la page relative aux tarifs de BigQuery.

Avant de commencer

  1. Créez un projet Firebase.

  2. Créez une application émettant des événements Firebase. Pour savoir comment procéder, consultez la page Premiers pas avec Firebase Crashlytics, ou la page décrivant la prise en main de Google Analytics pour Firebase pour iOS ou Android.

Associer les données du projet à BigQuery

Le fait d'associer votre projet Firebase à BigQuery vous permet d'accéder à des données d'événement brutes et non échantillonnées.

  1. Accédez à la page Intégrations dans la console Firebase.

  2. Sur la fiche BigQuery, cliquez sur Associer.

  3. À l'aide des boutons bascules, indiquez si vous souhaitez exporter les données Analytics, les données Crashlytics ou les deux. Si vous exportez des données Analytics, vous pouvez également choisir d'inclure des identificateurs de publicité, qui fournissent des données plus riches, mais entraînent des coûts de stockage et de requête supplémentaires dans BigQuery.

  4. Cliquez sur Associer à BigQuery pour terminer cette tâche.

Une fois que vous avez associé votre projet, BigQuery crée l'ensemble de données correspondant et l'associe à votre projet. Chaque jour, votre projet ajoute une nouvelle table à cet ensemble de données pour chaque application associée. Cet ensemble de données est normalement disponible après la première exportation quotidienne des événements de votre projet.

Gérer les applications qui envoient des données à BigQuery

Lorsque vous associez votre projet à BigQuery, Firebase exporte les événements correspondant à chacune des applications de ce projet. Vous pouvez modifier ce comportement en désactivant les exportations quotidiennes pour certaines applications :

  1. Accédez à la page Intégrations dans la console Firebase.

  2. Sur la fiche BigQuery, cliquez sur Gérer.

  3. Pour empêcher une application d'envoyer des données à BigQuery, cliquez sur le bouton bascule situé à côté du nom de cette application, puis sélectionnez Arrêter l'exportation.

  1. Accédez à la page Intégrations dans la console Firebase.

  2. Sur la fiche BigQuery, cliquez sur Gérer.

  3. Sélectionnez Dissocier le projet au bas de la page, puis confirmez votre choix en cliquant sur Dissocier de BigQuery.

Interroger des données Firebase avec BigQuery

Une fois vos données chargées dans BigQuery, vous pouvez exécuter des requêtes de type SQL à l'aide de BigQuery. Pour en savoir plus, consultez la page Interroger les données dans la documentation BigQuery.

BigQuery fournit une interface utilisateur Web qui permet d'exécuter des requêtes sur vos données, en remplissant simplement un formulaire et en cliquant sur Exécuter la requête. Pour en savoir plus, consultez la page Démarrage rapide à l'aide de l'UI Web dans la documentation BigQuery.

Utiliser des données Firebase Analytics dans BigQuery

Vous trouverez ci-dessous des exemples de requêtes que vous pouvez exécuter sur vos données Analytics. Ces requêtes génèrent des rapports qui ne sont pas disponibles dans le tableau de bord Google Analytics.

Interroger un paramètre d'événement personnalisé

Dans Google Analytics, vous pouvez définir des clés et des valeurs personnalisées pour les paramètres sur les événements. Le type des clés est String. Le type des valeurs peut être String, Long ou Double.

Les requêtes suivantes montrent comment générer des rapports qui regroupent les valeurs des événements personnalisés pour faire ressortir des informations métier.

Exemple 1 :

Le développeur d'un jeu mobile veut savoir quel niveau déclenche le plus d'achats dans son jeu. Pour ce faire, il ajoute l'appel d'événement personnalisé suivant au jeu. Cet appel s'exécute lorsqu'un joueur déclenche un processus d'achat dans le jeu.

Dans cet exemple, le nom de l'événement personnalisé est trigger_purchase. Il possède une clé, level, qui spécifie une valeur entière. Cette valeur indique le niveau auquel le joueur était lorsqu'il a déclenché un processus d'achat.

iOS – Objective-C

[FIRAnalytics logEventWithName:@"trigger_purchase"
                parameters:@{
                              @"level": 3,
}];

iOS – Swift

FIRAnalytics.logEventWithName("trigger_purchase", parameters: [
  "level": 3
])

Android – Java

Bundle params = new Bundle();
params.putInt("level", 3);
mFirebaseAnalytics.logEvent("trigger_purchase", params);

Dans BigQuery, les entrées qui découlent de cet événement personnalisé sont les suivantes :

Champ Valeur
event_dim.name trigger_purchase
event_dim.params.key level
event_dim.params.value.int_value 3

Pour déterminer le nombre d'achats par niveau, il écrit une requête qui renvoie la distribution du nombre d'événements trigger_purchase, groupés par niveau de l'utilisateur au moment de l'achat. Cette requête s'étend sur la période du 1er janvier 2015 au 31 décembre 2016.

SELECT COUNT(event_dim.name) as NumberOfPurchases,
event_dim.params.value.int_value as level
FROM
TABLE_DATE_RANGE(com_game_example_ANDROID.app_events_, TIMESTAMP('2015-01-01'), TIMESTAMP('2016-12-31'))
WHERE event_dim.name = 'trigger_purchase'
GROUP BY level

Exemple 2 :

Un deuxième développeur travaillant sur le même jeu veut déterminer quelles classes de personnages battent le plus d'adversaires. Pour ce faire, il ajoute au jeu la journalisation des événements personnalisés suivante lorsqu'un joueur bat un adversaire.

Dans cet exemple, le nom de l'événement personnalisé est defeat_opponent. Il possède une clé, character, qui spécifie une valeur de chaîne. Cette valeur contient le nom de l'adversaire.

iOS – Objective-C

[FIRAnalytics logEventWithName:@"defeat_opponent"
                parameters:@{
                              @"character": "Hercules"
}];

iOS – Swift

FIRAnalytics.logEventWithName("defeat_opponent", parameters: [
  "character": "Hercules"
])

Android – Java

Bundle params = new Bundle();
params.putString("character", "Hercules");
mFirebaseAnalytics.logEvent("defeat_opponent", params);

Dans BigQuery, les entrées qui découlent de cet événement personnalisé sont les suivantes :

Champ Valeur
event_dim.name defeat_opponent
event_dim.params.key character
event_dim.params.value.string_value Hercules

Pour trouver la classe de personnages qui a le plus de victoires, il écrit une requête qui compte le nombre de fois qu'une classe de personnages est impliquée dans un événement personnalisé defeat-opponent.

SELECT COUNT(event_dim.name) as DefeatEvents,
event_dim.params.value.string_value as CharacterClass
FROM
TABLE_DATE_RANGE( com_game_example_ANDROID.app_events_, TIMESTAMP('2015-01-01'), TIMESTAMP('2016-12-31'))
WHERE event_dim.name = 'defeat_opponent'
AND event_dim.params.key = 'character'
GROUP BY CharacterClass
ORDER BY DefeatEvents desc

Interroger les événements utilisateur

Outre les requêtes sur les événements personnalisés, vous pouvez générer des rapports qui regroupent les valeurs des événements utilisateur pour faire ressortir des informations métier.

Exemple 3 :

Le développeur d'une application souhaite utiliser Firebase Cloud Messaging pour envoyer des notifications push de réengagement aux utilisateurs qui n'ont pas utilisé l'application récemment. Pour créer la liste des contacts à qui envoyer les notifications, le développeur utilise la requête suivante afin de trouver les utilisateurs de l'année écoulée qui n'ont pas visité l'application au cours des deux dernières semaines. Cette requête renvoie les utilisateurs iOS et Android, ainsi que la date à laquelle ils ont ouvert l'application pour la première fois.

Dans la requête ci-dessous, le champ user_dim.user_id contient l'ID utilisateur que le développeur a défini dans l'application en appelant l'API setUserId. Une fois cette valeur définie, Google Analytics la conserve et l'inclut dans toutes les futures lignes associées à cet utilisateur. Cette valeur n'est pas ajoutée de manière rétroactive aux lignes antérieures.

Si le développeur ne définit pas l'identifiant user_dim.user_id, il peut utiliser le champ app_info.app_instance_id à la place. Ce champ contient l'identifiant par défaut généré par Firebase qui sera utilisé en lieu et place de user_dim.user_id. Notez que Firebase génère un nouveau champ app_info.app_instance_id chaque fois que l'application Firebase est désinstallée et réinstallée sur le même appareil.

Le tableau de données exporté vers BigQuery pour l'application iOS est com_retail_example_IOS.app_events_[DATE]. Le tableau de données correspondant pour Android est com_retail_example_ANDROID.app_events_[DATE], où [DATE] est la date du jour.

SELECT
  userId,
  DATE(MIN( firstOpenTime )) firstOpenTime
FROM (
  SELECT
    user_dim.user_id AS userId,
    user_dim.first_open_timestamp_micros AS firstOpenTime
  FROM (TABLE_DATE_RANGE([com_retail_example_IOS.app_events_],
    DATE_ADD(CURRENT_TIMESTAMP(), -1, 'YEAR'), CURRENT_TIMESTAMP())),
    (TABLE_DATE_RANGE([com_retail_example_ANDROID.app_events_],
    DATE_ADD(CURRENT_TIMESTAMP(), -1, 'YEAR'), CURRENT_TIMESTAMP())) )
WHERE
  userId NOT IN (
  SELECT
    user_dim.user_id AS userId
  FROM (TABLE_DATE_RANGE([com_retail_example_IOS.app_events_],
    DATE_ADD(CURRENT_TIMESTAMP(), -14, 'DAY'), CURRENT_TIMESTAMP())),
    (TABLE_DATE_RANGE([com_retail_example_ANDROID.app_events_],
    DATE_ADD(CURRENT_TIMESTAMP(), -14, 'DAY'), CURRENT_TIMESTAMP())) )
GROUP BY
  userId

Exemple 4 :

Le développeur d'une application souhaite déterminer les pays dans lesquels les utilisateurs sont les plus actifs, sur les plates-formes iOS et Android. Pour ce faire, il utilise la requête suivante afin de répertorier le nombre d'utilisateurs et d'événements par pays à une date donnée.

La requête interne renvoie le user_id et le country d'une ligne, puis effectue le comptage de tous les événements de cette ligne. Cette requête utilise la clause WITHIN RECORD comme enregistrement event_dim au sein d'un objet RECORD. Il s'agit de la meilleure façon de gérer les agrégations pour les enregistrements imbriqués.

La requête externe utilise EXACT_COUNT_DISTINCT du userId pour fournir le nombre total exact d'utilisateurs. Comme alternative, le développeur pourrait utiliser COUNT(DISTINCT user_id), mais il s'agit d'une estimation et non d'une valeur exacte. Une estimation peut être plus rapide lorsqu'il existe un très grand ensemble de données et que vous recherchez des tendances dans le temps. Dans ce cas, la précision peut avoir moins d'importance que la vitesse.

SELECT
  country,
  EXACT_COUNT_DISTINCT(user_id) AS users,
  SUM(noOfEvents) AS totalEvents
FROM (
  SELECT
    user_dim.app_info.app_instance_id AS user_id,
    user_dim.geo_info.country AS country,
    COUNT(event_dim.name) WITHIN RECORD noOfEvents
  FROM
    [com_retail_example_IOS.app_events_20160723],
    [com_retail_example_ANDROID.app_events_20160723]
    )
GROUP BY
  1
ORDER BY
  2 DESC

Comprendre le schéma Google Analytics dans BigQuery

Lorsque vous associez Google Analytics pour Firebase à BigQuery, Firebase exporte les données vers BigQuery de manière quotidienne. L'exportation s'effectue dans les formats suivants :

Ensembles de données

Google Analytics pour Firebase crée un ensemble de données dans BigQuery pour chaque application Firebase. Le nom de l'ensemble de données a le format suivant : [app_name]_[PLATFORM], où app_name est l'ID de groupe (iOS) ou le nom du package (Android).

Google Analytics convertit les points en traits de soulignement dans l'ID de groupe ou dans le nom du package pour s'adapter aux conventions d'attribution de noms de BigQuery. Analytics spécifie le nom de la plate-forme en majuscules pour s'adapter aux conventions d'attribution de noms de Firebase.

Par exemple, l'ensemble de données correspondant à une application iOS avec l'ID de groupe "com.username.myapp" aboutit à l'ensemble de données nommé com_username_myapp_IOS.

Tables

Chaque jour, Google Analytics crée un tableau correspondant à l'application dans l'ensemble de données BigQuery. Les tableaux sont nommés en utilisant le format app_events_YYYYMMDD. Ils contiennent les événements enregistrés pour le jour spécifié.

Lignes

Dans un tableau, chaque ligne correspond à un groupe d'événements. La taille du groupe est déterminée par l'application qui envoie les données dans les appels au SDK de Google Analytics pour Firebase.

Colonnes

Google Analytics exporte les événements utilisateur sous forme de colonnes. Elles incluent les événements de données personnalisés. Pour obtenir la liste des colonnes standards exportées vers BigQuery, consultez la page Schéma de BigQuery Export dans la documentation d'aide de Firebase.

Utiliser des données Firebase Crashlytics dans BigQuery

Voici quelques exemples illustrant 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 agrègent les données d'événement de plantage sous une forme synthétique plus facilement exploitable.

Exemple 1 :

Après s'être efforcé d'éliminer autant de bugs que possible, le développeur principal de l'éditeur Friendly Pix considère que tout est prêt pour le lancement de la nouvelle application de partage de photos. Avant cela, l'équipe tient à vérifier le nombre de plantages par jour au cours du mois écoulé afin de s'assurer que ses actions de débogage ont progressivement réussi à stabiliser l'application :

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

Exemple 2 :

Afin de hiérarchiser correctement les plans de production, un responsable de projet chez PineapplePlusPlus se demande comment identifier les plantages les plus pervasifs dans les produits de l'entreprise. Son équipe crée alors la requête suivante afin de générer les points de données pertinents :

#standardSQL
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.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 :

L'automne est la saison idéale pour changer de téléphone ! Un développeur de Planned Obsolescence, Inc. sait que cette saison annonce également une foule de problèmes inédits liés à tous ces nouveaux appareils. Pour anticiper les problèmes de compatibilité à venir, l'équipe a mis en place une requête qui identifie les 10 appareils ayant subi le plus de plantages au cours de la semaine écoulée :

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

Un développeur de jeux vidéo travaillant sur le projet "Mecha Hamster 2: Hammy's Revenge" veut savoir quel niveau du jeu connaît le plus de plantages. Pour suivre cette statistique, l'équipe définit la clé Crashlytics personnalisée current_level et la met à jour chaque fois que l'utilisateur atteint un nouveau niveau :

iOS – Objective-C

[CrashlyticsKit setIntValue:3 forKey:@"current_level"];

iOS – Swift

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

Android – Java

Crashlytics.setInt("current_level", 3);

Une fois cette clé incluse dans son exportation BigQuery, l'équipe n'a plus qu'à rédiger une requête indiquant la distribution des valeurs current_level associées à chaque événement de plantage :

#standardSQL
SELECT
  COUNT(DISTINCT event_id) AS num_of_crashes,
  value
FROM
  `projectId.crashlytics.package_name_ANDROID`,
  UNNEST(custom_keys)
WHERE
  key = "current_level"
GROUP BY
  key,
  value
ORDER BY
  num_of_crashes DESC

Exemple 5 :

L'un des développeurs de l'éditeur Mostly Okay Software gère une application en accès anticipé. La plupart des utilisateurs adorent cette application, mais quelques-uns ont subi un nombre inhabituel de plantages. Afin d'aller au fond du problème, l'équipe rédige 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 :

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

Comprendre le schéma de Firebase Crashlytics dans BigQuery

Lorsque vous associez Crashlytics à BigQuery, Firebase exporte les événements de plantage récents, fatals ou non, en remontant jusqu'à deux jours avant l'association. À partir de ce moment et jusqu'à ce que vous désactiviez l'association, Firebase exporte quotidiennement les événements Crashlytics. Plusieurs minutes peuvent être nécessaires pour que les données soient disponibles dans BigQuery après chaque exportation.

Ensembles de données

Firebase Crashlytics crée un ensemble de données dans BigQuery pour les données Crashlytics. Cet ensemble de données couvre la totalité de votre projet, même si celui-ci comporte plusieurs applications, mais n'inclut pas les exportations Analytics.

Tables

Firebase Crashlytics crée une table distincte dans l'ensemble de données pour chacune des applications de votre projet, à l'exception de celles pour lesquelles vous avez désactivé les exportations de données. Firebase nomme les tables d'après l'identifiant de groupe de l'application, en remplaçant les points par des traits de soulignement et en ajoutant un nom de plate-forme à la fin. Par exemple, les données d'une application Android dont l'ID est com.google.test figureraient dans une table nommée com_google_test_ANDROID.

Lignes

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

Colonnes

La table comprend les mêmes colonnes pour les erreurs fatales et non fatales. Pour connaître la liste des colonnes exportées vers BigQuery, consultez la page Schéma de BigQuery Export pour Crashlytics.

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

Google Data Studio transforme vos ensembles de données Crashlytics dans BigQuery en rapports. Entièrement personnalisables, ces derniers sont aussi faciles à lire qu'à partager.

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

Utiliser un modèle de rapport Crashlytics

Data Studio propose un exemple de rapport pour Crashlytics qui comprend un ensemble complet de dimensions et de métriques issues du schéma BigQuery pour les données exportées depuis Crashlytics. Vous pouvez utiliser cet exemple comme modèle pour créer rapidement des rapports et des visualisations basés sur les données de plantage brutes de votre propre application :

  1. Ouvrez le modèle de tableau de bord Data Studio pour Crashlytics.
  2. Cliquez sur Utiliser le modèle dans l'angle supérieur droit.
  3. Dans la liste déroulante Sélectionnez une source de données, cliquez sur Créer une 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 accédant à Mes projets > [nom de votre projet] > crashlytics > [nom de votre table].
  6. Sous Configuration, définissez le champ Niveau du modèle Crashlytics sur Par défaut.
  7. Sous Table partitionnée, désélectionnez Utilisateur_PARTITIONTIME en tant que dimension de l'heure.
  8. Cliquez sur Associer pour créer la source de données.
  9. Cliquez sur Ajouter au rapport pour revenir au modèle Crashlytics.
  10. Enfin, cliquez sur Créer le rapport pour créer votre copie du modèle de tableau de bord Data Studio pour Crashlytics.

Effectuer un nettoyage

Afin d'éviter que des frais ne soient facturés sur votre compte Google Cloud Platform pour les ressources utilisées dans ce tutoriel, procédez comme suit :

Le moyen le plus simple d'arrêter les frais de facturation est de supprimer le projet. Comme le projet Firebase et le projet Cloud Platform ne font qu'un, vous pouvez le supprimer à l'aide de la console Firebase ou Cloud Platform.

  1. Dans la console GCP, accédez à la page "Projets".

    Accéder à la page Projets

  2. Dans la liste des projets, sélectionnez celui que vous souhaitez supprimer, puis cliquez sur Delete project (Supprimer le projet). Après avoir coché la case à côté du nom du projet, cliquez sur "Supprimer le projet".
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Si vous ne souhaitez pas supprimer votre projet Cloud Platform et Firebase, vous pouvez réduire les coûts en dissociant le projet de BigQuery.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…