Skip to main content
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 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 and anonymity signals you receive over webhooks and the 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:
“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 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 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 — 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:

​
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: The Risk Badge renders the source’s risk as a score plus its band: <score> <level>, for example 71 High or 8 Clean. The number is the average Risk Score of the requests attributed to that source, on the same 0–100 scale used everywhere. The word is the band:
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 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.
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:
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 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: identifiers, IPs, connection_type, traffic source fields, and detection_flags.
Each request ships an explainable Risk Score: 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

Anonymity Signals

The signal catalog behind every risk badge: VPN, anti-detect, datacenter, Tor, and the rest, each with its weight.

Traffic quality

Measure traffic quality per source over time and turn cost per real visitor into a metric your code can act on.

Affiliate fraud

Score traffic per affiliate and per campaign, find the partner sending masked clicks, and reconcile payouts against real visitors.