Tableau Dashboards People Actually Use
After building 30+ production dashboards, here are the parameter tricks, tooltip patterns, and layout principles that separate decoration from daily tools.
Most Tableau dashboards die within two weeks.
Someone builds a beautiful chart, presents it in a meeting, gets a round of compliments, and then nobody opens it again. I know because I've built the dead ones too. Early in my career at VNG, I made dashboards that looked great in screenshots but collected dust in practice. Nobody told me they stopped using them — they just quietly switched back to spreadsheets.
After building 30+ dashboards that teams actually open every morning, I've learned that the difference between a dead dashboard and a living one has almost nothing to do with how it looks. It's about how it thinks.
Here's what I mean.
The dashboard is not the deliverable. The decision is.
Every dashboard I build now starts with one question: what decision does this help someone make?
Not "what data should we display." Not "what metrics are available." What decision.
If the answer is "the UA team needs to decide which campaigns to kill by 10am every morning," that tells me everything about what goes on the dashboard, what doesn't, and how fast it needs to load. If the answer is "leadership wants to see how revenue is trending," that's a different dashboard entirely — different granularity, different filters, different refresh cadence.
When I was managing ad monetization across 5–10 titles at VNG, the UA team and the product team needed completely different views of the same underlying data. Same BigQuery tables, same metrics, but one team needed daily campaign-level CPI and ROAS to make spending decisions before lunch, and the other needed weekly cohort-level retention curves to inform feature planning. I could've built one dashboard with a dozen filters. Instead I built two, each with exactly what that team needed and nothing else.
A dashboard that tries to serve everyone serves no one.
Parameters are the most underused feature in Tableau
Most people use parameters as simple toggles — switch between "Revenue" and "Users," that kind of thing. That barely scratches the surface.
The cohort analysis dashboard I built at VNG has a single metric selector with 40+ options: overall revenue, net revenue, ARPDAU, ad revenue, ad impressions, eCPM, IAP revenue, packs sold, ARPPU, paid user rate — and it dynamically rewires the entire dashboard. The charts, the axis labels, the tooltips, the formatting all change based on what you pick.
Here's the trick: I use calculated fields that reference the parameter value and return the correct measure. Something like:
CASE [Metric Selector]
WHEN "Ad Revenue" THEN [Ad Revenue]
WHEN "ARPDAU" THEN [ARPDAU]
WHEN "eCPM" THEN [eCPM]
...
END
Then every chart on the dashboard points to that single calculated field instead of a hardcoded measure. One parameter, one calculated field, and the entire dashboard becomes a Swiss Army knife.
The reason this matters: instead of building 40 separate dashboards (which is what the team had before), you build one that does everything. The team self-serves any cut they need. They stop pinging you on Slack asking for "the same chart but with eCPM instead of revenue."
I combine this with parameter-driven cohort group selectors (short-term: 0–2d, 3–7d, 8–14d, 15–30d, 31–60d, 61–90d, 91–180d, >180d; or long-term: 0–7d, 8–30d, 31–60d, >60d) and country group filters. The same dashboard can show you ARPDAU by short-term cohort for US users, or revenue by long-term cohort for all Tier 1 markets. One dashboard, hundreds of possible views.
Tooltips should answer the next question
Default Tableau tooltips are terrible. They show you the exact same number that's already on the chart label, plus some dimension values you can already see on the axis. Useless.
A good tooltip answers the question the viewer is about to ask after they see the number. If they're looking at a daily ARPDAU bar and it dipped, they're going to wonder: was it organic or non-organic? Which cohort group drove the drop? What's the impression count?
So I build tooltips that show the breakdown they'd otherwise need to open a separate dashboard for. In my cohort analysis dashboards, hovering over a daily ARPDAU bar shows the contribution from each cohort age group, the organic/non-organic split, and the impression count — all in the tooltip. The person gets their answer without clicking anything.
The rule: the tooltip should save someone from opening a second dashboard.
Layout is information hierarchy, not decoration
The biggest layout mistake I see: treating dashboards like PowerPoint slides. Big title, centered chart, lots of white space, maybe a logo in the corner. It looks polished in a screenshot. It's horrible for daily use.
Here's how I lay out a working dashboard:
Filters go on the right, not the top. Horizontal filter bars eat vertical space on every single view. A right-side panel gives the filters a home without pushing your charts down. The user's eye goes left-to-right — chart first, filters second. That's the correct priority.
The most-checked metric goes top-left. Eye-tracking studies show people start top-left. Put the number they open this dashboard to check right there. Don't make them scroll.
Break columns to show structure, not just because you can. In my cohort dashboards, I use "Break columns to: Cohort groups" to show each cohort age band as a separate row. This looks dense, but for an analyst who checks this every day, density is a feature. They can scan eight cohort bands in one glance without clicking anything. Sparse layouts look better in demos; dense layouts work better at 9am on a Monday.
Performance is a feature
A dashboard that takes 30 seconds to load doesn't get used. Period. People will go back to a spreadsheet before they'll wait for your chart to render.
When I took over data engineering at VNG, some of the existing queries were scanning entire tables on every dashboard refresh. BigQuery charges by data scanned, so not only were the dashboards slow — they were expensive.
I restructured the pipelines: partitioned tables by date, clustered by the most common filter dimensions (country, app_id, media_source), and pre-aggregated the heavy metrics into summary tables. The dashboards went from 30-second loads to near-instant. Query costs dropped to near-zero.
The principle: the fastest dashboard is the one querying a small, pre-aggregated table — not the one running a complex calculation on raw event data at view time.
If your Tableau dashboard is slow, the problem is almost never Tableau. It's your query.
Ship fast, iterate in production
My turnaround on a new dashboard is 1–2 days. That's not because I cut corners — it's because I've built a personal system.
I start every dashboard from a template I've refined over dozens of iterations: right-side filter panel, parameter-driven metric selector, standardized calculated fields, consistent color coding. The structure is pre-built. I just plug in the specific data source and customize the metrics.
Then I ship it, watch how people use it for a week, and iterate. The first version is never the final version. But a good-enough dashboard in someone's hands today is infinitely more valuable than a perfect one that ships next month.
Building 30+ dashboards taught me this: the ones people love aren't the prettiest. They're the ones that loaded fast, answered their question, and didn't make them think about the tool.
This is the first in a series about data, game design, and monetization in F2P mobile games. I'm Du Che Anh — currently Product Owner & Lead Game Designer at Corochti Studio, previously at VNG Corporation. If you're building dashboards for a gaming team and want to talk shop, reach out at anhdc@corochti.vn.