Measure Killer: The Power BI External Tool That Finally Tells You What’s Actually Being Used in Your Reports
(link to YouTube video at the bottom!)
In Power BI, it’s surprisingly easy to end up with a semantic model that feels solid… but is carrying way more than it needs to. Retired measures, old unused calculated columns and table, “maybe we’ll need it later” data—stuff that quietly adds complexity, increases storage, slows refreshes, and makes the model harder to maintain.
That’s why I’m a big fan of Measure Killer (https://en.brunner.bi/measurekiller).
It’s an external tool that takes your semantic model and report layer and answers a simple question with real insights:
What’s being used, and what isn’t?
And once you know that, you can delete unneeded stuff with confidence.
What Measure Killer does (in plain terms)
Measure Killer analyzes your semantic model + report layer and shows how objects are used across visuals, filters, pages, and dependencies—so you can identify cleanup opportunities across tables, columns, measures, calculated objects, and more. Not only that, but it’s a helpful reference tool if you quickly want to see dependencies of objects in your model.
Versions: Portable vs Admin vs Enterprise
Portable vs Admin install
On the official download page, you’ll see both Measure_Killer_Admin and Measure_Killer_portable.
Portable: doesn’t require admin rights, but typically won’t appear in the External Tools ribbon in Microsoft Power BI Desktop.
Admin / Store install: more likely to integrate cleanly (including external tools ribbon behavior), but requires admin rights.
Enterprise / Tenant Analysis
The bigger value for organizations is found in the enterprise version: Measure Killer includes Tenant Analysis, which can scan an entire Power BI / Fabric tenant (or everything you have access to in a limited mode).
That’s where it becomes really compelling for central BI teams managing shared semantic models with lots of downstream reports—because it’s no longer “this PBIX uses that measure,” it’s “this model is used across the tenant like this.”
Getting started
Download Measure Killer from the official site (Admin or Portable)
Launch it (portable users will often launch it directly, not from the ribbon)
It will detect open files and prompt you to select the report/model to analyze
Click Run and you’ll get the results that we’ll discuss below.
The Executive Summary (bottom left)
After running, you’ll see an executive summary that quickly tells you % of your model is used in visuals and highlights high-level flags (relationships, model/report best practices, etc.). This is a great first checkpoint to decide whether you’re looking at a small tidy-up—or a “we should probably do some pruning” situation.
The Results tab (big section to the right of the summary): the “bread and butter” view
This is the view provided a lot of insights in a variety of ways:
Used vs unused objects
You can filter by status and see what’s used, what’s unused, and how usage is occurring (visuals, filters, etc.).
Dependency drilldowns
Measure Killer makes it easy to drill into dependencies—especially useful when something is “used by an unused metric,” or when you’re trying to trace how a field is showing up in visuals/filters.
Right-click depth (the practical stuff)
From the results grid, you can usually jump into things like:
dependencies (model, artifacts, visuals, visual-level filters)
details/raw data views (including lineage identifiers)
The nice part is: if you’re hunting something down, there are often multiple ways to get to the same answer (a little redundancy, but in a helpful way).
Export to Excel (!!!)
Measure Killer’s “Export to Excel” options are genuinely useful—especially for ad hoc analysis, de-duplication, and quick review with teammates who don’t want to open another tool.
If you’re doing governance or cleanup in a team setting, being able to export “what’s used” (or “what’s unused”) and discuss it is underrated.
DAX Expressions: quick visibility + duplicate detection
The DAX Expressions view gives you a one-stop list of the DAX behind measures and calculated objects—again with export options.
Duplicate DAX detection
One feature worth calling out: Measure Killer can flag duplicate DAX expressions (not duplicate names—duplicate logic). This is a great way to find “same measure, different name” scenarios that happen when reports evolve over time. Recent release notes also mention improvements to duplicate detection logic.
Best practice move here: when you find duplicates, decide which becomes the canonical measure, update dependencies as needed, and remove the redundant one.
Hide vs Kill: a practical cleanup strategy
Measure Killer gives you multiple ways to reduce clutter. Two of the most useful patterns:
1) Hide artifacts first (the cautious approach)
There’s a workflow for hiding unused (or “used only by unused”) artifacts instead of deleting them immediately. This is a great fit for shared models or collaborative work: hide now, wait a defined window (30/60/90 days), then delete if nobody asks questions or misses it.
2) Kill artifacts (when you’re ready)
Measure Killer gives you a checklist and button to automatically remove unused DAX measure artifacts from your model in one click.
Kill Columns: helpful, but be mindful of folding and upstream filtering
Measure Killer can also identify unused columns and help you remove them—often by generating a “removed columns” step at the end of M.
Two best-practice notes (aligning with how you framed it in the video):
Where the remove-columns step lands can matter for query folding (earlier is often better).
The ideal version is upstream: if you can eliminate unused columns in source SQL (or upstream transforms), you reduce data pulled and processed in the first place.
Measure Killer won’t magically rewrite every upstream query for you, but it does give you a clear target list of what to go after.
Best Practice Analyzer: great default rules, but apply judgment
Measure Killer includes a best practices feature that surfaces “violations” and scoring. Its rules are derived from Microsoft Power BI best practices.
That being said, treat this like a strong checklist, not absolute truth:
Some flags are “always fix this”
Others depend on context (model pattern, enterprise conventions, performance tradeoffs)
The real value is consistency: it gives you a shared language for model quality.
Logs: a simple feature that’s surprisingly useful
The logs view gives you a history of actions taken in the tool—helpful when you’re doing repeated cleanup passes over time or want an audit trail of what you changed and when.
When Measure Killer matters most
Measure Killer is useful for any model, but it becomes especially valuable when:
You’re maintaining shared semantic models with many downstream reports (tenant analysis / enterprise mode)
You’re trying to reduce model size and improve performance through cleanup
You need confidence before deleting objects (dependency clarity)
You want a repeatable cleanup workflow (hide → validate → remove)
Closing thought
If you’re serious about keeping models clean over time, Measure Killer is one of the easiest wins you can add to your workflow. It doesn’t replace good modeling habits—but it does make it much easier to stay honest about what your model is actually doing in the real world.