Getting marketing data into BigQuery is one of the most common requests I see from marketing analytics teams.
The platforms all have APIs, but the gap between "the API exists" and "clean, validated data in BigQuery ready for reporting" is where most of the work lives.
Here is how each connection actually works and what to watch for.
Google Ads to BigQuery
Native option: BigQuery Data Transfer Service
Google provides a native connector that schedules daily transfers of Google Ads report data into BigQuery. It handles authentication, schema creation, and backfill windows. This is the fastest path to get Google Ads data into BigQuery.
What it does not handle: custom columns, derived metrics, or any cross-account logic. You get the platform's report shape, not your reporting shape.
Custom option: Google Ads API + Python or Apps Script
For teams that need specific metrics, cross-account aggregation, or tighter control over update windows, a Python-based extraction using the Google Ads API gives full flexibility. Google Ads Scripts are another option for teams already in the Sheets ecosystem.
Key watch points:
- Date ranges: Google Ads data is mutable for conversion windows. Pull with enough lookback to catch late conversions.
- Deduplication: If you pull the same date range twice, you need a merge strategy in BigQuery, not a straight append.
- Grain: Decide early whether you need campaign, ad group, ad, keyword, or creative grain. Mixing grains in one table causes the same row-multiplication problems as any marketing warehouse.
Meta Ads to BigQuery
Meta does not have a native BigQuery connector. The path is the Meta Marketing API + a Python pipeline.
The typical shape:
- Request reports via the Marketing API (asynchronous - you submit, poll, then download).
- Parse the response into rows.
- Load into a BigQuery staging table.
- Merge into a clean reporting table using a unique key (account + campaign + date + breakdown fields).
Key watch points:
- Rate limits: The Marketing API has per-account, per-app, and per-endpoint limits. A pipeline that works for one account may throttle when you add five more.
- Attribution windows: Meta reports change depending on the attribution window selected (7-day click, 1-day view, etc.). The window needs to be a column, not an assumption.
- Conversion values: Meta's reported conversion values can differ significantly from your actual revenue data. Flag this before building dashboards that mix Meta conversions with order data.
GA4 to BigQuery
GA4 has a native BigQuery export that is free for standard properties and streams event-level data daily or in real time with BigQuery linking. This is the cleanest path.
What to watch for:
- GA4 exports event-level rows, not session or campaign-level rows. Building session or campaign-level aggregations requires modeling on top of the raw export.
- Sampling is not present in the raw export (unlike the GA4 interface), which is the main reason to prefer BigQuery for serious analysis.
- The
events_intraday_*table is replaced byevents_*at the end of each day. Pipelines that query intraday tables need to account for this.
LinkedIn Ads to BigQuery
LinkedIn uses the Marketing Developer Platform API. There is no native BigQuery connector.
The pipeline follows the same pattern as Meta: API extraction, staging load, merge. LinkedIn's API is more restrictive than Google or Meta - rate limits are tight and some metrics require specific report types.
DV360 to BigQuery
DV360 (Display & Video 360) data can reach BigQuery through several paths:
- Bid Manager Reports: Scheduled offline reports exported to Cloud Storage, then loaded into BigQuery.
- DV360 API: Entity-level metadata (advertisers, campaigns, line items, creatives) through the Display & Video API.
- Ads Data Hub: Privacy-aggregated join of DV360 impression data with first-party data, queried within ADH's controlled environment.
DV360 is the most complex of these connections. The report export and metadata sync often need to be separate pipelines with separate trigger patterns.
What breaks in practice
Timezone mismatches. Ad platforms often report in account timezone. BigQuery stores in UTC by default. If you join Google Ads (Pacific time) with GA4 (UTC) on a date field, the numbers will not reconcile at day boundaries.
Schema drift. Ad platform APIs change field names, add new breakdown dimensions, and deprecate columns. Pipelines without schema validation break silently when a new field appears or an old one disappears.
Grain mismatch before the join. Campaign-level spend joined to creative-level performance joined to order-level revenue will multiply rows unless each side is aggregated to the same grain first.
Missing conversion windows. If your pipeline pulls a fixed lookback window, late-attributed conversions will not be captured. The result is that last week's numbers always look worse than they will after the conversion window closes.
How I build these connections
For marketing analytics warehouse projects, I build platform-specific extraction modules with:
- Explicit grain declarations per source
- Merge patterns in BigQuery (not append) to handle reruns and late data
- Spend reconciliation checks that compare loaded totals against platform exports
- Attribution window tracking as a column, not an assumption
- Schema validation before load
The goal is a warehouse where the numbers are trustworthy before they reach a dashboard.
Related projects
- Multi-Platform Ads Reporting Automation: Google Ads, Meta Ads, LinkedIn Ads, and Bing Ads into Google Sheets.
- Creative/Campaign Intelligence Data Platform: Meta and GA4 ingestion into BigQuery with Airflow orchestration.
- Dataform + BigQuery Marketing Analytics Warehouse: Layered warehouse with GA4, Google Ads, and Salesforce CRM.
If you need a reliable connection from Google Ads, Meta Ads, or other ad platforms into BigQuery, I can help scope and build it. The tricky parts are usually grain, deduplication, and attribution - not the API connection itself.