Diagnose what changed
Muon does not stop at "conversion dropped" — it checks whether the change is real, what kind of explanation fits, what has been ruled out, and what to do next.
What is Muon's investigation engine?
When Muon detects a Finding, it first checks the data and whether the change is real. It then tests technical, traffic and product explanations, ruling out the ones that do not fit.
The result shows what remains, what was excluded and what the data is still too weak to answer — so you start with a clear diagnosis instead of an empty dashboard.
One possible diagnosis: a version regression.
In this example, a global conversion drop is concentrated in one environment and coincides with a release and error increase. Other changes can lead to different diagnoses — or show that the measurement itself is broken.
Each step is chosen because it concentrates the change more than any alternative at that level. Muon measured that Safari accounts for 62% of the total drop, narrowed within it to iOS and the /signup page, then found the change began right after release 1.8.4 — coinciding with a 320% spike in browser errors.
This is offered as a likely, ranked path to investigate — correlation, not proven causation. The 0.93 is statistical confidence in the affected segment, not a claim that the release broke the flow. What triggers this →
Different explanations need different checks.
Muon starts with the data itself, then checks technical conditions, traffic composition and product behavior. Dimensions such as browser, country, campaign and release are used only when they help distinguish the explanations.
Audience & environment
Browser, OS and device isolate rendering and platform-specific regressions — a change that only hits Safari on iOS looks nothing like one that hits everyone.
Context & acquisition
Page, country, referrer and UTM campaign locate the change in the product surface and traffic source — a broken landing page or a single campaign cohort.
Release & errors
Release markers and error type connect the change to what shipped and what broke — the two signals most often behind a sudden product move.
Browser Health →Check, rule out, then explain.
Checks run in order. Broken measurement stops the investigation; a product explanation is only shown after the data, technical and traffic alternatives have been considered.
1 · Check the data
Muon looks for missing events, contradictions and tracking changes. If measurement is broken, interpretation stops until it is fixed.
2 · Check the change
Historical comparisons and uncertainty tests distinguish a meaningful change from normal variation.
3 · Rule out explanations
Technical failures, traffic composition, automation, seasonality and product behavior are checked in order, using the data available for this case.
4 · Show what fits
Muon shows the best-fitting explanation, the checks behind it, what was ruled out and what remains unknown.
5 · Recommend the next step
The result ends with an action: fix measurement, filter traffic, inspect a product step, pause a rollout, collect missing data or simply check again later.
Every step before the last is deterministic. The explanation is the only stage that uses an LLM — and it can only describe what the statistics already found.
Why this matters
Most teams lose hours manually slicing dashboards — filtering by browser, then OS, then page, then release, trying to guess where a metric actually moved. Muon does that first round of investigation automatically, the moment a Finding appears.
You start from a narrowed, ranked hypothesis instead of a blank filter. Muon describes what it finds as likely and related — it points you at the segment and the correlated release or error to check, and leaves the final call to you. It surfaces likely causes; it never claims proven causation.
What triggers investigation
Investigation runs on every Finding — a structured signal that a change is real and meaningful, detected by statistics before anyone asks. Findings engine →
Browser Health signals
Frontend error spikes are one of the strongest related signals in investigation. Muon connects them to the affected metric, release and page. Browser Health →
Questions, answered directly.
How does Muon find the affected segment?
Does Muon prove causation?
Which dimensions does it check?
Does an LLM do the investigation?
Can it correlate with releases and errors?
Let Muon run the first round of investigation.
The investigation engine ships in the open-source core. Spin up Muon with Docker and let it narrow the cause before you open a dashboard.