Construire un mini data warehouse marketing avec n8n et BigQuery

Un rapport hebdomadaire envoyé sur Slack répond à une question : « comment se sont comportées mes campagnes cette semaine ? ». Mais dès que la question devient « quelle est l'évolution du CPA sur les six derniers mois, par plateforme et par mois ? », un fichier Google Sheets qui s'allonge ou une table Supabase pensée pour de la journalisation transactionnelle montrent vite leurs limites : les agrégations sur de gros historiques deviennent lentes, et personne ne construit de tableau de bord fiable sur une feuille de calcul qui change de format à chaque campagne. Le node Google BigQuery de n8n permet d'écrire directement dans un véritable entrepôt de données analytique, conçu pour ce cas précis — et de le brancher ensuite sur un dashboard qui se met à jour tout seul.

Pourquoi un tableur ou une base transactionnelle ne suffisent plus au bout de quelques mois

Une étude de Raymond, Brisoux et Azami, Une étude empirique des systèmes d'information marketing dans les PME manufacturières (Revue internationale P.M.E., 2000 — voir sur Google Scholar), menée auprès de 54 PME québécoises, montre que la qualité de la collecte et de la diffusion de l'information marketing influence directement la qualité des décisions prises et, in fine, la performance de l'entreprise. Le constat vaut encore aujourd'hui : une donnée éparpillée entre plusieurs Google Sheets, plusieurs comptes publicitaires et plusieurs formats n'est pas exploitable, quelle que soit sa qualité brute. Centraliser cette donnée dans un entrepôt unique, interrogeable en SQL, est la condition pour qu'elle serve réellement à décider — pas seulement à archiver.

C'est exactement le rôle d'un data warehouse comme BigQuery : un moteur pensé pour scanner des colonnes entières sur des mois d'historique en quelques secondes, là où un tableur rame et où une base transactionnelle comme Postgres, optimisée pour des lectures/écritures ligne par ligne, n'est pas taillée pour ce type de calcul.

Le node Google BigQuery dans n8n : Insert et Execute Query

Le node natif propose deux opérations, sur le même principe de séparation que le node Postgres :

• Insert : ajoute des lignes dans une table existante, en mappant les champs de vos items sur les colonnes du schéma BigQuery. Le chemin le plus simple pour archiver le résultat d'un workflow de reporting sans écrire une ligne de SQL.
• Execute Query : exécute n'importe quelle requête SQL BigQuery — création de table, agrégation, MERGE pour un upsert, DELETE conditionnel. Indispensable dès que le besoin dépasse l'ajout simple.

Les credentials nécessitent un projet Google Cloud avec l'API BigQuery activée, et un compte de service (service account) au format JSON — pas votre compte Google personnel, pour les mêmes raisons de moindre privilège détaillées dans notre guide sur la sécurisation des credentials API dans n8n. Un rôle BigQuery Data Editor limité au dataset concerné (plutôt que Owner au niveau du projet) suffit pour écrire et lire les tables du workflow.

Modéliser une table de faits marketing

Avant de brancher quoi que ce soit, un schéma simple évite de tout reconstruire plus tard. Une table de faits classique, partitionnée par date pour que BigQuery ne scanne que les jours interrogés :

CREATE TABLE `mon_projet.marketing.metriques_quotidiennes` (
  date_metrique DATE,
  plateforme STRING,      -- "google_ads", "meta_ads", "search_console"
  campagne STRING,
  depense FLOAT64,
  clics INT64,
  conversions INT64,
  cpa FLOAT64
)
PARTITION BY date_metrique;

Une ligne par plateforme, par campagne et par jour : c'est le grain le plus fin qui reste utile pour du reporting marketing, et il permet ensuite n'importe quelle agrégation (par semaine, par mois, toutes plateformes confondues) sans avoir à ré-ingérer la donnée source.

Alimenter la table depuis vos workflows n8n existants

Si vous avez déjà mis en place le workflow décrit dans notre guide sur le reporting Google Ads et Meta Ads automatisé, l'ajout tient en un node : à la sortie du node Code qui consolide les métriques des deux plateformes dans un format commun, un node Google BigQuery en opération Insert écrit chaque ligne dans la table de faits, en plus (ou à la place) de l'envoi Slack hebdomadaire. Même principe pour les données de Search Console : la requête API renvoie déjà des lignes datées, prêtes à être insérées telles quelles avec plateforme = "search_console".

Pour une migration progressive, un export ponctuel depuis un Google Sheets existant fonctionne aussi : un node Google Sheets en lecture, suivi d'un node Code qui reformate les colonnes vers le schéma cible, puis l'Insert BigQuery. Utile pour rapatrier un historique déjà accumulé avant de basculer la collecte en direct.

Écrire sans doublons : le vrai piège de BigQuery

L'opération Insert n'a pas de notion d'upsert ni de contrainte d'unicité — contrairement à Postgres, BigQuery n'impose pas de clé primaire appliquée au niveau du moteur. Un workflow rejoué deux fois sur la même journée insère deux fois les mêmes lignes, silencieusement. Le pattern fiable, comme pour n'importe quel webhook rejouable (voir notre guide sur l'idempotence des webhooks), consiste à traiter l'écriture comme un remplacement plutôt qu'un ajout aveugle :

DELETE FROM `mon_projet.marketing.metriques_quotidiennes`
WHERE date_metrique = @date_cible AND plateforme = @plateforme;

exécuté en Execute Query juste avant l'Insert, avec la date et la plateforme du lot en cours comme paramètres. Alternative plus élégante pour un flux à fort volume : un MERGE unique qui combine suppression et insertion en une seule requête atomique, à écrire directement en SQL libre.

Interroger : agrégations SQL et dashboard Looker Studio

Une fois la table alimentée, une requête d'agrégation dans un node Execute Query répond en une fraction de seconde à des questions qu'un tableur peinerait à formuler :

SELECT
  DATE_TRUNC(date_metrique, MONTH) AS mois,
  plateforme,
  SUM(depense) AS depense_totale,
  SUM(conversions) AS conversions_totales,
  SAFE_DIVIDE(SUM(depense), SUM(conversions)) AS cpa_moyen
FROM `mon_projet.marketing.metriques_quotidiennes`
GROUP BY mois, plateforme
ORDER BY mois DESC;

Le résultat peut repartir dans n8n (email, Slack, Google Sheets) exactement comme n'importe quelle sortie de node. Mais l'intérêt principal d'un vrai entrepôt est ailleurs : Looker Studio, l'outil de dashboard gratuit de Google, se connecte nativement à BigQuery comme source de données. Un tableau de bord construit une fois — courbes de dépense, CPA par plateforme, comparaison mensuelle — se met ensuite à jour tout seul à chaque insertion de n8n, sans export manuel ni fichier à renvoyer par email.

Combien ça coûte réellement

BigQuery inclut un palier gratuit permanent, hors crédit d'essai : environ 10 Go de stockage et 1 To de données traitées en requêtes chaque mois. Pour un historique de reporting marketing de quelques comptes publicitaires — quelques dizaines de milliers de lignes par an dans le schéma ci-dessus — ce palier couvre largement l'archivage et les requêtes de dashboard habituelles. Le stockage au-delà de ce palier reste de l'ordre de quelques centimes par Go et par mois ; c'est surtout le volume de données scannées par des requêtes mal écrites (un SELECT * sur une table non partitionnée, répété plusieurs fois par jour) qui peut faire grimper la facture. Filtrer systématiquement sur la colonne de partition (date_metrique) dans le WHERE de chaque requête est le réflexe qui évite l'essentiel des mauvaises surprises.

BigQuery ou Postgres/Supabase : lequel choisir

Les deux ont leur place dans une même architecture n8n, et ne se substituent pas l'un à l'autre :

• Postgres/Supabase reste le bon choix pour une piste d'audit ou tout ce qui ressemble à une base applicative : événements individuels, lectures et écritures fréquentes, contraintes relationnelles strictes, besoin de mettre à jour une ligne précise.
• BigQuery est pensé pour l'analytique sur de gros volumes historiques : agrégations sur des mois ou des années de données, dashboards qui interrogent des millions de lignes, colonnes scannées plutôt que lignes récupérées une à une.

Un même workflow n8n peut très bien écrire l'événement individuel dans Supabase pour la traçabilité, et sa version agrégée dans BigQuery pour l'analytique — les deux nodes cohabitent sans conflit dans le même canvas.

Pièges fréquents

• Confondre Insert et upsert : sans DELETE préalable ni MERGE, un workflow rejoué duplique silencieusement les lignes déjà écrites.
• Oublier la partition dans les requêtes : un Execute Query sans filtre sur date_metrique scanne toute la table à chaque exécution, même pour ne récupérer qu'un seul jour.
• Utiliser un compte de service avec un rôle Owner au niveau du projet Google Cloud plutôt qu'un rôle Data Editor limité au dataset marketing.
• Mélanger les devises ou les fuseaux horaires entre plateformes avant l'insertion : la normalisation doit avoir lieu dans le node Code de consolidation, jamais après coup dans le dashboard.

Pour aller plus loin

Ce principe — collecter dans des workflows dédiés, normaliser dans un node Code, archiver dans un entrepôt interrogeable, restituer via un dashboard qui se met à jour seul — prolonge directement l'approche des workflows d'audit et de synthèse du Pack Conformité & Audit (149 €), qui journalise déjà chaque événement sensible dans Supabase. Ajouter BigQuery en aval ne remplace pas cette piste d'audit : cela lui donne une couche analytique que le format transactionnel n'est pas conçu pour offrir.