BigQuery est l'entrepôt de données de Google Cloud. Tu y charges des tables, tu les interroges en SQL, et tu paies les octets que chaque requête lit. Pour quelqu'un qui achète du média, c'est le seul endroit où Google Ads, GA4 et ton CRM peuvent tenir dans la même requête.

Ça, c'est la partie facile à dire. La vraie question est de savoir si ton compte a quelque chose à y faire, et la plupart de ceux que je regarde n'en sont pas là.

Un entrepôt, pas un tableau de bord de plus

Ton interface Google Ads répond aux questions pour lesquelles elle a été construite. Le coût par campagne, les conversions par appareil, les termes de recherche des dernières semaines. Ce sont des rapports préparés : quelqu'un a décidé à l'avance quelles lignes tu voudrais voir, et jusqu'où tu pourrais descendre.

Pense au tableau de bord de ta voiture et à la prise diagnostic sous le volant. Même voiture, mêmes capteurs. Le tableau de bord affiche six chiffres choisis pour toi. La prise donne toutes les valeurs que la voiture enregistre, au rythme où elle les enregistre, y compris celles qu'aucun cadran ne montre. Personne ne branche une valise de diagnostic pour vérifier son niveau d'essence.

BigQuery, c'est la prise. C'est un service dans Google Cloud, pas Google Cloud lui-même : tu ouvres un projet Cloud, et BigQuery est ce que tu actives dedans.

La structure tient en trois niveaux :

  • Le projet : le contenant de facturation et d'accès. Tout vit dans un projet.
  • Le dataset : un dossier dans ce projet, rattaché à une région que tu choisis une fois.
  • La table : les lignes elles-mêmes, une par événement, par clic, par commande.

Le langage, c'est SQL, le même que celui de la plupart des bases de données. Ça compte plus qu'il n'y paraît : ton équipe technique sait déjà lire tes données publicitaires, et tu n'apprends pas un outil qui n'existe nulle part ailleurs.

À quoi ça sert vraiment sur un compte publicitaire

Quatre usages reviennent sur presque tous les comptes qui finissent par en avoir besoin.

  • Croiser des sources. La dépense d'un côté, les affaires signées de l'autre, réunies sur un identifiant de clic ou de commande. Aucune interface ne le fait, parce qu'aucune interface ne possède les deux côtés.
  • Garder l'historique. Les plateformes gardent ce qu'elles gardent. Un entrepôt garde ce que tu décides, aussi longtemps que tu paies le stockage.
  • Lire la ligne brute. GA4 agrège dans ses rapports. L'export contient l'événement tel qu'il a été reçu, avec ses paramètres, avant tout regroupement.
  • Alimenter un tableau de bord qui ne tombe pas. Looker Studio branché en direct sur une API devient lent et se heurte aux quotas. Sur une table, il lit.

Un chiffre pour rendre le volume concret. J'ai extrait les termes de recherche des quatorze comptes que je gère sur trente jours : 47 463 lignes. Un seul compte en porte 32 895, soit près de sept sur dix, et trois comptes ne rendent rien du tout parce qu'ils ne tournent pas sur du Search. Cet écart est exactement le sujet. La même fonctionnalité peut être sans objet sur onze comptes et structurante sur un seul.

Comment la donnée entre

Tu vas croiser trois portes, et elles ne sont pas ouvertes pareil.

GA4 a un export natif. Tu relies la propriété à un projet Cloud, et les événements commencent à atterrir dans une table quotidienne. Le centre d'aide Analytics est clair sur ce que tu reçois : la donnée d'événement brute, non échantillonnée, une fois par jour, avec une option de streaming qui tourne en continu. Les propriétés standard sont plafonnées à un million d'événements par jour pour l'export quotidien, et une propriété qui dépasse régulièrement voit cet export mis en pause. C'est le genre de chose à savoir avant une saison forte, pas pendant.

Google Ads a un service de transfert. Le BigQuery Data Transfer Service va chercher tes rapports selon une planification, au maximum une fois toutes les 24 heures, avec une fenêtre de rafraîchissement de sept jours par défaut et trente au maximum. Tu peux écrire tes propres rapports en GAQL, avec un détail qui coûte une après-midi quand tu le découvres tard : les rapports personnalisés de ce connecteur n'acceptent ni WHERE, ni ORDER BY, ni LIMIT, ni PARAMETERS. Tu filtres après le chargement, pas avant.

Ton CRM entre par la route dont il dispose. Un fichier planifié, un connecteur, un script. C'est en général cette partie qui prend des semaines, et elle n'a rien à voir avec BigQuery.

Un détail décide plus de budgets qu'il ne le devrait : sur la page tarifs, l'orchestration du transfert est sans frais pour les sources Alphabet, ce qui couvre Google Ads, GA4, Merchant Center, Search Ads 360, Display & Video 360 et Campaign Manager. Facebook Ads figure dans la liste payante, facturée à la consommation. Si ton reporting penche du côté Meta, la part gratuite de cette histoire est plus petite que ce que la démo laissait croire.

Ce que ça coûte, et ce qui coûte vraiment

Deux compteurs tournent. Le stockage, facturé au gibioctet par mois. Le calcul, facturé sur les octets que tes requêtes lisent, pas sur les lignes qu'elles rendent.

Le palier gratuit couvre plus que ce que la plupart des annonceurs imaginent : le premier tébioctet de données traitées chaque mois est gratuit, et les dix premiers gibioctets de stockage actif aussi. Un an de rapports Google Ads pour un compte de taille moyenne tient dans ce stockage sans forcer.

Ce qui veut dire que la facture ne vient presque jamais de ce que tu gardes. Elle vient de ta façon de demander. Un SELECT * sur une table large lit toutes les colonnes dont tu n'avais pas besoin, à chaque exécution, et un tableau de bord qui la rafraîchit cinquante fois par jour multiplie ça par cinquante. Nomme tes colonnes, filtre sur la date de partition, et le même travail coûte une fraction.

La règle à garder : le stockage est bon marché, ce que tu paies, ce sont tes questions.

Commencer sans carte bancaire

Le bac à sable BigQuery te laisse charger des tables et lancer des requêtes sans aucun compte de facturation rattaché. Mêmes limites gratuites que ci-dessus, et c'est la façon honnête de découvrir si tu as un vrai cas d'usage avant que qui que ce soit signe quoi que ce soit.

Lis ses limites avant de construire dessus, parce que deux d'entre elles mordent. Les tables, les vues et les partitions expirent automatiquement au bout de 60 jours, et le bac à sable ne prend en charge ni le Data Transfer Service, ni le streaming, ni les instructions DML. Le bac à sable, c'est donc l'endroit où tu testes une requête sur un export GA4. Ce n'est pas là que tu montes ton pipeline Google Ads.

Page de documentation Google Cloud du bac à sable BigQuery : la liste des limites, avec les mêmes limites d'utilisation sans frais que le niveau gratuit (10 Go de stockage actif et 1 To de données de requête traitées par mois), l'expiration automatique des tables, vues et partitions au bout de 60 jours, et les trois fonctionnalités non compatibles : flux de données, instructions LMD et service de transfert de données BigQuery

Si tu veux un premier geste utile qui ne coûte rien et prend dix minutes : relie ta propriété GA4 à un projet Cloud et active l'export quotidien. La donnée commence à circuler dans les 24 heures qui suivent la création du lien, et chaque jour apporte le fichier de la veille. L'historique que tu ne collectes pas aujourd'hui est celui qui te manquera dans huit mois.

Ce qui surprend : les modèles vivent dedans

BigQuery ML te laisse créer et exécuter des modèles de machine learning avec le même SQL que tes requêtes, et le modèle est stocké dans ton dataset, à côté de tes tables. Rien ne sort de l'entrepôt, et personne n'a de pipeline à construire vers un outil séparé.

Pour un annonceur, ça ouvre une porte qui restait fermée sans équipe data : noter les leads qui ressemblent à ceux qui ont signé, projeter une courbe de saisonnalité sur ton propre historique, regrouper des clients par comportement avant de construire une audience. Je garderais des attentes calmes ici. Un modèle bâti sur un jeu de données maigre et mal tracké produit des absurdités très confiantes, et les comptes qui en ont le plus envie sont souvent ceux dont la donnée de conversion n'est pas prête.

Les limites que la démo ne montre pas

Rien de tout ça n'est une raison d'écarter BigQuery. C'est une raison de savoir à quoi tu t'engages.

  • Hier, pas maintenant. L'export quotidien arrive en milieu d'après-midi pour la journée précédente. Pour tout ce qui est temps réel, tu restes dans l'interface de la plateforme.
  • Le plafond du million d'événements. Les propriétés GA4 standard voient leur export quotidien s'arrêter si elles le dépassent régulièrement. Les sites à fort trafic le touchent et s'en aperçoivent quand une table manque.
  • Quelqu'un doit écrire le SQL. L'entrepôt répond aux questions, il n'en a aucune à lui. Un compte sans personne pour l'interroger obtient une pièce vide très bien rangée.
  • Il mesure, il n'agit pas. Rien de ce que tu calcules dans BigQuery n'atteint tes campagnes tant que tu ne le renvoies pas, et c'est un autre chantier. J'ai écrit sur la version que Google a ouverte cette année, où Google Ads lit une table BigQuery pour alimenter une action de conversion, et ses conditions d'entrée sont strictes.

Quand tu n'en as pas besoin

Je prends la position que les pages d'éditeurs évitent : si ta question tient dans un rapport, le rapport gagne. Il est plus rapide, il est gratuit, et il est déjà devant toi.

BigQuery commence à avoir du sens quand l'une de ces phrases est vraie chez toi :

  • Tu as besoin de la dépense et du chiffre d'affaires sur la même ligne, et le chiffre d'affaires vit dans un système que Google ne voit jamais.
  • Tu as besoin d'un historique qui va au-delà de ce que la plateforme conserve pour toi.
  • Tu exportes déjà vers des tableurs qui cassent, qui figent, ou qu'il faut recoller à la main chaque mois.
  • Quelqu'un chez toi sait écrire du SQL, ou tu es prêt à payer cette compétence.

Aucune des quatre ? Alors la réponse honnête est que ton problème de reporting n'est pas un problème de stockage, et un entrepôt ne réparera pas une action de conversion qui n'a jamais été posée correctement. Ça, c'est un chantier de tracking et Google Tag Manager, et il passe avant.

Trois questions qui reviennent à chaque fois

BigQuery, c'est une base de données SQL ? Il s'interroge en SQL, mais c'est un entrepôt conçu pour l'analyse, pas une base applicative. Tu y requêtes de gros volumes vite ; tu ne t'en sers pas pour servir ton site.

C'est la même chose que Snowflake ? Même métier, économie différente. Les deux stockent tes lignes et répondent en SQL. BigQuery facture les octets lus par tes requêtes et ne demande aucun cluster à dimensionner ; Snowflake facture le calcul que tu laisses allumé. Pour un annonceur déjà dans l'écosystème Google, ce qui tranche est rarement le moteur : c'est que GA4 et Google Ads se déversent nativement dans BigQuery, et dans le reste par un connecteur que tu maintiens.

Ça coûte combien par mois ? Pour un seul compte publicitaire qui exporte Google Ads et GA4, le stockage reste longtemps dans les dix gibioctets gratuits, et les requêtes dans le tébioctet gratuit tant qu'un tableau de bord ne se rafraîchit pas n'importe comment. La facture grandit avec le nombre de personnes qui interrogent, pas avec le nombre de campagnes que tu fais tourner.

Avant d'ouvrir un projet Cloud, le geste utile est de regarder ce que tes conversions enregistrent vraiment, ligne par ligne. C'est exactement l'arbitrage que je fais dans un audit de compte avant de toucher à quoi que ce soit sur un compte Google Ads.