Configuration du Google Ads BigQuery Data Transfer Service

Le Google Ads BigQuery Data Transfer Service (DTS) offre un moyen gratuit et sans maintenance de charger des données Google Ads dans BigQuery. La configuration prend quelques minutes dans la console BigQuery, et en moins de 24 heures, plus de 88 tables de données de campagne se rafraîchissent automatiquement chaque jour. Pas de code, pas d’authentification API, pas de gestion des limites de débit.

Trois problèmes nécessitent une gestion explicite : les comptages d’impressions sont gonflés sans filtre sur le type de clic, les données Performance Max sont incomplètes par défaut, et le schéma nécessite des JOIN entre les tables attributs et stats pour produire des rapports utilisables.

Prérequis et configuration

DTS nécessite trois choses avant de commencer :

Un projet Google Cloud actif avec la facturation activée
Le rôle BigQuery Admin sur le projet
Un accès en lecture à un Customer ID Google Ads ou un compte MCC

La configuration se fait via la console BigQuery sous « Data Transfers ». Sélectionnez Google Ads comme source, choisissez le type de rapport Standard ou Custom (GAQL), entrez le Customer ID et définissez la fenêtre de rafraîchissement.

La fenêtre de rafraîchissement (de 1 à 30 jours, 7 par défaut) contrôle le nombre de jours de données historiques remplacés à chaque exécution. Les conversions Google Ads arrivent en retard — parfois plusieurs jours après le clic — donc définir une fenêtre de rafraîchissement trop courte signifie que vos chiffres de conversion seront définitivement sous-estimés pour les dates anciennes. Sept jours est un défaut raisonnable. Si votre fenêtre de conversion est plus longue (courant en B2B), portez-la à 14 ou 30 jours.

La fréquence de transfert maximale est d’une fois toutes les 24 heures. Si votre équipe a besoin de données de performance intraday pour les décisions budgétaires, DTS ne peut pas vous aider — vous aurez besoin d’un accès API direct ou d’un connecteur géré.

Les backfills remontent jusqu’à 180 jours par requête, mais vous pouvez enchaîner plusieurs requêtes séquentiellement si vous avez besoin d’un historique plus long. Exécuter un transfert deux fois à la même date écrase cette partition au lieu de créer des doublons, donc les backfills sont sûrs à relancer.

Vue d’ensemble du schéma : 88 tables, deux types

DTS crée 88+ tables organisées autour d’un schéma en étoile. Comprendre les deux types de tables est la clé pour écrire des requêtes correctes.

Tables attributs contiennent des dimensions : noms de campagnes, noms de groupes d’annonces, IDs, statuts, paramètres. Pas de métriques. Exemples : Campaign, AdGroup, Keyword, Ad.

Tables stats contiennent des faits : impressions, clics, coût, conversions. IDs uniquement — pas de noms. Exemples : CampaignBasicStats, AdGroupStats, KeywordStats.

Chaque table existe en deux versions. Campaign_CUSTOMERID est une vue. p_Campaign_CUSTOMERID est la table sous-jacente partitionnée par date. La convention de nommage est cohérente : le préfixe p_ signifie que vous interrogez directement la table partitionnée.

Utilisez toujours les versions p_ en production. Les vues sans préfixe scannent la table entière à chaque requête, quelle que soit votre filtre de date. Un SELECT * anodin sur la vue non partitionnée scannera des mois de données et consommera votre budget BigQuery on-demand. Les tables partitionnées respectent les filtres _DATA_DATE et permettent le partition pruning.

-- Faites toujours ceci
SELECT *
FROM `project.dataset.p_CampaignBasicStats_CUSTOMERID`
WHERE _DATA_DATE >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)

-- Ne faites jamais ceci en production
SELECT *
FROM `project.dataset.CampaignBasicStats_CUSTOMERID`

La colonne _DATA_DATE est la clé de partition dans toutes les tables DTS. Filtrez dessus explicitement et les requêtes resteront bon marché.

Configuration MCC vs par compte

Si vous gérez plus d’un compte Google Ads, configurez le transfert au niveau MCC (My Client Center) — pas au niveau des comptes individuels. Ce n’est pas une recommandation pour les cas limites ; c’est le défaut correct pour toute configuration non triviale.

Un seul transfert MCC gère tous les comptes enfants, jusqu’à 2 000 Customer IDs. Toutes les données atterrissent dans les mêmes tables, permettant des requêtes cross-comptes sans gymnastique avec UNION. Cela évite également les problèmes de quota que les transferts individuels par compte créent à mesure que le volume augmente.

L’alternative — un transfert séparé pour chaque Customer ID — aboutit à des datasets séparés, une surveillance séparée et des points de défaillance séparés. Pour les agences gérant plusieurs marques ou toute entreprise avec plus d’un compte publicitaire, la charge opérationnelle s’accumule rapidement. Google recommande explicitement la configuration au niveau MCC, et il vaut la peine de le faire dès le départ avant d’avoir construit des rapports pointant vers des datasets de comptes individuels.

Ce que coûte DTS

Le connecteur lui-même est gratuit. Pas de frais de transfert pour les connecteurs Google propriétaires. Vous payez uniquement les coûts BigQuery :

Stockage actif : 0,02 $/Go/mois
Stockage long terme (>90 jours sans modification) : 0,01 $/Go/mois
Requêtes on-demand : 6,25 $/Tio traité

La plupart des configurations Google Ads de taille modérée coûtent 1 à 5 $ par mois au total. Même les grands comptes dépassent rarement 20 $/mois. Les métadonnées publicitaires ne génèrent pas les volumes de données que produisent les analytics au niveau événementiel — une campagne peut avoir des milliers de lignes par jour, pas des millions.

Le contrôle de coût le plus impactant : interrogez toujours les tables avec préfixe p_ avec un filtre _DATA_DATE. Cela limite BigQuery à scanner uniquement les partitions dont vous avez besoin au lieu de l’historique complet de la table.

Les trois pièges à connaître

DTS est un outil véritablement bon caché derrière trois défauts véritablement mauvais :

Le piège des impressions ClickType — Les tables stats contiennent une colonne segments_click_type, et les impressions sont répétées pour chaque type de clic. Sans filtrage, les comptages d’impressions peuvent être 3 à 6 fois supérieurs à la réalité. Voir Google Ads ClickType Impression Trap pour le traitement complet et le correctif SQL correct.
Les lacunes de données Performance Max — Les campagnes PMax nécessitent de cocher une case séparée lors de la configuration, et même dans ce cas, les métriques sont fréquemment absentes des tables stats. Si PMax représente une part significative de vos dépenses publicitaires, DTS seul ne vous donnera pas de données complètes. Voir Google Ads Performance Max Data Gaps.
Les tables stats n’ont pas de noms — Les tables attributs ont des noms, les tables stats ont des IDs. Pour construire un rapport lisible par des humains, vous devez effectuer des JOIN en utilisant le pattern décrit dans l’article source. Le JOIN nécessite de filtrer la table attributs sur _LATEST_DATE pour obtenir les noms de campagnes actuels plutôt que les valeurs historiques.

Ces trois problèmes gérés, DTS nécessite une maintenance minimale et coûte presque rien.