A cookie or a local storage ID is a value your site writes into the browser and reads back later. Device fingerprinting works the other way round: nothing is written, and the server recognises the device from what it sends. Both answer "have I seen this visitor before?", and they fail in different ways, so fraud prevention usually wants both.
Side by side
| Cookie or local storage ID | Fingerly visitor ID in a browser | |
|---|---|---|
| Where the identity lives | In the browser, as a value your site set. | On the server. The browser SDK sets no cookies and keeps nothing in the browser. |
| The visitor clears storage | The identity is gone. | The same device keeps its visitor ID. |
| A private window | A new, empty store. | The incognito_mode signal can fire, and it adds to the score. |
| The visitor edits the value | Possible. The value is theirs. | There is no value in the browser to edit. |
| The device cannot be recognised | A new cookie is simply set. | The answer has identifiable: false and a fresh visitor ID, and you are not charged. |
| Tells you how risky the session is | No. | Yes: suspect_score, suspect_level and, to your backend, the triggers. |
| Works inside an app | Only in a web view. | Not with the web SDK. Use the iOS or Android SDK, which recognise an install ID. |
When a cookie is enough
- Keeping someone signed in, remembering a preference or a cart, and anything else that is about the person who chose to stay.
- Anything you want to disappear when the visitor clears their browser.
When you want a device fingerprint
- Limiting sign-ups, redemptions or trials per device, however many cookies, accounts or email addresses it uses. See sign-up abuse and promotion abuse.
- Counting failed logins per device rather than per address. See credential stuffing.
- Recognising a returning customer on a login or a payment, so a known device meets little friction. See account takeover.
- Seeing that one device is behind many accounts, or that a fresh-looking visitor is one you have seen before.
Using both
Keep your own session cookie for sessions, and store the visitor_id next to your user, order or session records. Comparing the two is where the signal is: one account with many visitor IDs, or one visitor ID with many accounts, is worth a look.
// Your own session says who is signed in. The visitor ID says which device they are on.
const event = await fingerly.events.get(requestId)
const knownDevice = await db.devices.exists({ userId: session.userId, visitorId: event.visitor_id })
if (!knownDevice && event.suspect_level !== 'low') return challenge()
Whether a cookie, a local storage ID or a fingerprint needs consent depends on your lawful basis and where your visitors are. Fingerly's SDKs collect nothing until you pass consent: granted. See privacy and consent.