Three tests, three different questions
Before reading any number, identify which question the tester answered.
Uniqueness tests collect many values, hash them, and compare against a dataset of previous visitors to report how rare your configuration is. This is a real measurement of tracking exposure and it is what fingerprint entropy quantifies. It says nothing about whether your browser is internally consistent - a perfectly ordinary and perfectly self-contradictory browser can score as common.
Coherence tests ask the browser the same question through independent APIs and check whether the answers agree, the approach described in cross-API coherence checking. The output is the share of applicable checks that agreed. This is close to what modern detection actually evaluates, but it says nothing about how rare you are.
Tell enumeration checks a list of known automation artefacts - the WebDriver flag, framework globals, known headless defaults. Useful as a smoke test, but it only finds what is already on the list, so a clean result means "none of these specific things", not "nothing detectable".
A browser can legitimately score as highly unique, fully coherent, and free of known tells all at once. Those are three compatible facts about three different properties.
The three result states, and why "not measured" is not a pass
Any honest test reports three outcomes, not two, and conflating them is the most common way a score gets misread.
- Scored - the check ran and either agreed or contradicted. These are the only results a percentage should be computed from.
- Not measured - the check could not run. The API was missing, a permission was denied, the hardware was unavailable, or a timeout hit. This is an unknown, and counting it as a pass inflates the score exactly where visibility is worst. A browser missing so many APIs that half the suite cannot execute is not thereby coherent.
- Contextual - the check found something that has ordinary explanations. Accessibility tooling, content blockers, privacy add-ons, and corporate proxies all perturb specific surfaces on real users' machines. Excluding these from scoring is what keeps a coherence test from flagging every hardened browser as automated.
Read the not-measured list before the score. It tells you where the test was blind, and blindness in a test suite frequently corresponds to surfaces a real detection script would have reached by another route.
What to do with the result
A useful reading order inverts the usual instinct.
Fix contradictions first. They are near-binary and have no innocent explanation, so they are both the highest-value and the cheapest thing to resolve. A single hard contradiction is worth more attention than a merely unusual hash.
Treat rarity as informational. Unusual hardware is legitimately unusual, and chasing an average fingerprint often means changing values, which creates contradictions. Optimising a uniqueness number by editing surfaces frequently makes a coherence score worse - the two goals genuinely pull against each other, and coherence is the one detection acts on.
Test twice and test across realms. Run the same profile twice to confirm the values that should be stable are stable - the concern in reconnect stability. Confirm a Worker and a fresh iframe report what the page reports, since page-only checks miss the whole class of realm mismatches.
Do not read any score as a permission prediction. No test knows a given site's thresholds, its network reputation data, its behavioural model, or its business rules. A high score means the browser was internally consistent on the questions asked. That is worth having, and it is not the same as access.
For teams whose objective is public web data rather than browser tuning, the most useful conclusion is often that this is the wrong thing to be optimising. A managed web data API absorbs the coherence problem as an infrastructure property, which removes the need to interpret a score at all.