Why Dashboards Fail Even When the Data Is Correct.
I filtered by region, but now the totals don’t add up.
There’s a moment that happens in almost every analytics team, and it usually goes something like this.
Someone builds a dashboard. It’s polished. The charts are clean, the filters are responsive, the colors are on-brand. Leadership approves it. The team celebrates. The dashboard goes live.
And then the questions start.
“Why does this number not match what Finance reported?”
“I filtered by region, but now the totals don’t add up.”
“Last week this showed 1,200 customers. This week it shows 1,800. What changed?”
The analyst who built the dashboard scrambles. They check the queries. They verify the filters. They trace the logic. Everything looks correct. And yet the numbers are wrong—or at least, different from what someone else has.
Days pass. Meetings happen. Fingers get pointed. Trust erodes. Eventually, the dashboard gets abandoned, or worse, it stays live while everyone quietly ignores it and goes back to asking for ad-hoc queries.
What happened?
The answer, almost always, has nothing to do with the dashboard itself. The charts were fine. The filters worked. The design was sound.
The problem was underneath. The data model the invisible foundation that the dashboard was built upon was broken. And no amount of dashboard polish can fix a cracked foundation.
This essay is about that invisible layer. It’s about why dashboards fail even when they’re built correctly. And it’s about the skill that separates analysts who build beautiful artifacts from analysts who build things that actually work.
What the Data Model Actually Means
Let me be clear about what I’m not going to do: I’m not going to define data modeling using entity-relationship diagrams or normalization forms. Those concepts have their place, but they’re not where understanding begins.
Here’s what the data model actually means in practice:
A data model is the set of decisions about how data is structured, related, and defined decisions that determine whether your dashboard can answer questions correctly or not.
That’s it. That’s what we’re talking about.
When those decisions are made well, building dashboards is straightforward. Questions have clear answers. Numbers match across reports. Filters work as expected.
When those decisions are made poorly or not made at all building dashboards becomes a nightmare. Simple questions require complex workarounds. Numbers disagree depending on how you slice them. Filters produce unexpected results.
Let me show you what I mean with an analogy, because this concept is worth understanding deeply.
The Plumbing Beneath the Faucet
Think about the plumbing in a house.
When you turn on a faucet, you expect water to flow. You don’t think about the pipes behind the walls, the connections under the floor, the main line from the street. You just turn the handle and water appears.
When plumbing is done well, this is exactly what happens. Water flows where it should. Hot comes from the hot tap, cold from the cold. The pressure is consistent. The system is invisible because it works.
When plumbing is done poorly, everything breaks down. You turn on the shower and the kitchen sink gurgles. You run the dishwasher and the toilet backs up. You get scalding water when you expected cold. The pressure drops randomly. The whole house becomes unpredictable.
Now here’s the key insight: no amount of beautiful faucets can fix bad plumbing.
You can install the most expensive fixtures. You can choose designer handles and rainfall showerheads. You can tile the bathroom with Italian marble. None of it matters if the pipes behind the walls are corroded, misconnected, or leaking.
Dashboards are the faucets. Data models are the plumbing.
When analysts complain about dashboards being slow, unreliable, or confusing—they’re usually complaining about plumbing problems while staring at the faucet. They’re trying to fix the wrong layer.
A beautiful dashboard built on a broken data model will never work correctly. The numbers will be wrong. The filters will behave unexpectedly. The performance will be slow. No amount of chart redesign or filter optimization will fix it, because the problem isn’t the dashboard.
The problem is underneath.
What a Broken Model Actually Looks Like
Let me be concrete about how data model problems manifest in dashboards.
Imagine someone builds a dashboard to answer a simple question: How many orders did we receive last month?
They write a query against a table called orders. They count the rows. They display the number on a dashboard. Simple.
The dashboard shows: 4,847 orders
Finance looks at the dashboard and says: “That’s wrong. We processed 3,215 orders last month.”
The analyst is confused. They check the query. They verify the date filter. Everything looks correct. So they dig into the data model, and they discover something:
The orders table doesn’t have one row per order. It has one row per order line item.
An order with three products has three rows in the table. The analyst counted rows, but they should have counted distinct order IDs.
This is a grain problem and it’s one of the most common data model failures.
❌ The Problematic Table:
textorders table
─────────────────────────────────────────────────────────
order_id │ product_id │ quantity │ price │ order_date
─────────────────────────────────────────────────────────
1001 │ SKU-A │ 2 │ 29.99 │ 2024-03-15
1001 │ SKU-B │ 1 │ 49.99 │ 2024-03-15
1001 │ SKU-C │ 3 │ 19.99 │ 2024-03-15
1002 │ SKU-A │ 1 │ 29.99 │ 2024-03-15
1003 │ SKU-D │ 2 │ 99.99 │ 2024-03-16
1003 │ SKU-E │ 1 │ 14.99 │ 2024-03-16
─────────────────────────────────────────────────────────This table is called orders, but its grain is actually order line items. Order 1001 appears three times. Order 1003 appears twice.
If you COUNT(*) this table, you get 6. But there are only 3 orders.
Now watch how this propagates through dashboards:
Query 1: Order Count
SQLSELECT COUNT(*) as order_count
FROM orders
WHERE order_date >= ‘2024-03-01’Returns: 6 (wrong should be 3)
Query 2: Total Revenue
SQLSELECT SUM(price * quantity) as revenue
FROM orders
WHERE order_date >= ‘2024-03-01’Returns: $339.91 (correct summing line items works)
Query 3: Average Order Value
SQLSELECT SUM(price * quantity) / COUNT(*) as aov
FROM orders
WHERE order_date >= ‘2024-03-01’Returns: $56.65 (wrong dividing by 6 instead of 3)
The correct AOV should be $339.91 / 3 = $113.30.
One table. Three queries. Two of them produce wrong results—and not obviously wrong. They produce plausible numbers that happen to be incorrect.
This is how bad data models poison dashboards. The dashboard faithfully displays what the query returns. The query faithfully executes against the model. The model is structured in a way that makes certain questions impossible to answer correctly without workarounds.
The Cascade of Confusion
The problems don’t stop with the first dashboard. They cascade.
Stage 1: Someone builds a dashboard showing order count, total revenue, and AOV. The AOV is wrong because of the grain problem, but nobody notices immediately.
Stage 2: The marketing team builds their own dashboard to track campaign performance. They use the same orders table. They make the same counting mistake. Now two dashboards have wrong numbers.
Stage 3: Someone compares the two dashboards and notices the order counts don’t match. But it’s not because of different errors it’s because the analysts applied different fixes. One used COUNT(*). Another used COUNT(DISTINCT order_id). A third used a subquery. Each approach produces different numbers.
Stage 4: Leadership starts asking: “Which number is right?” Nobody knows. Meetings get scheduled to debug the discrepancies. The data team gets labeled as unreliable.
Stage 5: To avoid the confusion, people start building their own tables. Marketing creates marketing_orders. Finance creates finance_order_summary. Now there are three versions of the truth, none of which match.
Stage 6: Dashboards get abandoned. People go back to requesting ad-hoc analyses. The entire promise of self-service analytics collapses.
All of this the confusion, the meetings, the workarounds, the collapse stemmed from one data model problem: a table with an unclear grain.
What a Clean Model Actually Looks Like
Now let me show you what happens when the data model is done well.
Instead of one ambiguous orders table, the model separates concerns into tables with clear grains:
✅ Orders Table (grain: one row per order)
textorders
─────────────────────────────────────────────────────────
order_id │ customer_id │ order_date │ order_total │ status
─────────────────────────────────────────────────────────
1001 │ C-501 │ 2024-03-15 │ 169.94 │ completed
1002 │ C-342 │ 2024-03-15 │ 29.99 │ completed
1003 │ C-501 │ 2024-03-16 │ 214.97 │ completed
─────────────────────────────────────────────────────────✅ Order Line Items Table (grain: one row per product in an order)
textorder_line_items
─────────────────────────────────────────────────────────
order_id │ line_number │ product_id │ quantity │ line_total
─────────────────────────────────────────────────────────
1001 │ 1 │ SKU-A │ 2 │ 59.98
1001 │ 2 │ SKU-B │ 1 │ 49.99
1001 │ 3 │ SKU-C │ 3 │ 59.97
1002 │ 1 │ SKU-A │ 1 │ 29.99
1003 │ 1 │ SKU-D │ 2 │ 199.98
1003 │ 2 │ SKU-E │ 1 │ 14.99
─────────────────────────────────────────────────────────Now every question has a clear home:
Order Count:
SQLSELECT COUNT(*) as order_count
FROM orders
WHERE order_date >= ‘2024-03-01’Returns: 3 ✓
Average Order Value:
SQLSELECT AVG(order_total) as aov
FROM orders
WHERE order_date >= ‘2024-03-01’Returns: $138.30 ✓
Units Sold by Product:
SQLSELECT
product_id,
SUM(quantity) as units_sold
FROM order_line_items
GROUP BY product_idReturns: Exactly what you’d expect ✓
The SQL is simpler. The queries are faster. The numbers are correct.
This is what clean plumbing feels like. You turn on the faucet, water comes out. You don’t have to think about the pipes.
What to Look for Before You Build
Before building any dashboard, ask these questions about the data model beneath it:
1. What is the grain of each table I’ll use?
Can you clearly state what one row represents? If you can’t if the answer is “it depends” or “I’m not sure” you will make counting errors. Guaranteed.
2. Do the joins produce expected row counts?
When you join two tables, do you get the number of rows you expect? If table A has 100 rows and table B has 100 rows, does the join produce 100 rows? Or does it explode to 10,000 because of duplicate keys?
3. Are metrics defined consistently?
If your dashboard shows “revenue,” is that the same revenue Finance reports? Gross or net? Including or excluding refunds? If definitions aren’t aligned, numbers won’t match.
4. Is the data fresh and reliable?
When was the table last updated? If your dashboard shows “real-time” numbers but the table updates weekly, you’ll confuse stakeholders.
If you can’t confidently answer these questions, you’re not ready to build the dashboard. You’re ready to investigate the model.
The Career Ceiling
Here’s the part where I tell you something that might sting.
Dashboard skills are valuable but capped. You can become excellent at Tableau or Looker in a year or two. These skills get you hired at the junior level. But they don’t differentiate you at the senior level, because plenty of people have them.
Data modeling skills are rare and compound. Understanding grain, relationships, metric definitions this is what separates analysts who build things that get abandoned from analysts who build things that actually work.
And here’s the leverage: if you understand both layers, you can build end-to-end.
You can look at a business problem, recognize when the model won’t support it, advocate for fixing it, and then build the dashboard on top. You’re not dependent on someone else to get the foundation right. You can see when it’s wrong.
This is the difference between being a faucet installer and being a plumber who can also install faucets. One needs someone else to get the pipes right. The other can do the whole job.
The market for faucet installers is competitive. The market for people who can do the whole job is much less so.
The Invisible Layer
Here’s the final thing I want you to understand.
Every dashboard you’ve ever seen every clean visualization, every useful filter, every number that stakeholders trust sits atop a data model.
When the dashboard works, nobody thinks about the model. They see the charts. They trust the numbers. The model is invisible because everything flows correctly.
When the dashboard fails, nobody blames the model. They blame the dashboard. They blame the analyst. They blame the tool. The model remains invisible even as it causes the problems.
This invisibility is what makes data modeling so powerful and so neglected.
The analysts who learn to see this invisible layer gain a superpower. They can predict which dashboards will fail before they’re built. They can diagnose problems others can’t explain. They can build things that actually work in an environment where most things don’t.
Most analysts spend their careers decorating the surface, wondering why their beautiful work keeps crumbling.
A few learn to see the foundation and build things that last.
The model is invisible.
Learn to see it.
P.S. I finally released my first ebook: Data Case Study Mastery Guide.
If case studies have ever felt like a pain in the ass if you’ve stared at a blank page wondering how to structure one this guide breaks down the exact approach I use. No fluff. No filler. Just a system that works.
Check it out here → https://payhip.com/b/F9HMS