Getting Google Ads data into BigQuery has four fundamentally different approaches. Each has distinct trade-offs around cost, setup complexity, sync frequency, and control. The decision matrix is simple once you know which constraints apply to you.
The First Gate: Developer Token
Before comparing tools, answer one question: do you have a Google Ads API developer token?
A developer token is required for any code-based API access. Getting one approved takes weeks to months. If you don’t have one and need to move quickly, your options narrow to three. If you can get one, all four approaches are available.
| Approach | Developer Token Required |
|---|---|
| BigQuery Data Transfer Service | No |
| Google Ads Scripts | No |
| Fivetran | No (they use their own) |
| dlt | Yes |
The Four Approaches
BigQuery Data Transfer Service
Best for: most teams running standard analytics and reporting.
Google’s native integration. Free — you pay only BigQuery storage and query costs. Setup takes minutes in the BigQuery Console. Authenticates via OAuth with no token required.
Limitations: daily sync only, no backfill beyond 180 days (7-day window by default), Google-managed schema you can’t customize. These limitations exclude fewer teams than you’d expect. The deeper gotchas — ClickType impression inflation, Performance Max data gaps, and the attribute/stats JOIN requirement — are covered in the dedicated notes.
→ Google Ads BigQuery DTS Hub
Fivetran
Best for: teams that need faster than daily sync and can absorb unpredictable costs.
Fully managed, 15-minute minimum sync frequency, pre-built dbt models included. Setup is low-effort. Fivetran uses their own developer token — you authenticate with OAuth.
The cost complication: Fivetran’s MAR pricing is harsh on marketing data. Ad metrics update retroactively, generating high row counts on every sync. A large Google Ads account can produce thousands of active rows per sync cycle. Get MAR estimates before committing. Reports of costs going from $20/month to $2,000/month as scale increases are common in this category.
The GEO_TARGET table runs full syncs on the 1st and 15th of each month, which can spike MAR unexpectedly.
Google Ads Scripts
Best for: teams that need custom logic without API complexity or server infrastructure.
Scripts run JavaScript inside the Google Ads interface and write directly to BigQuery. No developer token required. No server infrastructure needed. You control the fields and logic; GAQL queries can target any API-accessible data.
The constraint: a hard 30-minute execution limit per run. For small accounts this is ample; for enterprise-scale operations with keyword-level data across thousands of campaigns, it becomes a ceiling. Scheduling is hourly, daily, or weekly — no sub-hour custom schedules.
→ Google Ads Scripts BigQuery
dlt (Data Load Tool)
Best for: Python teams that have (or can get) a developer token and want infrastructure-cost-only pricing.
dlt is a Python library with a verified Google Ads source. You write GAQL queries, dlt handles pagination, rate limiting, schema inference, and incremental loading. Deploy anywhere Python runs — Cloud Functions, Cloud Run, Airflow, or a cron job.
Requires a developer token. The historical backfill capability is the main advantage over DTS: dlt can pull years of data, not just 30 days. The incremental pattern with merge write disposition handles retroactive attribution updates correctly.
Decision Framework
Start with your constraints:
- No developer token + need to move fast → Data Transfer Service (free, no token, minutes to setup)
- No developer token + need sub-daily sync → Fivetran (check MAR costs first)
- Custom extraction logic + no server → Google Ads Scripts (within 30-minute limit)
- Python team + developer token + cost-sensitive → dlt
- Need historical data beyond 30 days → dlt or Scripts for backfill, then DTS for ongoing
The mixed strategy is common: run a one-time historical load via dlt or Scripts, then switch to Data Transfer Service for ongoing daily syncs. The data structures produced are compatible enough that downstream dbt models don’t need major rewrites.
Common Pitfalls Across All Approaches
Attribution window restatement. Conversion data updates retroactively for up to 90 days depending on your settings. Whatever approach you use, build reporting to treat recent data as provisional. Yesterday’s conversion count will change. See Ad Pipeline Engineering Challenges for how to handle this in your transformation layer.
Cost reported in micros. Google Ads reports cost_micros — divide by 1,000,000 for actual currency values. Miss this in your dbt base model and spend figures are wrong by six orders of magnitude.
Schema changes on API version updates. When Google releases new API versions, field names change. The v21-to-v22 transition in January 2026 renamed several metrics. DTS applies these changes on Google’s timeline; downstream dbt models referencing renamed fields break silently. Custom pipelines need manual updates but on your schedule. The DTS schema quirks — like always querying p_-prefixed tables with _DATA_DATE filters — are worth understanding regardless of your loading approach.
Developer token approval timeline. If you’re planning to use dlt or build a custom pipeline, start the token application process early. Provide specific, detailed use case descriptions. Don’t mention open-source tools by name. See Google Ads Developer Token for the full approval path.