Comment nettoyer ses données marketing dans BigQuery ?

Résumer ce contenu avec :

Perplexity ChatGPT Claude Grok Mistral

En créant une couche propre entre les données brutes et vos dashboards. BigQuery doit standardiser, dédupliquer et contrôler vos sources avant Looker Studio. Sinon, vous obtenez un beau reporting faux, et c’est souvent là que les mauvaises décisions commencent.

C’est quoi une donnée marketing sale ?

Une donnée marketing sale, c’est une donnée qui existe, mais qui est trop incohérente pour servir correctement au reporting et à la décision.

Le piège, c’est de croire que le problème vient seulement des valeurs vides. Oui, un nom de campagne manquant, c’est gênant. Mais dans BigQuery, quand vous connectez GA4, Google Ads, Microsoft Ads, Campaign Manager, votre CRM, l’emailing, l’ecommerce, le POS et les ventes offline, le vrai sujet devient vite l’alignement.

Je vois souvent les mêmes problèmes chez les clients. Des lignes dupliquées parce qu’un export a tourné deux fois. Des conversions comptées dans GA4 puis recollées depuis le CRM. Des coûts Google Ads en euros, des coûts Meta en centimes, ou des montants importés sans devise. Des revenus ecommerce qui ne matchent pas les revenus offline. Des dates en UTC d’un côté, en heure locale de l’autre, et là votre lundi ne raconte plus la même histoire selon la source.

Le cas le plus simple, c’est le canal payé social. Dans une table, il remonte sous facebook. Dans une autre sous Facebook. Ailleurs sous fb, meta ou paid_social. Ça a l’air cosmétique, mais ça ne l’est pas. BigQuery ne devine pas que tout ça représente le même canal. Résultat, vos performances sont fragmentées, votre ROAS semble plus faible ou plus fort selon le filtre, et vos arbitrages budget deviennent moins fiables.

Les UTM ajoutent une couche de bazar. Un medium peut être cpc, paid, paid-social ou social_paid. Une source peut dire newsletter alors que le medium dit cpc. Les jointures cassent parce que les IDs de campagne ne sont pas au même format. Et parfois, la structure des campagnes est illisible, avec des noms du type FR_Traffic_Test_New_2_Bis, sans pays, objectif ou audience exploitable.

Pourquoi nettoyer avant Looker Studio ?

Looker Studio affiche les données, il ne répare pas une base marketing incohérente. C’est vraiment le point à garder en tête. Un dashboard peut être beau, lisible, bien filtré, avec des graphiques propres… et raconter n’importe quoi si les données dans BigQuery sont déjà fausses.

Looker Studio est une couche de visualisation. Il prend ce qu’on lui donne. Si une campagne Google Ads est dupliquée dans une table, si une jointure multiplie les lignes, si GA4 remonte des conversions différentes du CRM, le rapport va juste afficher cette incohérence avec de jolies couleurs. Et c’est là que ça devient dangereux, parce qu’un chiffre faux mais bien présenté inspire souvent plus confiance qu’un fichier brut plein d’erreurs visibles.

Les conséquences arrivent vite, surtout en marketing où les décisions sont liées au budget. Voilà ce que je vois le plus souvent quand la donnée n’est pas nettoyée avant d’arriver dans Looker Studio :

• Des dépenses média gonflées parce qu’une même ligne de coût est comptée plusieurs fois.
• Des revenus manquants parce que certaines transactions ecommerce ne matchent pas avec les campagnes.
• Des conversions comptées deux fois entre GA4, Google Ads et le CRM.
• Un mauvais mix de canaux, avec du budget déplacé vers les mauvaises sources.
• Une attribution instable, qui change selon le rapport ou la jointure utilisée.
• Des campagnes injustement valorisées ou pénalisées alors que le problème vient de la donnée.

J’ai souvent vu des équipes passer des heures à chercher le bug dans Looker Studio. Elles changent les dimensions, les filtres, les champs calculés, les plages de dates. Puis on ouvre BigQuery, et la vraie casse est dans les tables sources, dans les exports, ou dans une jointure trop large qui multiplie les conversions. C’est frustrant, mais au moins c’est concret.

L’objectif, c’est d’avoir une version unique de la vérité. Pas une vérité parfaite, ça n’existe pas vraiment en marketing. Mais une base cohérente, documentée, stable, sur laquelle tout le monde peut s’aligner.

Une base propre doit permettre de répondre sans débat interminable à des questions simples : quels canaux génèrent vraiment du revenu, quelles campagnes gaspillent le budget, quelles audiences convertissent, quelles landing pages sous-performent, est-ce que Google Ads, GA4, le CRM et l’ecommerce racontent à peu près la même histoire, et est-ce qu’une rupture de tracking se voit rapidement.

Avant de corriger quoi que ce soit, il faut déjà savoir repérer les signaux faibles. Les petits écarts, les chiffres qui bougent bizarrement, les ruptures discrètes. C’est souvent là qu’on voit que la donnée est déjà bancale.

Quels signaux doivent alerter ?

Les signaux apparaissent souvent quand le dashboard est déjà en production, quand quelqu’un dit “Les chiffres ne collent pas”. Mais dans la plupart des cas, ils étaient déjà visibles dans BigQuery. Il suffisait de regarder les bons symptômes avant de brancher Looker Studio, Power BI ou Tableau.

Le premier signal, c’est l’incohérence des noms de canaux. Un même canal paid social peut arriver sous plusieurs formes : paid social, Paid Social, facebook paid, meta_ads, social_paid. Sur le papier, ça a l’air bénin. En réalité, ça casse l’analyse multi-canal. Vous pensez comparer SEO, SEA, paid social et email, mais une partie du budget Meta est cachée dans un autre libellé. Le mix marketing devient faux, et les arbitrages aussi.

Le deuxième signal, c’est le nom des campagnes qui ne s’aligne pas entre Google Ads, Microsoft Ads, Campaign Manager, les UTMs, GA4 et le CRM. J’ai déjà vu un simple renommage dans Google Ads créer trois semaines d’écarts dans les rapports. La campagne avait changé de nom côté plateforme, mais pas dans les UTMs ni dans le CRM. Résultat : Des conversions impossibles à rattacher, des revenus qui tombent dans “unknown”, et des reportings cross-channel qu’on ne peut plus réconcilier proprement.

Le troisième signal, ce sont les lignes dupliquées. Un chargement multiple, un connecteur mal configuré, une table alimentée deux fois, et vos dépenses, clics, revenus ou conversions gonflent sans bruit. Là, je demande toujours des contrôles simples avant de discuter attribution ou performance.

• Comparer le nombre de lignes par source et par date.
• Vérifier les clés attendues, comme date, source, campaign, medium, ad_id ou transaction_id.
• Contrôler les dates d’ingestion pour repérer un reload involontaire.
• Repérer les variations anormales d’un jour à l’autre.

Comment créer une couche propre ?

Il faut créer une couche de transformation entre les tables brutes et les tables utilisées par les rapports. Je garde toujours les données brutes intactes dans BigQuery, parce qu’elles servent de référence en cas de doute. Mais je ne les connecte pas directement à Looker Studio quand elles mélangent Google Ads, Meta Ads, GA4, CRM, emailing et fichiers manuels. C’est là que les erreurs deviennent invisibles.

Le plus simple, c’est d’organiser BigQuery avec une logique claire, sans monter une usine à gaz.

Cette couche peut être faite avec des vues, des requêtes planifiées ou des tables matérialisées. Une vue recalcule le résultat à la demande. Une requête planifiée écrit une table à intervalle régulier. Une table matérialisée garde un résultat optimisé pour aller plus vite. Le choix dépend surtout du volume, du coût accepté et du besoin de performance dans les dashboards.

Dans cette couche, je mets les règles qui évitent les débats sans fin en réunion. Par exemple :

• Standardiser les noms de campagnes, surtout quand chaque équipe nomme les choses à sa façon.
• Uniformiser les UTMs, c’est-à-dire les paramètres utilisés pour suivre les campagnes dans les URLs.
• Normaliser source et medium, pour éviter d’avoir “Facebook”, “facebook”, “fb” et “Meta” dans quatre lignes différentes.
• Supprimer les doublons, notamment après des exports ou des imports API incomplets.
• Aligner les dates et les fuseaux horaires, parce qu’un clic à 23h peut vite changer de journée selon la source.
• Valider les coûts et les revenus, avec des contrôles simples sur les valeurs nulles, négatives ou anormales.
• Vérifier les jointures, pour ne pas dupliquer les ventes ou perdre des campagnes.
• Créer des règles de regroupement de canaux, comme Paid Search, Paid Social, Email, Organic ou Direct.
• Préparer des tables propres pour Looker Studio, avec uniquement les champs utiles au reporting.

Un exemple très simple de normalisation de canal peut ressembler à ça. Ce n’est pas une règle complète, juste une base pédagogique.

SELECT
  campaign_name,
  source,
  medium,
  CASE
    WHEN LOWER(TRIM(source)) IN ('google', 'google ads')
      AND LOWER(TRIM(medium)) IN ('cpc', 'paid', 'paid_search')
      THEN 'Paid Search'

    WHEN LOWER(TRIM(source)) IN ('facebook', 'meta', 'instagram')
      AND LOWER(TRIM(medium)) IN ('cpc', 'paid', 'paid_social')
      THEN 'Paid Social'

    WHEN LOWER(TRIM(medium)) = 'email'
      THEN 'Email'

    ELSE 'Other'
  END AS channel_group
FROM staging_marketing_traffic;

Cette couche propre devient le contrat de confiance entre la data marketing et le reporting. Les sources peuvent rester imparfaites, c’est normal. Mais les dashboards, eux, doivent raconter une histoire stable, cohérente et vérifiable.

Quelles règles appliquer dans BigQuery ?

Les bonnes règles dans BigQuery, ce sont celles qui rendent vos données comparables, auditables et réutilisables dans tous vos dashboards. Pas celles qui font joli dans une requête SQL. Celles qui évitent les “pourquoi Meta ne matche pas avec Looker Studio ?” le lundi matin.

Je commence toujours par la standardisation. Même source, même écriture, même logique. Ça paraît basique, mais j’ai vu des dashboards exploser juste parce qu’on avait “facebook”, “Facebook Ads”, “fb” et “meta” dans la même colonne.

La déduplication vient juste après. Je définis une clé fonctionnelle selon la source, pas une règle magique valable partout. Pour une ligne de coût média, ça peut être date + campaign_id + ad_id + source. Pour un lead CRM, ça peut être email normalisé + date de création + formulaire. L’idée, c’est de contrôler les imports répétés, surtout avec les connecteurs qui rejouent parfois les mêmes lignes.

Je ne supprime presque jamais les doublons sans trace. Je préfère isoler les lignes suspectes dans une table à part, avec un motif d’exclusion. C’est moins “propre” en apparence, mais ça sauve des heures de débat quand les chiffres changent. On peut dire exactement ce qui a été exclu, pourquoi, et quand.

L’alignement est le point le plus sous-estimé. Les dates doivent parler le même langage, avec le bon fuseau horaire. Les coûts doivent être dans la bonne devise. Les revenus doivent venir de la même définition métier. Une conversion GA4, un lead CRM et une commande ecommerce, ce n’est pas automatiquement la même chose.

Les jointures aussi méritent de l’attention. Une jointure cassée entre les campagnes et le CRM peut faire disparaître du revenu. Une mauvaise clé peut attribuer une conversion Google Ads à l’emailing. Et là, le dashboard devient dangereux parce qu’il a l’air propre.

• Sources auditées et connues.
• UTMs nettoyés et standardisés.
• Campagnes alignées avec une convention claire.
• Doublons détectés, traités et tracés.
• Coûts validés par source et par devise.
• Revenus cohérents avec le CRM ou l’ecommerce.
• Règles de canaux documentées noir sur blanc.
• Table finale testée avant connexion à Looker Studio.

Et si vos dashboards arrêtaient enfin de vous mentir ?

Nettoyer les données marketing dans BigQuery, ce n’est pas une coquetterie de data team. C’est la base si vous voulez piloter vos campagnes avec des chiffres fiables. Les problèmes viennent souvent de petites incohérences : un canal écrit de trois façons, une campagne renommée à moitié, une ligne chargée deux fois, une date mal alignée. Looker Studio ne corrigera pas ça. La bonne approche, c’est une couche propre entre les données brutes et le reporting, avec des règles claires, testées et documentées. Le bénéfice pour vous est simple : moins de doutes, moins de débats, de meilleures décisions marketing.

FAQ

• Pourquoi mes données BigQuery et Looker Studio ne correspondent pas ?
  Le problème vient souvent des données avant le dashboard : doublons, dates différentes, jointures cassées, UTMs incohérents ou règles de canaux absentes. Looker Studio affiche ce qu’on lui donne. Si la table BigQuery est bancale, le rapport le sera aussi.
• Faut-il nettoyer les données dans Looker Studio ou dans BigQuery ?
  Je préfère nettoyer dans BigQuery. C’est plus robuste, plus réutilisable et plus facile à contrôler. Looker Studio peut faire quelques ajustements d’affichage, mais il ne doit pas devenir l’endroit où on répare toute l’infrastructure data.
• Quels sont les premiers contrôles à faire sur des données marketing ?
  Je commence par les doublons, les noms de campagnes, les valeurs source et medium, les UTMs, les dates, les coûts, les revenus et les jointures avec le CRM ou l’ecommerce. Ces contrôles détectent déjà une grande partie des écarts visibles dans les dashboards.
• Comment éviter les noms de canaux incohérents ?
  Il faut créer une règle de mapping claire. Par exemple, facebook, fb, meta et paid_social peuvent être regroupés dans un canal unique si c’est votre convention. Le plus important, c’est que la règle soit appliquée dans BigQuery avant le reporting.
• Une couche de nettoyage BigQuery est-elle utile pour une petite équipe ?
  Oui, même avec peu de sources. Dès que vous mélangez GA4, Google Ads, un CRM ou une plateforme ecommerce, les écarts arrivent vite. Une couche propre évite de reconstruire les mêmes corrections dans chaque dashboard et sécurise vos décisions marketing.

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’Analytics Engineering, BigQuery, GA4, l’automatisation no code et low code avec n8n, l’IA appliquée au business et le SEO/GEO. J’ai travaillé avec des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez fiabiliser vos données marketing, vos dashboards ou vos automatisations, je peux vous aider. Contactez-moi.

Franck Scandolera

⭐ Expert et formateur en Tracking avancé, Analytics Engineering et Automatisation IA (n8n, Make) ⭐

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

Mon terrain de jeu :

Data & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, 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.