Charger les données Google Ads dans BigQuery : quatre approches comparées

Vous avez besoin de vos données Google Ads dans BigQuery. La tâche paraît simple jusqu’à ce que vous découvriez qu’il existe quatre approches fondamentalement différentes, chacune avec ses propres compromis en termes de coût, de fréquence de synchronisation et de charge de maintenance.

Le bon choix dépend de contraintes auxquelles vous n’avez peut-être pas encore pensé. Avant de comparer les dashboards et les fonctionnalités, une seule question élimine d’emblée la moitié de vos options.

La question du developer token

Un developer token Google Ads est une chaîne alphanumérique de 22 caractères, requise pour effectuer des appels à l’API Google Ads. On l’obtient depuis l’API Center d’un compte Google Ads Manager, mais c’est l’approbation qui pose problème.

Les niveaux d’accès progressent de Test Account (pas d’accès production) à Explorer (limité), Basic (production, 15 000 opérations quotidiennes) et Standard (production, illimité). Le délai annoncé est de 3 à 5 jours ouvrés. En pratique, comptez souvent plusieurs semaines, voire plusieurs mois.

Les motifs de rejet courants incluent des descriptions de cas d’usage trop vagues, des problèmes liés au site web et, point critique, l’utilisation d’outils tiers. Utiliser des outils open source comme Airbyte avec votre developer token peut enfreindre les conditions d’utilisation de l’API Google et entraîner un refus.

Concrètement, voici ce que cela implique pour vos options :

Si vous n’avez pas de developer token et ne souhaitez pas attendre des mois pour l’obtenir, vos options réalistes sont Data Transfer Service, Scripts ou un connecteur managé comme Fivetran. Cette seule contrainte oriente déjà votre décision.

Approche 1 : BigQuery Data Transfer Service

La solution native de Google est entièrement managée et gratuite, sans coût de connecteur. Vous ne payez que les tarifs standards de stockage et de requêtage BigQuery.

Configuration : tout se fait depuis la console BigQuery. Accédez à Data Transfers, créez un nouveau transfert, sélectionnez Google Ads comme source, entrez votre Customer ID, configurez le planning et autorisez via OAuth. Pour les campagnes Performance Max, activez les PMax Campaign Tables.

Données disponibles : des tables partitionnées par date au format ads_[ReportName]_[CustomerID]. Les rapports standards couvrent les campagnes, groupes d’annonces, annonces, mots-clés, termes de recherche, performances géographiques, données démographiques et diverses métadonnées. Les rapports GAQL personnalisés sont désormais supportés pour aller au-delà des champs standards.

Limite : la fréquence de synchronisation minimale est de 24 heures. La fenêtre de rafraîchissement est configurable de 0 à 30 jours (7 par défaut), et les backfills s’exécutent à environ 35 minutes d’intervalle par date. Les statistiques Google Ads peuvent accuser un retard allant jusqu’à 3 heures.

Données historiques : c’est la lacune la plus importante. Data Transfer Service ne charge les données qu’à partir du moment où vous le configurez, plus la fenêtre de backfill. Si vous avez besoin de deux ans de performance de campagnes pour construire des rapports de tendance ou entraîner des modèles d’enchères, cette approche ne suffira pas seule. L’API Google Ads (via dlt ou Scripts) permet de récupérer les données historiques. Les équipes qui ont besoin d’un historique complet font souvent un chargement initial ponctuel via une autre méthode, puis basculent sur Data Transfer Service pour la synchronisation continue.

Mises à jour de schéma : autre point d’attention. Quand Google met à jour les versions de l’API (la transition v21 vers v22 en janvier 2026 a renommé plusieurs métriques), vos requêtes en aval peuvent casser. Ce n’est pas propre à Data Transfer Service, mais les connecteurs managés vous isolent davantage de ces changements.

Quand choisir cette approche : vous avez besoin de données Google Ads dans BigQuery, des mises à jour quotidiennes suffisent et vous voulez une configuration simple sans frais de licence. Cela couvre la majorité des cas d’usage analytiques. Pour un MCC gérant plusieurs comptes, configurez les transferts au niveau MCC plutôt que par compte individuel.

Approche 2 : Fivetran

Fivetran propose un connecteur ELT entièrement managé avec une fréquence de synchronisation minimale de 15 minutes. La configuration est directe : créez un compte, ajoutez le connecteur Google Ads, connectez-vous via OAuth, sélectionnez les comptes, configurez les rapports et définissez votre fenêtre de conversion (1 à 90 jours, 30 par défaut).

La couverture des données est similaire à Data Transfer Service avec quelques ajouts. Les rapports personnalisés supportent les requêtes GAQL. Parmi les fonctionnalités récentes : SEARCH_TERM_KEYWORD_STATS et le support de Google Ads v22. Vous bénéficiez également de modèles dbt pré-construits pour accélérer les transformations.

Les coûts, c’est là que Fivetran se complique.

Fivetran utilise une tarification par Monthly Active Rows (MAR). Un changement de mars 2025 est passé d’un MAR global par compte à un MAR par connecteur, supprimant les remises de volume. Les plans vont de Free (500K MAR/mois) à Business Critical (environ 1 067 $/million de MAR), avec un frais de base de 5 $ par connexion standard et un contrat annuel minimum de 12 000 $.

Les données marketing sont particulièrement problématiques car les lignes se mettent à jour fréquemment. Les fenêtres d’attribution impliquent des conversions attribuées rétroactivement, et les données au niveau annonce génèrent des volumes de lignes élevés. Des retours sur Reddit rapportent des augmentations de coûts de 4 à 8x avec la nouvelle tarification, certains utilisateurs décrivant des coûts passant « de 20 $/mois à 2 000 $/mois » avec la montée en charge.

Comportement de synchronisation : le sync fonctionne de manière incrémentale pour les 3 derniers jours, avec un sync de rattrapage quotidien qui capture les changements en dehors de cette fenêtre. La table GEO_TARGET effectue des syncs complets les 1er et 15 de chaque mois, ce qui peut faire grimper votre MAR de façon inattendue.

Quand choisir cette approche : vous avez besoin d’une fréquence de synchronisation supérieure au quotidien, vous êtes déjà dans l’écosystème Fivetran pour d’autres connecteurs et votre budget peut absorber des coûts imprévisibles. Surveillez de près les compteurs MAR sur les données marketing et obtenez des estimations avant de vous engager. Pour un comparatif plus large des connecteurs managés et open source, consultez mon comparatif Fivetran, Airbyte et dlt.

Approche 3 : Google Ads Scripts

Les Google Ads Scripts exécutent du JavaScript directement dans l’interface Google Ads et permettent d’exporter les données vers BigQuery. Pas besoin de developer token.

Les scripts s’authentifient via le compte Google Ads connecté et s’exécutent dans l’infrastructure Google. Ils ont leurs propres limites d’exécution (30 minutes maximum) plutôt que d’utiliser les quotas de l’API externe.

Configuration : accédez à Google Ads → Outils → Actions groupées → Scripts, activez l’API BigQuery Advanced et collez un script qui interroge les données et les charge dans BigQuery. Planifiez une exécution quotidienne, de préférence à partir de 3h du matin pour la fiabilité des données.

Comparaison avec l’API complète :

Un script basique interroge l’API de reporting Google Ads, formate les résultats et les envoie en streaming vers une table BigQuery. Vous gardez le contrôle total sur les champs à extraire et la structure des résultats.

Les limites comptent pour les opérations de plus grande envergure. La limite d’exécution de 30 minutes devient problématique pour les comptes avec des volumes de données importants. La planification se fait à l’heure uniquement (pas de scheduling à la minute). Et c’est à vous de mettre à jour les scripts quand Google modifie les noms de champs.

Quand choisir cette approche : vous avez besoin de logique custom sans la complexité de l’API, vous gérez un nombre limité de comptes, vous n’avez pas d’infrastructure serveur et des rapports quotidiens ou hebdomadaires suffisent. Les scripts constituent un bon compromis entre la simplicité de Data Transfer Service et la complexité des solutions basées sur l’API.

Approche 4 : dlt (Data Load Tool)

dlt est une bibliothèque Python open source pour le chargement de données, avec une approche code-first pour l’extraction Google Ads. Contrôle total sur le pipeline, évolution automatique du schéma et chargement incrémental, le tout au seul coût de l’infrastructure.

Limite : dlt nécessite un developer token. Si vous parvenez à en obtenir un, vous gagnez une flexibilité significative.

La source Google Ads est vérifiée et fournit du code Python que vous pouvez personnaliser. Un pipeline basique :

import dlt
from dlt.sources.google_ads import google_ads

pipeline = dlt.pipeline(
    pipeline_name="google_ads",
    destination="bigquery",
    dataset_name="google_ads_data"
)

source = google_ads(
    customer_id="1234567890",
    queries=[
        {
            "query": "SELECT campaign.name, metrics.clicks FROM campaign",
            "table_name": "campaign_performance"
        }
    ]
)

load_info = pipeline.run(source)

dlt gère automatiquement la pagination, le rate limiting, l’inférence de schéma et le chargement incrémental. Vous déployez le pipeline partout où Python tourne : Cloud Functions, Cloud Run, Airflow ou un simple cron job.

Quand choisir cette approche : votre équipe maîtrise Python, vous avez (ou pouvez obtenir) un developer token, vous voulez des coûts limités à l’infrastructure et vous avez besoin d’un contrôle fin sur la logique d’extraction. dlt fonctionne particulièrement bien quand vous l’utilisez déjà pour d’autres sources et que vous recherchez une cohérence dans votre couche d’ingestion. Pour un guide complet, consultez mon guide pratique de dlt.

Tableau comparatif

Pièges courants, quelle que soit l’approche

Les fenêtres d’attribution posent problème avec toutes les approches (pour approfondir, voir la comparaison des modèles d’attribution). Les conversions peuvent être attribuées rétroactivement jusqu’à 90 jours selon vos paramètres. Quelle que soit votre fréquence de synchronisation, vos données changeront après coup. Concevez vos rapports en conséquence et évitez de considérer les chiffres de la veille comme définitifs.

La complexité du schéma prend les équipes au dépourvu. Data Transfer Service crée des dizaines de tables. Comprendre les relations entre les données au niveau campagne, groupe d’annonces et annonce nécessite une lecture attentive de la documentation Google.

L’approbation du developer token reste le principal obstacle pour les solutions basées sur l’API. Si vous avez besoin de dlt ou de pipelines custom, lancez la demande en amont. Fournissez des cas d’usage précis et détaillés dans votre candidature. Évitez de mentionner des outils tiers.

La misattribution GA4 + Google Ads est un problème connu. Quand vous joignez les données GA4 avec les données Google Ads dans BigQuery, l’attribution par gclid peut produire des résultats inattendus. Ce n’est pas propre à une approche de chargement en particulier, mais c’est votre problème une fois les données dans BigQuery.

Faire le bon choix

Partez de vos contraintes :

1. Avez-vous un developer token ? Si non et que vous devez avancer vite, vos options sont Data Transfer Service, Fivetran ou Scripts.

2. Un sync quotidien suffit-il ? Pour la plupart des besoins analytiques et de reporting, oui. Data Transfer Service couvre ce cas gratuitement.

3. Avez-vous besoin de plus qu’un sync quotidien ? Fivetran propose des syncs toutes les 15 minutes, mais surveillez les coûts de près sur les données marketing.

4. Avez-vous besoin de logique custom ? Les scripts offrent du contrôle JavaScript sans la complexité de l’API. dlt offre du contrôle Python avec plus de flexibilité, mais nécessite le developer token.

5. Quel est votre budget ? Gratuit (Data Transfer Service, Scripts) vs coût d’infrastructure uniquement (dlt) vs service managé payant (Fivetran).

6. Avez-vous besoin de données historiques ? Data Transfer Service ne remonte pas au-delà de 30 jours. Si vous avez besoin de mois ou d’années d’historique, il vous faudra Scripts ou un outil basé sur l’API pour le chargement initial, même si vous utilisez Data Transfer Service par la suite. Une stratégie mixte (backfill ponctuel + sync managé en continu) est courante et tout à fait raisonnable.

Pour la plupart des équipes, Data Transfer Service est le bon choix par défaut. C’est gratuit, les données quotidiennes couvrent la majorité des besoins de reporting et la configuration prend quelques minutes. Les cas d’usage de Fivetran (syncs infra-quotidiens) et de dlt (ingestion Python avec personnalisation complète) sont réels, mais plus restreints qu’on ne le pense.

Inutile de trop réfléchir au choix initial. Vous pourrez toujours migrer par la suite, et les structures de données sont suffisamment similaires d’une approche à l’autre pour que vos transformations en aval ne nécessitent pas de refonte majeure. La question plus large du build vs buy s’applique ici aussi.