BigQuery + Google Ads data pipeline 2026 : construire son data warehouse de reporting

Toute opération Google Ads sérieuse finit par dépasser l'interface plateforme et les tableurs exportés. Les questions de reporting qui comptent le plus — quel est mon vrai coût par deal closed-won, quelles campagnes génèrent des sessions qui convertissent 60 jours plus tard, comment Google, GA4 et le CRM se réconcilient — ne peuvent pas être répondues dans Google Ads parce que les données vivent dans trois systèmes différents. Un entrepôt de reporting BigQuery est la façon dont les équipes analytics résolvent cela en 2026, et Google a rendu l'accès dramatiquement plus facile avec le Data Transfer Service géré.

Ceci est un tutoriel pratique pour analystes et ingénieurs. Nous construirons le pipeline de bout en bout : provisionner le projet Cloud, configurer le Data Transfer Service, activer l'export GA4, concevoir un schéma en couches, joindre le revenu CRM sur le GCLID, planifier le rafraîchissement quotidien, mettre Looker Studio par-dessus, et garder les coûts BigQuery sous contrôle. Nous supposons une aisance en SQL et une familiarité de base avec Google Cloud. Si vous venez d'une fondation tracking-first, notre guide de configuration et d'import de conversions GA4 est le bon prérequis.

Pourquoi construire un pipeline BigQuery pour Google Ads

L'interface Google Ads est excellente pour gérer les campagnes et faible pour l'analyse inter-systèmes. Trois limites structurelles poussent les équipes vers un entrepôt.

Premièrement, l'écart de revenu. Google Ads sait ce qu'il a dépensé et combien de conversions il a comptées, mais il ne connaît pas votre pipeline closed-won, votre longueur de cycle de vente, ou votre taux de remboursement. Un lead que Google compte comme un événement de conversion à 0 € pourrait devenir un deal entreprise de 40 000 € neuf mois plus tard. Sans joindre le revenu CRM au clic, vous optimisez vers le volume de conversions au lieu du profit — l'échec de reporting le plus courant et le plus coûteux en PPC B2B.

Deuxièmement, le blend cross-canal. L'acquisition moderne tourne sur Google, Meta, LinkedIn et plus. Chaque plateforme reporte dans son propre walled garden avec sa propre attribution. Un entrepôt est le seul endroit pour construire une vue blended unique où le spend et les résultats de chaque canal sont dans la même table avec des définitions cohérentes. Notre guide d'attribution cross-canal couvre la méthodologie ; BigQuery est où vous l'implémentez.

Troisièmement, le plafond d'analyse. Le test d'incrémentalité, la modélisation de la valeur vie client, la rétention de cohortes et le marketing mix modeling exigent tous des données au niveau événement et historiques que l'interface n'expose simplement pas. Un entrepôt avec deux à trois ans d'historique propre est le substrat sur lequel toute technique de mesure avancée repose. Le framework MMM open source propre de Google, couvert dans notre guide Meridian, lit directement depuis BigQuery.

L'économie est favorable. Le Data Transfer Service est gratuit. Les 10 premiers Go de stockage de BigQuery et le premier To de traitement de requêtes chaque mois sont gratuits, et au-delà le stockage tourne à environ 0,02 € par Go par mois et les requêtes à environ 5-6 € par To scanné. Un entrepôt mono-compte bien construit dépasse rarement 150 €/mois et tourne fréquemment sous 50 €. Face au coût d'un spend pub mal alloué, c'est une erreur d'arrondi. L'investissement est du temps d'ingénierie, pas des factures cloud.

Le gain est durable. Une fois le pipeline existant, chaque nouvelle question devient une requête SQL au lieu d'un exercice manuel d'export-et-pivot. Les rapports se rafraîchissent d'eux-mêmes. Les nouveaux canaux se branchent au même schéma. Et la fondation de données se compose : plus l'entrepôt tourne longtemps, plus son historique devient précieux pour la modélisation.

Vue d'ensemble de l'architecture et les trois sources de données

L'architecture de référence est un entrepôt en couches alimenté par trois sources, transformé par du SQL planifié, et fait émerger dans Looker Studio.

Les trois sources de données :

La convention de dataset en couches garde l'entrepôt maintenable et efficace en coût :

• raw_google_ads — exports DTS bruts. Jamais interrogé directement par les rapports. À traiter comme zone d'atterrissage immuable.
• export GA4 brut — les tables events_ que GA4 dépose dans leur propre dataset, partitionnées par date d'événement.
• staging — vues et tables nettoyées et standardisées. Micros convertis en devise, colonnes renommées, doublons de fenêtre de rafraîchissement retirés, date-spine et mapping de compte joints.
• reporting — tables curées et dénormalisées conçues pour les dashboards. C'est la seule couche que Looker Studio touche.

Cette séparation compte pour trois raisons : elle isole les données brutes pour qu'un bug de transformation ne corrompe jamais la source, elle concentre les jointures coûteuses dans les constructions planifiées plutôt que par-rafraîchissement-de-dashboard, et elle vous donne une frontière de permissions propre — les analystes obtiennent un accès lecture à reporting uniquement.

L'orchestration est délibérément simple. Le Data Transfer Service et l'export GA4 tournent sur le planning de Google, déposant des données fraîches chaque matin. Quelques heures plus tard, les requêtes planifiées BigQuery reconstruisent les tables de staging et reporting. Looker Studio lit le résultat. Pas d'orchestrateur externe, pas de serveurs, pas de conteneurs. Vous pouvez passer à dbt et Cloud Composer plus tard, mais vous n'en avez pas besoin pour commencer, et les ajouter prématurément est du sur-engineering.

Une note sur les régions : choisissez un emplacement BigQuery (EU multi-région pour la résidence de données européenne) et utilisez-le pour chaque dataset. Les requêtes cross-région ne sont pas autorisées, donc un décalage d'emplacement entre votre dataset DTS et votre dataset CRM cassera les jointures. Décidez une fois, en amont.

Configurer le Google Ads Data Transfer Service

Le Data Transfer Service (DTS) est la fondation, et c'est réellement quelques clics de configuration plus une attente du backfill.

Prérequis :

• Un projet Google Cloud avec facturation activée
• Les API BigQuery et BigQuery Data Transfer activées
• Un compte Google avec accès lecture au compte Google Ads cible (ou MCC)
• Le customer ID du compte Google Ads (10 chiffres, sans tirets)

Étapes de configuration :

1. Dans la console BigQuery, ouvrez Data transfers et cliquez Create transfer.
2. Choisissez Google Ads comme source.
3. Nommez le transfert, réglez le planning sur quotidien, et choisissez une heure d'exécution tôt le matin.
4. Réglez le dataset de destination sur raw_google_ads.
5. Entrez le Customer ID — utilisez l'ID MCC pour tirer tous les comptes enfants en un seul transfert.
6. Configurez la fenêtre de rafraîchissement (le nombre de jours antérieurs que le DTS re-tire à chaque exécution) pour capter le backfill de conversions et l'attribution tardive.
7. Authentifiez-vous avec un compte ayant l'accès Google Ads nécessaire et enregistrez.

Le DTS créera un ensemble de tables dans raw_google_ads — campaign, ad group, ad group criteria (mots-clés), conversions, et plus — chacune suffixée par date ou partitionnée, selon la table. Le nommage suit le schéma documenté de Google ; gardez cette documentation ouverte comme référence parce que les noms de colonnes sont verbeux et que les tables de stats séparent les métriques des attributs.

Lancez un backfill immédiatement. Un transfert frais ne tire qu'à partir d'aujourd'hui. Pour obtenir de l'historique, déclenchez un backfill manuel pour les 12 derniers mois (ou aussi loin que vous en avez besoin et que le compte le supporte). Les backfills tournent comme une série de jobs quotidiens et peuvent prendre du temps pour de longues plages, mais ils n'ont besoin de tourner qu'une fois.

Validez le premier chargement. Après que l'exécution initiale a complété, faites un contrôle de cohérence : sommez le coût (en micros, puis divisez par 1 000 000) pour une semaine récente et comparez à l'interface Google Ads pour la même fenêtre. De petites différences sont normales à cause de la fenêtre de rafraîchissement d'attribution et des frontières de fuseau horaire, mais les totaux devraient être proches. S'ils sont follement décalés, vérifiez que vous avez sélectionné le bon customer ID et fuseau horaire.

Considérations MCC. Un transfert MCC étiquette chaque ligne avec son customer ID. C'est puissant pour les agences mais multiplie le volume de données. Avec de nombreux comptes, le partitionnement par date et le clustering par customer ID dans votre couche de staging cesse d'être un agrément et devient la différence entre une facture mensuelle de 40 € et de 400 €. Prévoyez-le dès la première table de staging.

Concevoir le schéma BigQuery et la couche de staging

Les tables DTS brutes sont exactes mais inconfortables : coûts en micros, noms de colonnes cryptiques, tables de stats et d'attributs séparées, et chevauchement de fenêtre de rafraîchissement. La couche de staging corrige tout cela une fois pour que les requêtes en aval restent propres.

Transformations de staging de base :

-- staging.campaign_performance_daily
CREATE OR REPLACE TABLE staging.campaign_performance_daily
PARTITION BY date
CLUSTER BY customer_id, campaign_id AS
SELECT
  _DATA_DATE                         AS date,
  customer_id,
  campaign_id,
  campaign_name,
  metrics_cost_micros / 1000000      AS cost,
  metrics_impressions                AS impressions,
  metrics_clicks                     AS clicks,
  metrics_conversions                AS conversions,
  metrics_conversions_value          AS conversion_value
FROM `raw_google_ads.ads_CampaignBasicStats_*` s
JOIN `raw_google_ads.ads_Campaign_*` c USING (campaign_id)
WHERE _DATA_DATE = c._DATA_DATE;

Les spécificités des noms de table varient avec la version du schéma DTS, mais le pattern tient : convertir les micros, renommer en colonnes lisibles, joindre les stats aux attributs, partitionner par date, clusteriser par les colonnes que vous filtrez le plus.

Dédupliquer la fenêtre de rafraîchissement. Parce que le DTS re-tire les jours antérieurs, la même date peut apparaître dans plusieurs chargements d'instantanés. Sélectionnez le dernier instantané par date logique en utilisant une fonction de fenêtre ou en lisant la partition que le DTS marque comme courante. Sauter cette étape double-compte le spend dans vos jours les plus récents — un bug subtil qui érode la confiance dans l'entrepôt.

Tables de support dont vous aurez besoin :

Le partitionnement et le clustering ne sont pas optionnels. Partitionnez chaque table de staging et reporting matérialisée par date. Clusterisez par customer_id et campaign_id (ou ce sur quoi vos rapports filtrent). C'est le levier qui maîtrise le coût : une requête pour le mois dernier contre une table partitionnée par date ne scanne que les octets du mois dernier, pas trois ans d'historique. La différence est souvent de 30x sur un entrepôt mature.

Vues versus tables. Pour les transformations légères, les vues conviennent et n'engagent aucun coût de stockage — mais elles re-scannent les données source à chaque lecture. Pour tout ce qui est interrogé à répétition par les dashboards, matérialisez une table partitionnée via une requête planifiée. La règle générale : transformation pas chère lue une fois égale vue ; transformation coûteuse lue plusieurs fois égale table matérialisée.

Gardez la couche de staging ennuyeuse et déterministe. Elle ne devrait faire qu'un seul travail — transformer les exports DTS et GA4 bruts en briques propres, bien typées et partitionnées — pour que la couche de reporting puisse se concentrer sur les jointures intéressantes.

Joindre les données GA4, Google Ads et CRM

C'est là que l'entrepôt gagne sa place. Trois sources, jointes correctement, répondent à des questions qu'aucune plateforme seule ne peut.

Le GCLID est la colonne vertébrale de l'attribution du revenu. Quand quelqu'un clique une annonce Google avec le marquage automatique activé, Google ajoute un GCLID à l'URL d'atterrissage. Capturez-le dans un champ de formulaire caché, persistez-le dans votre CRM contre le lead, et il devient la clé de jointure entre les clics Google Ads et le revenu closed-won.

-- reporting.campaign_to_revenue
SELECT
  ga.date,
  ga.campaign_name,
  ga.cost,
  ga.conversions,
  COUNT(DISTINCT crm.deal_id)        AS deals_closed,
  SUM(crm.closed_won_amount)         AS crm_revenue,
  SAFE_DIVIDE(ga.cost, SUM(crm.closed_won_amount)) AS cost_to_revenue_ratio
FROM staging.click_with_gclid ga
LEFT JOIN crm.deals crm
  ON ga.gclid = crm.gclid
GROUP BY ga.date, ga.campaign_name, ga.cost, ga.conversions;

Le LEFT JOIN est délibéré : le spend non matché doit rester visible. Si vous faites un inner-join, chaque clic sans deal matché disparaît silencieusement, et votre calcul de coût-par-revenu se flatte lui-même. Gardez tout le spend dans le résultat et traitez le taux de match comme sa propre métrique de santé.

Joindre GA4 pour la profondeur comportementale. L'export GA4 dépose des lignes au niveau événement avec des event_params imbriqués. Unnestez-les pour récupérer la campagne, la qualité de session et la landing page, puis agrégez à la granularité dont vous avez besoin.

-- staging.ga4_sessions (campagne et landing page récupérées depuis event_params)
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS date,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'campaign') AS campaign,
  COUNTIF(event_name = 'session_start') AS sessions,
  COUNTIF(event_name = 'sign_up')       AS signups
FROM `analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20261231'
GROUP BY date, campaign;

Contraignez toujours le _TABLE_SUFFIX GA4 à une plage de dates — les tables d'événements sont grandes et un scan wildcard sans bornes est le piège de coût GA4 classique.

Charger le CRM. Faites entrer les deals dans BigQuery avec ce qui convient à votre stack : un connecteur géré comme Fivetran, une Cloud Function planifiée appelant l'API de votre CRM, ou un chargement CSV nocturne. Les colonnes minimales sont deal ID, GCLID, montant closed-won, date de fermeture, et étape. Rafraîchissez quotidiennement pour que le revenu reste à jour.

Quand la couverture GCLID est mauvaise, les taux de match en souffrent et le revenu paraît sous-estimé. Les fixes en amont sont les enhanced conversions et l'import de conversions hors ligne, qui améliorent tous deux la fiabilité du rattachement des clics aux résultats — voir notre guide de configuration enhanced conversions. Comme repli dans l'entrepôt, une jointure basée sur les UTM récupère certaines lignes non matchées, mais traitez-la comme un complément de moindre confiance, pas un remplacement du GCLID.

L'output de cette section est une table unifiée unique portant côte à côte spend, conversions Google, engagement GA4 et revenu CRM — la table sur laquelle chaque rapport PPC significatif est construit.

Requêtes planifiées et le rafraîchissement quotidien

Avec la logique de staging et de reporting écrite, automatisez la construction quotidienne pour que l'entrepôt se maintienne lui-même.

Les requêtes planifiées natives sont le bon outil de départ. BigQuery vous laisse planifier toute instruction SQL sur une cadence de type cron sans coût supplémentaire au-delà du traitement de requête qu'elle consomme. Planifiez d'abord la construction de staging, puis la construction de reporting, toutes deux calées quelques heures après que le DTS et l'export GA4 complètent généralement le matin. Cet ordre garantit que chaque couche lit des données amont fraîches.

Utilisez les bonnes sémantiques d'écriture :

Pour la plupart du reporting PPC, reconstruire les N dernières partitions avec WRITE_TRUNCATE à portée de ces partitions est l'approche correcte la plus simple — elle absorbe naturellement le backfill de la fenêtre de rafraîchissement DTS sans dupliquer les données plus anciennes.

Ajoutez un contrôle de fraîcheur. Une petite requête planifiée qui compare la date max de chaque table source à aujourd'hui et écrit une alerte (ou échoue bruyamment) attrape le mode d'échec silencieux où le DTS ou l'export GA4 saute un jour et où vos dashboards montrent discrètement des chiffres périmés. Ce seul garde-fou prévient la classe la plus embarrassante d'incident de reporting.

-- monitoring.freshness_check
SELECT
  'google_ads' AS source,
  MAX(date)    AS latest_date,
  DATE_DIFF(CURRENT_DATE(), MAX(date), DAY) AS days_behind
FROM staging.campaign_performance_daily
HAVING days_behind > 1;

Si cette requête retourne des lignes, quelque chose en amont est périmé et nécessite de l'attention.

Quand passer à dbt. Les requêtes planifiées gèrent un entrepôt mono-compte confortablement pendant longtemps. Passez à dbt quand la logique de transformation dépasse environ 10-15 modèles interdépendants, quand vous voulez des tests automatisés et une documentation au niveau colonne, ou quand plusieurs analystes éditent le même SQL et ont besoin de versioning et de lineage. dbt orchestré par Cloud Composer (Airflow géré) est l'étape suivante courante — mais adoptez-le parce que la complexité l'exige, pas parce que c'est à la mode.

Discipline de backfill. Quand vous changez une transformation, re-faites-la tourner sur l'historique pour que les anciennes partitions reflètent la nouvelle logique. Paramétrez vos requêtes planifiées par date pour que le même SQL serve à la fois l'exécution incrémentale quotidienne et un backfill complet manuel.

Reporting Looker Studio et gestion des coûts

L'entrepôt n'est utile que si les gens peuvent le lire, et Looker Studio est le front-end naturel pour BigQuery.

Connectez-vous aux tables curées uniquement. Pointez chaque source de données Looker Studio vers le dataset reporting, jamais vers les exports bruts ou les larges tables de staging. C'est la décision de coût la plus importante de tout le pipeline. Looker Studio rafraîchit les requêtes à l'interaction et sur un planning de cache ; si un dashboard populaire interroge une table d'historique complet non partitionnée, les octets scannés — et la facture — se composent vite.

Un jeu de dashboards de départ pratique :

• Aperçu exécutif — spend blended, conversions et revenu CRM entre canaux, suivis dans le temps.
• Aperçu de compte — performance par compte pour les configurations MCC, en utilisant les noms conviviaux de l'account-map.
• Drill-down de campagne — spend, CPA, coût-par-revenu et engagement GA4 par campagne et groupe d'annonces.

Contrôles de coût qui comptent vraiment :

Surveillez les requêtes les plus chères. La vue INFORMATION_SCHEMA.JOBS expose chaque requête, qui l'a lancée, et combien d'octets elle a traités. Un coup d'œil hebdomadaire aux plus gros consommateurs fait remonter le seul rapport ou requête planifiée dominant discrètement votre facture, pour que vous puissiez l'optimiser — généralement en ajoutant un filtre de partition ou en matérialisant une jointure.

SELECT
  user_email,
  query,
  total_bytes_processed / POW(10, 12) AS tb_processed
FROM `region-eu`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY total_bytes_processed DESC
LIMIT 20;

Fixez un budget de facturation et une alerte sur le projet Cloud peu importe votre prudence. C'est le filet de sécurité qui transforme une requête incontrôlée d'une surprise de fin de mois en une notification le jour même.

Avec des tables curées, des filtres de partition, BI Engine pour les dashboards chauds, et un monitoring de coût hebdomadaire, un entrepôt mono-compte reste confortablement dans la plage de 30-150 €/mois tout en servant des rapports rapides et dignes de confiance.

Patterns SQL pour les fondations d'incrémentalité et de LTV

L'entrepôt n'est pas juste un reporting plus joli — c'est le substrat pour le travail de mesure qui pilote les vraies décisions budgétaires. Voici les patterns fondamentaux.

Incrémentalité geo-holdout. Le test d'incrémentalité demande quelles conversions auraient eu lieu sans les annonces. L'entrepôt rend l'analyse triviale une fois qu'une expérience geo tourne : étiquetez les régions comme test ou témoin, puis comparez les taux de conversion entre les deux groupes pour la fenêtre de test.

-- lift d'incrémentalité par groupe de régions
SELECT
  geo_group,
  SUM(conversions) / SUM(sessions) AS conversion_rate
FROM reporting.geo_experiment
WHERE date BETWEEN @test_start AND @test_end
GROUP BY geo_group;

Le lift entre test et témoin, normalisé pour la taille du groupe, estime la contribution incrémentale. La méthodologie et le design de test vivent dans notre guide de test d'incrémentalité ; BigQuery est où vous le calculez à l'échelle et le re-faites tourner chaque trimestre sans effort manuel.

Rétention de cohortes et LTV. La modélisation de la valeur vie commence par cohorter les clients par mois d'acquisition et suivre le revenu en avant.

-- cohortes d'acquisition mensuelles avec revenu cumulé
SELECT
  DATE_TRUNC(first_close_date, MONTH) AS cohort_month,
  DATE_DIFF(revenue_month, first_close_date, MONTH) AS month_index,
  SUM(revenue) AS cohort_revenue
FROM reporting.customer_revenue_monthly
GROUP BY cohort_month, month_index
ORDER BY cohort_month, month_index;

Cette matrice de cohortes est la matière première pour les courbes de LTV, l'analyse de période de payback, et les ratios CAC-vers-LTV par canal d'acquisition — les métriques qui devraient gouverner l'allocation budgétaire. Jointe à la campagne qui a produit le GCLID de chaque client, vous pouvez calculer la LTV par campagne, pas juste le CPA par campagne, ce qui est une cible d'optimisation bien meilleure. Notre analyse du CAC payback par verticale montre les benchmarks que ces requêtes alimentent.

Reporting cross-canal blended. Une fois que Meta, LinkedIn et d'autres canaux atterrissent dans le même entrepôt avec des définitions cohérentes, un seul UNION ALL de la table quotidienne de chaque canal suivi d'un GROUP BY channel avec SAFE_DIVIDE(SUM(revenue), SUM(cost)) pour le ROAS blended produit la vue cross-canal qu'aucune interface plateforme ne peut. La partie dure est les définitions cohérentes, pas le SQL.

Input de marketing mix modeling. Les équipes avancées alimentent l'entrepôt directement dans un MMM. Le framework open source Meridian de Google lit le spend et les résultats agrégés à la semaine — exactement la forme que vos tables de reporting produisent déjà. Une seule requête planifiée pivote les données quotidiennes en la matrice de canaux à la semaine que Meridian attend, bouclant la boucle des données de clic brutes à la modélisation budgétaire statistique.

Ces patterns sont des fondations, pas des modèles finis, mais ce sont la partie dure à bien faire structurellement. Avec des données propres, jointes et partitionnées dans BigQuery, superposer l'incrémentalité, la LTV et le MMM devient un exercice d'analytics plutôt qu'un cauchemar de plomberie de données.

Pour le contexte plus large des glissements de privacy et de tracking qui rendent un entrepôt first-party de plus en plus essentiel, voir notre guide de stratégie de données first-party et l'analyse du futur cookieless.

Un entrepôt de reporting vous dit où l'argent est allé ; une couche d'optimisation décide où il va ensuite. Si vous voulez une optimisation Google Ads pilotée par IA qui peut agir sur les signaux de coût-par-revenu que votre pipeline BigQuery fait émerger, SteerAds fait tourner un audit gratuit de 14 jours sur les comptes Google et Microsoft Ads.

Sources

• cloud.google.com/bigquery/docs/google-ads-transfer — documentation du Google Ads Data Transfer Service
• cloud.google.com/bigquery/docs — documentation BigQuery
• support.google.com/analytics — documentation de l'export GA4 BigQuery
• cloud.google.com/looker/docs/studio — documentation Looker Studio
• cloud.google.com/blog/products/data-analytics — blog Google Cloud data analytics

FAQ