Skip to main content
The Traffic Sources view answers a question your ad platform and your web analytics cannot: not how much traffic each source sent, but how risky that traffic was. It takes the same per-request Risk Score that powers the rest of the dashboard and rolls it up by channel, by referrer, and by UTM tag. Most analytics tools rank a source by volume: which campaign sent the most clicks. Traffic Sources ranks each source by the risk badge and the anonymous-traffic share it delivers. A campaign that sends 50,000 clicks at an average score of 71 High is not your best channel. It is the one quietly sending masked, VPN’d, anti-detect, and Tor traffic that inflates your click count and raises your real cost per visitor. This view points straight at it. Every number here is computed server-side and read-only. The dashboard renders results. It never blocks, challenges, or decides anything. Your own code owns the allow / challenge / review / block decision using the Risk Score and signals you receive over webhooks and the Management API.
Cost per real visitor, not per click. Read each source’s score alongside its volume. 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.

Where you find it

Traffic Sources appears in two places, both fed by the same data:
  • A Traffic Sources card on the Overview tab, summarizing channels and source details for the selected project and date range.
  • The per-request rows behind it on the Data tab, where Channel, Referrer Domain, and the five UTM columns are filterable, sortable, and exportable.
The card’s subtitle reads: “Traffic source breakdown by request volume, traffic share, and traffic risk. Use Source details to inspect referrers and UTM parameters.” It is two tables side by side: Channels on the left and Source details on the right.

The Channels table

The Channels table groups every request into one acquisition channel and scores the channel as a whole. Its columns:
ColumnWhat it shows
ChannelThe channel name with its icon.
Requests / ShareThe request count on top, the channel’s percent of total requests below it.
Traffic RiskA risk badge for the channel: <score> <level>, for example 71 High. Sortable.
The channel set is fixed and exact. Use these names, not synonyms:
ChannelNotes
Google AdsPaid Google traffic. There is no separate plain “Google” channel.
MetaFacebook and Instagram paid traffic. It is Meta, not “Meta Ads”.
TikTokTikTok paid and organic.
LinkedInLinkedIn paid and organic.
XThe channel is X, not “Twitter”.
Organic SearchUnpaid search referrals. It is Organic Search, not bare “Organic”.
ReferralInbound links from other sites.
DirectNo referrer (typed URL, bookmark, app, stripped referrer).
OtherAnything that does not map to the channels above.
Sort the Traffic Risk column descending and read it top to bottom. The first row is the channel sending you the most anonymous, masked, or abusive traffic. Cross-reference its request share: a high-risk channel that is also high-volume is where your acquisition budget is leaking.

The Source details table

Where Channels answers “which channel?”, Source details answers “which specific source inside it?”. A toggle at the top of the table switches between two views:
Each row is a referring host (for example news.ycombinator.com or partner-blog.example.com), with its Requests / Share and a risk badge. This is how you find the one inbound link, partner site, or affiliate that is sending masked traffic while the channel-level number still looks fine. The column header reads Referrer. When there is no data for the window, the table shows “No referrer data for the selected period.”
This is the resolution that matters for spend decisions. Channel tells you Google Ads runs at 42 Medium. UTM Campaign tells you the medium score is one clean campaign averaged with one campaign running 81 High. UTM Content tells you it is a single ad creative in that campaign. Now you know exactly which creative to pause, and you did it by risk, not by guessing.

The risk badge

Both tables render the source’s risk as a single badge: the score and its band label, side by side.
71 High      8 Clean      42 Medium      18 Low
The number is the average Risk Score of the requests attributed to that source, on the same 0–100 scale used everywhere in ShieldLabs. The word is the band:
LevelScore rangeBadge colorWhat it means for the source
Clean0–9greenNo meaningful anonymity or abuse signals. Real traffic.
Low10–29yellowOne minor signal on average. Mostly fine, worth a glance.
Medium30–59orangeOverlapping or moderate signals. A meaningful slice is masked.
High60–100redStrong anonymity or abuse signals. This source skews toward VPN, proxy, anti-detect, or Tor traffic.
The badge level here is just Clean / Low / Medium / High, without the word “Risk” after it. It is the same banding and the same 0–100 score used on the Data tab Score column and the Overview Traffic Score card. The label drops the suffix in this badge only.
A high badge is a signal to investigate, not an automatic verdict. A source can score high for honest reasons: a privacy-conscious audience on VPNs or iCloud Private Relay, a corporate-proxy B2B segment, a region where Tor or VPN use is common. Read the badge together with the signals behind it on the Data tab before you pause spend. The score is 0–100, capped at 100. There is no higher scale, and 999 is never a customer score. See acting on the Risk Score.

Attribution fields captured per request

Every identification call carries its own attribution, captured at request time and stored on the request record. These are the fields the Channels and Source details tables aggregate, and the same fields are columns on the Data tab:
FieldWhat it holds
channelThe resolved acquisition channel (Google Ads, Meta, TikTok, LinkedIn, X, Organic Search, Referral, Direct, or Other).
referrer_domainThe referring host for the request.
utm_sourceThe utm_source query parameter on the landing URL.
utm_mediumThe utm_medium query parameter.
utm_campaignThe utm_campaign query parameter.
utm_contentThe utm_content query parameter.
utm_termThe utm_term query parameter.
Because attribution lives on each request, every source’s badge is just the Risk Score of its requests, averaged. The Risk Score is explainable per request: each one ships with a Details array naming the signals that fired. So when a source reads High, you can drop into the Data tab, filter to that channel or referrer, and read the exact signals (VPN, Anti-detect Browser, Tor, Datacenter IP, and the rest) that pushed the average up.
On the Data tab, the Channel, Referrer Domain, UTM Source, UTM Medium, UTM Campaign, UTM Content, and UTM Term columns live in the Traffic Source and UTM column groups. Turn them on, filter to the source you are auditing, set the Score range to 60100, and sort by Anti-detect Browser or VPN to see the masked requests one by one. Then Export the rows as CSV or JSON, free of charge.

How to read it

A short workflow that turns the view into a decision:
1

Scan channels by risk, not volume

Sort the Channels table by Traffic Risk descending. The top rows are where masked traffic concentrates. Note each one’s request share so you know whether it is a large or a small slice of spend.
2

Drill into the worst channel

A high-risk paid channel is usually not uniformly bad. Open Source details, switch to UTM Parameters, and break the channel down by Campaign, then Content. The risk is almost always concentrated in a few campaigns or creatives, not spread evenly.
3

Confirm with referrers

For affiliate, partner, and referral traffic, switch Source details to Referrers. One affiliate sending High traffic while the rest run Clean is the affiliate to question.
4

Verify the signals

Open the Data tab, filter to the suspect source, set the Score range to the High band, and read the per-request signals. This is the evidence: which requests were VPN, anti-detect, datacenter, or Tor.
5

Act in your own tools

Pause the creative, drop the affiliate, or exclude the placement in your ad platform. ShieldLabs surfaced the masked source. The decision and the action are yours.

Worked example

Suppose Organic Search and Google Ads sent roughly the same volume this period:
ChannelRequests / ShareTraffic Risk
Organic Search41,200 / 38%8 Clean
Google Ads39,800 / 36%54 Medium
Meta18,400 / 17%71 High
X6,100 / 6%22 Low
Other3,300 / 3%61 High
By volume, Google Ads and Organic Search look like equal pillars. By risk, they are not. Organic Search runs Clean. Google Ads runs Medium, so a real slice of those clicks is masked. Meta runs High, meaning a large share is anonymous traffic that will never convert. Open Source details on Meta, break it down by UTM Content, and the High average usually resolves to one or two creatives. Pause those in Meta, and the channel’s effective cost per real visitor drops without touching the creatives that work.

The same data powers the cookbook

Traffic Sources is the dashboard read of two recipes you can wire into your own stack:

Affiliate and ad fraud

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

Traffic quality

Measure traffic quality per source over time and turn cost per real visitor into a metric you can act on.
Both recipes consume the per-request channel, referrer_domain, and utm_* fields over webhooks and the Management API. The dashboard view is for a human investigating a source. The cookbook recipes are for your code reconciling spend automatically.

Where to go next

Data tab

The per-request rows behind every badge, with Channel, Referrer Domain, and UTM columns to filter, sort, and export.

Visitor Insights

Estimated unique and new visitors, counted by identity rather than cookie.

Risk Score

How the 0–100 score and its Clean / Low / Medium / High bands work, with the explainable Details array.

Signals

The signal catalog behind a source’s score: VPN, anti-detect, datacenter, Tor, and the rest.