Charger des données Google Ads dans BigQuery repose sur quatre approches fondamentalement différentes. Chacune présente des compromis distincts en termes de coût, de complexité de configuration, de fréquence de synchronisation et de contrôle. La matrice de décision est simple une fois que vous savez quelles contraintes s’appliquent à vous.
Le premier filtre : le developer token
Avant de comparer les outils, répondez à une question : disposez-vous d’un developer token Google Ads API ?
Un developer token est requis pour tout accès API basé sur du code. L’obtenir peut prendre des semaines à des mois. Si vous n’en avez pas et devez aller vite, vos options se réduisent à trois. Si vous pouvez en obtenir un, les quatre approches sont disponibles.
| Approche | Developer token requis |
|---|---|
| BigQuery Data Transfer Service | Non |
| Google Ads Scripts | Non |
| Fivetran | Non (ils utilisent le leur) |
| dlt | Oui |
Les quatre approches
BigQuery Data Transfer Service
Idéal pour : la plupart des équipes faisant de l’analytics standard et du reporting.
L’intégration native de Google. Gratuite — vous ne payez que les coûts de stockage et de requête BigQuery. La configuration prend quelques minutes dans la console BigQuery. S’authentifie via OAuth sans token requis.
Limitations : synchronisation quotidienne uniquement, pas de backfill au-delà de 180 jours (fenêtre de 7 jours par défaut), schéma géré par Google que vous ne pouvez pas personnaliser. Ces limitations excluent moins d’équipes qu’on pourrait le croire. Les pièges plus profonds — gonflement des impressions ClickType, lacunes de données Performance Max, et la nécessité des JOIN attributs/stats — sont couverts dans les notes dédiées.
Fivetran
Idéal pour : les équipes ayant besoin de synchronisations plus fréquentes que quotidiennes et pouvant absorber des coûts imprévisibles.
Entièrement géré, fréquence de synchronisation minimale de 15 minutes, modèles dbt prébuiltés inclus. La configuration est peu complexe. Fivetran utilise son propre developer token — vous vous authentifiez avec OAuth.
La complication de coût : la tarification MAR de Fivetran est sévère pour les données marketing. Les métriques publicitaires se mettent à jour de manière rétroactive, générant un nombre élevé de lignes actives à chaque cycle de synchronisation. Un grand compte Google Ads peut produire des milliers de lignes actives par cycle. Obtenez des estimations MAR avant de vous engager. Des rapports de coûts passant de 20 $/mois à 2 000 $/mois à mesure que le volume augmente sont courants dans cette catégorie.
La table GEO_TARGET exécute des synchronisations complètes le 1er et le 15 de chaque mois, ce qui peut provoquer des pics de MAR inattendus.
Google Ads Scripts
Idéal pour : les équipes ayant besoin d’une logique personnalisée sans la complexité API ni infrastructure serveur.
Les Scripts s’exécutent en JavaScript dans l’interface Google Ads et écrivent directement dans BigQuery. Pas de developer token requis. Pas d’infrastructure serveur nécessaire. Vous contrôlez les champs et la logique ; les requêtes GAQL peuvent cibler n’importe quelle donnée accessible via l’API.
La contrainte : une limite d’exécution stricte de 30 minutes par exécution. Pour les petits comptes, c’est amplement suffisant ; pour les opérations à l’échelle entreprise avec des données au niveau des mots-clés sur des milliers de campagnes, cela devient un plafond. La planification est horaire, quotidienne ou hebdomadaire — pas de planifications personnalisées sub-horaires.
dlt (Data Load Tool)
Idéal pour : les équipes Python qui ont (ou peuvent obtenir) un developer token et veulent une tarification basée uniquement sur les coûts d’infrastructure.
dlt est une bibliothèque Python avec une source Google Ads vérifiée. Vous écrivez des requêtes GAQL, dlt gère la pagination, la gestion des limites de débit, l’inférence de schéma et le chargement incrémental. Déployable partout où Python s’exécute — Cloud Functions, Cloud Run, Airflow, ou une tâche cron.
Nécessite un developer token. La capacité de backfill historique est le principal avantage sur DTS : dlt peut récupérer des années de données, pas seulement 30 jours. Le pattern incrémental avec la disposition d’écriture merge gère correctement les mises à jour d’attribution rétroactives.
Cadre de décision
Commencez par vos contraintes :
- Pas de developer token + besoin d’aller vite → Data Transfer Service (gratuit, pas de token, configuration en quelques minutes)
- Pas de developer token + besoin de synchronisation sub-quotidienne → Fivetran (vérifiez d’abord les coûts MAR)
- Logique d’extraction personnalisée + pas de serveur → Google Ads Scripts (dans la limite de 30 minutes)
- Équipe Python + developer token + sensible aux coûts → dlt
- Besoin de données historiques au-delà de 30 jours → dlt ou Scripts pour le backfill, puis DTS pour les synchronisations continues
La stratégie mixte est courante : effectuez un chargement historique unique via dlt ou Scripts, puis passez au Data Transfer Service pour les synchronisations quotidiennes continues. Les structures de données produites sont suffisamment compatibles pour que les modèles dbt en aval n’aient pas besoin de réécriture majeure.
Pièges communs à toutes les approches
Retraitement de la fenêtre d’attribution. Les données de conversion se mettent à jour de manière rétroactive jusqu’à 90 jours selon vos paramètres. Quelle que soit l’approche utilisée, construisez votre reporting pour traiter les données récentes comme provisoires. Le comptage de conversions d’hier va changer. Voir Ad Pipeline Engineering Challenges pour gérer cela dans votre couche de transformation.
Coût rapporté en micros. Google Ads rapporte cost_micros — divisez par 1 000 000 pour obtenir les valeurs monétaires réelles. Manquer cela dans votre modèle de base dbt rend les chiffres de dépenses erronés de six ordres de grandeur.
Changements de schéma lors des mises à jour de version API. Quand Google publie de nouvelles versions d’API, les noms de champs changent. La transition v21 vers v22 de janvier 2026 a renommé plusieurs métriques. DTS applique ces changements selon le calendrier de Google ; les modèles dbt en aval référençant des champs renommés se cassent silencieusement. Les pipelines personnalisés nécessitent des mises à jour manuelles mais selon votre propre calendrier. Les particularités du schéma DTS — comme toujours interroger les tables avec préfixe p_ avec des filtres _DATA_DATE — valent la peine d’être comprises quelle que soit votre approche de chargement.
Délai d’approbation du developer token. Si vous planifiez d’utiliser dlt ou de construire un pipeline personnalisé, démarrez le processus de demande de token tôt. Fournissez des descriptions de cas d’usage spécifiques et détaillées. Ne mentionnez pas d’outils open source par leur nom. Voir Google Ads Developer Token pour le parcours d’approbation complet.