Skip to main content
The Patterns tab on the dashboard is where the 8 Abuse Patterns show up. Each pattern correlates linked identifiers across your historical identify data and flags entities (a device, an account, a VisitorID, a Local IP) that cross a threshold over a rolling window. This tab is read-only. ShieldLabs surfaces the flagged entities. Your own code owns every allow, challenge, review, or block decision. There is no in-product rules engine and no threshold UI: you export the flagged IDs and act on them in your own systems. The pattern descriptions, windows, grading theory, and the full catalog live on Abuse Patterns; this page documents the tab itself.
Abuse Patterns are a dashboard feature only. They are computed server-side from history and are not part of the webhook or Management API payload. For per-request decisions in your own code, use the Risk Score and Details you receive over webhooks.

​
How the tab is laid out

At the top of the tab is a Project select (default All Projects) that scopes everything below it to one domain or all of them. Below that are two sections:
  1. The Overlap Summary block: deduplicated totals across all patterns.
  2. The pattern cards: one card per abuse pattern, each broken down per identifier.

​
Empty until thresholds are crossed

A freshly connected domain shows an empty state:
No patterns detected yet. The pattern worker runs every 10 minutes. Data will appear once traffic is collected and detection thresholds are crossed.
A background worker recomputes all 8 patterns for each verified domain about every 10 minutes (with one run at startup). There is nothing to trigger and no schedule to configure. New flags appear on the next pass. A pattern only records a detection once an entity crosses its Suspicious floor, so low-traffic or clean domains stay empty by design.

​
Overlap Summary

One entity can match several patterns at once. The same DeviceID might show up under “Many Accounts on One Device” and under “Many Accounts on One Local IP.” Because of that, the totals on the individual pattern cards are not additive: summing them double-counts entities that match more than one pattern. The Overlap Summary block exists to give you the deduplicated picture. Its tooltip reads:
IDs may appear in multiple patterns. Totals across pattern cards are not additive. Use this block to compare total matches vs deduplicated affected IDs.

​
Severity filter

Three buttons scope the whole block:
FilterShows
All SeveritiesEvery flagged entity, Suspicious and Dangerous.
SuspiciousOnly entities graded Suspicious.
DangerousOnly entities graded Dangerous.

​
The three stats

StatTooltipWhat it tells you
Total affected IDs”All flagged IDs”The raw count of flags across every pattern. An ID that matches three patterns counts three times here.
Unique affected IDs”Deduplicated flagged IDs”The distinct count of entities flagged at least once. An ID that matches three patterns counts once here.
Avg patterns per ID”Average number of matched patterns per flagged ID”Total divided by Unique. A higher average means your flagged entities are tripping several patterns each, which is a stronger coordination signal than many entities each tripping one.
A bar chart beside the stats plots how many distinct entities matched 1 pattern, 2 patterns, 3 patterns, and so on. The right-hand tail of that chart (entities matching many patterns at once) is usually where the most clearly coordinated abuse sits.
Read Total vs Unique together. If Total is far larger than Unique, a small set of entities is responsible for a lot of flags. Sort your review by the entities at the high-pattern-count end of the chart first.

​
Pattern cards

Below the Overlap Summary is one card per abuse pattern. Each card shows:
  • the pattern name (for example, Many Accounts on One Device)
  • a one-line description of what it correlates
  • a Possible abuse cases row of badges (for example, Multi-accounting, Account farms, Anti-fraud bypass)
  • a grid of per-identifier blocks, one block per identifier type the pattern flags
The named patterns, their windows, their grading theory, and the abuse-case framing are documented in full on Abuse Patterns. The eight are: Many Accounts on One Device, Many Devices on One Account, Many Accounts on One Local IP, Shared Local IP Across Multiple Accounts, Multiple Countries on One Account, Many Devices on One Visitor, Changing IDs on One Account, and New Device and New Country on One Account.

​
Per-identifier blocks

Inside each card, an identifier block reports counts for one identifier type. The identifier types a pattern can flag are:
BlockIdentifier
UserHIDYour own logged-in account id, passed in via the snippet (hashed, never a raw email).
VisitorIDUUID5(DeviceID + CookieID). Breaks when storage is cleared.
DeviceIDUUID5 of stable browser components. Durable across cookie clear and incognito on the same browser.
CookieIDFirst-party cookie id, minted client-side.
WebRTC IPThe WebRTC-derived local IP, shown elsewhere as “Local IP”.
How each identifier is derived and how durable it is lives on Identifiers. Not every pattern flags every identifier: each card shows only the blocks relevant to that pattern. Each block shows a total count plus a Suspicious sub-count and a Dangerous sub-count, so you can see how the flags for that identifier split across the two persisted levels.
When a group fires, ShieldLabs marks every linked participant at the same level, not just the entity that triggered it. A flagged device also flags the accounts, visitors, and cookie ids correlated with it. That is why one event can populate several identifier blocks across a card.

​
Grading: Normal, Suspicious, Dangerous

Every pattern grades an entity on a three-level ramp.
GradeMeaning
NormalThe entity has not crossed the Suspicious threshold. It is the implicit baseline and is not recorded.
SuspiciousThe entity crossed the lower threshold for that pattern in its window.
DangerousThe entity crossed the higher threshold. The strongest grade.
Only Suspicious and Dangerous are persisted as detections, which is why those are the only two sub-counts on each identifier block. Normal is simply the absence of a flag. A level never downgrades: once an entity reaches Dangerous it stays Dangerous on later worker runs, and only its current count and last-seen time update.
The thresholds are server-side configuration, not a setting you change, and they adapt to the entity’s Risk Score: an entity that already looks anonymous or abusive flags sooner, while a low-risk entity has to cross a higher count first. Treat the levels as a prioritized review queue, not a verdict. A legitimate user can land on a card (shared office network, a frequent traveler, a privacy browser). Confirm against your own context before you act.

​
Card actions

Each pattern card has three actions.

More

Opens a detail modal for the pattern.

Export IDs

Downloads the flagged identifiers as a CSV.

View in Data

Deep-links to the Data tab, filtered to this pattern.

​
More: the detail modal

More opens a modal that repeats the per-identifier blocks and adds a How it triggers section. That section spells out the pattern’s thresholds in plain language, color-coded by level:
  • Normal (the baseline, no detection)
  • Suspicious (orange)
  • Dangerous (red)
It reads as count-in-window text, for example: Normal: up to 3 accounts in 30 days. Suspicious: 4 to 9 accounts in 30 days. Dangerous: 10 or more accounts in 30 days.
The numbers in How it triggers are illustrative of intent, not guaranteed exact thresholds. The live thresholds are server-side configuration that can change and that shifts with each entity’s Risk Score. Some patterns also carry a Score note (“thresholds adapt to the entity’s risk score”) and browser-specific notes (for example, Safari uses shorter history because cookies may not persist past 7 days). Read each line as “flags when an entity crosses a Suspicious or Dangerous count in this window,” not as a fixed number you can rely on.

​
Export IDs: the flagged-entity CSV

Export IDs downloads the flagged identifiers for that pattern as a CSV. This is the bridge from the dashboard to your own systems.
Workflow
1. Review a pattern card (or the Overlap Summary for cross-pattern entities).
2. Click "Export IDs" to download the flagged UserHIDs / VisitorIDs /
   DeviceIDs / CookieIDs / WebRTC IPs as CSV.
3. Load the CSV into your own fraud, billing, or moderation tooling.
4. Apply your own policy: flag the accounts, require re-verification,
   tighten limits, queue for manual review, or block, in YOUR code.
ShieldLabs hands you the list of correlated identifiers. What you do with them (flag, re-verify, rate-limit, review, or block) is a decision your own application owns. The exported IDs join cleanly to the per-request records you receive over webhooks and read through the History API.
Exports are free. They do not consume request balance. Billing is per identification only. See Billing.
View in Data opens the Data tab pre-filtered to this pattern, so you can drill from “this device matched Many Accounts on One Device” to the individual request rows behind the flag. On the Data tab you can:
  • filter records to any one of the 8 patterns
  • toggle Pattern IDs highlighting (highlights the ID cells that match a pattern)
  • toggle Patterns Count (a per-row count of how many patterns each record matched)
  • export the underlying request records as CSV or JSON
This gives you the row-level evidence (identifiers, country, signals, Risk Score) for every flagged entity.

​
How to work the tab

1

Scope it

Pick a Project and set the Overlap Summary severity filter to Dangerous to start with your highest-confidence flags.
2

Find the coordinated entities

In the Overlap Summary, compare Total vs Unique affected IDs and read the Avg patterns per ID. Use the bar chart to find entities matching the most patterns at once.
3

Open the pattern that matters

On the relevant pattern card, read the per-identifier blocks and their Suspicious / Dangerous sub-counts. Use More to confirm what threshold it crossed.
4

Get the evidence

Use View in Data to inspect the request rows behind the flag and confirm context before you act.
5

Export and act

Use Export IDs to pull the flagged identifiers as CSV, then apply your own policy in your own systems.

​
Patterns vs. the Risk Score

The Patterns tab and the Risk Score answer different questions. Use the right one.
Risk ScoreAbuse Patterns
ScopeOne visit, in real timeAn entity, across history
DeliveryWebhook + History APIThis dashboard tab only
GradesClean / Low / Medium / High (0-100)Normal / Suspicious / Dangerous
You act on itIn your own code, per requestBy exporting flagged IDs and acting in your own systems

​
Next steps

Abuse Patterns catalog

The 8 patterns in full: descriptions, windows, grading, and abuse cases.

Data tab

The request records behind each flag, filterable by pattern and exportable.

Identifiers

How UserHID, VisitorID, DeviceID, CookieID, and the Local IP are made and linked.

Acting on the Risk Score

Turn the Risk Score and Details into allow, challenge, review, or block in your own code.