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 aux propriétés Google Analytics 4 et les exporter pour les analyser dans BigQuery et Looker Studio.

Minhaz Kazi

Philip Walton

Google fournit un certain nombre d'outils : Console, PageSpeed Insights (PSI) l'expérience utilisateur de Chrome Rapport qui permettent aux développeurs d'évaluer les performances de leurs sites par rapport au Core Web Statistiques vitales de leurs utilisateurs réels dans le .

Ces outils sont très utiles, car ils vous donnent une vue d'ensemble de l'état des performances réelles d'un utilisateur et ne nécessitent aucune configuration pour être utilisées.

Cependant, il y a quelques raisons essentielles pour lesquelles vous ne voulez pas vous fier à ces seuls des outils permettant d'évaluer les performances de votre site:

Les outils basés sur l'expérience utilisateur Chrome présentent les données par mois ou par périodes de 28 jours précédentes. Vous devrez donc patienter longtemps après avoir apporté des modifications pouvez voir les résultats.
Les outils basés sur l'expérience utilisateur Chrome (CrUX) ne peuvent être segmentés qu'en fonction d'un nombre limité de dimensions, comme le pays, le type de connexion et la catégorie d'appareil (ordinateur ou mobile). Vous ne pouvez pas segmenter les données selon des dimensions spécifiques à votre entreprise (par exemple, le taux d'engagement utilisateurs, utilisateurs d'un groupe de test particulier, etc.).
Les outils basés sur l'expérience utilisateur Chrome (CrUX) peuvent vous indiquer quelles sont vos performances, mais ils ne peuvent pas le faire. vous pourquoi. Grâce aux outils d'analyse, vous pouvez envoyer des données supplémentaires pour suivre 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 vous explique comment utiliser les ressources les outils Google à cette fin.

Une fois que tout est 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

Il a toujours été possible de mesurer les performances avec Google Analytics en utilisant métriques personnalisées, mais quelques nouvelles fonctionnalités de Google Analytics 4 (GA4), que les développeurs devraient vous intéresser.

Zero-config, custom événement paramètres
Exportation BigQuery sans frais Vous pouvez donc interroger vos données à l'aide de SQL

L'interface Web de Google Analytics offre des outils d'analyse puissants, la puissance et la flexibilité de l'accès aux données d'événements brutes via une requête langue que vous connaissez probablement déjà.

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

Créer un compte Google Analytics 4 Propriété et une propriété Projet BigQuery.
Activez l'exportation vers BigQuery. dans la configuration de votre propriété Google Analytics. Ainsi, toutes les données que vous recevrez seront renseignés automatiquement dans les tables de votre projet BigQuery.
Ajouter le code JavaScript web-vitals à votre site pour 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, vous devriez voir des données d'événement s'afficher dans la et vous devriez être en mesure d'interroger les données comme ceci:

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 les données d'événement des signaux Web, il est important de comprendre comment les données sont agrégées.

Il est essentiel de comprendre que, dans certains cas, plusieurs événements peut être reçu pour la même métrique, sur la même page. Cela peut se produire si la valeur de la métrique et une valeur mise à jour est consignée (ce qui arrive fréquemment avec le CLS).

Pour les événements Signaux Web, la dernière valeur envoyée est toujours la plus précise. Avant d'effectuer une analyse, il est important de filtrer uniquement 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 ainsi utiliser afin de limiter vos résultats à la dernière valeur reçue pour chaque ID de la 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 pourriez que vous souhaitez 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 (p. 75) 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 avec le CLS 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 métriques des métriques Core Web Vitals, ce qui est utile pour comprendre vos performances actuelles et leur évolution au fil du temps. Toutefois, Que faire si vos performances sont moins bonnes que prévu, mais que vous n'êtes pas sûr ? pourquoi ?

Savoir à quoi s'adressent vos scores n'est pas utile si vous n'êtes pas en mesure d'agir et résoudre les problèmes.

L'article Résoudre les problèmes de performances sur le terrain explique comment procéder. vous pouvez envoyer des informations de débogage supplémentaires avec vos données d'analyse. Si vous suivez les instructions détaillées dans ce message, vous devriez voir des informations apparaissent également dans BigQuery.

Exemples de requêtes

Les requêtes suivantes montrent comment utiliser le paramètre d'événement debug_target pour aider 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 situé sur la page la plus pertinente par rapport à la valeur de la métrique.

Avec le CLS, debug_target représente l'élément le plus grand à partir 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 de debug_target sera null.

La requête suivante listera les pages de la pire à la meilleure en fonction de leur CLS au 75e jour centile (regroupement 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 de la page sont décalés devrait faciliter identifier et corriger la cause racine du problème.

Gardez à l'esprit que les éléments indiqués ici peuvent être différents de ceux vous constatez un décalage lorsque vous déboguez vos pages en local. C'est pourquoi il est si important de capturer ces données en premier lieu. C'est très difficile à régler dont vous ne réalisez pas qu'il s'agit de problèmes !

Déboguer d'autres métriques

La requête précédente affiche les résultats de la métrique CLS, mais les mêmes peut être utilisée pour générer des rapports sur les cibles de débogage pour LCP et INP. Juste Remplacez la clause WHERE par la métrique appropriée pour le débogage:

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

Là encore, vous pouvez consulter Déboguer les problèmes de performances dans 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 simplement en examinant les résultats de la requête. seul. Par exemple, la requête suivante répertorie les valeurs quotidiennes du 75e centile pour 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

À partir des résultats de ces requêtes, il est difficile d'identifier des tendances ou des valeurs aberrantes rien qu'en à examiner les données.

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

Dans ce cas, la visualisation des données peut vous aider à en dégager des insights plus rapidement.

Visualiser les résultats des requêtes dans Looker Studio

BigQuery permet de visualiser rapidement n'importe quel résultat de requête via Data dans Google Marketing Platform Studio. Looker Studio est une visualisation des données et de tableaux de bord sans frais. Pour visualiser les résultats de vos requêtes, Après avoir exécuté votre requête dans l'UI BigQuery, cliquez sur le bouton Explore Data (Explorer les données). sélectionnez Explorer avec Looker Studio.

Option "Explorer avec Looker Studio" dans BigQuery

Cela créera un lien direct entre BigQuery et Looker Studio dans l'exploration vue. Dans cette vue, vous pouvez sélectionner les champs à visualiser, des types de graphiques, configurer des filtres et créer des graphiques ad hoc pour effectuer une analyse visuelle rapide. À partir des résultats de la requête précédente, vous pouvez créer ce graphique en courbes pour voir la tendance de Valeurs LCP au fil du temps:

Graphique en courbes des valeurs LCP quotidiennes dans Looker Studio

Grâce à cette association directe entre BigQuery et Looker Studio, vous pouvez créer des des graphiques à partir de n'importe quelle de vos requêtes et effectuer une analyse visuelle. Toutefois, si vous souhaitez effectuer une analyse supplémentaire, vous pouvez examiner plusieurs graphiques d'une interactif afin d'obtenir une vue plus globale ou d'analyser en détail dans les données. Avec un tableau de bord pratique, vous n'avez pas à écrire de requêtes et générer manuellement des graphiques chaque fois que vous voulez analyser vos métriques.

Vous pouvez créer un tableau de bord dans Looker Studio à l'aide de l'outil natif BigQuery d'entrée. Pour ce faire, accédez à datastudio.google.com, puis créez source de données, sélectionnez le connecteur BigQuery, puis choisissez l'ensemble de données travailler avec:

Utiliser le connecteur natif BigQuery dans Looker Studio

Matérialiser les données des signaux Web

Lorsque vous créez des tableaux de bord des données d'événement du rapport Core Web Vitals, ne permet pas d'utiliser directement l'ensemble de données d'exportation Google Analytics 4. En raison du la structure des données GA4 et le prétraitement requis pour les signaux Web des métriques, certaines parties de votre requête s'afficheront plusieurs fois. Cela crée deux problèmes: les performances des tableaux de bord et les coûts BigQuery.

Vous pouvez utiliser le bac à sable BigQuery sans frais. Avec l'API BigQuery niveau d'utilisation sans frais, le le premier To de données de requêtes traitées chaque mois est sans frais. Pour les méthodes d’analyse abordé dans cet article, sauf si vous utilisez un ensemble de données très volumineux ou interrogent fréquemment l'ensemble de données, vous devez pouvoir rester cette limite sans frais chaque mois. Mais si votre site Web enregistre un trafic élevé et que vous souhaitez surveiller régulièrement différentes métriques à l'aide d'un tableau de bord interactif rapide, vous suggérons de prétraiter et de matérialiser vos données Web Vitals tout en utilisant Fonctionnalités d'efficacité de BigQuery telles que le partitionnement, le clustering et la mise en cache.

Le script suivant prétraite vos données BigQuery (table source) et créer une table matérialisée (table cible). Si vous utilisez cette requête pour vos propres vous pouvez également définir une plage de dates pour la table source 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 est plus facile à interroger.
Elle ne conserve que les événements Web Vitals de l'ensemble de données GA4 d'origine.
ID de session, type d'utilisateur (nouveau ou connu) et informations sur l'engagement au niveau de la session est directement disponible dans des colonnes.
Le tableau est partitionnée par date et en cluster 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 la requête peuvent sont mis en cache pendant 24 heures maximum. Cela permet de réduire les coûts liés à la répétition requête.
Si vous utilisez BigQuery BI Engine, vous pouvez exécuter des fonctions SQL optimisées et des opérateurs sur ce tableau.

Vous pouvez interroger directement cette table matérialisée à partir de l'UI BigQuery ou l'utiliser 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 du temps, nous avons développé un package qui créera pour vous un modèle de tableau de bord. Tout d'abord, assurez-vous que matérialisé votre tableau de signaux Web à l'aide de la requête précédente. Accédez ensuite au Le connecteur Web Vitals pour Looker Studio utilise ce lien: goo.gle/web-vitals-connector

Après avoir accordé une autorisation unique, vous devriez obtenir le résultat suivant : de configuration:

Écran d'autorisation du connecteur de signaux Web

Indiquez l'ID de la table BigQuery matérialisée (la table cible) et votre ID du projet de facturation BigQuery. Après avoir cliqué sur "Se connecter", Looker Studio crée un nouveau tableau de bord modélisé et lui associer 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, devrez accéder de nouveau au lien du connecteur, à moins que vous ne souhaitiez créer plusieurs tableaux de bord à partir de différents jeux de données.

Parcourir le tableau de bord

En parcourant le tableau de bord, vous pouvez voir les tendances quotidiennes des signaux Web des métriques et des informations sur l'utilisation de votre site Web, comme le nombre d'utilisateurs et de sessions, dans l'onglet Résumé.

Dans l'onglet Analyse des utilisateurs, vous pouvez sélectionner une métrique, puis obtenir le détail des le centile des métriques et le nombre d'utilisateurs par utilisation et activité métriques.

L'onglet Analyse du chemin de la page vous aidera à identifier les problèmes sur votre sur votre site Web. Ici, vous pouvez sélectionner une métrique pour afficher une vue d'ensemble. Mais vous voyez aussi à nuage de points représentant tous les chemins de la page avec la valeur du centile sur l'axe y et enregistrer sur l'axe des x. Le graphique à nuage de points permet d'identifier les pages dont les performances que les valeurs attendues. Une fois les pages sélectionnées à l'aide du graphique à nuage de points, du tableau Chemin de la page, vous pouvez examiner plus en détail la zone problématique en consulter le tableau Debug Target (Cible de débogage).

L'onglet Analyse des revenus illustre comment surveiller votre activité. et les métriques 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 par rapport à l'expérience utilisateur. au cours d'une session spécifique .

Utilisation avancée

Au fur et à 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 complète et ciblée. Pour rendre le tableau de bord plus vous pouvez procéder comme suit:

Configurez une requête programmée dans BigQuery pour obtenir les données mises à jour. La 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 et souhaitez actualiser votre tableau de bord avec les nouvelles données, vous pouvez exécuter qui s'exécutera chaque jour et ajoutera à votre table matérialisée le nouveau données.
Associez des données first party (par exemple, un CRM) pour obtenir des insights commerciaux. Dans l'environnement tableau, vous pouvez ajouter user_id en tant que colonne distincte. Vous pourrez ainsi rejoindre votre de vos données first party. Si vos données first party ne sont pas déjà dans BigQuery, vous pouvez chargez les données ou utilisez une méthode fédérée source.
Signaler la version de votre site ou de votre application en tant que paramètre dans les données que vous envoyez à Google Analytics et l'ajouter en tant que colonne dans la table matérialisée. Vous pouvez ensuite ajouter ces données de version en tant que dimension dans vos graphiques afin de mieux voir les modifications de version affectent les performances.
Si vous prévoyez une utilisation intensive de l'ensemble de données par le biais ou le tableau de bord, vous pouvez essayer la version payante de BigQuery Compute Engine.

Résumé

Dans cet article, nous avons vu les principes de base de l'utilisation de Google Analytics 4 et BigQuery pour : mesurer et déboguer les performances à l'aide de données utilisateur réelles collectées sur le terrain. Il Vous avez également expliqué comment créer des rapports et des tableaux de bord automatisés à l'aide de Looker Studio. et le connecteur Web Vitals visualiser les données aussi facilement que possible.

Voici quelques points à retenir de cet article:

Il est essentiel de mesurer les performances avec des données utilisateur réelles pour déboguer et optimiser votre site.
Vous pouvez obtenir des insights plus détaillés lorsque vos métriques de performances et votre activité les métriques se trouvent dans le même système. Grâce à Google Analytics et BigQuery, possible.
L'exportation des données brutes de Google Analytics vers BigQuery vous offre un potentiel illimité pour une analyse personnalisée en profondeur à l'aide d'un langage de requête que vous connaissez probablement déjà.
Google dispose d'un certain nombre d'API et d'outils de visualisation, comme Looker Studio, qui offrent la liberté de créer vos rapports exactement comme vous le souhaitez. conçue.