Explore checkers, demos and evaluation routes →
Summarize this page with
Device fingerprint accuracy needs at least two questions: does a known device remain recognizable, and do unrelated devices stay separate? A single headline percentage can hide the trade-off. Build a labeled evaluation with explicit identity scope, time windows, missing results and denominators before comparing vendors.
- 1Count correct returns
- 2Inspect false merges
- 3Measure split identities
Define ground truth outside the detector
Assign test labels independently of the returned fingerprint. Use known devices, browser profiles and authorized account actions recorded by your test process. If the product's returned ID becomes the ground-truth label, the evaluation merely confirms its own output.
Define whether a match should hold within one browser, across profiles, after reinstall, or across native and web surfaces. Do not count an unsupported cross-browser case as a failure of a narrower promise. Conversely, a product claiming that wider scope should be tested against it rather than given credit for ordinary cookie continuity.
Use separate measures for continuity and false matches
| Measure | Numerator | Denominator |
|---|---|---|
| Returning-device recall | Known return observations correctly linked | All known return observations in scope |
| False-merge rate | Known separate entities incorrectly merged | The defined set of separate-entity comparisons |
| Split-identity rate | Known returns given an incorrect new identity | Known return observations in scope |
| Assessment availability | Events returning usable identity evidence | All attempted collection events |
| Legitimate-action restriction | Legitimate actions restricted by the application | All known legitimate actions |
For false merges, state how comparisons were sampled. Comparing every possible pair in a population creates a different denominator from reviewing only the matches a system proposed. Neither rate is interpretable without that definition. Report both the number of affected entities and the relevant comparison population.
A worked example
Imagine 1,000 known return observations. If 940 are correctly linked, 40 receive a new identity and 20 cannot be assessed, recall over all attempted returns is 94 percent. Over the 980 assessed returns it is about 95.92 percent. Both figures can be useful, but their denominators answer different questions.
Now suppose 100 proposed links include two confirmed matches between entities that should be separate. That is 2 percent incorrect links among reviewed proposals. It is not a 2 percent false-merge rate over every device pair. These figures are illustrative arithmetic, not measured results for this site's ranking.
Test drift over time
A device can change software, graphics drivers, language settings or browser privacy behavior. Repeat the known-device set after scheduled updates and ordinary usage. Record the age of the last known observation and compare outcomes by elapsed time rather than pooling same-day recognition with a long return window.
Test cookie removal, IP changes and incognito separately before combining them. Include shared hardware and similar managed devices: an organization can deploy many nearly identical laptops, making a configuration hash look less unique than it does in a mixed consumer sample. The persistence guide provides a condition matrix.
Keep identity quality separate from fraud detection
Recognizing the same device is not the same as correctly predicting fraud. A known device may perform both legitimate and abusive actions; a new device may belong to a trusted customer. Evaluate identity matching against known devices, and evaluate risk outcomes against independently reviewed business actions.
ShieldLabs combines identity with device/network evidence and account-level findings. Fingerprint offers identification and Smart Signals through its hosted plans. Sift's device API has its own access and labeling model. Use the full comparison to identify the product shape, then run equivalent cases before choosing a tool.
Capture operational conditions
Store product plan, SDK version, collection settings, event time, retrieval time and response status. Measure p50 and p95 end-to-end time alongside assessment availability. A fast successful response can coexist with a high rate of missing collection, so never report latency alone.
Review the labels before adjusting thresholds. A mislabeled shared device or duplicated test account can make a correct detector appear wrong. Preserve the original response and record corrections separately. This gives the engineering and fraud teams a common record instead of competing screenshots.
FAQ
Is uniqueness the same as accuracy?
No. Uniqueness describes distinctions within observed attributes or identifiers. Accuracy requires known entities and an explicit definition of a correct match over time.
Should unknown results count as clean?
No. Record unavailable or inconclusive results separately and report whether they are included in each denominator. The application needs an explicit fallback for them.
Can I compare vendor headline percentages directly?
Only when their populations, matching scope, time windows and denominators are comparable. Otherwise evaluate the same known-device cases and report the differences.
Sources
Sources reviewed October 23, 2026.
Continue reading
- Device ID persistence after cleared cookies, incognito and IP changes
- Integrate device fingerprinting into signup, login and checkout
- Web vs mobile device fingerprinting: choose the right integration
Compare all eleven tools or read the complete deployment guide.