Your dashboard looks right. Is it?

Somewhere in your dashboard is a number nobody has checked against the total it came from. Mine was in a side project on 120 years of Himalayan climbing data, and it said hired staff reach the summit almost twice as often as climbing members. Counted properly, the gap nearly disappeared. Here’s how that happened, and how to find your own version of it.

The number that was wrong

Before we set off

It was convincing, it was on the screen, and it was wrong.

At Bitmetric, many of us run a data project of our own next to client work. It’s how we keep sharpening the saw: new techniques on data we’re curious about. This time I tried a Python pipeline, version control for the model and Power BI’s Key Influencers visual.

The dataset: the Himalayan Database, with 120 years of expeditions from 1905 to 2025. Behind every row is a real person, and not all of them came home.

This post follows that Sherpa headline from start to finish: how it ended up on my screen, how I caught it, and how you can catch the same kind of mistake in your own dashboard. At the end you’ll find five questions to test whether your numbers can be trusted.

Base camp: understand and prepare the data

Every expedition starts with preparation: understand first, then touch.

Every Bitmetric project runs through the same six steps, in the same order:

The Himalaya data is unusual. The approach isn’t.

Step 1, question.

You’re planning an expedition. Which peak, which season, and with or without oxygen?

Step 2, explore.

The data: 11,690 expeditions on 490 peaks, loaded into SharePoint by a Python script and picked up by Power Query.

Before fixing anything, I checked what it really records:

• A “member” is one person on one expedition, not a unique person. Climb Everest five times and you’re five rows.
• Whether an expedition followed a commercial route is missing for 84% of expeditions.
• Most fields are number codes, and the oxygen fields contradict each other.

That sounds specific to mountaineering. It isn’t.

Picture this: you want to know which customers bring in the most. Your ERP holds one row per order line, not per order. The “customer segment” field only became mandatory a few years ago, so it’s empty for older orders. And credit notes live in a separate system. The dashboard on top of that looks fine, until someone asks why revenue per customer doesn’t add up to the annual accounts.

Before you trust that dashboard, ask the same three questions I asked of the Himalaya data:

1. What does one row mean?
2. What does empty mean?
3. Do the details add up to the total?

All three come back below.

Step 3, clean.

About two-thirds of this project went into bringing in, understanding and cleaning the data. Two principles guided it. Empty is not “no”, and a zero can mean “unknown”: a missing commercial-route flag becomes “Route classification not recorded”. And every label must be defensible: “Non-commercial, hired support”, not an attractive but unprovable “semi-guided”.

Name fields are removed and each climber is a key: pseudonymised, not anonymised, since the public source can still link a key to a name.

Four real expeditions: raw codes on the left, readable labels on the right, empty values shown as “not recorded”.

For the techies: Transformations live in Power Query, not DAX: almost 90% of the logic I wrote sits there, where the data comes in, so the model stays readable. Step names say what the step does, so the next developer can follow along without asking me, and the report is saved as .pbip, so every change goes through version control.

Two steps from the model:

// FACT_Expeditions: a 0 in days or team size means "not recorded", not zero
#"replace 0s with null" = Table.ReplaceValue(#"Changed Type1", 0, null,
    Replacer.ReplaceValue, {"SMTDAYS", "TOTDAYS", "TOTMEMBERS"}),

// FACT_Members: an empty nationality becomes "Unknown", not a blank that disappears
#"null nationality = unknown" = Table.ReplaceValue(#"insert summit month",
    each [CITIZEN],
    each if [CITIZEN] = "" or [CITIZEN] = null then "Unknown" else [CITIZEN],
    Replacer.ReplaceValue, {"CITIZEN"}),

Set the route: model and definitions

One truth per number

Step 4, model.

If two reports show a different success rate, nobody trusts either of them. So every number in this model has one definition, written once as a measure and reused everywhere. The success rates for hired staff and for climbing members build on the same base measure, not on two lookalikes.

Facts and assumptions never mix silently. Every member row is labelled “Listed” (in the source) or “Derived” (reconstructed from expedition totals; part 5 explains why). Click “Listed” under “Data scope” and the overall success rate moves from 36% to 43%. Same data, a different question, and you can see which one you’re answering.

Where the model makes assumptions, you have to be able to back them up when someone asks how. The dashboard rates every peak with a Risk Band from “Low” to “Extreme”. Behind it is the risk-matrix approach from risk management (ISO 31000 and its companion standard IEC 31010): mortality and success stay two separate axes instead of being blended into one score, and their combination sets the band. The cut-offs are fixed at 1% and 3% for mortality and 30% and 60% for success.

Same dashboard, two scopes. All records: 109,997 member records, 36% success, 1.07% mortality. Listed only: 92,731 records, 43% success, 1.27% mortality.

The summit: the dashboard, live

Every visual answers a question from step 1

Step 5, dashboard.

Every visual title is a question the planner would ask, such as “Summit Rate: Who Reaches the Top?” or “Peak Selection: Mortality Risk vs Summit Reward”. That’s the difference between a wall of charts and a dashboard people actually use: you open it with a question and find the answer, without a manual or an analyst next to you.

Colleagues tested it as stand-in users and told me where they got lost. With a client, that’s the people who make the decisions.

Don’t take my word for it. The dashboard is live, so click through it yourself:

Three things to try:

• Click “Listed” under “Data scope”, top right, and watch the success rate move.
• Pick a peak you know in the “Peaks” filter.
• Hover over a dot in “Peak Selection” to see that peak’s details.

The main page, filtered to climbing members, leaders and deputies.

One page is missing from the live version: Key Influencers, which ranks the factors that make an outcome more likely. Microsoft doesn’t support it in a public “Publish to web” embed, so here it is as a screenshot. Behind a normal login it works as usual.

Key Influencers page. It only uses Listed records, the people with personal attributes, as its subtitle says. The factors show patterns in the records, not causes.

The descent: checking, correcting, limitations

Why the Sherpa number was wrong.

Step 6, check.

In the Himalaya, more people die on the descent (347) than on the push to the summit (128). Data projects go wrong in the same place: the dashboard is finished, it looks good, and nobody checks it again. Check is the last of our six steps, and the first one to get squeezed when a deadline gets close. That’s exactly why it’s on the list. Back to the opening headline: I compared the people listed individually with the totals each expedition reports.

The deaths among hired staff matched. The people didn’t: only just over half of the hired staff the expeditions report appear as individuals, and the missing ones mostly never reached the summit. Leave them out and the success rate looks far better than it is.

Counted correctly, the hired staff on the mountain (the “Sherpas” of my headline) reach the summit 40% of the time, against 36% for climbing members. Still higher, but not twice as high. And because the gap in the records changes from period to period, the trend over time was partly a trend in record-keeping too.

Left: the hired-staff summit rate counted on listed staff only (72%) and on everyone the expeditions report (40%), next to climbing members (36%). Right: the share of hired staff not individually listed, by period.

The fix follows the same principle as the cleaning: missing people are added only from the source’s own totals, labelled “Derived”, with no invented details. Then I checked again, and the fix had created its own counting effect: Key Influencers mistook the empty new rows for a pattern. Every fix gets checked again.

One thing I deliberately left at base camp: the route names, which need alpine expertise I don’t have. For a client, I’d bring a domain expert to the table, because we’d rather name a limitation now than have it surprise you later.

So what does this mean for you? Your dashboard probably has its own Sherpa number: a margin, a conversion rate or a revenue per customer that looks convincing because nobody has checked it against the total it came from.

A wrong headline in a board meeting costs more than one extra check. It can steer a decision the wrong way, and once one number turns out to be wrong, people stop trusting the others too. Checking before any questions come up is cheap. Winning back trust after they do isn’t.

Back in the valley

Going live is only halfway

Going live is the summit. What comes after decides whether a dashboard gets used: maintenance, adoption and trust in the numbers.

Trust starts with five questions for your own dashboard:

1. What does one row in your data actually represent?
2. What do blanks, zeros and missing values actually mean?
3. Could you explain and defend this number in a board meeting?
4. Which numbers are facts, and which are derived, assumed or classified by you?
5. Do the numbers still add up when you check them another way?

Sherpa is the name of a people before it’s a job title. In this data, they did much of the carrying and were counted the least. So I use the comparison with respect, and for exactly that reason: the work that makes a number trustworthy rarely shows in the final total. You know which summit you want to reach. Checking a number against the total it came from is that kind of work: slow, invisible, and the reason the result holds.

I took on 120 years of mountaineering data because I was curious. That curiosity comes along to your project too.

Want to discuss what we can do for your environment? Let us know; we’d be happy to help you think it through.