Skip to main content
Identification gives every visitor a persistent VisitorID and DeviceID that survive cleared cookies, incognito, and IP rotation within the same browser. One snippet collects the signals. The server returns the identity plus the signals around the device, all in one response. You read it from the webhook or the History API.

​
The identifier model

Every identify call returns six identifiers. Each one answers a different question, from “this exact call” up to “this known account.”
IdentifierHow it is madePersistence
RequestIDA client-generated UUID, one per identify call. It joins the snapshot, the webhook, and History together.Unique per call.
SessionIDA client UUID for the current visit, scoped to a short browsing window.Per visit or tab.
CookieIDA first-party UUID minted in the browser and stored in cookies and site storage.Lost when cookies or site storage are cleared.
DeviceIDServer-derived from dozens of stable browser and device characteristics. Not stored in the browser.Durable. Survives cleared cookies, incognito, and IP rotation within the same browser. Browser-bound.
VisitorIDServer-derived from the DeviceID combined with the CookieID.Resets when cookies are cleared. Many VisitorIDs can map to one DeviceID.
UserHIDYour own hashed account id, passed into the snippet. ShieldLabs never derives it.Whatever you set.
RequestID, SessionID, and CookieID are minted in the browser. DeviceID and VisitorID are computed on the server, so the browser never sees them. You correlate everything by RequestID.

​
Why DeviceID is durable

DeviceID is the identifier most analytics tools cannot match, because it is derived, not stored. The server computes it from dozens of stable browser and device characteristics. The same browser environment always produces the same DeviceID. Because nothing about it lives in the cookie, it holds when cookie-based tracking breaks:
  • Survives cleared cookies. Clearing cookies removes the CookieID, not the identity.
  • Survives incognito. A private window is the same browser on the same machine.
  • Survives IP rotation. Switching networks or using a VPN does not change the identity.
This durability is why a returning person on the same browser keeps the same DeviceID, even after their cookies expire.
DeviceID is browser-bound. The same person on Chrome and on Firefox produces two different DeviceIDs. ShieldLabs does not do cross-browser recognition today, and identity-based counts are best read as estimated, not exact.

​
Why VisitorID resets

VisitorID is built from two inputs: the DeviceID and the CookieID. The DeviceID half is durable. The CookieID half is not. So when a visitor clears cookies:
  1. The CookieID is gone, and the browser mints a fresh one on the next visit.
  2. The server combines the same DeviceID with the new CookieID.
  3. The result is a new VisitorID.
That is by design. One durable DeviceID can sit behind many VisitorIDs over time. Use DeviceID for the most stable handle on a returning person within a browser. Use VisitorID for the cookie-scoped view, and UserHID once a person signs in.
A burst of new VisitorIDs all mapping to one DeviceID, or one VisitorID seen across many DeviceIDs, is itself a signal. The dashboard surfaces these as Patterns.

​
UserHID is your hashed account id

UserHID is the only identifier you control. It is your own account id, passed into the snippet so ShieldLabs can tie anonymous activity to a known account. Pass a hashed or pseudonymous value, and apply the same transform every time so the same account always maps to the same UserHID. 
// Hash the account id before passing it to the snippet.
const userHID = await sha256(currentUser.id); // never the raw id or email
const mod = await import('https://cdn.shieldlabs.ai/snippet.js?publicKey=YOUR_PUBLIC_KEY');
mod.checkAuthenticatedUser(userHID);
Never pass a raw email, username, or primary-key user id as the UserHID. ShieldLabs echoes the UserHID back in webhooks and History, so a raw value would put plaintext account data in those payloads. Always hash it or use a pseudonymous token.
When no one is signed in, call checkAnonymous() and the UserHID is left unset. See the snippet setup for the full method list.

​
Device Intelligence is part of identification

The output of identification is not just an ID. It is the identity plus the signals around that device, delivered together in one response.
You getWhat it is
DeviceIDThe persistent, browser-bound identity described above.
Risk Score (0-100)An explainable score with a Details array naming every signal that fired. See Risk Scoring.
SignalsThe anonymity and mismatch signals behind the score. See Anonymity Signals.
You never call a separate “fingerprint” endpoint and a separate “risk” endpoint. One snippet collects the signals, the server scores them, and the result arrives by webhook. Browser fingerprinting is a component of this, not the whole thing.

​
Example response

A realistic webhook body. The six identifiers arrive alongside the Risk Score and the Details that explain it. 
{
  "RequestID": "13f84f05-2f3a-4c2e-9b1f-7a6d3e8c1b22",
  "SessionID": "a1c9e740-5b6d-4e2a-8f31-0c2b9d4e7f11",
  "CookieID": "7e2d1b88-3c4f-4a9e-b6d2-1f8a0c5e9d34",
  "DeviceID": "5eb7fd5c-9a21-4b6e-8c3d-2f1a9e7b0c45",
  "VisitorID": "161dfbad-4e8c-4d1a-9f72-3b6c0a2e8d57",
  "IP": "37.214.25.112",
  "OS": "Windows",
  "Country": "Belarus",
  "UserHID": "8f14e45fceea167a5a36dedd4bea2543",
  "Score": 30,
  "Details": [
    { "Value": 15, "Description": "VPN" },
    { "Value": 15, "Description": "Privacy Relay" }
  ],
  "LastRequestTime": "2026-06-16T18:00:21.685Z",
  "Phase": "initial"
}
DeviceID and VisitorID are the server-derived identity. UserHID is your hashed account id, echoed back. For every field and its types, see API models.

​
Next steps

Anonymity Signals

VPN, proxy, Tor, Privacy Relay, and the mismatch signals around each device.

Risk Scoring

The explainable 0 to 100 score and its bands: Clean, Low, Medium, High.

Glossary

Every identifier and term in one place.