Comment créer un tableau de bord Google Analytics ?

Google Analytics lance enfin de vrais dashboards personnalisés dans GA4

Google Analytics 4 avait un problème assez difficile à défendre : pour construire un vrai tableau de bord métier dans l’interface, on finissait presque toujours par sortir de GA4. On bricolait avec les rapports Overview. On construisait une Exploration. Ou, plus sérieusement, on passait sur Looker Studio.

Google vient de combler une partie de ce trou avec une nouvelle fonctionnalité simplement appelée Google Analytics dashboard.

Et cette fois, le mot « dashboard » n’est pas usurpé.

On peut créer directement dans GA4 une page composée de plusieurs visualisations, les déplacer, les redimensionner, glisser-déposer dimensions et métriques, puis publier le tableau de bord dans le menu Reports de la propriété.

Découvrez égalementPourquoi Google Analytics fausse vos données web ?

Google décrit cette nouvelle surface comme un moyen de réunir sur une seule page les KPI importants pour l’entreprise. Pour moi, c’est probablement l’une des améliorations les plus utiles apportées récemment au reporting natif de GA4.

Pas parce qu’elle remplace Looker Studio. Elle ne le remplace clairement pas.

Mais parce qu’elle remet enfin dans GA4 quelque chose qui manquait depuis la disparition d’Universal Analytics : un véritable écran de pilotage personnalisable.

À quoi sert le nouveau dashboard Google Analytics ?

Au lieu de naviguer entre Acquisition, Engagement, Monetization, User attributes et une série de rapports personnalisés, je peux réunir les indicateurs dont j’ai réellement besoin dans une seule vue.

Par exemple, pour un site e-commerce :

• chiffre d’affaires ;
• nombre d’achats ;
• taux de conversion des sessions ;
• sessions ;
• produits consultés ;
• produits ajoutés au panier ;
• produits achetés ;
• meilleures ventes ;
• évolution du revenu ;
• répartition par canal.

Découvrez égalementPourquoi votre Google Analytics tracking devient faux ?

L’intérêt n’est donc pas de créer un nouveau modèle de données.

Le dashboard repose toujours sur les données et les métriques disponibles dans Google Analytics.

Ce qui change, c’est la couche de visualisation et d’organisation.

Google parle explicitement d’une « consolidated, single-page KPI view », autrement dit une vue consolidée des KPI sur une seule page.

Et ça change pas mal de choses pour les utilisateurs qui veulent consulter leurs données sans devenir experts des Explorations.

Comment créer un dashboard personnalisé dans GA4 ?

Découvrez égalementPourquoi connecter Google Business à Google Analytics

Google a volontairement simplifié la création.

Il faut disposer du rôle Editor ou Administrator sur la propriété. Ces droits sont nécessaires pour créer et publier le dashboard. Les utilisateurs disposant simplement d’un accès à la propriété pourront ensuite consulter les dashboards publiés.

Depuis GA4 :

Reports → + Create → Dashboard

On arrive alors sur le canvas.

La logique est assez différente de celle d’un rapport détaillé GA4.

Ici, on construit une page à partir de plusieurs composants indépendants.

Le workflow ressemble à ça :

1. j’ajoute une visualisation ;
2. je choisis son type ;
3. j’ajoute les dimensions ;
4. j’ajoute les métriques ;
5. je configure éventuellement son filtre ;
6. je configure le tri ;
7. je positionne la carte ;
8. je la redimensionne ;
9. je recommence avec les autres indicateurs.

Google permet donc réellement de travailler par drag-and-drop : dimensions et métriques peuvent être glissées vers les visualisations présentes sur le canvas.

Une fois le dashboard construit :

Save, puis Publish.

La publication ajoute directement le dashboard à la navigation de gauche des rapports GA4. C’est un détail qui compte. Jusqu’ici, publier proprement des rapports personnalisés passait généralement par la Library et la gestion des Collections.

Quels graphiques peut-on utiliser ?

Google annonce actuellement six familles de visualisations.

• Les scorecards sont particulièrement intéressantes pour construire une première ligne de KPI.
• Lorsqu’une comparaison de dates est appliquée, elles peuvent également afficher l’évolution en pourcentage.
• Les courbes disposent pour leur part d’une granularité quotidienne, hebdomadaire ou mensuelle.
• Les tables peuvent afficher des barres ombrées directement dans les cellules et utiliser la pagination.

Ce n’est pas encore Looker Studio, mais on dépasse largement la simple collection de « summary cards » que GA4 proposait jusqu’ici.

Le canvas fonctionne avec une vraie grille

Autre différence importante : les cartes ne sont pas simplement empilées les unes sous les autres.

Le dashboard repose sur une grille.

Chaque visualisation peut être déplacée et redimensionnée.

On peut donc créer quelque chose comme :

La disposition devient réellement une partie du reporting. C’est important parce qu’un dashboard n’est pas simplement une collection de données.

La hiérarchie visuelle sert à dire : voilà ce qu’il faut regarder d’abord.

Exemple : construire un dashboard e-commerce utile

Je reprendrais volontiers une structure très proche de celle montrée par Google.

En haut, les KPI opérationnels :

• Total revenue ;
• Items viewed ;
• Items added to cart ;
• Items purchased ;
• Sessions ;
• Session key event rate ou une métrique de conversion pertinente ;
• Average purchase revenue ;
• utilisateurs ou sessions mobiles.

En dessous, je mettrais quelques analyses réellement actionnables.

Évolution du chiffre d’affaires

Une courbe :

Dimension : Date
Métrique : Total revenue

L’objectif est de détecter immédiatement une rupture ou une tendance.

Performance par canal

Un bar chart :

Dimension : Session default channel group
Métriques : Sessions + Total revenue

On commence à rapprocher acquisition et résultat business.

Produits les plus performants

Une table :

Dimension : Item name

Avec par exemple :

• Items viewed ;
• Items added to cart ;
• Items purchased ;
• Item revenue.

Cette vue permet déjà d’identifier des produits très vus mais peu achetés.

Funnel e-commerce

Un Funnel chart sur les étapes disponibles dans la propriété :

view_item → add_to_cart → begin_checkout → purchase

On obtient alors une page de pilotage qui peut être consultée quotidiennement sans reconstruire systématiquement une Exploration.

Dashboard, Reports, Explorations, Looker Studio : ce n’est pas la même chose

C’est probablement le point le plus important.

Le nouveau dashboard ne remplace pas les autres surfaces de reporting.

Il faut choisir le bon outil pour le bon besoin.

Google rappelle d’ailleurs que les Reports, Explorations, Data API et BigQuery n’utilisent pas exactement les mêmes couches de données et peuvent présenter des différences.

Un dashboard GA4 doit donc être considéré comme une nouvelle interface de reporting native, pas comme un remplacement de la stack Analytics.

Est-ce que les dashboards remplacent les Explorations ?

Non.

Et heureusement.

Une Exploration reste beaucoup plus puissante lorsqu’il faut analyser.

Je peux y créer des segments, manipuler plusieurs dimensions, explorer un funnel, étudier un chemin utilisateur ou effectuer des croisements beaucoup plus poussés.

Le dashboard répond à une autre question :

quelles informations ai-je besoin de voir régulièrement ?

L’Exploration répond plutôt à :

pourquoi est-ce que ce chiffre évolue ?

La différence est fondamentale.

Un dashboard doit permettre de détecter.

Une analyse doit permettre de comprendre.

Est-ce que ça remplace Looker Studio ?

Là encore : non.

Je vois déjà venir le raccourci « on n’a plus besoin de Looker Studio ».

Ce serait aller beaucoup trop vite.

Le dashboard GA4 reste actuellement limité aux données présentes dans Google Analytics.

Looker Studio permet notamment de connecter et combiner :

• Google Analytics ;
• Google Ads ;
• Search Console ;
• BigQuery ;
• Google Sheets ;
• bases SQL ;
• API et connecteurs tiers ;
• CRM ;
• données commerciales.

Il offre également beaucoup plus de contrôle sur le design, les filtres, les champs calculés et le partage.

Le dashboard GA4 a cependant un énorme avantage : il est dans GA4.

Pour une équipe marketing qui veut simplement surveiller ses principaux indicateurs Analytics, ne pas avoir à maintenir un rapport externe est loin d’être anecdotique.

Une fonction très intéressante : publier directement dans Reports

C’est probablement la partie que je trouve la plus intelligente.

Une fois le dashboard enregistré, Google permet de le publier directement dans la navigation Reports.

Cela permet par exemple de créer :

• Dashboard Direction ;
• Dashboard Acquisition ;
• Dashboard Ecommerce ;
• Dashboard Contenu ;
• Dashboard Produit ;
• Dashboard Lead Generation.

Puis de rendre ces vues directement accessibles aux personnes qui travaillent dans la propriété.

Le reporting devient beaucoup plus orienté métier.

Au lieu d’imposer la structure standard de Google Analytics aux utilisateurs, on rapproche l’interface de leur besoin réel.

Qui peut créer et consulter les dashboards ?

Google distingue clairement création et consultation.

Pour créer ou publier un dashboard :

Editor ou Administrator requis.

Pour consulter un dashboard publié :

un accès à la propriété suffit.

Cela permet de conserver une gouvernance assez saine.

Les utilisateurs ne construisent pas chacun leur propre cockpit officiel.

Quelques personnes administrent le reporting, tandis que les autres utilisent les vues publiées.

Combien de cartes peut-on ajouter ?

Google fixe actuellement une limite différente selon le type de propriété :

15 cartes me paraissent largement suffisantes pour la majorité des dashboards.

Et je dirais même que si j’ai besoin de 30 graphiques pour comprendre mon activité, mon problème n’est probablement plus la limite de GA4.

C’est le dashboard.

Un bon tableau de bord n’est pas un entrepôt de graphiques.

Les limites actuelles sont importantes

C’est ici qu’il faut calmer un peu l’enthousiasme.

Google documente plusieurs limitations.

Pas de segments

Les segments ne sont actuellement pas pris en charge dans les dashboards.

C’est une différence majeure avec Explorations.

Impossible donc de construire librement un dashboard autour d’un segment comportemental complexe comme on pourrait le faire dans une Exploration.

Pas de comparaison au niveau de chaque carte

Google indique également que les card-level comparisons ne sont pas supportées actuellement.

On ne dispose donc pas encore de toute la souplesse nécessaire pour appliquer des comparaisons différentes à chaque composant.

Pas de support API

Autre limitation explicitement indiquée par Google : API support is currently not supported.

Autrement dit, ne partez pas du principe que vous pourrez créer ou administrer ces dashboards automatiquement avec la Google Analytics API.

La fonctionnalité est, pour l’instant, essentiellement pilotée depuis l’interface.

Un dashboard publié est partagé à la propriété

Google précise également que tous les dashboards publiés sont partagés au niveau de la propriété.

Il ne s’agit donc pas d’un espace de reporting privé par utilisateur.

C’est à prendre en compte dans la gouvernance.

Attention aux différences entre dashboard GA4 et données BigQuery

Le fait d’afficher les données dans une nouvelle visualisation ne change évidemment pas la manière dont Google Analytics construit ses données de reporting.

Google précise que Reports et Explorations peuvent utiliser des données agrégées ou des données événementielles et utilisateur selon la requête.

La haute cardinalité peut toujours entraîner l’apparition de la ligne (other).

L’échantillonnage peut également intervenir dans certaines conditions lorsque des données granulaires doivent être traitées.

À l’inverse, BigQuery travaille sur les données événementielles exportées et n’inclut pas nécessairement certaines transformations ou modélisations ajoutées par GA4 dans ses rapports.

Google rappelle notamment que :

• la Data-Driven Attribution est présente dans les rapports mais pas directement dans l’export brut BigQuery ;
• la modélisation des key events peut être intégrée aux rapports ;
• le behavioral modeling peut également modifier les résultats affichés par rapport aux données BigQuery.

Un dashboard GA4 n’est donc pas une nouvelle « source de vérité ».

C’est une nouvelle manière d’interroger et présenter la couche de reporting Google Analytics.

Comment je construirais un bon dashboard GA4

Je commencerais par une règle assez brutale :

une métrique qui ne déclenche aucune décision n’a probablement rien à faire dans le dashboard.

Afficher Users, Sessions, Views, Event count, Engagement rate, Average engagement time et vingt autres KPI simplement parce qu’ils existent ne sert pas à grand-chose.

Je partirais plutôt de quelques questions.

Est-ce que l’activité progresse ?

Revenue, leads, purchases, key events.

Est-ce que l’acquisition fonctionne ?

Sessions, users, conversion ou revenue par canal.

Est-ce que le site transforme correctement le trafic ?

Funnel et taux associés.

Où apparaît une anomalie ?

Évolution temporelle et éventuellement comparaison avec la période précédente.

Quels éléments génèrent réellement le résultat ?

Pages, landing pages, produits, campagnes ou sources.

Cela donne généralement un dashboard beaucoup plus utile que la traditionnelle collection de KPI GA4.

Dashboard Direction et dashboard Analyste ne doivent pas être identiques

Autre erreur classique : construire un dashboard universel.

Je préfère séparer les besoins.

Pour une direction, je peux avoir :

• Revenue ;
• Purchases ;
• Leads ;
• Sessions ;
• évolution du revenu ;
• revenu par canal ;
• top produits.

Pour une équipe acquisition :

• Sessions ;
• New users ;
• Session source / medium ;
• Session campaign ;
• Total revenue ;
• Session key event rate ;
• coût publicitaire si les données concernées sont disponibles dans GA4.

Pour un responsable e-commerce :

• Items viewed ;
• Add to carts ;
• Checkouts ;
• Purchases ;
• Item revenue ;
• funnel ;
• produits les plus vendus.

Même source de données.

Mais pas le même besoin.

Un retour assumé vers ce qu’Universal Analytics savait déjà faire

Il y a aussi quelque chose d’un peu ironique dans cette nouveauté.

Universal Analytics disposait de dashboards personnalisables.

GA4 est arrivé avec une architecture beaucoup plus puissante sur certains aspects, mais sans véritable équivalent.

Pendant plusieurs années, on nous a proposé :

• Reports snapshot ;
• Overview reports ;
• summary cards ;
• Library ;
• Explorations.

Tout cela était utile.

Mais aucun ne répondait exactement au besoin très simple :

je veux poser plusieurs indicateurs et graphiques sur une page et en faire mon tableau de bord.

C’est maintenant possible.

Et parfois, une bonne fonctionnalité n’a pas besoin d’intelligence artificielle, d’agent ou de bouton magique.

Elle doit juste résoudre un problème concret.

Ce que cette nouveauté change pour Looker Studio

Je ne pense pas que Looker Studio ait beaucoup à craindre sur les projets avancés.

En revanche, je pense qu’une partie des petits dashboards Looker Studio risque de devenir inutile.

Je pense notamment aux rapports qui ne font que présenter :

• quatre scorecards GA4 ;
• une courbe des sessions ;
• un tableau des sources ;
• un graphique des conversions ;
• un tableau des landing pages.

Si toute la donnée vient de la même propriété GA4, la question mérite maintenant d’être posée :

est-ce que j’ai encore besoin d’un outil externe pour ça ?

Parfois oui.

Parfois probablement plus.

Et c’est précisément là que cette nouvelle fonctionnalité devient intéressante.

Ce qui manque encore

La première version pose de bonnes bases, mais je surveillerais particulièrement plusieurs évolutions.

Des filtres et comparaisons réellement indépendants par carte changeraient beaucoup de choses.

Le support des segments rapprocherait davantage le dashboard des possibilités d’Explorations.

Une API permettrait aux agences et grandes organisations d’industrialiser le déploiement de dashboards sur plusieurs propriétés.

Des mécanismes de duplication et de templates plus poussés seraient également très utiles.

Google ne promet pas ces évolutions dans la documentation que j’ai consultée.

Je préfère donc ne pas transformer ma liste de souhaits en roadmap imaginaire.

Aujourd’hui, les faits sont plus simples : API, segments et comparaisons au niveau des cartes ne sont pas supportés.

Est-ce que je recommande d’utiliser les nouveaux dashboards GA4 ?

Oui.

Clairement.

Pas pour remplacer toute votre BI.

Pas pour faire disparaître Looker Studio.

Pas pour abandonner BigQuery.

Et certainement pas pour remplacer les Explorations.

Je l’utiliserais comme premier niveau de pilotage dans Google Analytics.

Le dashboard répond très bien à une situation courante : j’ouvre GA4 et je veux comprendre en trente secondes si mon activité va dans la bonne direction.

C’est exactement le rôle qu’un dashboard devrait avoir.

Google Analytics dispose maintenant d’une surface dédiée pour le faire.

Il était temps.

Sources principales

• Documentation officielle Google Analytics : About Google Analytics dashboard.
• Documentation officielle Google Analytics : Reporting surfaces comparison, pour les différences entre Reports, Explorations, Data API et BigQuery.
• Documentation Google sur la personnalisation des rapports GA4, utile pour distinguer les dashboards des Detail reports et des Overview reports.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.