Since September 9, 2026, a “Dashboard” button has appeared in the ”+ Create” menu of your Google Analytics reports. And if you already maintain a dozen Looker Studio reports wired to GA4, the first question GA4 Dashboards raises is not “how does it work”. It is: can I retire some of them, and exactly which ones? This article will not walk you through thirty screenshots to build your first dashboard. It answers the only thing that matters when you inherit an unmanageable pile of dashboards: which reports to move to native, which ones never to touch, and why. One quick naming note, because it causes real confusion: since April 2026, Looker Studio has been renamed back to Data Studio (with a free Data Studio tier and a paid Data Studio Pro tier). I use both names in this article; they mean the same tool.
What changed on September 9, 2026
GA4 Dashboards is a native dashboard builder, baked directly into the property. You reach it through Reports, the ”+ Create” button, then “Dashboard”. You drop cards onto a grid canvas by drag-and-drop, and you publish the dashboard straight into the property’s left-hand navigation, with no report library and no third-party tool involved.
On paper it looks like a miniature Looker Studio locked inside GA4. In practice it is something else, and the trap would be to treat it as a Data Studio replacement. It is not one. It is a fast internal-reporting tool with very sharp limits that draw its usage boundary precisely. Those limits are not footnote-level technical details: they are what decides, report by report, whether you can migrate or not.
What GA4 Dashboards can do
The concept is deliberately simple. A grid canvas, cards you drop and resize, and six families of visualizations: scorecards, tables, line charts, bar charts, donuts, and funnels. That last one deserves attention: the funnel used to be near-exclusive territory of Explorations. Seeing it land in a native dashboard, publishable in one click, is directly relevant to ecommerce teams that want to show a purchase funnel without building a full exploration.
The real novelty is not visual, it is in the plumbing. A native dashboard publishes into the left-hand navigation and becomes visible to the whole property. No export, no share link to manage, no connector to configure. To create and publish, you need the Editor or Administrator role on the property; everyone else can view. Short, factual, and already enough for many teams that have never opened Looker Studio in their life.
The five limits that decide everything
Here is the heart of the matter. Five limits, documented by Google, that on their own determine what Dashboards replaces and what it never will. Take them one by one, with the practical consequence.
| Limit | Detail | Practical consequence |
|---|---|---|
| Number of cards | 15 max on standard properties, 30 on 360 | You cannot rebuild a 40-block client report |
| API | Not supported | No automation, no versioning, no multi-property deployment |
| Segments | Not supported | Any cohort or audience view stays in Explorations |
| Card-level comparisons | Not supported | Comparison is page-wide only, never per card |
| Sharing | Any published dashboard is shared with the property | No “draft” dashboard visible to you alone once published, and no sharing to an outsider without property access |
Add a sixth constraint that often slips past people: you are limited to native GA4 metrics. No on-the-fly calculated metric, no custom field the way Data Studio allows. If your client report relies on a homemade ratio (cost per qualified lead, margin per channel), Dashboards will not produce it.
Each of these limits is a boundary. The card cap rules out the dense report. The missing API rules out anything that must run on its own or be duplicated. The lack of segments sends audience analysis back to Explorations. Property-wide sharing rules out the confidential report and the client report. Internalize that, and half your migration decisions are already made.
What Dashboards fixes that Looker Studio never did
Here is the part nobody will write, because it does not make a good announcement headline. For many teams, the daily pain of reporting was never “I want more visualizations”. It was “my report throws a quota error at 9 a.m.” The Looker Studio GA4 connector goes through the GA4 Data API, and that API has quotas. A slightly ambitious dashboard, opened by several people at once, and you hit the infamous error message, the half-empty report, the card that will not load.
A native dashboard reads the data where it lives. No connector, no Data API in the loop, so no quota error. That is the decisive argument for a team living with a broken report one morning in three. If your pain is reliability rather than richness, Dashboards solves your problem overnight.
Be careful not to over-read this. Thresholding and sampling are behaviors of GA4 itself, not of the connector. Going native removes the API quota errors, not the limits of the data. A thresholded number stays thresholded in a native dashboard. If you see gaps in your data today, first check whether it is a report broken by the connector or a genuine collection problem: those are two different diagnoses, and Dashboards only fixes the first.
Dashboards, Explorations, custom reports, or Data Studio: the comparison
This is the table everyone is looking for and that Google documents poorly. Four reporting surfaces, four uses, not to be confused.
| Criterion | Dashboards | Explorations | Custom reports | Looker / Data Studio |
|---|---|---|---|---|
| Audience | Internal, quick steering | Analyst, ad hoc | Internal, standard report | Client, external, leadership |
| Segments | No | Yes | Partial | Yes |
| Source blending | No, GA4 only | No, GA4 only | No | Yes, multi-source |
| External sharing | No, via the property | No | No | Yes, link or PDF |
| Automation / API | No | No | No | Yes, connectors and scheduling |
| Complexity ceiling | Low, 15 cards | High | Medium | Very high |
Quick read: Dashboards owns the “internal KPI page checked every morning” slot. Explorations keep fine-grained, segmented analysis. Custom reports stay the standard table inside the interface. And Looker / Data Studio keeps everything client-facing, external, blended, and automated. Each in its own slot, and above all: stop making Looker Studio do the job of a plain KPI page.
The decision grid in 6 questions
You have a report in front of you and you wonder where it should live. Answer these six questions in order. The first “yes” that pushes you out of Dashboards settles it.
- Do you need to combine GA4 with another source (cost, CRM, BigQuery)? If yes, it is not Dashboards. Head to Looker / Data Studio or BigQuery.
- Does the recipient have access to the GA4 property? If no, it is not Dashboards. A native dashboard does not share outside the property.
- Do you need segments or an audience-based view? If yes, that is Explorations.
- Does the report need to deploy across several properties? If yes, it is not Dashboards: no API, no cross-property duplication.
- Do you exceed 15 blocks (30 on 360)? If yes, native will not keep up.
- Does the report need to survive a tool change, or be versioned? If yes, stay on an exportable surface.
If you answer “no” to all six, congratulations: your report belongs in a native dashboard, and you can probably retire its equivalent from your Looker Studio stack. Otherwise, you now know exactly why it must live elsewhere.
The BigQuery case
For this blog’s audience, this is the fault line. Dashboards only reads GA4. Full stop. Anything involving the BigQuery export, custom queries, imported cost data, CRM joins, or blended tables is out of native’s reach. If your reporting relies on BigQuery, Dashboards does not reduce the value of that export, it relocates it: native takes the “pure GA4 steering” layer, and BigQuery keeps everything else.
Concretely, the BigQuery-to-Data-Studio pipeline that many of you maintain stays perfectly valid. It even gains clarity now that a native tool absorbs the simple reports. If you have not yet industrialized that flow, the full method is laid out in Automating your reports with Looker Studio and BigQuery, still current despite the rebrand. And for anything that must leave the Google world (Power BI, Tableau, another BI tool), routing through BigQuery remains the right door, detailed in Exporting your BigQuery data to Power BI, Tableau, and Looker.
Migrating, in practice
Do not delete anything in a hurry. The right method has four steps: inventory your existing Looker Studio reports, classify each against the question “does it read GA4 only, no segments, under 15 blocks?”, rebuild the candidates as native dashboards, and test them across a full reporting cycle before deleting anything. A month of running both costs less than a deleted report that quietly mattered to someone.
The first to move are always the same: the internal KPI page checked every morning, the simple campaign tracker, the standard ecommerce funnel. The ones you never touch: the client report, the BigQuery-blended report, the segmented report, the automated report.
The 3 Looker Studio reports you can retire this week. One, the KPI home page (sessions, users, conversions, revenue) the whole team checks: it fits comfortably in 15 cards and never leaves the property. Two, the weekly tracker for a single campaign, with no blending or imported cost. Three, the basic SEO dashboard wired to GA4 alone (pages, organic channel, key events). None of those three still justify a connector that crashes; rebuild them native, let them run one cycle, then archive the originals.
One prerequisite, though: a dashboard built on a misconfigured property reproduces the error, more visibly. Before you freeze your reports in native, a quick GA4 configuration audit keeps you from casting a shaky configuration in stone.
The pitfalls in daily use
Three pitfalls recur, and the third is the most original because nobody documents it.
The 15-card cap arrives faster than you think. Stack five scorecards, two line charts, three tables, and you are already there. Design your native dashboards for the essentials, not for exhaustiveness: this is not a client report, it is a steering page.
Publishing means sharing with the entire property. There is no “private draft” once published. Warn the team before you push a dashboard into the left-hand navigation, or everyone inherits your half-finished experiment.
And the most blocking one for multi-property setups: with no API, a dashboard cannot be saved, exported, or duplicated from one property to another. For an agency managing thirty clients, or a multi-brand group, that means rebuilding everything, property by property, by hand. No central deployment, no reusable template. This is probably the limit that disqualifies Dashboards for half of this blog’s readers, and it deserves to be stated plainly rather than buried in a feature list.
Conclusion: a three-tier reporting architecture
The answer to the title’s question is not “abandon Looker Studio”. It is: you will retire about a third of it, and knowing which third will save you serious time. The architecture that holds up in 2026 has three tiers. Dashboards for daily internal steering, fast and reliable. Looker / Data Studio on BigQuery for the client report, blends, and automation. Explorations for ad hoc, segmented analysis. Each in its tier, and above all: stop asking a Looker Studio dashboard wired straight to the GA4 connector to do a KPI page’s job, because that intermediate layer is exactly the one getting squeezed.
Because that is the real underlying shift. Google is re-internalizing reporting inside GA4 (Dashboards, Ask Advisor, generated insights) at the very moment it pushes advanced analysis toward BigQuery. The Looker Studio dashboard wired straight to the connector, the one that lived in between, is caught in a pincer from both sides. If you want to understand the other side of that shift, the assistant absorbing the analysis, take a look at GA4 Ask Advisor: is Google’s AI replacing the data analyst?. Run the inventory this week, test across one cycle, and you will head into Q4 with lighter, more reliable reporting.