GA4's 15-Card Dashboard Limit and SaaS Metric Sprawl

On September 9, 2026, Google added drag-and-drop Dashboards to GA4 — and capped them at 15 cards on standard properties and 30 on Analytics 360. The feature is a real usability upgrade: a flexible, single-report way to see your KPIs with intuitive visualization building. But the number is the story for SaaS teams. A hard card limit turns dashboard construction from an accumulation habit into a prioritization decision, and most SaaS measurement sets are not organized to survive that constraint. PPC Land reported the rollout as drag-and-drop dashboards limited to 15 cards, and that ceiling is exactly what forces the useful question.

This post treats the card limit not as a complaint but as a forcing function. It covers what the limit actually is, why 15 cards exposes metric sprawl in a growing SaaS, how to decide which metrics earn a card, where the line falls between GA4 and a dedicated product analytics tool, and how to structure the dashboards you do build around decisions rather than around whatever data happens to be available. The goal is a primary view your team acts on, not a gallery nobody reads.

What the card limit actually is

GA4 Dashboards, released September 9, 2026, let you assemble a single report from cards — scorecards, time series, tables, bar charts, and the newer report visualizations — using drag-and-drop placement. Each dashboard holds a maximum of 15 cards on a standard property and 30 on a 360 property. The limit is per dashboard, not per account, so you can create more dashboards; what you cannot do is put a 16th card on a standard dashboard. For a small site that is plenty. For a SaaS company tracking signups, activation events, trials, plans, channels, campaigns, and revenue, 15 slots is a budget that runs out fast.

It helps to be precise about what a card represents. One card is one answer to one question: "how many signups this week," "which channel drove paid conversions," "what is the trend in trial starts." Under an unbounded model, teams rarely have to decide whether a question is worth a permanent slot — they just add it. The card limit reintroduces scarcity, and scarcity is what makes a dashboard legible. The same discipline underpins our decision-first analytics framework: a metric earns a place on the dashboard by being tied to a decision someone actually makes.

Why 15 cards exposes metric sprawl

Metric sprawl is the default failure mode of a growing SaaS analytics setup: metrics get added far faster than they get retired, because adding one satisfies a stakeholder and removing one requires an argument. An unbounded dashboard hides the cost of that accumulation — the view just gets longer, and everyone stops reading past the fold. The 15-card cap makes the cost visible and immediate. Suddenly the third variant of a vanity chart is competing directly against the one metric that predicts churn, and someone has to choose.

That competition is healthy, but it surfaces an uncomfortable truth: a large share of what SaaS teams try to cram into GA4 is not acquisition data at all. It is product-behavior data — activation funnels, feature adoption, retention cohorts — that GA4's model handles poorly even when it can display it. The card limit does not create that mismatch; it just stops you from papering over it with more cards. Deciding what to keep forces you to confront the difference between product analytics and web analytics, which is the real boundary the limit is pushing you to draw.

Deciding which metrics earn a card

Rank candidates by decision value, not by how interesting they look. Start from the decisions your team makes on a weekly cadence — where to put budget, whether onboarding is working, which channel to double down on — and admit only the metrics that directly inform one of them. A metric that no one would act on if it moved does not earn a card, no matter how many times it has been requested. This is a ruthless filter, and applied honestly it usually leaves fewer than 15 survivors, which means the limit was never the real constraint — the missing prioritization was.

A simple test: for each candidate card, write the sentence "if this number changes, we will do X." If you cannot finish the sentence, the card is reference data, not a dashboard KPI, and it belongs in an explore report someone pulls on demand rather than on the daily view. Anchor the survivors to a single top metric so the dashboard has a spine; our guide to the north-star metric selection framework covers how to pick the one number the rest of the cards should explain.

What belongs in GA4 versus a product analytics tool

The cleanest way to spend a 15-card budget is to stop asking GA4 to answer questions it was not built for. GA4 is strong at acquisition and traffic: sessions, channels, campaign performance, and site-level conversion events. It is weak at in-product behavior: multi-step activation funnels, feature-level adoption, and cohort retention curves are awkward or impossible to express in its reporting model. When a card you want is really a product-behavior question, the fix is not a smaller GA4 card — it is moving that question to a tool designed for it.

A rough split for where each metric class should live:

Drawing this line does more than free up cards. It stops teams from misreading GA4's structural gaps as their own instrumentation failures — a trap we cover in GA4's native reporting gaps. And it means the GA4 dashboard becomes what it is good at: a tight acquisition-and-conversion view, not a failed attempt at a product analytics suite. The funnel-chart limitations specifically are worth understanding before you commit any card to a funnel, which our piece on GA4 dashboards versus product analytics for funnels walks through.

Structure dashboards around decisions, not availability

With a finite card budget, the organizing principle should be the decision the dashboard supports, not the data that happens to be on hand. Build one dashboard per recurring decision and per audience: an acquisition view for whoever owns channel spend, a conversion view for the growth team, an executive view for the leadership standup. Each gets its own 15 cards spent entirely on the question that view exists to answer, which keeps every dashboard legible and every card accountable to a reader who will act on it.

The anti-pattern to avoid is using multiple dashboards to smuggle sprawl back in — spreading one team's single decision across five views so the card cap never bites. That defeats the purpose and forces the reader to reassemble a picture from fragments. Multiple dashboards are for genuinely separate audiences and decisions; within a single decision, the 15-card constraint should stay real. When metric definitions differ across those views, keep them reconciled to one canonical definition so the same word means the same thing everywhere, a discipline we detail in avoiding metric-definition drift.

A practical triage checklist

Turn the limit into a repeatable procedure. First, list every card you currently want and, for each, write the "if this moves, we do X" sentence; drop any card that fails the test to an on-demand report. Second, tag each survivor as acquisition/conversion (GA4-native) or product-behavior (move to a product analytics tool), and remove the product-behavior cards from GA4 entirely rather than shrinking them. Third, group the remaining GA4-native cards by the decision and audience they serve, and put each group on its own dashboard within the 15-card budget.

Fourth, revisit the set on a schedule, because dashboards decay: a card that mattered last quarter becomes noise once the initiative behind it ships. Treat the card limit as a standing invitation to retire the stale ones, not a one-time cleanup. Done this way, GA4's 15-card cap stops feeling like a restriction and starts working as a governance tool — it keeps your primary view tied to real decisions, pushes product-behavior questions to where they belong, and leaves you with dashboards your team reads because everything on them is there for a reason.