Le rapport sur l'expérience des utilisateurs de Chrome est disponible sur Google BigQuery, comme une source de donnée accessible à tous. Il s'agit d'un excellent moyen pour commencer à utiliser Google Big Query avec un cas pratique.

Pour commencer, vous aurez besoin d'un compte Google, d'un projet Google Cloud que vous utiliserez pour accéder au projet, et de connaissances de base sur SQL.

Accéder au projet Chrome User Experience report sur BigQuery

Le projet est disponible sur le lien https://console.cloud.google.com/bigquery?project=chrome-ux-report&page=dataset&d=all&p=chrome-ux-report.

Si vous visitez cette page et obtenez une invite à créer un projet comme celui ci-dessous, continuez avec les étapes suivantes pour créer un nouveau projet. Sinon, vous pouvez passer à la section suivante et commencer à interroger l'ensemble des données.

Naviguez vers [Google Cloud Platform] (https://console.cloud.google.com/projectcreate) .
Cliquez sur Create a Project.
Donnez à votre nouveau projet un nom tel que "My Chrome UX Report" et cliquez sur Create.

Vous êtes maintenant prêt à commencer à interroger l'ensemble des données.

Comprendre le schéma de l'ensemble de données

Consultez la [documentation sur la méthodologie] (https://developers.google.com/web/tools/chrome-user-experience-report) pour un aperçu des mesures, des dimensions et du schéma de haut niveau.

Commençons à parcourir la donnée. D'une part, elle est organisée par pays (nous prendrons country_fr ici). D'autre part, par mois.

Si nous regardons maintenant le schéma de donnée, nous constatons que celle-ci est constituée de champs imbriqués (Nested fields en Anglais).

Requêter pour analyser la donnée

Commençons par une requête de base pour voir si un site en particulier est disponible dans l'ensemble de données. Par exemple fnac.com

#standardSQL
SELECT *
FROM `chrome-ux-report.country_fr.202005`
WHERE origin LIKE '%://fnac.com'
LIMIT 100

Nous avons bien des informations. Attention : il faut noter que cette simple requête a consommé 30Gb de donnée.

Nous pouvons maintenant plonger plus profondément dans les données relatives à l'expérience de l'utilisateur. Ecrivons une requête pour visualiser la distribution de l'histogramme.

#standardSQL
SELECT
  bin.start,
  SUM(bin.density) AS density
FROM
  `chrome-ux-report.country_fr.202005`,
  UNNEST(first_contentful_paint.histogram.bin) AS bin
WHERE
  origin = 'https://fnac.com'
GROUP BY
  bin.start
ORDER BY
  bin.start

Voici les résultats :

Que l'on peut visualiser plus simplement dans Google Data Studio

En modifiant un tout petit peu la requête, nous pouvons maintenant commencer à comparer les domaines entre eux.

#standardSQL
SELECT
  bin.start,
  origin,
  SUM(bin.density) AS density
FROM
  `chrome-ux-report.country_fr.202005`,
  UNNEST(first_contentful_paint.histogram.bin) AS bin
WHERE
  origin IN ('https://www.fnac.com', 'https://www.cdiscount.com', 'https://www.amazon.fr')
GROUP BY
  bin.start, origin
ORDER BY
  bin.start

Par exemple FNAC et Amazon ci-dessous. On constate que la performance est clairement du côté d'Amazon, tant en terme de moyenne, que d'absence de valeurs extrêmement hautes :

Maintenant que nous avons un moyen d'examiner les données, écrivons quelques requêtes pour calculer des mesures de synthèse supplémentaires. Par exemple, comparons la part des utilisateurs ayant eu des FCP de moins de 1000 ms sur ces 3 sites :

#standardSQL
SELECT
    ROUND(SUM(bin.density),3) AS density,
    origin
FROM
    `chrome-ux-report.country_fr.202005`,
    UNNEST(first_contentful_paint.histogram.bin) AS bin
WHERE
    bin.start < 1000 AND
    origin IN ('https://www.fnac.com', 'https://www.cdiscount.com', 'https://www.amazon.fr')
GROUP BY 
    origin
ORDER BY
    density DESC

Et voilà le résultat : 76,5% des vues de pages Amazon ce sont faites en moins de 1000ms, contre 32,9% pour la Fnac.

Nous pouvons aller plus loin et également segmenter l'ensemble de données via l'une des dimensions fournies. Par exemple, nous pouvons utiliser la [dimension du type de connexion effective] (https://developers.google.com/web/tools/chrome-user-experience-report/bigquery/getting-started#effective_connection_type) pour comprendre comment l'expérience ci-dessus varie pour des utilisateurs ayant des vitesses de connexion différentes.

#standardSQL
SELECT
    effective_connection_type.name AS ect,
    origin,
    ROUND(SUM(bin.density),3) AS density
FROM
    `chrome-ux-report.country_fr.202005`,
    UNNEST(first_contentful_paint.histogram.bin) AS bin
WHERE
    bin.end <= 1000 AND
    origin IN ('https://www.fnac.com', 'https://www.cdiscount.com', 'https://www.amazon.fr')
GROUP BY
    ect, origin
ORDER BY
    density DESC

Le résultat de cette interrogation montre la fraction des utilisateurs qui font l'expérience du FCP en moins d'une seconde, divisée par type de connexion effective. À première vue, les utilisateurs d'une connexion 3G peuvent avoir des performances nettement inférieures, mais il est important de se rappeler que la valeur obtenue est relative à la population globale ; la valeur indiquée est également fonction de la taille de la population 3G, qui peut être inférieure - voir [conseils d'analyse et meilleures pratiques] (https://developers.google.com/web/tools/chrome-user-experience-report#analysis_tips_best_practices) pour en savoir plus.

Pour aller plus loin, nous allons vouloir requêter l'ensemble des mois disponibles, c'est à dire les tables allant de chrome-ux-report.country_fr.201712 à chrome-ux-report.country_fr.202005

Pour cela, nous allons utiliser la fonction "Table Wildcard" de BIgQuery, qui permet justement de faire cela de manière extrêmement simple :

#standardSQL
SELECT
    effective_connection_type.name AS ect,
    origin,
    _TABLE_SUFFIX as date,
    ROUND(SUM(bin.density),3) AS density
FROM
    `chrome-ux-report.country_fr.*`,
    UNNEST(first_contentful_paint.histogram.bin) AS bin
WHERE
    bin.end <= 1000 AND
    origin IN ('https://www.fnac.com', 'https://www.cdiscount.com', 'https://www.amazon.fr')
GROUP BY
    ect, origin, date
ORDER BY
    date ASC

Nous récupérons donc une table avec toutes les valeurs, pour les 3 domaines sélectionnés, pour toutes les dates :

Automatiser la mise à jour

Nous allons construire un reporting dans Google Data Studio basé sur ces données. Afin d'éviter d'appeler toute la donnée à chaque fois, nous allons donc sauvegarder cette donnée dans une table, et mettre en place une récurrence de la requête.

Nous allons donc enregistrer les résultats de la requête dans une table

La table ne fait que 7kb. L'interroger sera donc pratiquement gratuit.

Ensuite, il ne reste qu'à mettre en place la récurrence. Nous allons mettre à jour cette table une fois par mois. Nous pouvons également demander à recevoir un email lorsque la mise à jour est effectuée. Nous pourrions aussi déclencher un évènement à envoyer dans Pub/Sub, afin de déclencher une autre action. Ce n'est pas le cas ici.

Construire le reporting dans Google Data Studio

Nous allons ajouter une source de donnée. Ici "BigQuery" :

On choisit la table que nous venons de créer :

Et il n'y a plus qu'à créer les graphiques et vues :

Autres ressources utiles sur le même thème

Tous les articles concernant Google BigQuery

🤙

Présentation de l'interface web de Google Big Query

🤙

Chrome User Experience Report : explorer les données dans Big Query

🤙

Google Search Console to BigQuery avec Python

🤙

Tutoriel : déployer une application Python avec Google App Engine