- The Risk Score scores a single visit in real time from the signals on that one request. It is delivered by webhook and readable via the History API. See Risk Score and Signals.
- Abuse Patterns look across many visits over time and flag an entity (a device, an account, a visitor, a local IP) when its linked identifiers cross a threshold. This is correlation over history, not a single-request score.
How a pattern is computed
Each pattern counts linked identifiers for an entity inside a rolling time window, then grades the entity. The identifiers a pattern can group and link are:| Identifier | What it is |
|---|---|
| UserHID | The customer’s own logged-in account id, passed in via the snippet (hashed, never a raw email). |
| VisitorID | UUID5(DeviceID + CookieID). Breaks when storage is cleared. |
| DeviceID | UUID5 of stable browser components. Durable across cookie clear and incognito on the same browser. |
| CookieID | First-party cookie id, minted client-side. |
| Local IP | The WebRTC-derived local IP. Shown on the dashboard as “Local IP”. |
Grading: Normal, Suspicious, Dangerous
Every pattern grades an entity on three tiers:| Grade | Meaning |
|---|---|
| Normal | The entity has not crossed the Suspicious threshold. It is the implicit baseline. Nothing is recorded. |
| Suspicious | The entity crossed the lower threshold for that pattern in its window. |
| Dangerous | The entity crossed the higher threshold. The strongest grade. |
Only Suspicious and Dangerous are persisted as detections. Normal is simply the absence of a detection: an entity that never crosses the Suspicious floor is not recorded.
- The level never downgrades. Once an entity reaches Dangerous, it stays Dangerous across later worker runs. Only its current count and last-seen time update. The grade does not slide back down.
- Thresholds adapt to the entity’s Risk Score. A low-risk entity (a low Risk Score) needs to cross a higher count before it flags, while an entity that already looks anonymous or abusive flags sooner. The thresholds are server-side configuration, not a setting you change.
Time windows
Most patterns use a rolling 30-day window by default. Three override it:| Window | Patterns |
|---|---|
| 30 days (default) | Many Accounts on One Device, Many Devices on One Account, Many Accounts on One Local IP, Shared Local IP Across Multiple Accounts, Many Devices on One Visitor |
| 24 hours | Multiple Countries on One Account |
| 7 days | Changing IDs on One Account |
| Recent 7 days vs 30-day history | New Device and New Country on One Account |
When patterns refresh
A background worker recomputes all 8 patterns for each verified domain on a fixed cadence, roughly every 10 minutes, with one run at startup. There is nothing to trigger and no schedule to configure. Newly flagged entities appear on the Patterns tab on the next pass.The 8 Abuse Patterns
1. Many Accounts on One Device
1. Many Accounts on One Device
One device linked to many different user accounts.A single physical browser environment (one DeviceID) is associated with several distinct logged-in accounts (UserHIDs) inside the window. The pattern groups by device and counts the distinct accounts behind it.
- Window: 30 days
- Grouped by: DeviceID, counting linked UserHIDs (also flags the linked VisitorIDs and CookieIDs)
- Reads as: Suspicious when a handful of stable accounts share one device, Dangerous when many do
- Example abuse cases: Multi-accounting, account farms, anti-fraud bypass
2. Many Devices on One Account
2. Many Devices on One Account
One user account used from many different devices.A single account (UserHID) is seen on an unusually large number of distinct devices (DeviceIDs) inside the window. The pattern groups by account and counts the distinct devices.
- Window: 30 days
- Grouped by: UserHID, counting linked DeviceIDs (also flags the linked VisitorIDs and CookieIDs)
- Reads as: Suspicious when an account spreads across several devices, Dangerous when it spreads across many
- Example abuse cases: Account sharing, account resale, account takeover
3. Many Accounts on One Local IP
3. Many Accounts on One Local IP
Many different accounts connected through the same local (WebRTC) IP.Several distinct accounts share one Local IP inside the window. Because the Local IP is the WebRTC-derived private address, this surfaces accounts that look distinct on the public IP but resolve to the same local network.
- Window: 30 days
- Grouped by: Local IP, counting linked UserHIDs (also flags the linked VisitorIDs and DeviceIDs)
- Reads as: Suspicious when several accounts cluster on one Local IP, Dangerous when many do
- Example abuse cases: Account farms, multi-accounting, anti-fraud bypass
4. Shared Local IP Across Multiple Accounts
4. Shared Local IP Across Multiple Accounts
5. Multiple Countries on One Account
5. Multiple Countries on One Account
One account active from many countries in a short window.A single account (UserHID) appears from several different countries inside a tight 24-hour window. The short window is what makes this meaningful: distance and travel time make a normal user unlikely to legitimately appear from many countries in one day.
- Window: 24 hours
- Grouped by: UserHID, counting distinct countries (also flags the linked DeviceIDs, VisitorIDs, and CookieIDs)
- Reads as: Suspicious when an account spans several countries in a day, Dangerous when it spans more
- Example abuse cases: Account sharing across regions, VPN and proxy abuse, geo bypass
6. Many Devices on One Visitor
6. Many Devices on One Visitor
One VisitorID seen on many distinct devices.A single VisitorID appears across an unusual number of distinct DeviceIDs inside the window. Since
VisitorID = UUID5(DeviceID + CookieID), one VisitorID resolving to many devices points to fingerprint instability or spoofing. This pattern includes anonymous visitors (it does not require a logged-in account).- Window: 30 days
- Grouped by: VisitorID, counting linked DeviceIDs (also flags the linked UserHIDs and CookieIDs)
- Reads as: Suspicious when a visitor maps to several devices, Dangerous when it maps to many
- Example abuse cases: Fingerprint spoofing, anti-detect browsers, automated or scripted activity (surfaced here as a downstream symptom of identity churn)
7. Changing IDs on One Account
7. Changing IDs on One Account
The same account keeps changing its VisitorID, DeviceID, or both.A single account (UserHID) churns through a high number of distinct VisitorIDs or DeviceIDs inside a 7-day window. ShieldLabs grades on the higher of the two churn counts. Some churn is normal (Safari may not persist cookies past 7 days, some browsers reset daily), so the window and thresholds account for that baseline.
- Window: 7 days
- Grouped by: UserHID, counting the greater of distinct DeviceID churn or distinct VisitorID churn
- Reads as: Suspicious when an account changes IDs repeatedly in a week, Dangerous when it changes them constantly
- Example abuse cases: Scripted or automated activity, anti-detect browser usage, anti-fraud bypass, an unstable browser environment
8. New Device and New Country on One Account
8. New Device and New Country on One Account
An existing account appears from a new device and a new country it has not used before.ShieldLabs compares an account’s recent 7 days against its historical activity over a longer lookback. When the account shows up from a (device, country) combination that is new to it, the pattern flags it. The strength rises if there is no prior history in that country and the account’s old device is still active elsewhere.
- Window: recent 7 days, compared against a 30-day historical lookback
- Grouped by: UserHID plus DeviceID, checking new device-and-country combinations against history
- Reads as: Suspicious on a new combination, Dangerous when several new combinations stack up
- Example abuse cases: Account takeover, compromised credentials, suspicious login
A note on “bot activity”
Some pattern use cases mention automated, scripted, or “bot” activity. That language describes a downstream symptom these correlation patterns can surface, for example a VisitorID jumping across many devices. ShieldLabs identifies visitors, detects anonymity (VPN, proxy, Tor, anti-detect browsers), and correlates abuse signals across linked identifiers. Read these use cases as the kinds of abuse a pattern can light up. The patterns flag suspicious correlation over history; your own code decides what to do with a flagged entity.Patterns vs. Risk Score
Use the right tool for the question you are answering.| Risk Score | Abuse Patterns | |
|---|---|---|
| Scope | One visit, in real time | An entity, across history |
| Delivery | Webhook + History API | Dashboard Patterns tab only |
| Question | How anonymous or masked is this single request? | Is this device, account, visitor, or Local IP behaving like coordinated abuse over time? |
| Grades | Clean / Low / Medium / High (0-100) | Normal / Suspicious / Dangerous |
| You act on it | In your own code, per request | By reviewing flagged entities on the dashboard |
Details.
Next steps
Patterns dashboard
See flagged entities, levels, and counts on the dashboard Patterns tab.
Identifiers
How UserHID, VisitorID, DeviceID, CookieID, and the Local IP are made and linked.
Risk Score
The per-request 0-100 score, its bands, and recommended actions.
Acting on the Risk Score
Turn Score plus Details into allow, challenge, review, or block in your own code.