Overview

​

What is ShieldLabs?

ShieldLabs is a software-as-a-service platform for identifying visitors and detecting anonymity at any level with up to 99% accuracy, helping you assess traffic quality and prevent abuse and fraud. It is built for teams from startups to mid-market companies. ShieldLabs covers the full spectrum of anonymity, from a clean or returning visit to visitors and users behind VPNs, proxies, anti-detect browsers, and other anonymity tools. It scores the risk of each visit from 0 to 100, surfaces the anonymity signals behind that score, and provides ready-made patterns that point to abuse and fraud, such as multi-accounting and account sharing, all with detailed analytics and ready to act on through an API and webhooks. ShieldLabs gives you a ready-made layer of transparent data and evidence, and you decide how to use it by setting your own thresholds and rules.

​

How it works

To identify a visitor and detect anonymity signals, ShieldLabs collects 100+ signals from the device, browser, OS, IP, and network on every visit. From the stable ones it derives a set of persistent identifiers, including a durable DeviceID (for example d290f1ee-6c54-4b01-90e6-d701748f0851) and a VisitorID (for example a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d). The DeviceID survives cleared cookies, incognito, and IP rotation. That stability is what lets you recognize the same person on a later visit, even when they try to stay anonymous. It is the foundation of accurate analytics, abuse and fraud prevention, and account protection, and it works the other way too: a returning trusted user is just as easy to recognize, so you can spare them repeated logins and extra checks. The snippet runs quietly in the page and requests no permissions, so visitors are never interrupted. The persistent identifier and the Risk Score come from ShieldLabs and are correlated by the RequestID for each request. Every Risk Score is explainable, not a black box. The Details array lists every signal that fired and the points it added, so you can always see why a visit scored the way it did.

​

Reading the Risk Score

​

Our products

Every feature comes from the same snippet and the same score.

• Identification - precise visitor identification that holds after cleared cookies, IP changes, and incognito, plus recognition of your signed-in users through a hashed account id you control.
• Anonymity Signals - detection of VPNs, proxies, anti-detect browsers, and other anonymity tools. It works by spotting mismatches across the 100+ signals it collects, so it catches masking that ordinary IP blocklists miss.
• Risk Scoring - a Risk Score from 0 to 100 on every visit. Every score comes with a detailed breakdown that shows which anonymity signals fired and how many points each one added.
• Patterns - ready-made patterns that show the connections between accounts, devices, and IPs, pointing to possible abuse and fraud. They are computed from historical correlation between identifiers and shown in the analytics dashboard, graded by risk and scale.
• Traffic Analytics - a single, aggregated risk score across your traffic, tagged by channel, referrer, and UTM, so you rank each source by the risk and anonymous-traffic share it sends. Measure cost per real visitor, not per click.

​

Design patterns

You act on identity in three ways. Each is a building block you combine with your own rules, and every feature page shows the pattern in code.

​

Compare identities across visits

Before a sensitive action, like a login or a withdrawal, your backend reads the identity ShieldLabs returned for the visit and compares it to the one you stored last time. A matching DeviceID means the same device came back, so a trusted user continues without extra checks. A mismatch can mean a new device, or an attempt that is not the real account holder, so it is worth a step-up such as a one-time code. This keeps sensitive actions in the hands of the people who own the account.

​

Count identities linked to one account

Each time a key action happens, your backend adds the visit’s identity to the set it keeps for that account. When one account gathers many distinct devices, that can mean shared credentials or an account takeover. When one device gathers many accounts, that can mean multi-accounting or a signup farm. You can keep these counts yourself from the History API, or let Patterns track and grade them for you on the dashboard.

​

Act on the Risk Score and its Details

When you make decisions about a visitor’s or user’s risk score, the anonymity signals behind it, and traffic quality, read the risk score band together with the Details, which explain which signals make up the final score and how much each anonymity signal added. Then let your code choose the action: allow, challenge, send to manual review, or block. The same risk score can call for different actions depending on the situation, so always weigh it against how sensitive the specific action is. A recommended policy for each band gives you a starting point.

​

Use cases

The patterns above power most fraud-prevention and traffic-quality work. Here are four common examples.

​

Reduce login friction

The pattern used here is comparing identities across visits. On a trusted login, your backend compares the current identifier to the one it saw for that account before. When they match and the visit carries no anonymity signals, the user signs in with no extra challenge. When the identifier is new, or the login arrives over a VPN, proxy, or anti-detect browser, you add a check. Returning users on a known device get a smoother path, and an unexpected or masked login is still verified before it gets in. The full identifier model covers what you compare.

​

Prevent account sharing and takeover

The pattern used here is counting identities linked to one account. By counting the distinct devices that reach a single account, you can tell an ordinary household apart from a shared password or a hijacked login. A takeover attempt often pairs a new device with anonymity signals such as a datacenter IP or a VPN, which push up the risk score on that session. Past a threshold you set, prompt the real owner to verify instead of locking everyone out. The “Many Devices on One Account” pattern surfaces this on the dashboard.

​

Stop multi-accounting at signup

The pattern used here is counting accounts linked to one device. When new signups should map to real, distinct people, count how many accounts trace back to one identifier. A small number is normal. One device behind many fresh accounts, especially over an anti-detect browser or a proxy, points to a signup farm or promo abuse, and earns a step-up such as phone verification. The “Many Accounts on One Device” pattern grades this for you.

​

Screen anonymous and high-risk traffic

The pattern used here is acting on the risk score and its Details. Every visit arrives with a risk score and the anonymity signals behind it: VPN, proxy, Tor, iCloud Private Relay, datacenter IPs, and anti-detect browsers among them. Score a checkout, a payout, or a signup, read which signals fired in the Details, and let your code allow, challenge, or block. A legitimate user on a corporate VPN can score high, so weigh the score against how sensitive the action is.

​

Built to stay accurate

Identification is split between the browser and the server. The snippet collects the signals on the page, and ShieldLabs derives the identifiers, detects the anonymity signals, and computes the risk score on the server. That split is what keeps results steady as browsers change.

• Resilient to browser privacy changes. The identifiers are derived on the server from many stable signals, not from a cookie or a single browser API. When a signal is missing, the server still derives the identity from the ones that remain, so no single cleared cookie or blocked API takes identification down. And because the risk score is corroborated across many independent signals, losing any one lowers confidence gradually instead of breaking the result. Privacy updates affect every identification method, and the server-side half is what keeps ShieldLabs comparatively stable when they land.
• No permissions, no interruption. The snippet requests no permissions and shows no pop-ups. It runs asynchronously and does not block page load, so visitors are never interrupted while they act.
• Degrades gracefully when a signal is unavailable. Every signal is collected within a time limit, and errors are handled. If a signal cannot be obtained, for example on an older device or a browser with strict privacy settings, the snippet skips it and still sends the visit, without hanging or blocking the page.
• Hard to fake. A spoofed environment often contains internal mismatches that raise the risk score, so faking one signal is not enough to make a visit look safe. Using an anti-detect browser is itself one of the signals ShieldLabs detects.

​

Next steps