> ## Documentation Index > Fetch the complete documentation index at: https://docs.shieldlabs.ai/llms.txt > Use this file to discover all available pages before exploring further. # Glossary > Plain definitions for the terms used across ShieldLabs docs: identifiers, the Risk Score, anonymity signals, Patterns, and integration. A quick reference for the terms used across these docs. Each entry is a short, standalone definition; most link to the page where the concept is covered in full. ## Identifiers The full [identifier model](/features/identification) covers how each id below is built and how durable it is. ### RequestID A UUID generated per identify call. It is the join key that ties a single check across the snapshot, the [webhook](/api/webhooks), and the [History API](/api/server-api). Use it as your idempotency key. ### SessionID A per-visit, short-lived UUID stored in the browser's `sessionStorage`. Resets on a new session or tab. ### CookieID A first-party cookie / `localStorage` UUID minted in the browser. It is lost when the visitor clears cookies or storage. ### DeviceID A [server-derived](/features/identification) identifier computed from hundreds of stable browser and device characteristics. Because it is derived rather than stored, it survives cleared cookies, incognito, and IP rotation. This is the durable identity that recognizes a returning browser across cookie clears and incognito. When the snippet cannot run, it returns the all-zero UUID. ### VisitorID A server-derived identifier built from the DeviceID and the CookieID. Because it includes the cookie, it changes when cookies are cleared. Many VisitorIDs can map to one DeviceID. ### UserHID Your own account identifier, passed in from the snippet. It must be hashed or pseudonymous, never a raw email or login; you set this value yourself. ## Risk Score and signals The [Risk Score](/features/risk-scoring) reference and the [signal catalog](/features/anonymity-signals) explain the mechanics behind the terms below. ### Risk Score An explainable score from 0 to 100 (hard-capped at 100) attached to each visit. Higher means more anonymous, masked, or abusive. It is a weighted sum of the signals that fired. ShieldLabs reports the score; your own code decides what to do with it. ### Band The four labels the Risk Score maps to: Clean (0 to 9), Low (10 to 29), Medium (30 to 59), High (60 to 100). There is no other band; the [Risk Score](/features/risk-scoring) page carries the full table. ### Signal One detectable property of a visit — an anonymity signal — that contributes points to the Risk Score, such as VPN, Tor, OS Mismatch, or Anti-detect Browser. The full catalog and its weights are on [Anonymity Signals](/features/anonymity-signals). ### Details The explainable breakdown on a **History snapshot** (PascalCase): an array of `{ "Value": , "Description": "" }`. The webhook `data.signals` array carries the same breakdown as stable `{ "name", "weight" }` slugs; see [Data Models](/api/models). ### Detection flags The `detection_flags` object inside webhook `data` and on snapshots: one **stable boolean** per detection dimension (for example `vpn`, `tor`, `datacenter_ip`, `abuser`). Branch on these and on signal `name` slugs in your code. They are a superset of the scored [anonymity signals](/features/anonymity-signals) plus informational flags that carry no score today (`incognito`, `ip_mismatch`, `suspicious_paid_click`). The full list is in the [webhook reference](/api/webhooks). ## Anonymity and connections The [anonymity signals](/features/anonymity-signals) reference covers the checks and connection types defined below. ### Anonymity detection The set of checks that determine how masked a visit is: VPN, proxy, Tor, Privacy Relay, datacenter IPs, IP reputation, anti-detect browsers, and location / timezone spoofing. ### Connection type The classification of a visit's connection. The `connection_type` field on the webhook and snapshot carries one of `direct`, `mobile`, `vpn`, `proxy`, `tor`, `privacy_relay`, `browser_vpn_proxy`, or `unknown` (when the type could not be resolved). The dashboard breakdown uses the same values and counts in-browser VPN/proxy extensions under Proxy. Each signal below also appears as a stable boolean in [`detection_flags`](#detection-flags); the flag name is shown in `code` so you can map a log field to its meaning. ### VPN A virtual private network routes traffic through an intermediary server, so the visible IP belongs to the VPN provider rather than the visitor (`vpn`). ### Browser VPN/Proxy An in-browser VPN or proxy *extension* routing the session, rather than a system-wide VPN. An extension-level mask and a deliberate choice to hide the connection (`browser_vpn_proxy`). The dashboard counts it under Proxy. ### Proxy A proxy server relays a connection so the destination sees the proxy's IP instead of the visitor's. Proxies range from datacenter to residential; ShieldLabs weighs the proxy signal together with IP reputation and datacenter checks (`proxy`). ### Residential proxy A proxy that routes traffic through real consumer devices and home ISPs, so the exit IP looks like an ordinary residential connection and carries residential reputation. Read it in the full context of the visit, not on the IP alone — for example a residential proxy paired with an anti-detect browser is a far stronger signal than the IP by itself. ### Datacenter IP An IP that belongs to a hosting provider or cloud datacenter rather than a consumer ISP. Ordinary visitors rarely browse from datacenter ranges, so ShieldLabs treats it as an anonymity signal (`datacenter_ip`). ### Tor The Tor network routes traffic through a chain of volunteer relays, so the exit IP cannot be traced back to the visitor. A visit from a known Tor exit node is the strongest single anonymity signal (`tor`). ### Privacy Relay iCloud Private Relay or a similar service that hides the IP for privacy. ShieldLabs surfaces it as its own connection type so you can choose to treat a privacy-conscious visitor differently from a generic VPN (`privacy_relay`). ### Abuser Flag (IP reputation) A reputation check on the visitor's IP or device. It flags addresses that appear on known blocklists — for example a known proxy or Tor exit, or an address linked to earlier spam or network attacks (`abuser`). ### Anti-detect browser A browser built to spoof or randomize its fingerprint to evade identification. ShieldLabs surfaces it through cross-layer signals. A deliberate, sophisticated evasion attempt and a strong tell (`anti_detect_browser`). ### Browser automation A browser driven by an automation framework instead of a person, detected when the standard `navigator.webdriver` flag is set (frameworks such as Selenium, Puppeteer, or Playwright set it by default). Near-certain non-human traffic; it scores independently of the connection (`browser_automation`). ### Search bot A visit from a known search-engine crawler IP such as Googlebot or Bingbot. It is not a masking signal — it adds no points and instead groups the visit into the **Search bot** traffic channel so crawlers do not distort your analytics (`search_bot`). ### OS Mismatch The operating system reported by the device and browser does not match the OS determined from other data, such as the network. A clear spoofing sign: an honest device does not contradict itself (`os_mismatch`). ### OS not Detected The operating system could not be determined from the available device, browser, and network data — the environment was stripped down or had unusual parameters (`os_not_detected`). ### Timezone Mismatch The browser's timezone does not match the timezone of the IP's location. A location-spoofing tell that can also be innocent, such as a traveler (`timezone_mismatch`). ### IP Mismatch The public IP (`public_ip`) and the real network IP from the follow-up check (`local_ip`) resolve to different countries. **Informational only — it does not add to the Risk Score.** A raw difference can be benign (mobile networks route over different paths), so compare `public_ip.country` with `local_ip.country` rather than acting on the raw flag (`ip_mismatch`). ### Stun not checked The follow-up network check did not complete for this visit. That check is a quick background step that helps reveal a visitor's real network even behind a VPN or proxy. Anonymization tools (VPNs with leak protection, anti-detect and privacy browsers, UDP-blocking firewalls) often block it, so a failure can itself mean the network is masked (`stun_not_checked`). ### JavaScript Disabled The page ran without the scripting a real browser provides — near-certain automation or a headless client, and one of the strongest tells. The visit also returns the all-zero DeviceID (`javascript_disabled`). ### Incognito The visit ran in a private or incognito browsing mode. **Informational only — it does not add to the Risk Score** (`incognito`). ### Suspicious paid click An informational flag set when a visit arrives on a paid channel and scores high-risk. A paid-traffic quality marker for [Traffic Quality](/use-case/traffic-quality); it carries no score (`suspicious_paid_click`). ### Public IP and Local IP The two network addresses on each webhook `data` payload. `public_ip` is the public IP seen on the HTTP request — the one a VPN or proxy can set to anywhere. `local_ip` is the real network IP recovered by the follow-up network check, which can expose the network behind a mask. Each carries an `ip` and a two-letter `country`; `local_ip` is empty when the check did not complete. Compare their **countries** (see [IP Mismatch](#ip-mismatch)) rather than the raw addresses, which differ normally. ### IP geolocation The country resolved from a visitor's IP address. ShieldLabs returns it as the `country` on both `public_ip` and `local_ip`, and uses it for location checks and the [IP Mismatch](#ip-mismatch) country comparison. ### Browser fingerprinting The technique of recognizing a browser from a combination of its attributes without relying on cookies. It is one component of ShieldLabs Device Intelligence, not the whole of it. ### Device fingerprinting Recognizing a device from stable hardware and software characteristics, producing an identifier that survives cookie clears and new browser sessions. ShieldLabs returns it as the DeviceID. ### Device Intelligence The discipline of [combining a device fingerprint](/features/identification) with network analysis, risk signals, and mismatch detection into one profile, returned as a persistent DeviceID plus the signals behind it. ### Network Intelligence The network side of the analysis: IP geolocation and reputation, connection type, the VPN / proxy / Tor / datacenter / Privacy Relay checks, and the follow-up network check that recovers the real network behind a mask. It pairs with Device Intelligence — the two corroborating each other is what drives the high detection accuracy the [accuracy](/features/accuracy) page describes. ### Headless browser A browser running without a visible interface, driven by automation rather than a person. When the snippet cannot collect a normal browser environment (for example JavaScript or the network check is unavailable), the visit returns the all-zero DeviceID and a high Risk Score. ## Patterns The [Patterns](/features/patterns) reference defines the grades and pattern types below. ### Pattern A relationship pattern computed server-side from historical data and shown on the dashboard [Patterns](/features/patterns) tab (for example, Many Accounts on One Device). Patterns are distinct from the per-request scoring signals and are not part of the webhook or API payload. ### Local IP The customer-facing name for the visitor's real network address, recovered by the follow-up network check (the same value the webhook carries as `local_ip`). It can reveal the network behind a VPN or proxy, and is used to group related entities in patterns such as Many Accounts on One Local IP. ### Suspicious / Dangerous The two grades an entity can receive in a pattern, based on how many linked identifiers it accumulates in a time window. An entity that has not crossed a threshold is the unflagged baseline, which is never recorded or emitted. A grade never downgrades. ## Analytics The [Visitors](/features/traffic-analytics) and Traffic Sources views on the dashboard report the metrics defined below. ### Visitor / New Visitor The dashboard's estimated count of unique people, computed by the VisitorID (the server-derived DeviceID combined with the cookie). A New Visitor is one first seen within the selected date range. The number is an estimate, not an exact headcount. ### Traffic Risk The overall traffic-quality gauge (0 to 100) on the dashboard [Overview](/features/traffic-analytics). It reflects how concentrated High- and Medium-risk requests are in the period, together with the severity of the signals that fired. It is not a simple average of every score. ### Requests Checked The number of scored requests in the selected period, shown on the [Overview](/features/traffic-analytics) next to Traffic Risk, with its period-over-period trend. ### Risk Trend The [Overview](/features/traffic-analytics) chart of how many requests fell into each band — Clean, Low, Medium, High — over time. ### Traffic Source The acquisition attribution captured on each request: the resolved **channel** and channel group, the **referrer domain**, the **landing URL**, the paid **click-ID type** (for example `gclid`), and the **UTM parameters**. The dashboard [Traffic Sources](/features/traffic-analytics) view ranks sources by the risk and anonymous-traffic share they deliver. ### Channel The resolved acquisition channel for a request: Google Ads, Microsoft Ads, Meta, TikTok, LinkedIn, X, Pinterest, Organic Search, Referral, Email, Direct, or Other. A coarser **channel group** (Paid Search, Paid Social, Social, Organic, Email, Referral, Direct, Other) rolls these up. ### UTM parameters The `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, and `utm_term` values from the inbound URL, captured per request for source attribution and surfaced in the dashboard and exports. ## Integration The [snippet install guide](/setup/snippet) and the [API overview](/api/overview) cover the integration concepts named below. ### Snippet The ShieldLabs JavaScript agent, an ES module loaded from `cdn.shieldlabs.ai` that collects signals in the browser. It is not an npm package or a native mobile SDK. ### Public Key The per-domain key placed in the snippet URL. It identifies the domain and is safe to expose in the browser. ### Secret Key The per-domain key used only on your backend to authenticate the Management API. Never ship it to the browser. Webhooks use separate `whsec_…` signing secrets per endpoint. ### Private API Key The per-domain `sec_…` key used on your backend to authenticate the [History API](/api/server-api) on `account.shieldlabs.ai`. Sent as a Bearer token; never expose it in the browser. ### Webhook signing secret The `whsec_…` value for one webhook endpoint. It keys the HMAC in the `X-Shield-Signature` header. Copy it from the dashboard **Webhooks** tab; one secret per endpoint. ### Webhook The [server-to-server delivery](/api/webhooks) of a scored result to an endpoint you register in the dashboard. One webhook fires per scored identification: the server waits up to \~60s for optional follow-up network checks, then sends the final score once (\~1s when no follow-up is expected). The body is a signed envelope (`event_type`, `schema_version`, `created_at`, `data`). Delivery is at-most-once with no retries, so make handlers idempotent on `data.request_id`. ### X-Shield-Signature The request header that carries the webhook HMAC: `sha256=` plus hex(HMAC-SHA256(raw body, `whsec_…`)). Verify it before trusting the payload. ### Idempotency The property where handling the same result more than once has the same effect as handling it once. Because webhook delivery is at-most-once and you may also read the same result from the History API, key your writes on `request_id` so a webhook and a History read for one check never double-apply. ### Server API The [server-side APIs](/api/server-api): the **History API** on `account.shieldlabs.ai/api` (Private API Key) and the **Management API** on `api.shieldlabs.ai` (Secret Key, for profile and balance). ### History API The `GET /api/v1/history/{search_type}/{value}` endpoint on `account.shieldlabs.ai`. It returns stored snapshots by identifier and is the guaranteed-read fallback when a webhook may have been missed. Free to read. ### Snapshot A stored record of one scored identification. A superset of the webhook body that also carries connection and network fields. Returned by the History API. ### Request The [billing unit](/billing). One identification is one request. The Management History path on `api.shieldlabs.ai` bills one request per returned row. History reads through `account.shieldlabs.ai`, webhooks, dashboard views, and exports are free.