Découvrez comment envoyer les données Core Web Vitals aux propriétés Google Analytics 4, et les exporter pour les analyser dans BigQuery et Looker Studio.
Google fournit un certain nombre d'outils (Search Console, PageSpeed Insights (PSI) et le rapport sur l'expérience utilisateur Chrome (CrUX) qui permettent aux développeurs d'évaluer les performances de leur site par rapport aux métriques Core Web Vitals pour leurs utilisateurs réels sur le terrain.
Ces outils sont très utiles, car ils offrent une vue d'ensemble des performances réelles de votre site et ne nécessitent aucune configuration pour être utilisés.
Cependant, il existe plusieurs raisons essentielles pour lesquelles vous ne devez pas compter uniquement sur ces outils pour mesurer les performances de votre site:
- Les outils basés sur CrUX rapportent les données par période de 28 jours ou mensuellement. Cela signifie que vous devrez attendre longtemps après avoir apporté des modifications avant de pouvoir voir les résultats.
- Vous ne pouvez segmenter les outils basés sur CrUX que selon un nombre limité de dimensions, telles que le pays, le type de connexion et la catégorie d'appareil (ordinateur ou mobile). Vous ne pouvez pas segmenter les données en fonction de dimensions propres à votre entreprise (par exemple, utilisateurs intéressés, utilisateurs d'un groupe de test spécifique, etc.).
- Les outils basés sur CrUX peuvent vous indiquer quelles sont vos performances, mais ils ne peuvent pas vous dire pourquoi. Grâce aux outils d'analyse, vous pouvez envoyer des données supplémentaires pour vous aider à repérer 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 sans frais proposés par Google pour y parvenir.
Une fois que tout est configuré, vous pourrez créer des tableaux de bord comme ceux-ci:
Si vous souhaitez 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 à l'aide de métriques personnalisées. Cependant, Google Analytics 4 (GA4) propose quelques nouvelles fonctionnalités qui devraient particulièrement intéresser les développeurs.
- Paramètres d'événement personnalisé sans configuration
- L'exportation BigQuery sans frais, pour pouvoir interroger vos données à l'aide de SQL
Bien que l'interface Web de Google Analytics dispose d'outils d'analyse puissants, il est difficile de surpasser la puissance et la flexibilité de l'accès aux données d'événements brutes en utilisant un langage de requête 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:
- Créez une propriété Google Analytics 4 et un projet BigQuery.
- Activez l'exportation BigQuery dans la configuration de votre propriété Google Analytics, afin que toutes les données que vous recevez soient automatiquement inséré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.
Analyser
Une fois la configuration terminée, les données d'événement devraient se remplir dans l'interface BigQuery et vous devriez pouvoir interroger les données comme suit:
SELECT * FROM `my_project_id.analytics_XXXXX.events_*`
WHERE event_name IN ('LCP', 'FID', 'CLS')
Voici un aperçu des résultats de cette requête:
Interroger les données Web Vitals
Avant de commencer à interroger les données d'événements Web Vitals, il est important de comprendre comment elles sont agrégées.
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 (occurrence courante 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 filtrer uniquement sur 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 identifiant 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', 'FID', '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.
Les sections suivantes présentent quelques exemples de requêtes Web Vitals courantes qu'il peut être judicieux d'exécuter.
Exemples de requêtes
LCP, FID et CLS au 75% 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', 'FID', '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', 'FID', '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', 'FID', '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 pages principales avec le CLS le plus faible (p75)
# 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', 'FID', '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 ci-dessus montrent comment interroger les données des métriques Web Vitals, ce qui est utile pour comprendre vos performances actuelles et leur évolution au fil du temps. Mais que pouvez-vous faire si vos performances sont moins bonnes que prévu, mais que vous n'êtes pas sûr de la raison ?
Savoir quels vos scores ne sont pas utiles si vous n'êtes pas en mesure de prendre des mesures et de résoudre les problèmes.
La section Performances de débogage sur le terrain explique comment envoyer des informations de débogage supplémentaires avec vos données d'analyse. Si vous suivez les instructions détaillées dans cet article, vous devriez également constater que les informations de débogage apparaissent également dans BigQuery.
Les requêtes suivantes montrent comment utiliser le paramètre d'événement debug_target pour identifier la cause des problèmes de performances.
Exemples de requêtes
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 pour la valeur de la métrique.
Avec le CLS, debug_target représente l'élément le plus grand du décalage de mise en page le plus important ayant contribué à la valeur CLS. Si aucun élément n'est décalé, la valeur debug_target sera null.
La requête suivante répertorie les pages du pire au meilleur 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', 'FID', '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
Savoir quels éléments de la page changent devrait faciliter l'identification et la résolution de la cause racine du problème.
Gardez à l'esprit que les éléments indiqués ici peuvent ne pas être les mêmes que ceux que vous voyez décaler lorsque vous déboguez vos pages localement. C'est pourquoi il est si important de capturer ces données en premier lieu. Il est très difficile de réparer des choses que vous ne réalisez pas comme des problèmes !
Déboguer d'autres métriques
La requête ci-dessus affiche les résultats de la métrique CLS, mais vous pouvez utiliser exactement la même technique pour générer des rapports sur les cibles de débogage pour le LCP et le FID. Remplacez simplement la clause WHERE par la métrique appropriée à déboguer:
WHERE metric_name = 'CLS'
WHERE metric_name = 'LCP'
Là encore, vous pouvez consulter la section Performances du débogage 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 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 du 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', 'FID', '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 de ces résultats de requête, il est difficile d'identifier des tendances ou des anomalies simplement en examinant les données.
Dans de tels cas, la visualisation des données peut vous aider à en dégager des insights plus rapidement.
Visualiser les résultats de requête dans Looker Studio
BigQuery permet de visualiser rapidement des résultats de requête via Data Studio. Looker Studio est un outil sans frais de visualisation de données et de tableaux de bord. Pour visualiser les résultats de votre requête, après avoir exécuté la requête dans l'interface utilisateur BigQuery, cliquez sur le bouton Explorer les données et sélectionnez Explorer avec Looker Studio.
Un lien direct depuis BigQuery vers Looker Studio est alors créé dans la vue d'exploration. 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 requête ci-dessus, vous pouvez créer ce graphique en courbes pour observer la tendance des valeurs LCP au fil du temps:
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 une analyse visuelle. 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 d'afficher le détail des données. Grâce à un 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 souhaitez utiliser:
Matérialiser les données des signaux Web
Lorsque vous créez des tableaux de bord des données d'événements Web Vitals comme décrit ci-dessus, 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 Web Vitals, certaines parties de votre requête finiront par s'exécuter plusieurs fois. Cela entraîne deux problèmes: les performances du tableau de bord et les coûts BigQuery.
Vous pouvez utiliser le mode bac à sable de BigQuery sans frais. Avec le niveau d'utilisation sans frais de BigQuery, le premier To de données de requêtes traitées chaque mois est sans frais. Pour les méthodes d'analyse abordées dans cet article, vous devriez pouvoir respecter cette limite sans frais tous les mois, sauf si vous utilisez un ensemble de données très volumineux ou si vous interrogez régulièrement l'ensemble de données. Toutefois, si vous avez un site Web très fréquenté et que vous souhaitez surveiller régulièrement différentes métriques à l'aide d'un tableau de bord interactif rapide, nous vous suggérons de prétraiter et de matérialiser vos données Web Vitals tout en utilisant les 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ée 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', 'FID', '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 plus facile à interroger.
- Il ne conserve que les événements Web Vitals de l'ensemble de données GA4 d'origine.
- Les informations sur l'ID de session, le type d'utilisateur (nouveau ou connu) et l'engagement de la session sont directement disponibles dans des colonnes.
- La table est partitioned par date et mise en cluster par nom de métrique. Cela réduit généralement 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 réduit les coûts liés à la répétition d'une même requête.
- Si vous utilisez le moteur BigQuery BI, 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'interface utilisateur de BigQuery ou l'utiliser dans Looker Studio à l'aide du connecteur BigQuery.
Utiliser le connecteur de signaux Web
Créer un tableau de bord à partir de zéro prend beaucoup de temps. Nous avons donc développé une solution empaquetée qui va vous permettre de créer un modèle de tableau de bord. Tout d'abord, assurez-vous d'avoir matérialisé votre tableau Core Web Vitals à l'aide de la requête ci-dessus. Accédez ensuite au connecteur Web Vitals pour Looker Studio à l'aide du lien suivant : goo.gle/web-vitals-connector.
Après avoir accordé une autorisation ponctuelle, l'écran de configuration suivant doit s'afficher:
Indiquez l'ID de la table BigQuery matérialisée (la table cible) et l'ID de votre projet de facturation BigQuery. Après avoir cliqué sur "Associer", Looker Studio crée un tableau de bord modélisé 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 de cliquer à nouveau sur le lien du connecteur, sauf si vous souhaitez créer plusieurs tableaux de bord à 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 Web Vitals et certaines informations sur l'utilisation de votre site Web, telles que les utilisateurs et les sessions, dans l'onglet Résumé.
Dans l'onglet Analyse des utilisateurs, vous pouvez sélectionner une métrique, puis obtenir la répartition de son centile et du nombre d'utilisateurs en fonction de différentes métriques métier et d'utilisation.
L'onglet Analyse du chemin de la page vous aidera à identifier les problèmes sur votre site Web. Ici, vous pouvez sélectionner une métrique pour afficher la vue d'ensemble. Toutefois, vous voyez également la carte à nuage de points de tous les chemins de la page avec la valeur de centile sur l'axe Y et le nombre d'enregistrements sur l'axe X. La carte à nuage de points peut aider à identifier les pages dont les valeurs de métriques sont inférieures aux attentes. Une fois que vous avez sélectionné les pages à l'aide du graphique à nuage de points de la table Chemin de la page, vous pouvez analyser la zone du problème plus en détail en consultant le tableau Cible de débogage.
L'onglet Analyse des revenus montre comment surveiller votre activité et vos 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 et l'expérience utilisateur au cours d'une session spécifique .
Utilisation avancée
À mesure que vous vous familiarisez avec l'ensemble de données, vous pouvez modifier le tableau de bord et ajouter vos propres graphiques pour une analyse plus précise et ciblée. Pour rendre le tableau de bord plus utile, vous pouvez procéder comme suit:
- Configurer une requête programmée dans BigQuery pour obtenir des données mises à jour La requête de matérialisation que nous avons exécutée ci-dessus ne prend qu'un instantané de vos données à ce moment-là. Si vous souhaitez maintenir votre tableau de bord à jour avec de nouvelles données, vous pouvez exécuter une requête programmée qui s'exécutera tous les jours et ajouter les nouvelles données à votre table matérialisée.
- Combinez des données first party (ex. : CRM) pour obtenir des insights commerciaux. Dans la table matérialisée, vous pouvez ajouter
user_iden tant que colonne distincte. Cela vous permettra de 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. - Enregistrez 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 la table matérialisée. Vous pouvez ensuite ajouter ces données de version en tant que dimension dans vos graphiques. Vous pourrez ainsi voir plus facilement les modifications de version affectent les performances.
- Si vous prévoyez une utilisation intensive de l'ensemble de données via une requête directe ou le tableau de bord, vous pouvez essayer la version payante de BigQuery BI Engine.
Résumé
Cet article décrit 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 utilisateur réelles collectées sur le terrain. Il explique également 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:
- Pour comprendre, déboguer et optimiser votre site, il est essentiel de mesurer vos performances avec des données utilisateur réelles.
- Vous pouvez obtenir des insights plus détaillés lorsque vos métriques de performances et vos métriques métier se trouvent dans le même système. C'est possible grâce à Google Analytics et BigQuery.
- L'exportation vers BigQuery des données brutes de Google Analytics 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 dispose d'un certain nombre d'API et d'outils de visualisation, comme Looker Studio, qui vous permettent de créer vos rapports exactement comme vous le souhaitez.