Patterns

Patterns link a visitor’s activity over time and flag eight relationship shapes that signal abuse, such as many accounts on one device. They look across many visits, not one request, and grade an entity by how its linked identifiers cluster. A pattern flags an entity: a device, an account, a visitor, or a Local IP. When that entity’s correlations cross a threshold, it surfaces on the dashboard for your team to review.

​

The eight abuse patterns

Each pattern answers one question about how identifiers cluster over time. The name says the shape, the outcome says what it signals. “Local IP” is the dashboard name for the visitor’s local network address, used to correlate accounts that look distinct on their public IP.

​

How grading works

Every pattern grades an entity on three levels by counting its linked identifiers inside a rolling window.

• Normal - the entity has not crossed the Suspicious threshold. The 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 stored as detections. Normal is simply the absence of a flag.

​

The window

Most patterns count over a rolling 30-day window. Three use a shorter one to make the signal meaningful. A tight window is what gives Multiple Countries on One Account its meaning: one account from several countries in a day is hard to explain as normal travel.

​

Two rules shape every grade

• The level never downgrades. Once an entity reaches Dangerous, it stays Dangerous on later runs. Only its current count and last-seen time update.
• Thresholds adapt to the entity’s Risk Score. An entity that already looks anonymous or abusive flags sooner. A low-risk entity has to cross a higher count first.

A legitimate user can land on a card too: a shared office network, a frequent traveler, a privacy browser. Confirm against your own context before you act.

​

Where patterns live

Patterns are computed server-side from your historical identify data, then shown on the dashboard Patterns view. A background worker recomputes all eight for each verified domain about every 10 minutes, with one run at startup. There is nothing to trigger and no schedule to configure. The Patterns view gives you three things.

• Overlap summary - deduplicated totals across all patterns, so you can tell whether a small set of entities is responsible for most flags. Per-card totals are not additive: an entity matching three patterns counts three times across the cards but once here.
• Pattern cards - one card per pattern, broken down per identifier, each with a Suspicious and a Dangerous sub-count. You can export flagged IDs to CSV or JSON, or open the Data view filtered to that pattern.
• Data view - the request rows behind each flag, with the identifiers, country, signals, and Risk Score that produced it.

​

Patterns are distinct from per-request signals

Patterns and the per-request Risk Score answer different questions. Use the right one for the job. A note on “bot activity”: some pattern use cases mention automated or scripted traffic. That is a downstream symptom these correlation patterns can surface, for example a visitor jumping across many devices. ShieldLabs identifies visitors, detects anonymity, and correlates abuse signals across linked identifiers.

​

You export the IDs and decide

The Patterns view 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. The workflow is short. The exported IDs join cleanly to the per-request records you receive over webhooks and read through the History API. Load them into your fraud, billing, or moderation tooling and apply your rules there.

​

Next steps