> ## 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.
# Traffic Analytics
> Learn how ShieldLabs measures traffic quality and ranks each source by the anonymous traffic it sends.
This page doubles as the manual for the analytics dashboard: the Overview tab, its Visitor Insights and Traffic Sources cards, the Traffic Risk gauge, and the Data table you read and export the underlying records from.
Traffic Analytics lives on the dashboard [Overview](/overview) tab. It answers what plain pageview analytics leaves out: how much of your traffic is real versus masked or anonymous, and which sources send it. Visitors are counted by a server-derived identity, the VisitorID, not a raw client-side id.
Every number here is computed server-side and read-only. The dashboard renders results. Your own code owns the allow / challenge / review / block decision using the [Risk Score](/features/risk-scoring) and [anonymity signals](/features/anonymity-signals) you receive over [webhooks](/setup/webhooks) and the [Server API](/api/server-api).
Traffic Analytics has three parts:
* **Traffic Risk and the Data table** - an overall read on traffic quality: how much of your traffic is real versus masked, plus the per-request records behind it.
* **Visitors and New Visitors** - real and new headcounts, counted by the VisitorID (the durable DeviceID combined with the cookie).
* **Traffic Sources** - every channel, referrer, and campaign ranked by the risk it delivers.
## Visitors and New Visitors
Two metrics sit at the top of the Visitor Insights card. These are the exact product tooltips:
| Metric | Tooltip |
| ---------------- | ------------------------------------------------------------------------- |
| **Visitors** | "Estimated unique visitors using cookies, browser info, and device info." |
| **New Visitors** | "Visitors first seen in the selected period." |
**"Estimated" is deliberate.** ShieldLabs reports a confident estimate of real people — built from a stable identity, not a single cookie — but not an exact headcount. The count is not an audited 1:1 tally, and the [Identifiers](/features/identification) page spells out where the identity boundaries lie. New Visitors is the subset first seen inside the selected window, so the determination moves with the date filter.
### How visitors are counted
ShieldLabs counts Visitors by the **VisitorID** — a server-derived identity that combines the durable [DeviceID](/features/identification) with the browser cookie. Because it is computed on the server and anchored to the device identity, it is more robust than a raw client-side id a page hands out, which is what lets the dashboard report a confident estimate of real people rather than a raw hit count.
The card also breaks the same visitors down by top countries, browsers, operating systems, device types, and [connection type](/features/anonymity-signals) — Direct, Mobile, VPN, Proxy, Tor, Privacy Relay, and Unknown. That last breakdown is an early read on how anonymous your audience is.
### How it compares
Pageview analytics count by a cookie or a client-side id, so they cannot tell real traffic from masked traffic. ShieldLabs adds a durable device identity and a per-visit anonymity read on top:
| | Google Analytics | Vercel Analytics | ShieldLabs |
| -------------------------------------------------- | ------------------ | ----------------------------- | --------------------------------------------------------------------------------------- |
| **Unique-visitor basis** | First-party cookie | Client id (partly IP-derived) | VisitorID (server-derived device + cookie) |
| **Durable device identity** | No | No | **DeviceID** — survives cleared cookies, incognito, and IP rotation |
| **Recognize the same device after a cookie clear** | No | No | Yes, via the DeviceID ([History API](/api/server-api) / [Patterns](/features/patterns)) |
| **Tell real traffic from masked or anonymous** | No | No | **Yes** — the [Risk Score](/features/risk-scoring) and anonymity signals |
| **Rank sources by anonymous-traffic share** | No | No | Yes |
## Traffic Sources
Traffic Sources ranks every acquisition channel, referrer, and campaign by the risk it delivers, not the volume it sends. Two channels with identical request counts are not equal if one runs Clean and the other runs High. That delta is the difference between paying for real visitors and paying for masked traffic.
The card holds two tables side by side: **Channels** on the left, **Source details** on the right.
### Channels
The Channels table groups every request into one acquisition channel and scores the channel as a whole. Each row shows the channel name, its **Requests / Share**, and a **Risk Badge**. The channel set is fixed and exact:
| Channel | What it covers |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Google Ads** | Paid Google traffic. There is no separate "Google" channel. |
| **Meta** | Facebook and Instagram. It is **Meta**, not "Meta Ads". |
| **TikTok** | TikTok paid and organic. |
| **LinkedIn** | LinkedIn paid and organic. |
| **X** | The channel is **X**, not "Twitter". |
| **Organic Search** | Unpaid search referrals. Not bare "Organic". |
| **Referral** | Inbound links from other sites. |
| **Direct** | No referrer (typed URL, bookmark, stripped referrer). |
| **Search bot** | Known search-engine crawlers (Googlebot, Bingbot, and similar), identified by the `search_bot` flag. Grouped on their own so crawler traffic does not distort the human channels. |
| **Other** | Anything that does not map to the channels above. |
The **Risk Badge** renders the source's risk as a score plus its band: ` `, for example `71 High` or `8 Clean`. The number is the average [Risk Score](/features/risk-scoring) of the requests attributed to that source, on the same 0–100 scale used everywhere. The word is the band:
| Level | Score range | What it means for the source |
| ---------- | ----------- | -------------------------------------------------------------- |
| **Clean** | 0–9 | No meaningful anonymity signals. Real traffic. |
| **Low** | 10–29 | One minor signal on average. Mostly fine. |
| **Medium** | 30–59 | Overlapping or moderate signals. A meaningful slice is masked. |
| **High** | 60–100 | Strong anonymity signals. Skews toward masked traffic. |
**A high badge is a signal to investigate, not a verdict.** A source can score high for honest reasons: a privacy-conscious audience, a corporate-proxy B2B segment, or a region where VPN use is common. Read the badge with the signals behind it before you pause spend, [acting on the Risk Score](/guides/acting-on-risk-score) in your own code. The score is 0–100, capped at 100.
### Source details
Where Channels answers "which channel?", Source details answers "which specific source inside it?". A toggle switches between two views, each row carrying its own **Requests / Share** and **Risk Badge**:
* **Referrers** - each row is a referring host (for example `news.ycombinator.com`). This is how you find the one inbound link, partner site, or affiliate sending masked traffic while the channel-level number still looks fine.
* **UTM Parameters** - a select picks which campaign tag to break down by.
| UTM field | Breaks the rows down by |
| ------------ | ---------------------------------------------------- |
| **Source** | `utm_source` (for example `newsletter`, `partner_x`) |
| **Medium** | `utm_medium` (for example `cpc`, `email`) |
| **Campaign** | `utm_campaign` (the specific campaign) |
| **Term** | `utm_term` (the paid keyword) |
| **Content** | `utm_content` (the specific creative or ad variant) |
This is the resolution that drives spend decisions. Channel says Google Ads runs `42 Medium`. **UTM Campaign** shows the medium score is one clean campaign averaged with one running `81 High`. **UTM Content** narrows it to a single creative. Now you know exactly what to pause, ranked by risk instead of guesswork. Paid traffic that scores High is also flagged per request: `detection_flags.suspicious_paid_click` is `true` when a request arrives on a paid channel and scores 60+, so you can isolate paid clicks that look masked without re-deriving the channel-plus-score logic.
Rank each paid and organic source by the risk and anonymous-traffic share it delivers, measuring cost per real visitor rather than cost per click. The campaign that sends 50,000 clicks at `71 High` is not your best channel. It is the one quietly inflating your click count and your real cost per visitor.
## Traffic Risk and the Data table
The **Traffic Risk** gauge on the Overview tab reflects how concentrated Medium- and High-Risk requests are in the period, weighted by signal severity — it is not a simple average of every score. A half-circle gauge maps it to a band, with a short subtitle under the needle:
| Band | Range | Gauge subtitle |
| --------------- | ------ | ------------------- |
| **Clean** | 0–9 | All Clear |
| **Low Risk** | 10–29 | Worth a Quick Check |
| **Medium Risk** | 30–59 | Needs Attention |
| **High Risk** | 60–100 | Action Recommended |
The denominator is requests, not visitors. Traffic Risk is computed across every request analyzed, and Requests Checked is that total. One person who triggers ten identify calls is ten requests here. The visitor counts above count unique people, so the two numbers measure different things on purpose.
Two more Overview cards sit alongside the gauge: a **Risk Trend** chart that plots the risk reading over time so you can spot spikes, and a **Request Signals** card that breaks down which [anonymity signals](/features/anonymity-signals) fired across your traffic.
The Traffic Risk gauge is the summary. The **Data** table is the evidence behind it. It lists per-request records, one row per identification call, joinable by `RequestID`:
* **Filterable** by project, score range (for example `60`–`100` to isolate the High band), and date range.
* **Searchable** by a single identifier: `request_id`, `session_id`, `cookie_id`, `user_hid`, `visitor_id`, `device_id`, or `ip`.
* **Sortable** by date and score.
* **Exportable** to CSV (free; does not consume request balance). Columns match the flat [webhook payload](/api/webhooks): identifiers, IPs, `connection_type`, traffic source fields, and `detection_flags`.
Each request ships an explainable [Risk Score](/features/risk-scoring): a `signals` array naming the signals that fired and the points each added. So when a source reads High, filter the Data table to it, set the Score range to the High band, and read the exact anonymity signals (`VPN`, `Anti-detect Browser`, `Tor`, `Datacenter IP`, and the rest) that pushed the average up. The dashboard surfaced the masked source.
## Next steps
The signal catalog behind every risk badge: VPN, anti-detect, datacenter, Tor, and the rest, each with its weight.
Measure traffic quality per source over time and turn cost per real visitor into a metric your code can act on.
Score traffic per affiliate and per campaign, find the partner sending masked clicks, and reconcile payouts against real visitors.