Google Ads
Source Advertising

Google Ads

Campaign spend, clicks and conversions in the same database as the revenue they are supposed to explain.

Insightlytics ingests your Google Ads data — spend, clicks, impressions and conversions from campaign down to the search term — through the native BigQuery Data Transfer, the Google Ads API or both. We normalize micros into money, re-sync recent days until late conversions settle, and model it into data models that sit next to your GA4 sessions — so cost per acquisition is computed from spend and outcomes in one place. You get the tables and the history; we run the transfers, the API pacing and the monitoring. Everything is written to a database you own — BigQuery today, with more warehouses on the roadmap.

What we ingest

Google Ads exposes its reporting two ways, and they do not carry the same things. We land the raw report tables first and model on top — so you keep the source rows, not just our interpretation of them.

  • ads_Campaign_ / ads_AdGroup_ / ads_Ad_ Data Transfer

    The structure tables: campaigns, ad groups and ads with their settings and status, landed per day so a renamed campaign does not quietly rewrite last quarter.

  • ads_CampaignBasicStats_ Data Transfer

    Daily impressions, clicks, cost and conversions, with the matching segment tables alongside for device, network and geography splits.

  • Search terms API only

    Not part of the native transfer at all. If wasted spend matters to you, this is the report that shows it — and the API is the only way to get it.

  • Custom GAQL reports API

    Anything the fixed transfer schemas cannot express, pulled on our schedule and subject to the metric–segment compatibility rules.

Which of these you end up with depends on the route, and that decision is covered further down, in how we work with Google Ads data.

The problems we solve

Google Ads data is easy to look at and hard to report on — the numbers keep moving, the formats fight you, and the join to your analytics is on you. These are the problems this pipeline is built around.

How do you join Google Ads cost with GA4 sessions?

Out of the box, you don’t — spend lives in one silo and sessions in another, and the join is on you. It needs campaign keys that actually match, UTM conventions that survive renames and both sides landed in the same database at the same grain. Most teams settle for eyeballing two dashboards instead.

We build that join into the data models: campaign names parsed into market, product and funnel-stage columns, keys aligned with your GA4 session models, and cost sitting next to the sessions and revenue it bought. That’s the foundation a real cost-per-acquisition number stands on.

Which CPA is the true CPA — Google Ads or GA4?

They will not agree, ever. Different attribution models, different count dates (Google Ads writes conversions back to the click date, GA4 counts events on the day they happen), different visibility into the journey. Neither is broken, and picking one at random just moves the argument to next quarter.

The data models put both next to each other in clearly labelled columns, computed over the same spend rows — which turns a recurring argument into a known, stable difference you can decide against.

Why do last week’s Google Ads conversions keep changing?

Conversion lag. A click today can convert next week, and Google writes that conversion back onto today’s row. Any export that pulls each day once diverges from the interface within days.

The pipeline’s rolling re-sync window exists precisely for this — recent days are re-pulled until they stop moving, so the data models converge on final numbers instead of freezing the early ones.

Why is the native Google Ads transfer so hard to query?

The BigQuery Data Transfer lands dozens of fixed report tables — campaign, ad group, ad, a family of *Stats tables — with cost serialized as micros: millionths of the account currency, as ten-digit integers. Forget the division once and a dashboard reports a million times the spend.

The transfer is a delivery mechanism, not a model. We treat it as one: normalization, rounding policy and currency conversion happen in the pipeline, and what your team queries are data models where cost is simply money.

Why don’t search terms sum to campaign totals?

Two reasons. Google withholds low-volume search terms for privacy, so the search-term report is a large sample, not a census. And the terms aren’t in the native transfer at all — they exist only on the API route, which is why transfer-only setups never see them.

We pull search terms through the API alongside whichever route carries the rest, and the data models record both levels so the withheld share is a measurable number, not a suspicion.

How we work with Google Ads data

Two routes exist — the native BigQuery Data Transfer and the Google Ads API — and choosing between them is a consulting decision, not a checkbox.

The native transfer lands Google’s fixed report tables on schedule, re-lands a 7-to-30-day window as conversions settle and isn’t metered by your developer token — but it doesn’t carry search terms and its schemas are take-it-or-leave-it. The API can express any report GAQL can — search terms included — but it’s paced by access tiers and operation quotas, and metric–segment compatibility rules decide what can be pulled together. Which route fits depends on the reports you need, the size of your MCC and how deep the join to GA4 has to go.

We settle that together on the discovery call. Many accounts end up on both — the transfer for the standard report tables, the API for search terms and custom shapes — feeding the same data models. Either way, running the pipeline is our job: no connector to configure, no quota to babysit.

Delivered to a database you own

Every table — raw and modeled — is written to your own database, under your billing and your access controls. Our access is read-only, and if we part ways, everything stays with you.

  • BigQuery BigQuery Your data models are built in your own BigQuery project — our access is read-only, and the tables are always yours.

BigQuery is the supported database today. If you run a different warehouse, tell us — the roadmap is driven by requests.

How current the data stays

Data models rebuild every day. Where a platform restates recent numbers after the fact, we re-read those days rather than freezing the first version we saw.

Refresh

Daily. API syncs re-pull a rolling lookback; the native transfer’s refresh window re-lands recent days — either way, late conversions and invalid-traffic removals flow through instead of freezing.

Backfill

First sync loads the report history the API exposes; the native transfer backfills in chunks of up to 180 days, as far as your account’s history reaches. From then on everything accumulates under your retention, not the platform’s.

Monitoring

Every sync is checked for freshness, volume and schema drift. Google Ads API versions rotate on a fixed cadence; upgrades happen inside the pipeline, so field renames never reach your data models.

What lands in your database

Not raw API responses — data models: named, documented tables at a stated grain, rebuilt every day and ready to query. Each one has its own page.

The shipped data models are the starting point, not the ceiling. When your questions need a different shape — another grain, another split, a join against another source — we build additional models for your stack as part of the engagement.

Put ad spend next to the revenue it’s meant to explain.

Tell us how many accounts you run and what you need cost joined against. We’ll map the route, the data models and the grain that makes the join hold.

Free discovery call · No commitment — leave with a starting point