- The Device ID is computed on the server from the device itself, not from anything the browser stores. It is what lets a returning person keep the same identity after clearing cookies or using incognito.
- Risk signals tell you whether an identification looks relayed, tunneled, spoofed, automated, or coming from infrastructure. Each risk signal that fires is named in the webhook
signalsarray with its weight.
Identification accuracy
Identification accuracy is the ability to recognize a returning browser as the same one over time. The handle for this is the Device ID, the most durable identifier ShieldLabs produces. The Device ID is computed on the server, not stored in the browser, so it holds through cleared cookies, incognito mode and IP changes (see Identifiers). Because nothing about it lives in the cookie, it holds when cookie-based tracking breaks. This is the difference from cookie analytics. Tools that count by a first-party cookie or client ID count a brand-new visitor every time someone clears cookies or opens incognito. Recognizing by a derived identity keeps that returning person on the same Device ID instead. A returning visitor keeps a stable Device ID even when the cookie-scoped Visitor ID resets:device_id is the durable handle here. The visitor_id is the cookie-scoped view (one device plus one cookie), so it changes when cookies are cleared while the device_id stays put. The full identifier model walks through how each one is made.
How accuracy is measured
Both figures come from testing ShieldLabs against a wide range of browser, device and network fingerprints, from ordinary browsers and direct connections to masked, spoofed and proxied setups. On every test identification the snippet collects the full set of signals, and network and device intelligence are cross-checked against each other before a result is returned.- Identification accuracy (99.9%) is how reliably a returning browser gets the same Device ID across those fingerprints.
- Risk signal detection accuracy (99.9%) is how reliably the matching risk signal fires when an identification is masked.
- What is collected. ShieldLabs collects 344 signals: 196 from the browser and device, 83 from the network, 27 from user behavior and 38 cross-checks between them. Every connection is also checked against 446 network signatures, with IP data merged from several sources.
- How the Risk Score is built. The Risk Score is the sum of the fixed weights of the risk signals that fire, capped at 100. The weighted risk signals cover the network (such as Tor, iCloud Private Relay, VPN, proxy and datacenter IPs) and the device and browser (such as an OS that does not match the network, a timezone mismatch, anti-detect browsers and browser automation). Every risk signal that fires is returned by name with its weight, and Risk Scoring publishes the full table.
- Automated tests. ShieldLabs detection is backed by 1,511 automated tests: 119 for VPN, browser VPN and proxy detection, 104 for anti-detect browsers, virtual machines and fingerprint consistency, 73 for risk scoring, 69 for network and OS fingerprints, 65 for WebRTC and STUN leaks, 47 for browser signal collection, 46 for timezone, geolocation and IP data, 41 for identification, 24 for bots and automation, 11 for High-Risk Events and 912 for signal processing, data delivery, the API, webhooks and the analytics dashboard.
- Identification tests check that the Device ID stays the same when the user agent, browser version, screen, locale or request timing change, that it changes when a stable device component changes, and that a visitor who clears cookies is recognized again.
- Production audit. Detection results are audited on more than 1 million mobile and web identifications.
You can check both figures on your own traffic. Start with 5,000 free identifications, one time, no credit card. Run ShieldLabs next to any tool you already use and compare which users, devices and IP addresses each one flags.
High-Risk Events
ShieldLabs detects four High-Risk Events on your users out of the box, without building rules or training a fraud model, and grades each at Medium or High confidence, a separate axis from the Risk Score. High-Risk Events are available in the analytics dashboard, the API and webhooks. The confidence of each event depends on the combination of evidence.- Multi-accounting: several accounts run by one person, linked through the devices and network they share. By default it fires from 3 accounts on one visitor, and the threshold is configurable.
- Account sharing: one account used from several distinct devices. By default it fires from 4 devices on one account, and the threshold is configurable.
- Impossible travel: an account appearing in locations it could not reach in the time between them.
- Account takeover: an existing account appearing in a new environment that points to someone else using it.
checkAuthenticatedUser. High-Risk Events covers each one and the legitimate cases to allow for.
Risk signal detection accuracy
Risk signal detection accuracy is the ability to tell that an identification is masked: relayed, tunneled, spoofed, or coming from infrastructure rather than an ordinary network. You never have to take the result on faith. Every Risk Score is explainable: each risk signal that fires lands in thesignals array with its weight (what it added to the Risk Score), and risk_score is their sum, capped at 100, so you can see which risk signals produced the number.
The risk signals page lists every one; the Risk Scoring table carries the weights.
The 99.9% risk signal detection figure is measured as described in How accuracy is measured.
A worked example
An identification scored70, with the risk signals that produced it:
70, which lands in the Dangerous band (60-100). The Risk Scoring table lists every risk signal and its weight; branch on detection_flags and signals[].name, not on display labels.
99.9%, never 100%. No detection is perfect, so decide on the Risk Score, its
signals and the user’s history together, and choose the action for each case.Reading the results
Read both figures with these points in mind.- Identifiers count browsers; users count accounts. One person on two browsers is two Device IDs until they sign in; the User HID then joins both Device IDs to one user. Treat visitor and device counts as a close measure of people.
- Read a high Risk Score with its risk signals and the user’s history. A real customer on a corporate VPN can reach the Suspicious band; the risk signals show why, and you choose the action for each case.
- A legitimate user can look masked. A corporate proxy, a VPN, or a privacy browser all raise the Risk Score without any wrongdoing.
- You choose the action for each case. ShieldLabs returns the Risk Score and every named risk signal on each identification and detects High-Risk Events on your users; you allow, challenge, review or block in your backend. ShieldLabs stops fraud and abuse and helps block fraudulent and abusive traffic.
Next steps
Identifiers
The identifiers each identification carries and how they tie to your users, devices, visitors and IP addresses.
Risk Signals
Every risk signal that can fire, from masking to bots, and the connection type behind it.
Risk Scoring
The explainable 0 to 100 Risk Score and its bands: Trusted, Suspicious, Dangerous.