Pourquoi vos métriques Looker Studio divergent ?

Vos métriques Looker Studio divergent parce que le rapport ne mesure pas toujours la même chose que la source. Dates, filtres, blending, champs calculés, agrégations ou fraîcheur des données peuvent tout fausser. Je vous montre comment isoler l’écart sans partir dans tous les sens.

Que compare-t-on vraiment ?

On compare rarement deux chiffres identiques, même quand ils portent le même nom dans Looker Studio. C’est ça le piège. Une métrique “revenu”, “session”, “conversion” ou “clic” peut changer selon la source, le connecteur, le filtre, la date, l’agrégation ou la formule utilisée dans le graphique.

J’appelle ça une métrique conflictuelle : un chiffre qui semble parler de la même chose, mais qui n’est pas calculé avec les mêmes règles. Et dans un dashboard, ça se voit vite.

• Une scorecard affiche 42 000 € de revenu, mais le tableau détaillé affiche 39 800 €.
• Le revenu Looker Studio ne colle pas avec GA4, Shopify ou le CRM.
• Les dépenses Google Ads doublent après un blending, parce qu’une jointure multiplie les lignes.
• Un taux de conversion change selon le graphique, car le numérateur ou le dénominateur n’est pas le même.
• Les clics, pages vues ou sessions bougent selon le connecteur utilisé.
• Une table Search Console dans Looker Studio ne donne pas exactement les mêmes impressions que l’interface Search Console.

Le danger n’est pas juste technique. Quand deux personnes regardent le même dashboard et ne voient pas le même chiffre, la confiance saute. Et là, les équipes marketing arrêtent de parler décision. Elles parlent du chiffre. Elles cherchent qui a raison, au lieu de décider quoi faire.

Chez un client, on pensait avoir un problème GA4. En fait non. Le rapport mélangeait deux définitions du revenu : d’un côté le revenu produit, de l’autre le revenu payé après remises et remboursements. Les deux chiffres étaient “vrais”. Ils ne répondaient juste pas à la même question.

Découvrez égalementData Studio : quelle édition choisir pour vos rapports ?

Il faut donc distinguer un vrai bug d’une différence de définition. Un bug, c’est une erreur de calcul, une donnée cassée, une jointure qui explose les lignes. Une différence de définition, c’est plus subtil : même nom, mais règles différentes. Looker Studio visualise et transforme les données. Il ne garantit pas que chaque graphique applique les mêmes filtres, les mêmes champs calculés, les mêmes périodes ou la même logique métier.

D’où vient l’écart ?

L’écart vient le plus souvent d’une différence de contexte entre la source et le graphique. Dit autrement, Looker Studio n’invente pas forcément des chiffres faux. Il affiche parfois une métrique qui n’a pas été calculée avec les mêmes règles, la même période, les mêmes filtres ou la même fraîcheur de données.

La première cause, c’est la définition des métriques. Deux sources peuvent utiliser le même mot sans mesurer la même chose. L’exemple classique, c’est Universal Analytics versus GA4. Dans UA, on était sur un modèle basé surtout sur les sessions. Dans GA4, on est sur un modèle basé sur les événements. Même le mot “utilisateur” ne recouvre pas exactement la même réalité selon les réglages, l’identité utilisée, les signaux Google ou les cookies disponibles.

C’est pareil avec “revenu”, “conversion” ou “session”. Une plateforme peut inclure les taxes, une autre non. Une conversion peut être comptée une fois par session ici, plusieurs fois là-bas. Une session peut expirer selon des règles différentes. J’ai déjà vu un client comparer le revenu Shopify avec le revenu GA4 comme si c’était la même colonne. Ce n’était pas le cas, et l’écart était logique.

Ensuite, il y a les plages de dates. Un rapport peut avoir une période globale. Une page peut en avoir une autre. Un graphique peut aussi forcer sa propre période, sans que ce soit visible au premier coup d’œil. Les comparaisons de périodes ajoutent encore du bruit, surtout quand on lit trop vite un scorecard ou un tableau avec “période précédente”.

Découvrez égalementComment exploiter Looker Studio pour analyser vos données ?

Les filtres créent aussi pas mal de confusion. Un filtre peut être appliqué au niveau du rapport, de la page, d’un groupe de graphiques ou d’un graphique seul. Donc non, un filtre n’est pas forcément appliqué partout. C’est une source très classique d’incompréhension.

Il faut aussi regarder les connecteurs, les identifiants et la fraîcheur des données. Les connecteurs Google, les connecteurs tiers et les connexions API peuvent échouer, perdre des droits ou remonter des données partielles. La fraîcheur dépend du connecteur, du cache, des exports programmés, de l’entrepôt de données, de Google Sheets ou d’une API tierce. Et parfois, c’est juste un schéma qui a bougé : champ renommé, type modifié, mapping cassé.

• Vérifiez que la source utilisée par le graphique est bien celle attendue.
• Comparez la définition exacte de la métrique dans chaque outil.
• Contrôlez la plage de dates du rapport, de la page et du graphique.
• Regardez si une comparaison de période est activée.
• Listez les filtres appliqués au rapport, à la page, au groupe et au graphique.
• Testez la fraîcheur des données et le dernier rafraîchissement du connecteur.
• Vérifiez les droits, les identifiants et les erreurs de connexion.
• Contrôlez les champs renommés, les types modifiés et les mappings cassés.

Le blending fausse-t-il les chiffres ?

Le blending peut fausser les chiffres dès que les clés de jointure ne sont pas assez propres ou pas au bon niveau de granularité. Je le vois souvent : le rapport a l’air cohérent, les graphiques chargent bien, mais les totaux partent doucement dans le décor.

Dans Looker Studio, un blend combine plusieurs sources autour de clés de jointure, de dimensions et de métriques. Dit simplement, on demande à l’outil de rapprocher deux tables qui ne viennent pas forcément du même endroit. Le piège arrive quand les données ne sont pas au même grain. Le grain, c’est le niveau de détail d’une ligne. Une ligne par campagne côté dépenses Google Ads, mais plusieurs lignes par date, device ou page côté résultats, et vos dépenses peuvent être répétées plusieurs fois.

Les erreurs classiques sont assez faciles à reconnaître :

• Dépenses Google Ads dupliquées parce qu’une campagne est jointe à plusieurs lignes Analytics.
• Clics multipliés quand la clé ne distingue pas la date ou le device.
• Conversions gonflées parce qu’un revenu est répété sur plusieurs pages.
• Pages vues surcomptées quand on joint seulement sur l’URL sans date.
• Revenus répétés quand une transaction est reliée à plusieurs événements.

Découvrez égalementQu'est-ce que Google Looker Studio et pourquoi l'utiliser ?

Les clés faibles font beaucoup de dégâts. Campagne seule au lieu de campagne + date. Page seule sans date. Source medium sans identifiant de campagne. Ça marche techniquement, mais ça ne veut pas dire que le résultat est juste.

Looker Studio propose plusieurs types de jointure : left outer, right outer, inner, full outer et cross join. Pas besoin de jargon SQL ici. L’idée à retenir, c’est de vérifier quelle table porte le bon niveau de détail. Si votre table de gauche est trop agrégée et votre table de droite trop détaillée, les métriques de gauche risquent d’être répétées.

Il faut aussi regarder les champs calculés. Un champ calculé au niveau de la source de données peut donner un résultat différent du même champ calculé au niveau du graphique. Même nom, logique proche, résultat différent. Surtout avec les taux de conversion, le bounce rate ou les métriques d’engagement.

Somme, moyenne, count et count distinct ne racontent pas la même histoire. Une moyenne de taux par campagne n’est pas égale à un taux recalculé sur le total. C’est bête, mais c’est une des causes les plus fréquentes d’écarts.

Comment auditer sans se perdre ?

Il faut repartir de la source d’origine, puis isoler une seule métrique, une seule période et un seul graphique. Sinon, on audite tout à la fois, et là c’est le meilleur moyen de se raconter des histoires.

Je commence toujours par comparer Looker Studio à la plateforme source. GA4, Search Console, Google Ads, Shopify, le CRM, peu importe. Je prends exactement la même plage de dates, la même devise si on parle de chiffre d’affaires, les mêmes filtres, le même pays, le même canal, le même périmètre. Puis je note l’écart. Pas “ça semble différent”. Un vrai écart. Par exemple : Looker affiche 12 430 sessions, GA4 affiche 12 910 sessions, donc j’ai -3,7 % côté Looker.

Ensuite je remonte le fil, calmement. Je vérifie d’abord la plage de dates du rapport, puis celle de la page, puis celle du graphique. Looker Studio peut appliquer des dates à plusieurs niveaux, et c’est souvent là que ça part de travers. Après, je contrôle la source de données attachée au graphique. Ça paraît bête, mais j’ai déjà vu un client comparer un graphique branché sur une vue GA4 de test avec un autre branché sur la propriété principale.

Je désactive temporairement les filtres. Tous. Puis je regarde les segments, les conditions, les exclusions, les filtres de contrôle utilisateur. Je veux savoir si le chiffre brut colle avant de chercher plus loin. Si le graphique utilise du blending, donc un mélange de plusieurs sources, je l’inspecte tout de suite. La clé de jointure, par exemple la date, l’URL ou l’ID client, peut créer des doublons ou supprimer des lignes sans prévenir.

Après ça, j’ouvre les champs calculés. Je vérifie les formules, les divisions, les conditions, les conversions de devise. Je regarde aussi l’agrégation de chaque métrique : somme, moyenne, nombre distinct, auto. Une métrique mal agrégée peut transformer un KPI fiable en chiffre complètement bancal. Je contrôle les identifiants du connecteur, surtout si plusieurs comptes Google ou outils SaaS sont utilisés. Puis je vérifie la fraîcheur des données. Certaines sources ne sont pas à jour en temps réel. Dernier point, je cherche un changement de schéma ou de type de champ : une date devenue texte, un montant passé en chaîne de caractères, une colonne renommée.

Mon astuce terrain : je duplique la page du rapport et je travaille sur une version de test. Comme ça, je casse ce que je veux sans toucher au dashboard de production. Et très souvent, un tableau brut avec date, clé de jointure et métrique aide plus qu’un graphique joli. Le graphique raconte, le tableau révèle.

• Comparer Looker Studio à la source d’origine.
• Utiliser exactement la même plage de dates.
• Vérifier la devise, les filtres et le périmètre analysé.
• Isoler une seule métrique, une seule période et un seul graphique.
• Contrôler les dates au niveau rapport, page et graphique.
• Vérifier la source de données attachée au graphique.
• Désactiver temporairement tous les filtres.
• Regarder les segments, conditions et exclusions.
• Inspecter le blending et la clé de jointure.
• Ouvrir les champs calculés et relire les formules.
• Vérifier l’agrégation de chaque métrique.
• Contrôler le compte ou l’identifiant utilisé par le connecteur.
• Vérifier la fraîcheur des données.
• Chercher un changement de schéma ou de type de champ.
• Travailler sur une page dupliquée avant de modifier la production.

Comment éviter que ça revienne ?

On évite que ça revienne en documentant les définitions, en verrouillant les calculs et en testant les rapports comme un produit de données. Looker Studio est souvent utilisé comme un outil rapide, et c’est très bien pour explorer. Mais dès qu’un dashboard sert à piloter du budget, du SEO, du CRM ou du e-commerce, il mérite un minimum de gouvernance. Pas une usine à gaz. Juste quelques règles propres.

Ce que je vois souvent chez les clients, c’est le même problème qui revient sous des formes différentes. Deux personnes pensent regarder le même chiffre, mais l’une utilise “sessions”, l’autre “sessions filtrées hors marque”, et personne ne l’a écrit quelque part. Le dashboard n’est pas faux. Il est ambigu.

Je garde quelques réflexes simples pour limiter ça :

• Créer une source de données de référence quand c’est possible, plutôt que laisser chaque rapport recréer ses propres champs.
• Centraliser les champs calculés importants au bon endroit. Un taux de conversion, un ROAS ou une marge doivent avoir une seule définition.
• Nommer clairement les métriques. “CA net hors taxes” vaut mieux que “Revenue 2”. Ça évite les débats inutiles en réunion.
• Éviter deux champs avec le même nom mais une formule différente. C’est le genre de détail qui casse la confiance très vite.
• Documenter les filtres permanents, comme l’exclusion du trafic interne, d’un pays, d’une marque ou d’un canal.
• Noter les plages de dates particulières, surtout quand un score compare une période glissante avec une période fixe.
• Limiter les blends fragiles. Un blend, c’est une jointure entre plusieurs sources dans Looker Studio. C’est pratique, mais dès que la clé de jointure n’est pas propre, les chiffres dérapent.
• Préparer les données en amont dans BigQuery, Sheets propre ou une table métier quand les jointures deviennent critiques.
• Surveiller les accès connecteurs. Un compte Google Ads déconnecté ou un droit GA4 retiré peut suffire à casser un rapport.
• Vérifier régulièrement la fraîcheur des données. Un chiffre juste mais pas mis à jour depuis cinq jours, ça reste un mauvais chiffre.

L’impact business est très concret. Si les chiffres ne sont pas fiables, les budgets pub peuvent partir sur les mauvais canaux, les arbitrages SEO peuvent privilégier les mauvaises pages, les campagnes CRM peuvent cibler les mauvais segments, et les priorités e-commerce peuvent être décidées sur du bruit.

Un dashboard fiable, ce n’est pas un dashboard plus complexe. C’est un dashboard avec moins d’ambiguïtés.

On corrige quoi en premier maintenant ?

Je commencerais toujours par le plus simple : comparer une métrique Looker Studio à sa source, sur la même période, avec les mêmes filtres. Ensuite seulement je regarde le blending, les champs calculés, les agrégations, les connecteurs, la fraîcheur et le schéma. Dans la majorité des cas que je vois, le problème n’est pas un gros bug mystérieux. C’est une règle différente appliquée quelque part dans le rapport. Une fois ces règles rendues visibles, le dashboard redevient utile. Vous gagnez du temps, vous récupérez la confiance des équipes et vos décisions business reposent sur des chiffres défendables.

FAQ

• Pourquoi Looker Studio n’affiche pas les mêmes chiffres que GA4 ?
  Le plus souvent, Looker Studio et GA4 ne sont pas configurés avec le même contexte. La plage de dates, les filtres, les dimensions, les champs calculés ou l’agrégation peuvent changer le résultat. Il faut comparer une métrique précise, sur la même période, avec les mêmes conditions.
• Pourquoi une scorecard et un tableau donnent deux totaux différents ?
  Une scorecard et un tableau peuvent utiliser des filtres, des dimensions, des plages de dates ou des règles d’agrégation différentes. Même si la métrique porte le même nom, le graphique peut la recalculer dans un contexte différent.
• Le blending dans Looker Studio peut-il dupliquer les données ?
  Oui, surtout si les clés de jointure ne sont pas uniques ou si les sources ne sont pas au même niveau de granularité. Une jointure trop large peut multiplier les dépenses, les clics, les conversions ou les revenus.
• Comment vérifier si un champ calculé fausse une métrique ?
  Je vérifie où le champ est créé, au niveau de la source ou du graphique, puis je compare sa formule avec la définition attendue. Deux champs peuvent avoir le même nom mais une logique différente. Il faut aussi contrôler l’agrégation utilisée.
• Quelle est la première action quand un chiffre Looker Studio ne colle pas ?
  Je repars de la source d’origine. Je prends une seule métrique, une seule période, les mêmes filtres, puis je compare. Si l’écart reste présent, j’audite ensuite la source de données, les filtres, le blending, les champs calculés, les agrégations, le connecteur et la fraîcheur des données.

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des équipes sur le tracking avancé server-side, l’analytics engineering, Looker Studio, GA4, l’automatisation no low code avec n8n, l’IA appliquée au business et le SEO GEO. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vos dashboards ne sont plus fiables ou si vous voulez remettre de l’ordre dans vos données, contactez-moi, je peux vous aider.

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.