Cette page a été traduite par l'API Cloud Translation.

Mesurer et déboguer les performances avec Google Analytics 4 et BigQuery

Découvrez comment envoyer les données des signaux Web vers les propriétés Google Analytics 4, puis les exporter pour les analyser dans BigQuery et Looker Studio.

Minhaz Kazi

Philip Walton

Google propose plusieurs outils (Search Console, PageSpeed Insights (PSI) et le rapport sur l'expérience utilisateur de Chrome) qui permettent aux développeurs de voir comment leurs sites se comparent aux métriques Core Web Vitals pour leurs utilisateurs réels sur le terrain.

Ces outils sont excellents, car ils vous offrent une vue d'ensemble des performances réelles de votre site et ne nécessitent aucune configuration pour commencer à les utiliser.

Toutefois, il existe plusieurs raisons essentielles pour lesquelles vous ne devez pas vous fier uniquement à ces outils pour mesurer les performances de votre site :

Les outils basés sur CrUX présentent les données par mois ou par période de 28 jours précédente. Vous devrez donc attendre longtemps après avoir apporté des modifications avant de pouvoir consulter les résultats.
Les outils basés sur CrUX ne peuvent être segmentés que par un nombre limité de dimensions, telles que le pays, le type de connexion et la catégorie d'appareil (ordinateur de bureau ou mobile). Vous ne pouvez pas segmenter les données en fonction de dimensions spécifiques à votre entreprise (par exemple, utilisateurs engagés, utilisateurs d'un groupe de test particulier, etc.).
Les outils basés sur CrUX peuvent vous indiquer quelles sont vos performances, mais pas pourquoi. Avec les outils d'analyse, vous pouvez envoyer des données supplémentaires pour vous aider à identifier et à déboguer les problèmes.

C'est pourquoi nous recommandons à tous les propriétaires de sites de surveiller les métriques Core Web Vitals à l'aide de leur outil d'analyse existant. Cet article explique comment utiliser les outils gratuits proposés par Google pour y parvenir.

Une fois tout configuré, vous pourrez créer des tableaux de bord comme ceux-ci :

Capture d'écran du rapport du connecteur Web Vitals

Pour obtenir un aperçu visuel de toutes les étapes décrites ici, regardez notre conférence Google I/O 2021:

Mesurer

Mesurer les performances a toujours été possible avec Google Analytics à l'aide de métriques personnalisées, mais Google Analytics 4 (GA4) propose quelques nouvelles fonctionnalités qui devraient intéresser particulièrement les développeurs.

Paramètres de événement personnalisé sans configuration
Exportation BigQuery gratuite pour pouvoir interroger vos données à l'aide de SQL

Bien que l'interface Web de Google Analytics dispose de puissants outils d'analyse, il est difficile de surpasser la puissance et la flexibilité de l'accès aux données d'événement brutes à l'aide d'un langage de requête que vous connaissez probablement déjà.

Pour commencer à mesurer les Core Web Vitals à l'aide de Google Analytics 4 et de BigQuery, vous devez effectuer trois étapes :

Créez une propriété Google Analytics 4 et un projet BigQuery.
Activez BigQuery Export (BigQuery Export) dans la configuration de votre propriété Google Analytics afin que toutes les données que vous recevez soient automatiquement renseignées dans les tables de votre projet BigQuery.
Ajoutez la bibliothèque JavaScript web-vitals à votre site afin de pouvoir mesurer les métriques Core Web Vitals et envoyer les données à Google Analytics 4, y compris les données d'attribution.

Analyser

Une fois la configuration terminée, les données d'événement devraient s'afficher dans l'interface BigQuery. Vous devriez pouvoir interroger les données comme suit :

SELECT * FROM `my_project_id.analytics_XXXXX.events_*`
WHERE event_name IN ('LCP', 'INP', 'CLS')

Voici un aperçu des résultats de cette requête :

Données d'événement Web Vitals dans BigQuery

Interroger les données Web Vitals

Avant de commencer à interroger vos données d'événements Web Vitals, il est important de comprendre comment elles sont agrégées.

Il est essentiel de comprendre que, dans certains cas, plusieurs événements peuvent être reçus pour la même métrique, sur la même page. Cela peut se produire si la valeur de la métrique change et qu'une valeur mise à jour est signalée (ce qui est courant avec le CLS).

Pour les événements Web Vitals, la dernière valeur envoyée est toujours la plus précise. Par conséquent, avant d'effectuer une analyse, il est important de ne filtrer que ces valeurs. L'extrait de code fourni par la bibliothèque JavaScript Web Vitals pour envoyer des données à Google Analytics 4 inclut l'envoi d'un ID unique par métrique. Vous pouvez donc utiliser la requête suivante pour limiter vos résultats à la dernière valeur reçue pour chaque ID de métrique :

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)

Notez que toutes les autres requêtes référencées dans cet article commenceront par cette sous-requête.

Exemples de requêtes

Les sections suivantes présentent quelques exemples de requêtes Web Vitals courantes que vous pouvez exécuter.

LCP, INP et CLS au 75% du centile (p75) sur l'ensemble du site

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  metric_name,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS p75,
  COUNT(1) as count
FROM (
  SELECT
    metric_name,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
  FROM web_vitals_events
)
GROUP BY 1

Toutes les valeurs LCP individuelles, de la plus élevée à la plus basse

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
FROM web_vitals_events
WHERE metric_name = 'LCP'
ORDER BY metric_value DESC

Scores LCP (p75) des 10 pages les plus populaires

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  page_path,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS LCP,
  COUNT(1) as count
FROM (
  SELECT
    REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
  FROM web_vitals_events
  WHERE metric_name = 'LCP'
)
GROUP BY 1
ORDER BY count DESC
LIMIT 10

10 premières pages dont le CLS est le plus faible (p. 75)

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  page_path,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS CLS,
  COUNT(1) as count
FROM (
  SELECT
    REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
  FROM web_vitals_events
  WHERE metric_name = 'CLS'
)
GROUP BY 1
HAVING count > 50 # Limit to relatively popular pages
ORDER BY CLS DESC
LIMIT 10

Déboguer

Les requêtes précédentes montrent comment interroger les données de métrique Web Vitals, ce qui est utile pour comprendre vos performances actuelles et leur évolution au fil du temps. Mais que faire si vos performances sont moins bonnes que prévu et que vous ne comprenez pas pourquoi ?

Connaître vos scores n'est pas utile si vous n'êtes pas en mesure d'agir et de résoudre les problèmes.

Déboguer les performances sur le terrain explique comment envoyer des informations de débogage supplémentaires avec vos données analytiques. Si vous suivez les instructions détaillées dans cet article, les informations de débogage devraient également s'afficher dans BigQuery.

Exemples de requêtes

Les requêtes suivantes montrent comment utiliser le paramètre d'événement debug_target pour identifier l'origine des problèmes de performances.

Principaux éléments contribuant au CLS

debug_target est une chaîne de sélecteur CSS qui correspond à l'élément de la page le plus pertinent par rapport à la valeur de la métrique.

Avec le CLS, debug_target représente l'élément le plus grand du plus grand décalage de mise en page ayant contribué à la valeur CLS. Si aucun élément n'a été décalé, la valeur debug_target sera null.

La requête suivante liste les pages de la pire à la meilleure en fonction de leur CLS au 75e centile, regroupées par debug_target :

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  page_path,
  debug_target,
  APPROX_QUANTILES(metric_value, 100)[OFFSET(75)] AS CLS,
  COUNT(1) as count
FROM (
  SELECT
    REGEXP_SUBSTR((SELECT value.string_value FROM UNNEST(event_params) WHERE key = "page_location"), r'\.com(\/[^?]*)') AS page_path,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = "debug_target") as debug_target,
    ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = "metric_value"), 3) AS metric_value,
    *
  FROM web_vitals_events
  WHERE metric_name = 'CLS'
)
GROUP BY 1, 2
HAVING count > 50 # Limit to relatively popular pages
ORDER BY CLS DESC

Résultat de la requête pour les principaux éléments contribuant au CLS

Savoir quels éléments sont décalés sur la page devrait vous permettre d'identifier et de résoudre l'origine du problème beaucoup plus facilement.

Gardez à l'esprit que les éléments signalés ici peuvent ne pas correspondre aux éléments décalés lorsque vous déboguez vos pages en local. C'est pourquoi il est très important de collecter ces données au départ. Si vous ignorez que des problèmes existent, vous aurez du mal à les résoudre.

Déboguer d'autres métriques

La requête précédente affiche les résultats de la métrique CLS. Toutefois, vous pouvez utiliser la même technique afin de créer des rapports sur les cibles de débogage pour le LCP et l'INP. Il vous suffit de remplacer la clause where par la métrique appropriée pour effectuer le débogage :

WHERE metric_name = 'INP'
WHERE metric_name = 'LCP'

Encore une fois, consultez Déboguer les performances sur le terrain pour savoir comment collecter et envoyer des informations de débogage pour chacune des métriques Core Web Vitals.

Visualiser

Il peut être difficile d'obtenir des insights en se basant uniquement sur les résultats de la requête. Par exemple, la requête suivante liste les valeurs quotidiennes du 75e percentile pour le LCP dans l'ensemble de données.

# Subquery all Web Vitals events from the last 28 days
WITH web_vitals_events AS (
  SELECT event_name as metric_name, * EXCEPT(event_name, is_last_received_value) FROM (
    SELECT *, IF (ROW_NUMBER() OVER (
      PARTITION BY (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
      ORDER BY (SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value') DESC
    ) = 1, true, false) AS is_last_received_value
    FROM `bigquery_project_id.analytics_XXXXX.events_*`
    WHERE event_name in ('CLS', 'INP', 'LCP') AND
      _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 28 DAY)) AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE, INTERVAL 1 DAY))
  ) WHERE is_last_received_value
)
# Main query logic
SELECT
  event_date,
  metric_name,
  APPROX_QUANTILES(ROUND(metric_value, 2), 100)[OFFSET(75)] AS p75
FROM
  (
    SELECT
      event_date,
      metric_name,
      ROUND((SELECT COALESCE(value.double_value, value.int_value) FROM UNNEST(event_params) WHERE key = 'metric_value'), 3) AS metric_value
    FROM web_vitals_events
    WHERE
      metric_name = 'LCP'
  )
GROUP BY
  1, 2
ORDER BY event_date

Il est difficile d'identifier des tendances ou des valeurs aberrantes à partir de ces résultats de requête en examinant simplement les données.

Résultats de la requête quotidienne sur la valeur des métriques

Dans ce cas, visualiser les données peut vous aider à dégager des insights plus rapidement.

Visualiser les résultats de la requête dans Looker Studio

BigQuery permet de visualiser rapidement des résultats de requête via Data Studio. Looker Studio est un outil de visualisation de données et de tableaux de bord gratuit. Pour visualiser les résultats de votre requête, après avoir exécuté votre requête dans l'UI BigQuery, cliquez sur le bouton Explorer les données et sélectionnez Explorer avec Looker Studio.

Explorer avec l'option Looker Studio dans BigQuery

Un lien direct de BigQuery vers Looker Studio est alors créé dans la vue "Explorer". Dans cette vue, vous pouvez sélectionner les champs que vous souhaitez visualiser, choisir des types de graphiques, configurer des filtres et créer des graphiques ad hoc pour une analyse visuelle rapide. À partir des résultats de la requête précédente, vous pouvez créer ce graphique en courbes pour observer l'évolution des valeurs LCP au fil du temps :

Graphique en courbes des valeurs LCP quotidiennes dans Looker Studio

Grâce à ce lien direct entre BigQuery et Looker Studio, vous pouvez créer des graphiques rapides à partir de n'importe quelle requête et effectuer des analyses visuelles. Toutefois, si vous souhaitez effectuer une analyse supplémentaire, vous pouvez consulter plusieurs graphiques dans un tableau de bord interactif afin d'obtenir une vue plus globale ou de pouvoir afficher le détail des données. Grâce à ce tableau de bord pratique, vous n'avez pas besoin d'écrire des requêtes ni de générer des graphiques manuellement chaque fois que vous souhaitez analyser vos métriques.

Vous pouvez créer un tableau de bord dans Looker Studio à l'aide du connecteur BigQuery natif. Pour ce faire, accédez à datastudio.google.com, créez une source de données, sélectionnez le connecteur BigQuery, puis choisissez l'ensemble de données que vous voulez interroger :

Utiliser le connecteur BigQuery natif dans Looker Studio

Matérialiser les données des métriques Web Vitals

Lorsque vous créez des tableaux de bord pour les données d'événement "Signaux Web", comme décrit précédemment, il n'est pas efficace d'utiliser directement l'ensemble de données d'exportation Google Analytics 4. En raison de la structure des données GA4 et du prétraitement requis pour les métriques des signaux Web, certaines parties de votre requête finissent par s'exécuter plusieurs fois. Cela entraîne deux problèmes concernant les performances du tableau de bord et les coûts associés à BigQuery.

Vous pouvez utiliser le mode bac à sable de BigQuery sans frais. Avec la version gratuite de BigQuery, le premier téraoctet de données de requêtes traitées chaque mois est gratuit. Pour les méthodes d'analyse décrites dans cet article, sauf si vous utilisez un ensemble de données très volumineux ou que vous interrogez régulièrement l'ensemble de données, vous devriez pouvoir respecter cette limite sans frais chaque mois. Toutefois, si votre site Web génère un volume de trafic important et que vous souhaitez surveiller régulièrement différentes métriques à l'aide d'un tableau de bord interactif rapide, nous vous conseillons de prétraiter et de matérialiser vos données de signaux Web tout en utilisant les fonctionnalités de BigQuery, telles que le partitionnement, le clustering et la mise en cache.

Le script suivant prétraitera vos données BigQuery (table source) et créera une table matérialisée (table cible). Lorsque vous utilisez cette requête pour votre propre ensemble de données, vous pouvez également définir une plage de dates pour la table source afin de réduire la quantité de données traitées.

# Materialize Web Vitals metrics from GA4 event export data

# Replace target table name
CREATE OR REPLACE TABLE bigquery_project_id.ga4_demo_dev.web_vitals_summary
  PARTITION BY DATE(event_timestamp)
  CLUSTER BY metric_name
AS
SELECT
  ga_session_id,
  IF(
    EXISTS(SELECT 1 FROM UNNEST(events) AS e WHERE e.event_name = 'first_visit'),
    'New user',
    'Returning user') AS user_type,
  IF(
    (SELECT MAX(session_engaged) FROM UNNEST(events)) > 0, 'Engaged', 'Not engaged')
    AS session_engagement,
  evt.* EXCEPT (session_engaged, event_name),
  event_name AS metric_name,
  FORMAT_TIMESTAMP('%Y%m%d', event_timestamp) AS event_date
FROM
  (
    SELECT
      ga_session_id,
      ARRAY_AGG(custom_event) AS events
    FROM
      (
        SELECT
          ga_session_id,
          STRUCT(
            country,
            device_category,
            device_os,
            traffic_medium,
            traffic_name,
            traffic_source,
            page_path,
            debug_target,
            event_timestamp,
            event_name,
            metric_id,
            IF(event_name = 'LCP', metric_value / 1000, metric_value) AS metric_value,
            user_pseudo_id,
            session_engaged,
            session_revenue) AS custom_event
        FROM
          (
            SELECT
              (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
                AS ga_session_id,
              (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'metric_id')
                AS metric_id,
              ANY_VALUE(device.category) AS device_category,
              ANY_VALUE(device.operating_system) AS device_os,
              ANY_VALUE(traffic_source.medium) AS traffic_medium,
              ANY_VALUE(traffic_source.name) AS traffic_name,
              ANY_VALUE(traffic_source.source) AS traffic_source,
              ANY_VALUE(
                REGEXP_SUBSTR(
                  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location'),
                  r'^[^?]+')) AS page_path,
              ANY_VALUE(
                (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'debug_target'))
                AS debug_target,
              ANY_VALUE(user_pseudo_id) AS user_pseudo_id,
              ANY_VALUE(geo.country) AS country,
              ANY_VALUE(event_name) AS event_name,
              SUM(ecommerce.purchase_revenue) AS session_revenue,
              MAX(
                (
                  SELECT
                    COALESCE(
                      value.double_value, value.int_value, CAST(value.string_value AS NUMERIC))
                  FROM UNNEST(event_params)
                  WHERE key = 'session_engaged'
                )) AS session_engaged,
              TIMESTAMP_MICROS(MAX(event_timestamp)) AS event_timestamp,
              MAX(
                (
                  SELECT COALESCE(value.double_value, value.int_value)
                  FROM UNNEST(event_params)
                  WHERE key = 'metric_value'
                )) AS metric_value,
            FROM
              # Replace source table name
              `bigquery_project_id.analytics_XXXXX.events_*`
            WHERE
              event_name IN ('LCP', 'INP', 'CLS', 'first_visit', 'purchase')
            GROUP BY
              1, 2
          )
      )
    WHERE
      ga_session_id IS NOT NULL
    GROUP BY ga_session_id
  )
CROSS JOIN UNNEST(events) AS evt
WHERE evt.event_name NOT IN ('first_visit', 'purchase');

Cet ensemble de données matérialisé présente plusieurs avantages :

La structure des données est aplatie et devient plus facile à interroger.
Elle ne conserve que les événements "Signaux Web" de l'ensemble de données GA4 d'origine.
L'ID de session, le type d'utilisateur (nouveau ou connu) et les informations sur l'engagement de la session sont directement disponibles dans les colonnes.
La table est partitionnée par date et regroupée par nom de métrique. Cela permet généralement de réduire la quantité de données traitées pour chaque requête.
Comme vous n'avez pas besoin d'utiliser de caractères génériques pour interroger cette table, les résultats de requête peuvent être mis en cache pendant 24 heures maximum. Cela permet de réduire les coûts liés à la répétition de la même requête.
Si vous utilisez BigQuery BI Engine, vous pouvez exécuter des fonctions et opérateurs SQL optimisés sur cette table.

Vous pouvez interroger directement cette table matérialisée à partir de l'UI BigQuery ou vous en servir dans Looker Studio à l'aide du connecteur BigQuery.

Utiliser le connecteur Web Vitals

Comme créer un tableau de bord à partir de zéro prend beaucoup de temps, nous avons développé une solution empaquetée qui vous permettra de créer un modèle de tableau de bord. Tout d'abord, assurez-vous d'avoir matérialisé votre tableau de signaux Web à l'aide de la requête précédente. Accédez ensuite au connecteur de signaux Web pour Looker Studio via le lien suivant : goo.gle/web-vitals-connector.

Une fois que vous avez accordé une autorisation unique, l'écran de configuration suivant doit s'afficher :

Écran d'autorisation du connecteur Web Vitals

Indiquez l'ID de la table BigQuery matérialisée (la table cible) et l'ID de votre projet de facturation BigQuery. Lorsque vous cliquez sur "Associer", Looker Studio crée un tableau de bord à partir d'un modèle et y associe vos données. Vous pouvez modifier et partager le tableau de bord comme vous le souhaitez. Si vous créez un tableau de bord une seule fois, vous n'avez pas besoin d'accéder à nouveau au lien du connecteur, sauf si vous voulez créer plusieurs tableaux à partir de différents ensembles de données.

Parcourir le tableau de bord

Lorsque vous parcourez le tableau de bord, vous pouvez consulter les tendances quotidiennes des métriques de signaux Web ainsi que des informations sur l'utilisation de votre site Web (utilisateurs et sessions, par exemple) dans l'onglet Résumé.

Dans l'onglet Analyse des utilisateurs, vous pouvez sélectionner une métrique, puis obtenir une répartition du centile des métriques et du nombre d'utilisateurs en fonction de différentes métriques d'utilisation et métier.

L'onglet Analyse du chemin de la page vous permet d'identifier les points problématiques sur votre site. Ici, vous pouvez sélectionner une métrique pour afficher une vue d'ensemble. Toutefois, vous voyez également le graphique à nuage de points représentant tous les chemins de page, avec la valeur du centile sur l'axe Y et le nombre d'enregistrements sur l'axe X. Ce graphique peut vous permettre d'identifier les pages présentant des valeurs de métriques inférieures aux attentes. Une fois les pages sélectionnées à l'aide du graphique à nuage de points du tableau Chemin de la page, vous pouvez afficher une vue détaillée de la zone problématique en consultant le tableau Cible de débogage.

L'onglet Analyse des revenus illustre comment vous pouvez surveiller vos métriques commerciales et de performances au même endroit. Cette section représente toutes les sessions au cours desquelles l'utilisateur a effectué un achat. Vous pouvez comparer les revenus générés et l'expérience utilisateur au cours d'une session spécifique.

Utilisation avancée

À mesure que vous vous familiarisez avec le jeu de données, vous pouvez modifier le tableau de bord et ajouter vos propres graphiques pour une analyse plus riche et ciblée. Pour rendre le tableau de bord plus utile, vous pouvez procéder comme suit:

Configurez une requête planifiée dans BigQuery pour obtenir des données à jour. La requête de matérialisation que nous avons exécutée précédemment ne prend qu'un instantané de vos données à ce moment-là. Si vous souhaitez mettre à jour votre tableau de bord avec de nouvelles données, vous pouvez exécuter une requête planifiée qui s'exécutera tous les jours et ajouter les nouvelles données à votre table materialisée.
Joindre des données first party (CRM, par exemple) pour obtenir des insights commerciaux Dans le tableau materialisé, vous pouvez ajouter user_id en tant que colonne distincte. Vous pourrez ainsi joindre vos données first party. Si vos données first party ne se trouvent pas déjà dans BigQuery, vous pouvez les charger ou utiliser une source de données fédérée.
Indiquez la version de votre site ou de votre application en tant que paramètre dans les données que vous envoyez à Google Analytics, puis ajoutez-la en tant que colonne dans le tableau matérié. Vous pouvez ensuite ajouter ces données de version en tant que dimension dans vos graphiques pour voir plus facilement comment les modifications de version affectent les performances.
Si vous prévoyez d'utiliser l'ensemble de données de manière intensive via une requête directe ou le tableau de bord, vous pouvez essayer la version payante du moteur de BI BigQuery.

Résumé

Cet article a présenté les principes de base de l'utilisation de Google Analytics 4 et de BigQuery pour mesurer et déboguer les performances à l'aide de données sur les utilisateurs réels collectées sur le terrain. Il a également expliqué comment créer des rapports et des tableaux de bord automatisés à l'aide de Looker Studio et du connecteur Web Vitals pour simplifier au maximum la visualisation des données.

Voici quelques points clés à retenir de cet article :

Mesurer les performances à l'aide de données utilisateur réelles est essentiel pour comprendre, déboguer et optimiser votre site.
Vous pouvez obtenir des insights plus précis lorsque vos métriques de performances et vos métriques commerciales se trouvent dans le même système. Google Analytics et BigQuery le permettent.
L'exportation des données Google Analytics brutes vers BigQuery vous offre un potentiel illimité d'analyses personnalisées et approfondies à l'aide d'un langage de requête que vous connaissez probablement déjà.
Google propose un certain nombre d'API et d'outils de visualisation tels que Looker Studio, qui vous permettent de créer vos rapports exactement comme vous le souhaitez.