Build a Professional Looker Studio Google Ads Dashboard

Looker Studio became a standard tool in my reporting workflow not because it was the most powerful option available, it isn't, but because it sits at the right intersection of capability, accessibility, and shareability. A Looker Studio Google Ads dashboard connects live to the account, updates automatically, and can be shared with a client or stakeholder via a URL without giving them access to the Google Ads account itself. That last point alone made it irreplaceable for client work.

My first Looker Studio reports were functional but shallow: a time series of spend and conversions, a campaign table, a date range control. Over time, as I learned the Google Ads connector in depth, started using calculated fields for custom metrics, and understood how data blending changes what's possible, the dashboards I build became genuinely different from what Google Ads exports on its own. This article documents that evolution, not as a feature walkthrough, but as a practitioner's account of what actually matters when building professional reports for real accounts.

The Looker Studio Google Ads connector

The Looker Studio Google Ads connector is the native bridge between Looker Studio and a Google Ads account. Connecting it is straightforward: from the Looker Studio home, click Create → Data Source → select the Google Ads connector → authorize access → select the account. Full setup documentation is at Connect to Google Ads. The connector supports individual accounts and manager accounts, with MCC connections covering up to 50 sub-accounts per data source.

Overall Account Fields vs. individual report types

When configuring the Google Ads connector in Looker Studio, you choose between "Overall Account Fields" and specific report types (Campaigns, Ad Groups, Keywords, etc.). The Overall Account Fields option combines all available dimensions and metrics into a single data source, convenient for quick setup but potentially misleading. Some metric combinations are only valid at certain entity levels: mixing keyword-level quality scores with campaign-level impression share, for example, produces null values for one of the dimensions depending on the query scope.

From experience: I always create separate data sources for the report types I actually use, one for campaign-level data, one for ad group level if needed, one for keywords. The temptation to use Overall Account Fields and build everything in one data source is real, but the aggregation behavior differences between entity levels will catch you eventually. A campaign-level time series and a keyword-level table in the same report should use different data sources that share the same Google Ads account connection.

What the connector exposes that the native interface doesn't organize well

The Looker Studio Google Ads connector exposes the same data as the native Google Ads interface, but the reporting layer makes certain analyses significantly easier. Segment-level breakdowns, device, network, day of week, ad format, that require creating separate report views in Google Ads can be combined in a single Looker Studio chart by adding a dimension and a breakdown dimension. The date range dimension in the connector also makes period-over-period comparison charts trivial to build, something the native interface handles only through the "Compare" toggle, which doesn't persist across exports or shares.

Calculated fields in Looker Studio for Google Ads

Calculated fields are the most underused feature in Looker Studio Google Ads work. They let you define custom metrics and dimensions directly inside the data source or within individual charts, using formulas that combine existing fields with arithmetic, conditional logic, and text functions. The complete reference is at About calculated fields.

Data source calculated fields vs. chart-specific calculated fields

There are two types of calculated fields in Looker Studio. Data source calculated fields live in the data source configuration and are available in any chart in any report that uses that data source, they behave like native fields. Chart-specific calculated fields exist only inside the chart where they're created and cannot be reused, but, unlike data source fields, they are the only kind that works on blended data. For Google Ads reporting, I create calculated fields at the data source level when the metric is something I'll use across multiple charts or reports: a custom ROAS formula, a CPA classification label, a weighted efficiency score. Chart-specific fields I reserve for one-off display formatting, like truncating a campaign name for a chart where full names won't fit, and for any metric that has to sit on top of a blend.

The calculated fields I actually use on Google Ads dashboards

Three calculated fields have become standard in every Looker Studio Google Ads dashboard I build:

The first is a custom ROAS field built around only the conversion actions I define as primary, rather than the "All conversion value" metric that includes every tracked action regardless of its relevance to the business goal. The core formula is SUM(Conversion Value) / SUM(Cost); the restriction to specific conversion actions is applied through a chart-level filter or a CASE expression, since the standard connector fields don't expose this slice on their own.

The second is a CPA performance label, a conditional field using CASE WHEN syntax that returns a text label ("On Target," "Within Range," "Over Target") based on the campaign's CPA relative to a threshold I set. This field drives a color-coded scorecard in the executive summary page of the dashboard, replacing a raw CPA number with a status that non-specialist stakeholders read in seconds.

The third is a cost efficiency ratio: SUM(Conversions) / SUM(Cost) * 1000, normalized to a per-thousand-spend basis, which makes campaigns with very different budget scales directly comparable in a single sorted table.

How to create and edit calculated fields

To create a data source calculated field: open the data source editor (Resource → Manage added data sources → Edit), click Add a Field → Add calculated field, write the formula, name the field, and save. The full step-by-step is documented at Add, edit, and troubleshoot calculated fields. Field names must be unique within the data source and cannot use reserved keywords, a minor but recurring source of errors when naming fields like "Cost" or "ROAS" that conflict with native field names.

Data blending: combining Google Ads with other sources

Data blending in Looker Studio allows merging data from multiple connectors into a single chart. For Google Ads dashboards, the most common use cases are: combining Google Ads spend data with GA4 session and revenue data on a shared Date dimension, joining Google Ads campaign-level data with a Google Sheets table that contains target CPA or budget goals per campaign, and merging Search Console impression share with Google Ads paid impression data for a unified search visibility view.

The official documentation for creating and configuring blends is at Create, edit, and manage blends.

The join key problem and how to solve it

Every blend in Looker Studio requires a join key, a shared dimension that exists in all the data sources being combined. For time-based blending, Date works well. For campaign-level blending, Campaign Name works if the naming is consistent across platforms, which in multi-channel accounts it often isn't. A Google Ads campaign named "Brand_Search_Exact" and a GA4 source/medium group labeled differently won't join unless you define a normalization layer, typically in a Google Sheets mapping table that translates between naming conventions.

From experience: the join key problem is the single biggest reason data blending fails in practice. I've seen dashboards where the blend nominally works, no error shown, but returns null values for 60% of campaigns because the names don't match exactly. Looker Studio's left outer join (the default) keeps all rows from the primary data source and fills nulls for unmatched rows from secondary sources, so a mismatched join looks like missing data rather than an error. Always validate a blend by looking at the row count of the blended source versus the row count of each individual source before adding visual complexity.

Blending performance considerations

Blended data sources in Looker Studio query each underlying source independently, then join the results. This means performance degrades with the number of fields included in the blend, a blend with 20 fields from three sources will load significantly slower than one with 5 fields from two sources. The documented best practice is to include only the fields you'll actually use in charts from a given blend. This is covered in detail at Blending tips and advanced concepts.

Building professional Google Ads dashboards: what I learned from real accounts

The page structure that works for client dashboards

A professional Looker Studio Google Ads dashboard for a client needs to answer three audiences: the executive who wants a number and a trend, the account manager who needs campaign-level detail to act on, and the analyst who needs segment breakdowns to diagnose. Trying to put all three audiences on one page produces a report that's too long and too noisy for anyone. I structure dashboards with three pages: an executive summary (scorecards, a spend-vs-conversions time series, a CPA status indicator), a campaign performance page (sortable table with all key metrics, a budget pacing chart), and a segment analysis page (device, network, day-of-week breakdowns, keyword-level data if relevant).

From experience: the executive summary page is the one clients actually open. The campaign performance page is the one account managers use for decisions. The segment analysis page is the one I use during monthly calls to explain anomalies. Designing for these three distinct use cases, rather than for "all the data in one place", changes what goes on each page and how it's formatted. The executive summary uses large scorecards with comparison periods and almost no tables. The segment analysis uses tables with conditional formatting and almost no scorecards.

Date range controls and comparison periods

Every Looker Studio Google Ads dashboard should have a report-level date range control that applies to all charts simultaneously. But the comparison period, showing this period vs. the previous period, requires a deliberate choice about what "previous period" means. Looker Studio supports previous period (same number of days immediately before), previous year (same dates one year prior), and custom comparison ranges. For most Google Ads dashboards, previous period is correct for short-term monitoring and previous year is correct for accounts with strong seasonal patterns. Mixing both on the same report without clearly labeling which comparison applies to which chart is one of the most common sources of dashboard confusion in shared client reports.

Sharing a Looker Studio Google Ads report without sharing account access

One of the most valuable properties of a Looker Studio Google Ads report for client and stakeholder work is that sharing the report doesn't share the underlying Google Ads account. Viewers of the report see the data that the report's data credentials allow, which are determined by the account that created the data source, not by the viewer's own Google account. This means you can share a dashboard with a URL, have the client see live campaign data, and never grant them any role in the Google Ads account itself. The sharing mechanics for data sources are documented at Share reusable data sources.

What breaks Looker Studio Google Ads dashboards

The most common failure mode is authorization expiry: Looker Studio connects to Google Ads via an authorization token that can expire or be revoked, causing the data source to return an error rather than live data. The report still loads visually, but all charts show "Data set configuration error", alarming for clients who see it before you do. The fix is to reconnect the data source from Resource → Manage added data sources → edit the connection. Prevention: check that the Google account used for the data source connection is a stable service account or admin account, not a personal account that might be deactivated if someone leaves the organization.

From experience: I've had this happen to a client dashboard during a quarterly business review, the client opened the report before the call and saw error messages across every chart. The data was fine; the token had expired. It took three minutes to fix but fifteen minutes to recover the call. Since then I build a weekly automated check: a simple Apps Script that tries to fetch one row from the data source and emails me if it fails. Not a Looker Studio feature, just a wrapper around the potential failure mode.