Stop Maintaining 10 Dashboards: Use Filter Presets Instead

Here is a pattern that sneaks up on every team. You build a dashboard. It is good. Then someone wants the same view but only for iOS, so you clone it. Then only for the latest version, so you clone it again. Then marketing wants Brazil, support wants enterprise accounts, and six months later you have ten dashboards that are ninety percent identical and slowly drifting apart. Change a metric definition and you now have to change it in ten places, and you will miss one.

This is dashboard sprawl, and it is not a discipline problem. It is a tooling problem. The fix is not “be more organized.” It is global filters and presets, which let one dashboard do the job of all ten.

Why the copies pile up

The sprawl happens because many analytics tools bind filters to the widget instead of the dashboard. Each chart has its own little filter, set once when you built it. So when you need the whole view scoped to a different segment, there is no switch to flip. Cloning the entire dashboard is the only move the tool gives you.

Every clone feels cheap in the moment. Two minutes, done. The cost is invisible until later, and then it is everywhere:

• Drift. You fix a metric on the main dashboard and forget the nine copies. Now different people quote different numbers for the same thing, and trust in the data quietly erodes.
• Maintenance tax. Every new widget has to be added ten times. Every definition change, ten times. The work scales with the number of copies, not the number of real questions.
• No source of truth. When ten dashboards disagree, nobody knows which is right. The thing analytics was supposed to settle is now another argument.

The dashboards were supposed to save time. Past a few copies they start spending it.

The fix: global filters

The alternative is to make the filter a property of the dashboard, not each widget. One control at the top scopes every chart at once.

Want the whole view for iOS? Set the platform filter. For the latest release? Set the version filter. For Brazil on weekends? Set those too. Nothing was cloned. The same dashboard, the same single definition of every metric, just answers a different question because you pointed it at a different slice. The ten dashboards collapse into one dashboard and a set of filters.

This only works if you can filter by the dimensions you actually care about: platform, version, country, and your own custom dimensions, not just whatever the vendor hardcoded. A real game would filter by game mode. A SaaS product would filter by plan or account type. The point is that the slice is just a value in your data, so filtering on it should be a toggle, not a rebuild.

Presets: name the slices you reuse

Global filters fix the cloning. Presets fix the next annoyance, which is re-setting the same filter combination over and over.

A preset is a saved filter combination you can recall in one click. The combinations a team reaches for constantly become named shortcuts:

• “iOS, latest version” for the mobile release review.
• “Enterprise accounts, last 30 days” for the account-health check.
• “EU users” for the privacy and compliance read.

Instead of manually setting three filters every Monday, you pick the preset. The dashboard reshapes instantly. You get the convenience that made people clone dashboards in the first place, without creating a single copy to maintain.

This is the whole trick. Cloning was a workaround for “I keep wanting this specific scoped view.” A named preset gives you that scoped view directly, pointed at the one real dashboard, so there is nothing to drift.

Do not forget the time window

The same logic applies to time. Hardcoding “last 7 days” into every widget is just another flavor of the copy problem, where comparing this week to this month means rebuilding charts.

Relative time expressions, set once at the dashboard level, solve it the same way filters do. Something like now-7d for the last week, or now/d for since the start of today, controls the window for every widget at once. Change the range and the whole dashboard moves with it. One dashboard, any time window, no duplicates.

What this looks like in practice

Picture the team that built ten dashboards. Here is the same coverage with the preset model:

• One dashboard with every metric defined once.
• Global filters for platform, version, country, and your custom dimensions.
• Presets for the handful of slices the team checks regularly.
• A relative time range at the top for the window.

A new widget is added once and instantly works under every filter and preset, because it is reading the same data through the same controls. A metric definition changes in one place. Nobody quotes stale numbers from a forgotten copy, because there are no copies. The maintenance load stops scaling with the number of questions and starts scaling with the number of actual metrics, which is far smaller.

This pairs naturally with querying your own data directly. When each widget is a query you control rather than a fixed vendor view, global filters and presets are just parameters on top of those queries, which is why the whole thing stays flexible instead of becoming another set of rigid boxes. We made the broader case for that in why your analytics should run on SQL.

The bottom line

If you are maintaining a separate dashboard per platform, per version, or per segment, you are not organized, you are duplicating. Every copy is a future drift, a forgotten update, a number someone quotes that no longer matches reality.

The model that scales is one dashboard, global filters, and named presets for the slices you reuse. Build the view once, point it wherever you need, and let the filter do the work the clone was doing badly.

Hintway is built this way. Scope an entire dashboard by platform, version, or any custom dimension, save the combinations you use as presets, and control the time window with relative expressions, all on a single dashboard you do not have to duplicate. The filters and presets guide walks through the setup.