Google Ads Dashboards in Looker Studio 2026: Why Your Numbers Never Match

A scene that plays out in almost every agency on a Monday. The Google Ads interface says the account spent $47,310 last month on 1,208 conversions. The Looker Studio dashboard built on that same account says $45,880 and 1,174. Nobody can explain the gap in under five minutes, so everybody quietly goes back to the Google Ads UI and the dashboard becomes a slide that gets shown on calls and trusted by no one.

Looker Studio is almost never the liar in this story. The gap comes from how the connector pulls data, what blending does to rows, and which time zone the account happens to live in. This guide covers exactly where Google Ads Looker Studio dashboards drift away from the interface, how to build one in three layers so it can actually be debugged, the calculated fields nearly every account needs, the hard limits on data extracts, when to stop fighting and move to BigQuery, and a twelve-point acceptance checklist you can run before handing a report to a client.

What the native Google Ads connector actually gives you

The native connector is free, needs no middleware, and is enough for most single-account reporting. But it is a reporting slice, not a data warehouse, and treating it as the latter is where most broken dashboards begin.

What you pick when you connect

You choose an account and a report type. The report type decides which fields exist and at what grain rows arrive:

• Account — top-line metrics with no campaign breakdown.
• Campaign — the default choice for most dashboards: spend, clicks, impressions, conversions by campaign.
• Ad group — the same set one level down.
• Keyword / search term — what you bid on versus what actually triggered the ad.
• Ad / asset — the creative view.
• Video and other specialised views — availability depends on the campaign types running in the account.

The mechanic people skip: one data source holds exactly one report type. You cannot pull campaigns and search terms from the same source. If a page shows both, you already have two sources, and from that point on they must be configured identically — same account, same time zone, same freshness setting — or the two halves of your page will disagree with each other.

What the connector will not give you

• No change history. Who raised that tCPA and when lives in the Google Ads UI only.
• No data older than the report’s retention window for some views, search terms being the usual casualty. Long-run keyword retrospectives are not a connector job.
• No event-level rows. Everything is pre-aggregated, so a record-level click → lead → sale funnel is impossible here.
• No clean cross-account stitching out of the box. Connecting at manager-account level helps but behaves differently from what most people expect — see the currency section below and the separate breakdown of cross-account conversion tracking in Google Ads.
• None of your money. Margin, cost of goods, LTV — every profit figure comes from your systems, never from Google.

The native connector answers “what happened in the ad account.” It cannot answer “what did we earn.” That second question always requires a second source and a careful join.

Seven reasons Looker Studio and the Google Ads UI disagree

Before rebuilding anything, identify which of the seven is biting you — in practice it is one or two from this table.

Symptom	Likely cause	Where to look
Spend is off by roughly one day at either end of the range	Source time zone differs from account time zone	Data source settings
Spend is off by a multiple or an exchange rate	Manager-level source converting currencies	Account currency vs report currency
Today’s conversions look low, then grow all week	Click-date attribution plus conversion lag	Conversion column, conversion window
Numbers are from yesterday even after a refresh	Cache and data freshness setting	Source data freshness
Table total does not match the scorecard above it	Different date ranges on different components	Chart-level date range
Spend doubled after adding a breakdown	A dimension multiplying rows	Dimensions added to the table
Metrics went strange after blending	Join type plus non-unique keys	Blend configuration

1. Time zone

The most common and most annoying cause. A Google Ads account runs in the time zone chosen at creation, which cannot be changed without contacting support. The Looker Studio data source has its own. If the account is UTC+3 and the source is UTC, the day boundary shifts three hours and everything spent between 21:00 and midnight lands on the wrong date. Over a quarter this is invisible. On a “yesterday” report it can be a double-digit percentage error.

Fix: set the source time zone explicitly to match the account, and write it into the report documentation. If you manage accounts across several time zones, do not compare them day by day in one table — only by week or month.

2. Currency and the manager account

Connecting at manager-account level is convenient: one source, many accounts. But when sub-accounts bill in different currencies, Google converts to the manager account’s currency at its own daily rate, so your total will not reconcile against any individual account. That is by design, not a bug.

Fix: either report in the manager currency and label it clearly on the dashboard, or connect accounts individually and normalise currency yourself with a calculated field and a fixed rate. The second is more honest for unit economics but requires someone to maintain the rate.

3. Click date versus conversion date

Google Ads attributes a conversion to the date of the click, not the date the conversion happened. Someone clicks on 3 October and buys on 9 October; the conversion is written back to 3 October and only appears once it occurs. This is why yesterday is always undercounted and why last Tuesday keeps growing for another week or two.

In a dashboard it looks like this: you open yesterday, see a terrible CPA, panic, and five days later the same date looks fine. Nothing broke — the data backfilled. The lag mechanics are covered in detail in the piece on conversion windows and conversion lag in Google Ads.

Fix: never present the last one to three days as fact. Either shift the window (for example “last 30 days excluding yesterday”) or label recent dates as incomplete. And stop comparing yesterday with the same weekday a month ago — that is a partial period against a complete one.

4. Cache and data freshness

Looker Studio does not call the Google Ads API every time someone opens the report. Each data source has a data freshness setting that controls how long cached results are reused. The default interval differs by connector family and Google changes these from time to time, so the right move is to open the setting on your specific source and read it rather than rely on a number you remember.

Fix: shorten the interval for dashboards that drive daily decisions, lengthen it for weekly reporting so pages load faster. Either way, put a text box on the dashboard showing when the data last refreshed, so the person reading it knows what they are looking at.

5. Component-level date ranges

A table has its own date range, the scorecard above it has another, the page has a third. It looks like one report; it is three periods. One minute to check: click each component and see whether it has its own date range instead of inheriting the page default.

6. Dimensions that multiply rows

You add a device dimension and the spend total jumps. Usually spend is unchanged and you are reading a subtotal at the wrong grain — but sometimes it is genuine duplication, because certain dimensions belong to a different aggregation level and repeat the metric on every breakdown row. Which segments are compatible with which metrics is covered separately in the article on Google Ads report segments.

Rule of thumb: after adding any new dimension to a table, re-check the spend total against the previous version. If it moved, that dimension is not compatible with that metric at that level.

7. A blend built by eye

The most expensive mistake, and it gets its own section below. In short: if the join key is not unique on at least one side, the other table’s metrics multiply by the number of matches and spend inflates — silently, with no error anywhere in the report.

Building a dashboard you can trust: three layers

A reliable report is not a pile of charts but three layers, each with one job. Mixing them produces a dashboard nobody can debug later.

Layer 1: sources

This layer decides one thing only — where the numbers come from.

• One source = one report type = one account (or deliberately the whole manager account).
• Sources are created as standalone objects and reused across reports, not re-created inside each one.
• Time zone, currency and data freshness are set here and nowhere else.
• Names are self-documenting: GAds_Campaigns_UK-Account_UTC, not “Google Ads (2)”.

Layer 2: calculated fields

All business logic belongs here, at source level, not inside one chart. A CPA defined inside a single table does not exist in the table next to it, and a month later nobody remembers why two CPAs on one dashboard disagree.

Field	Formula (Looker Studio pseudocode)	Why you need it
CPA	Cost / Conversions	Baseline efficiency metric
ROAS	Conv. value / Cost	Anywhere conversion value exists
Click-to-conversion rate	Conversions / Clicks	Separates a traffic problem from a landing page problem
Campaign group	CASE WHEN REGEXP_MATCH(Campaign, '^BRAND.*') THEN 'Brand' ELSE 'Non-brand' END	Brand traffic must never be averaged with the rest
Margin ROAS	(Conv. value * Margin) / Cost	Moves the report from revenue to profit
Incomplete-day flag	CASE WHEN Date >= DATE_ADD(CURRENT_DATE(), INTERVAL -2 DAY) THEN 'Incomplete' ELSE 'Final' END	Honest labelling of recent dates

The campaign group field is quietly the most important one. It only works if campaign naming is disciplined — the same discipline described in the guide to UTM tagging and naming conventions. If a campaign is BRAND_UK_Search today and brand-uk-search-v2 tomorrow, every regex breaks without raising an error and the dashboard starts lying while looking perfectly healthy.

Layer 3: presentation

Layout only. No formulas, no “temporary” chart-level metrics.

• One page, one question. “Where the money went”, “What it produced”, “What broke” — three pages, not one twenty-widget wall.
• Five numbers above the fold, maximum. Spend, conversions, CPA, ROAS, share of budget. Everything else scrolls.
• Period-over-period comparison on by default. A number without a trend is trivia, not a decision.
• One inherited date range per page.
• Source, currency and last-refresh time in the footer of every page.

Blending: where it breaks and how to do it safely

Blending is where a sound report turns into a random number generator. The mechanic is simple and treacherous: Looker Studio joins tables on a key and returns the combined rows, so if the key is not unique, metrics multiply.

An example. On the left, spend by campaign from Google Ads — one row per campaign. On the right, CRM orders by order date — many rows per campaign. Join on campaign name. Each campaign’s spend now repeats once per matching order and total spend inflates by an order of magnitude, with no error anywhere in the report.

Rules for safe blends

• Aggregate before you join. Both sides must share one grain — one row per date-and-campaign pair on the left and the right. If the CRM delivers individual orders, roll them up to date and campaign first.
• Use a compound key with matching formats. Date plus campaign. And “date” must be a date type on both sides, not text, or the join quietly finds nothing and you see zeros instead of an error.
• Choose the join type deliberately. Left outer, right outer, inner, full outer and cross are available. For an ads-plus-sales blend you almost always want left outer with ads on the left, so campaigns with no sales still appear. An inner join silently deletes your losers and the dashboard reports a better ROAS than you earned.
• Keep the table count low. Looker Studio allows up to five tables in a blend (worth re-checking in the documentation, as Google has adjusted this), but the practical ceiling is lower — by the third table debugging becomes miserable. Needing more is a signal that the joining belongs in a warehouse, not in a report.
• Reconcile after every step. Built the blend? Compare total spend against the unblended source for the same period. A single cent of drift is worth solving now; in a month you will never find it.

One gap blending cannot close is the difference between the ad platform and your analytics tool — it only hides it. The nine reasons Google Ads and GA4 report different conversions are covered in the dedicated piece on the Google Ads and GA4 conversion discrepancy. If both systems appear on one dashboard, explain the delta before you draw the chart.

When the report is slow: Extract Data

A dashboard that takes twenty seconds to load does not get used. The usual cause: every component re-queries the connector on every open, and blends are recomputed live.

The built-in cure is Extract Data — a snapshot source. You pick the dimensions, metrics, filters and date range you need, and Looker Studio stores the result on its own infrastructure, so the report reads a snapshot instead of calling the API.

How to build one: from the home page choose Create → Data Source, pick Extract Data from the connector list, select the underlying source, drag in the fields you need, optionally set aggregation and filters, set a date range, switch on Auto update with a schedule, and click Save and Extract.

The hard limits that sink most attempts:

• Size: up to 100 MB. Beyond that the extract fails with an error.
• Rows: up to 750,000. Beyond that the data is truncated silently, leaving an incomplete report. This is more dangerous than the error, because nothing tells you.
• The data is static until the next scheduled refresh.
• Extracting from an aggregated source produces disaggregated data, and aggregation rules can differ from the original source, so totals may drift slightly from the live version.
• Deleting the extracted source deletes the data from Google’s servers.

Practical read: extracts are excellent for “campaigns over the last 13 months” and useless for “search terms across every account”, where 750,000 rows last about a fortnight. Current limits and the full procedure are in the official Extract Data documentation.

When to move to BigQuery

The native connector plus extracts cover most one- and two-account setups. Four signals say further fighting with Looker Studio is wasted time:

1. More than five to seven accounts that must appear in one table with shared naming rules and one currency.
2. You need history deeper than the connector returns, particularly for search terms and structural changes.
3. Three or more systems in one report — ads plus CRM plus billing plus call tracking.
4. You need real calculations: cohort analysis, payback by day since first click, product-level margin.

At that point Looker Studio stops being where data is joined and becomes what it should be: a presentation layer over a finished model. How the export works, what it costs and where the Google Ads data model double-counts is covered in the walkthrough of the Google Ads BigQuery Data Transfer.

Worth saying separately: no reporting architecture fixes incomplete conversion data — if the tag misses orders, the dashboard just renders the gap neatly. Google ships a native backfill for this: multi-source conversions connect a CRM or order database to an existing conversion action and fill missing records by transaction ID. That is measurement work, and it belongs before dashboard work.

AI reporting versus Looker Studio: what to give to which

Google Ads now offers AI-generated dashboards inside the interface: ask in plain language, get a report without a builder. The two do different jobs. A conversational report is excellent for a one-off check (“show campaigns where CPA rose more than 30% in two weeks”), and a poor permanent reporting layer: you cannot freeze it, it does not carry your business logic, and it does not reliably distinguish modelled data from observed data.

The split that works: Looker Studio is the standing instrument — same metrics, same rules, period over period. AI reporting is reconnaissance inside an anomaly that instrument surfaced. The piece on media buyer dashboards and reporting covers which rituals actually make a dashboard get looked at.

Acceptance checklist: twelve points

Run this before handing a report to a client, a manager, or your future self. Each item is a separate reason reports lose credibility.

1. Source time zone matches the account time zone.
2. Report currency is labelled on the dashboard itself.
3. Spend for the last closed month reconciles with the Google Ads UI to the cent.
4. Conversions for the last closed month reconcile with the UI.
5. The last one to two days are either excluded or labelled incomplete.
6. Every component on a page inherits one date range.
7. All calculated metrics live at source level, not inside charts.
8. For every blend, spend total is unchanged versus the unblended source.
9. Brand and non-brand traffic are separated.
10. Every page shows “data last refreshed at time“.
11. The report opens in under five seconds.
12. Access follows least privilege: view for everyone, edit for one or two people.

That last point is chronically underrated. A report anyone can edit becomes a museum of other people’s formula experiments within six months — especially when in-house teams, freelancers and agencies all read the same data on shared or Google Ads agency accounts. One reporting layer, one owner with edit rights.

Five mistakes that cost money

Mistake 1: comparing a partial period with a complete one

“CPA is up 40% this week” is meaningless when the week is not over and conversions are still backfilling. Compare closed periods only, or the first N days of this period against the first N days of the last.

Mistake 2: averaging the CPA column

The arithmetic mean of a CPA column is not the account’s CPA. The correct figure is total spend divided by total conversions. In Looker Studio that means CPA must be a calculated field over aggregates, not an average of rows. The error is silent: the number looks plausible and is always biased.

Mistake 3: not knowing which conversions you are looking at

The Conversions column only contains actions flagged to be included in it. If primary and secondary conversion actions are configured differently from what you assume, the dashboard shows a number that bidding is not optimising towards. Verify this in the conversion action settings in the UI, not in the report.

Mistake 4: one attribution model in the account, another in your head

Google Ads reports conversions under its configured attribution model while you read them as last click. On channels with heavy assisted activity the gap reaches double digits. The models and how they rewrite history are covered in the piece on attribution models: DDA versus last click.

Mistake 5: building the dashboard before fixing measurement

The most expensive one. A polished report on bad data is worse than no report, because it manufactures confidence. The order is always the same: conversion actions and their completeness, then tagging and naming, then reporting. Starting at step three guarantees a rebuild a month later.

What to do this week

1. Reconcile spend and conversions for the last closed month against the UI. Write the gap down as a percentage.
2. If it drifts, walk the seven-cause table from the top, starting with time zone.
3. Move every formula out of charts and into the data source.
4. Test each blend for inflation: spend total before versus after.
5. Add source, currency and refresh time to every page footer.
6. Exclude the last two days from headline widgets, or label them incomplete.

A good dashboard is not the one that looks best. It is the one nobody re-checks in the Google Ads UI afterwards. Reconciliation beats design, and it is won at the data source layer, not in the charts.

If reporting is one part of a wider paid-traffic build, see what else is covered on the infrastructure side: services and tools for working with Google Ads.

FAQ: Google Ads dashboards in Looker Studio

Why is spend in Looker Studio lower than in Google Ads?

Nine times out of ten it is one of three things: a time zone mismatch between the source and the account, a stale cache, or a forgotten component-level filter. Check in that order — a gap of exactly one day is nearly always the time zone.

Can I connect several Google Ads accounts to one data source?

Yes, by connecting at manager-account level. But if sub-accounts bill in different currencies, Google converts them to the manager currency at its own rate and your total will not match any individual account. For precise unit economics, connect accounts individually.

How often does Looker Studio data refresh?

On the cache schedule set by the data freshness option on each source, not on every page view. Defaults vary by connector family and change over time, so open the setting on your own source and read it rather than assume. Shorten it for daily decisions, lengthen it for weekly reporting and faster loads.

Why did total spend increase after I blended data?

The join key is not unique on at least one side, so each left-hand row matched several right-hand rows and the metric multiplied. Fix it by aggregating both tables to the same grain — usually date plus campaign — before joining.

Which join type should I use for ads plus CRM?

Almost always a left outer join with ads on the left, so campaigns with zero sales still appear. An inner join silently drops your losing campaigns and the report shows a better ROAS than reality.

How much data fits in an extract?

Up to 100 MB and up to 750,000 rows. Exceeding the size fails the extract with an error; exceeding the row count truncates the data with no obvious warning, which is the more dangerous of the two.

Why do yesterday’s conversions keep changing?

Google Ads attributes conversions to the click date, not the conversion date. Someone who clicked yesterday and buys next week is written back to yesterday, so that day keeps filling in. Never present the last one to three days as final.

Do I need a paid connector instead of the native one?

The native connector is enough for one or two accounts and standard views. Paid connectors are bought for automatic stitching of many ad platforms and deeper history. If the real job is joining three or more sources, a BigQuery model is usually cheaper and sturdier.

Can Looker Studio report profit instead of revenue?

Yes, but only if you supply the margin. Create a calculated field with a margin coefficient and report margin ROAS. If margin varies by product, one coefficient will not do — you need a cost-of-goods feed joined at product level, which is warehouse territory.

Why does my report take twenty seconds to load?

Usually three things together: too many components on one page, several blends recomputed live, and a long date range. Fix with Extract Data, splitting pages, and cutting widgets above the fold.

How should I share a report with a client?

Share view access to the report rather than to the underlying data sources, and check the source’s credential mode: owner credentials let the client see data without their own account access, viewer credentials require it. Keep edit rights with one or two people.

Where do I start if I have no dashboard yet?

One page and five metrics: spend, conversions, CPA, ROAS and share of budget by campaign group. Build it, reconcile it against the UI for a closed month, reach exact agreement, and only then add breakdowns. A report that reconciles on five numbers grows easily; one that never reconciled can never be repaired.