How accurate is device fingerprinting?

Device fingerprinting is accurate enough to be useful and never accurate enough to be treated as proof. It recognises most returning devices, but the match is probabilistic, so collisions, software updates, resets and privacy tools all affect it. This guide quotes no accuracy percentage, because a figure measured on someone else’s traffic would not describe yours.

#Is device fingerprinting accurate?

It is accurate in the way a good witness is accurate: usually right, occasionally unsure, and worth more when it agrees with other evidence. A fingerprint is a recognition, not a stored label, so it can be confident, uncertain or absent. Good systems say which, instead of returning a clean answer every time.

Fingerly returns a visitor ID with a confidence value from 0 to 100 on every identification. That value is how the match was reached, and it is the part your code should read.

#Can two devices have the same fingerprint?

In principle, yes. Two devices of the same model, on the same software, with the same settings, can look very alike. This is a collision, and it is the reason a visitor ID should never be treated as a person’s identity. It also means one visitor ID can sometimes cover more than one real device, and one person can appear under several.

The practical defence is to combine the visitor ID with what you already know: the account, the order, the history. A device shared by a household is a normal case, not an attack, so test your rules against it before you enforce them.

#What happens when a browser updates or a device changes?

Devices change constantly. Browsers and operating systems update, fonts are added, monitors are swapped, and people travel between networks. Fingerly’s browser identification is designed to survive these ordinary changes, and the confidence value tells you when it had to work for the match.

• 100 means this exact device has been seen before.
• 85 to 99 means the device was recognised after it changed, such as after an update. Lower values mean more change.
• 0 means nothing matched, so a new visitor ID was issued.

#What about private browsing, privacy browsers and resets?

These are the hard cases. Some browsers and settings are built to reveal very little. When there is too little to identify anyone, Fingerly answers that the device is not identifiable, issues a fresh visitor ID each time, and does not charge for the request. Those clients look like a stream of new visitors, so do not count them as returning or unique. The request is still scored, and a private window can also be reported as context.

A genuinely new device, a different browser, or a factory reset should be expected to look new, and you should not build logic that assumes the same person will be recognised across different browsers. A visitor identity is also deleted 180 days after the device was last seen, so a device that returns after that is a new visitor.

In native apps, recognition rests on a random install ID, so confidence is 100 for an install seen before and 0 for a new one. A reinstall keeps its visitor ID on iOS and gets a new one on Android.

There is one more honest limit. The server can only score what it receives, and a modified browser or app can send whatever it likes. On mobile, hardware attestation is the evidence that resists forged input, which is why it is worth setting up where it is available.

#How do you measure accuracy on your own traffic?

The only accuracy that matters is yours, measured on your own users. Fingerly returns the visitor ID and confidence, and you hold the ground truth, because you know which sessions belong to which signed-in accounts. A few simple checks make the picture clear:

• Compare the visitor IDs of signed-in customers across several sessions. How often does a known customer on the same device come back as the same visitor?
• Look at the share of new visitors among logged-in returning customers. A high number points to browsers that reveal little, resets or frequent device changes.
• Review a sample of accounts that share a visitor ID. Households and shared computers will show up here, and they are legitimate.
• Watch how many results are not identifiable, and decide in advance what each one should do.

Do this in observation mode before you enforce a rule, then keep measuring. A threshold that looks right on staging traffic can behave differently on live customers.

#How should you use an imperfect result?

Treat it as evidence, not a verdict. A practical order of work looks like this:

• Start in observation: record what you would have done, and review it before you enforce anything.
• Prefer friction a real customer can pass, such as a second factor, to an outright block.
• Treat unknown and not-identifiable results as their own case. An absent score is not a score of zero.
• Read the result on your server with a secret key. A browser or app can be modified, so its copy of the answer is a convenience, not a decision.
• Give legitimate users a path back, and track the customers you disturbed alongside the abuse you caught.

Behaviour described as Fingerly returns it today. No accuracy percentage is claimed.