Patterns

Why is this in beta?

Pattern analysis is still being calibrated because the same technical relationship can mean different business risk in different products. For example, one DeviceID linked to many UserHIDs may indicate bonus abuse, account farming, shared access, internal testing, or another scenario entirely, depending on your business model.ShieldLabs identifies the technical relationships between IDs. Your team should review the affected entities, the action context, the history, and your own policy before deciding whether to monitor, challenge, restrict, review, or block.

Some abuse and fraud only shows up across many visits, so Patterns grade an entity by how its linked identifiers cluster over time, not on any single request. Eight relationship shapes point to it, such as many accounts on one device. They are starting points, not verdicts: several accounts on one device is often perfectly normal, and whether a given count is worth a look depends on your platform (an email provider may expect a dozen accounts behind one device, while a bank expects one account per customer), so read them with your own context. 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 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 a flagged entity at one of two levels by counting its linked identifiers inside a rolling window.

• 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. An entity that stays below the Suspicious threshold is the unflagged baseline: it is never recorded or surfaced.

​

How each pattern triggers

A pattern grades an entity Suspicious when it crosses the lower count in its rolling window, and Dangerous at the higher count. These are the current default thresholds, with the window built into each one. 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.

​

How the level settles

• 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 are server-side configuration. The counts above are the current defaults, the same for every domain. There is no setting you control, and they can change as detection is tuned — read each row as the shape of what trips a pattern, not a number to hard-code against.

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.

​

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, so they load straight into your fraud, billing, or moderation tooling.

​

Next steps