identification_id to retrieve one result, device_id to investigate returning device activity, and user_hid to associate checks with an authenticated account.
An identification, a user and a visitor are entities. A device and an IP address are anchors on the check. A Session ID and a Cookie ID name neither.
The identifier model
These are technical identifiers, not a verified identity of a person. Browser or device changes can affect recognition. Use the account ID you supply to connect a known user’s activity across devices.
The User HID is your account key
Pass a stable pseudonymous account token tocheckAuthenticatedUser(userHid) or the matching SDK option. Generate the token on your backend and reuse it for that account. Do not send a raw email, login or other personal account data.
The snippet accepts the supplied value without checking that it is a hash. It sends the value with the check’s technical data in an encrypted request. Your application determines which account it represents; ShieldLabs stores it and groups checks with the same value within one site.
High-Risk Events need this account association. checkAnonymous() records a check without a signed-in user; it does not imply that a later sign-in will reassign earlier checks.
Why the Device ID is durable
Device recognition does not depend solely on a cookie or IP address. It helps identify repeated activity when those change. Treat a missing or all-zero Device ID as unavailable evidence, not as a device shared by every incomplete check. ShieldLabs calculates Device ID from hardware and software characteristics of the browser environment. Different browsers on one physical device can have differentdevice_id values: Chrome and Microsoft Edge on the same computer are one example. For High-Risk Events, ShieldLabs also uses its own device-matching algorithms within the account to recognize one physical device across these changes. See Device ID.
Preserve identifiers as returned. Do not derive device equivalence by modifying or comparing parts of IDs.
The Visitor ID
A Visitor ID identifies a visitor using the device, cookie and previously stored links. When the cookie or device characteristics change, ShieldLabs compares the available data to retain the previous identifier where possible. Visitors and devices are different concepts and can have different counts. Private browsing has separate cookies, so its Visitor ID may differ from regular browsing. A check without JavaScript, where no device or cookie is available, receives a separate Visitor ID. See Visitor ID.Session and cookie storage
Open site tabs for the same user share a Session ID inlocalStorage. After the last page is closed or left, the next site load creates a new Session ID. Navigation within a single-page application without a full reload preserves it; a full reload in the only open tab can create a new one. Session ID groups browsing activity and is separate from your application’s login session.
Cookie ID is stored in both a first-party cookie and localStorage. If either copy survives, the snippet reuses the value and restores the other. A new Cookie ID is created when no saved value can be retrieved. Private browsing uses separate storage. See Session ID and Cookie ID.
Read an identification
A shortened scored webhook:id for the Identification ID, risk.score when risk.state is ok, a public_ip string for the address and a traffic object for attribution. The scored webhook instead uses identification_id, risk_score, public_ip.ip and traffic_source inside data.
Related: Users, devices, visitors and IPs, Identification flow, Accuracy.