How to identify anonymous traffic and visitors

Most web traffic is no longer human. The 2025 Imperva Bad Bot Report found automated traffic made up 51% of all web traffic, outweighing humans for the first time in a decade. Not all of it is malicious, but the same masking that hides a bot also hides a returning user: one visitor can present as many, looking like a crowd of strangers under a fresh IP, a cleared cookie, or a different browser. That inflates growth numbers, distorts attribution, and hides the abuse patterns underneath. The good news for teams trying to spot it is that masking is rarely clean. Hide one layer and the others usually still line up, and that inconsistency is exactly what makes anonymous traffic identifiable.

Key takeaways

• Anonymous traffic is masked, not invisible. Visitors hide parts of their profile with VPNs, proxies, Tor, Private Relay, or anti-detect browsers, but the layers rarely stay consistent with each other.
• Identifying anonymous visitors means restoring continuity: deciding whether different visits, sessions, and accounts belong to the same underlying visitor, without needing real-world identity.
• One signal is never enough. Reliable identification correlates device, browser, operating system, and network signals so a single fresh IP or cleared cookie can't break the link.
• The same masking infrastructure that fragments analytics also powers multi-accounting, bonus abuse, referral fraud, and ban evasion, which is why traffic-quality and abuse problems show up together.

What is anonymous traffic?

Anonymous traffic is traffic from visitors who deliberately hide their visit, using tools that stop a site from recognizing them across sessions. The visit still happens and still leaves technical traces. What's missing is continuity: the site can't tell that this "new" visitor is the same one from yesterday.

The common methods:

• VPNs that change the visible IP address and apparent location
• Proxies, including residential, mobile, and datacenter proxies, that route traffic through someone else's address
• Tor, which layers connections to reduce traceability
• iCloud Private Relay, which splits the request path so the site never sees the real IP
• Anti-detect browsers, which rewrite device and browser fingerprints per profile
• Anonymous (incognito) browsing, cookie resets, browser switching, and device switching
• Environment spoofing, where timezone, language, or OS are faked to look like a different machine

Each method changes how the visitor appears: a different IP, a different fingerprint, or a different declared environment. None of them changes the fact that a real device made the request.

What does it mean to identify anonymous visitors?

Identifying anonymous visitors means deciding whether different visits, sessions, or accounts belong to the same underlying visitor, even when the obvious identifiers have changed. It is not about uncovering a name or a real-world identity. It's about restoring the connection between actions that were made to look unrelated.

In practice it comes down to three jobs:

• Recognize a returning visitor who reappears as "new" after clearing cookies or switching networks.
• Link repeated sessions into one continuous timeline instead of many disconnected ones.
• Connect accounts when the same user runs several, or the same account is shared across people.

This is a different question from what a unique visitor count answers. A unique visitor is counted once per period; an anonymous visitor can be counted many times, once for each masked appearance. That gap is why analytics can show "new visitor" growth that is really the same users returning under altered conditions.

Why cookie-based analytics counts the same visitor twice

Most analytics tools, Google Analytics included, count a visitor with a randomly assigned ID stored in a browser cookie. That works until the cookie goes away, and it goes away often: clearing it, opening an incognito window, or switching browser all wipe the ID, so the same person is counted again as brand new. A returning visitor on a VPN, or one who simply cleared their history, inflates the "new visitor" number and quietly breaks any metric built on it.

When a returning visitor…	Cookie or tag-based analytics	Cookieless signal correlation
Clears cookies	counts them as new	still recognizes the device
Opens an incognito window	counts them as new	still recognizes the device
Rotates their IP	counts them as new	unaffected, the IP is not the anchor

The difference is what the count is anchored to. A cookie is a tag the browser stores and can drop; a cookieless read leans on the device and network traits that survive a reset, so a returning visitor stays one visitor instead of splitting into several. That recognition has a friendly side too: the same layer that flags a coordinated multi-account pattern also lets your own product greet a genuine returning visitor without forcing another login, with the verdict and any personalization staying in your application.

How do you identify anonymous visitors on a website?

Anonymous visitors are identified by correlating technical signals across layers, not by trusting any single identifier. Cookies get cleared and IP addresses rotate, so reliable identification has to be cookieless at its core, leaning on the things that are harder to change all at once: how the device, browser, operating system, and network look when read together.

The working layers:

• Device intelligence assesses whether the underlying device looks familiar and stable, or like one machine wearing many faces.
• Browser fingerprinting answers a narrow question: have I seen this browser before? It re-identifies a returning browser even after a cookie reset.
• Operating system and environment checks surface contradictions, like a browser claiming one OS while the network stack describes another.
• Network intelligence reads the connection itself, flagging VPNs, proxies, Tor, Private Relay, hosting, and datacenter infrastructure.
• Cross-session and account linkage ties repeated activity back to the same visitor over time.

Read together, these layers recognize a repeated pattern even when the visitor changes IP, clears cookies, or switches to an anonymity tool. A single fresh identifier can hide one layer. It rarely hides all of them at the same time.

Which anonymization methods matter most?

The methods worth detecting first are the ones that most often break continuity or imitate ordinary traffic. Detecting the masking tool is a named, factual capability: you can flag a VPN, a proxy, Tor, Private Relay, or an anti-detect browser reliably, even though the masking tool alone never proves abuse.

Method	Why it matters to detect
VPN	Changes the visible IP history and apparent geolocation, breaking IP-based continuity.
Proxy (residential, mobile, datacenter)	Can imitate ordinary user traffic, especially residential and mobile proxies that look like real consumer connections.
Tor	Provides stronger anonymity and reduces traceability through layered routing.
iCloud Private Relay	Weakens IP-only logic by hiding the real IP, even though it's often used legitimately.
Anti-detect browser	Rewrites device, browser, and OS fingerprints per profile, often paired with a proxy, to sever links between sessions.

Two of these deserve a note. Private Relay is mostly a privacy feature used by ordinary people, so it's a weak signal on its own. Anti-detect browsers are the opposite: purpose-built to defeat fingerprinting, which makes their use a much stronger indicator that someone is working to look like many separate visitors.

Which signals reveal suspicious anonymous traffic?

Websites reveal suspicious anonymous traffic by reading many independent signals across the device, browser, operating system, and network, then checking whether they describe one coherent visitor or a stitched-together one. No single reading is decisive. Public research and open-source detection work converge on a recognizable set of techniques, none of them proprietary:

• Fingerprint-consistency checks: cross-check attributes that should agree, like the user agent versus the platform the browser reports separately, the graphics renderer versus the claimed OS, and timezone versus locale, plus a low-level platform hint sent over the connection that page scripts can't rewrite.
• Graphics, audio, and font fingerprinting: re-sample canvas, WebGL, and audio output, since a real device returns identical results every time while a randomizer or noise injector returns something different on each read.
• Browser-API integrity and tool signatures: patched browser APIs stop behaving like the originals, and a built-in automation flag gives away tools that drive a browser headlessly.
• IP and connection intelligence: resolve the address to its ASN and owner, separate datacenter and hosting ranges from genuine residential and mobile ones using reverse DNS, WHOIS, and published proxy feeds, and cross-reference reputation and abuse history, since ordinary users rarely browse from datacenter ASNs.
• Network and transport fingerprinting: passive TCP/IP fingerprinting infers the real OS from packet traits, the TLS handshake catches a faked browser stack, an unusual MTU hints at a tunnel, and round-trip latency that contradicts the claimed location exposes a relay in the middle.
• Connection-origin leaks: a WebRTC or STUN request can expose the real IP behind a proxy, and name resolution that happens outside the tunnel (or a blocked UDP path) betrays the region the IP was meant to conceal.
• Timezone, locale, and geolocation mismatch: compare the browser's reported timezone and language against the region the IP resolves to, since a US IP on a session reporting a European timezone is the classic seam.
• Cross-signal correlation: each tell is weak alone, so they are weighed into one score, and a profile that is too clean or internally contradictory becomes its own anomaly.

The strongest tell is disagreement across these layers. When the browser points to one region, the IP resolves to another, the timezone hints at a third, and the route leads through anonymized infrastructure, the profile is internally contradictory. That contradiction, not any single flag, is what marks the traffic as suspicious. The more independent signals you read together, the harder it is for masked traffic to stay consistent.

Why is one signal not enough?

One signal can't classify a visitor reliably. A VPN alone doesn't prove abuse, and a clean residential IP doesn't prove legitimacy. Plenty of ordinary people use a VPN; plenty of users buy residential IPs precisely because they look clean. Judging either in isolation produces false positives and missed cases in equal measure.

Accuracy comes from correlation. The more independent signals a system reads, the harder the profile is to fake consistently:

• A single identifier is easy to change. A fresh cookie, a new IP, a different user agent, each takes seconds.
• A layered identity model is hard to fake all at once. Spoofing the browser but not the network, or the OS but not the timezone, leaves seams.
• Continuity compounds. Device, browser, OS, and network signals read together build a picture that survives the loss of any one layer.

This is why returning-visitor identification gets more reliable as more layers are added. A new IP hides the network; a cleared cookie hides the browser state; an anti-detect profile hides the fingerprint. Hiding all of them on every visit, without a single contradiction, is the hard part, and the part most masked traffic gets wrong.

Anonymous traffic is also a traffic-quality problem

Anonymous traffic isn't only a fraud problem. It's a data-quality problem that quietly corrupts marketing, product, and operational decisions. When the same visitor is counted as several, the numbers everyone trusts stop describing reality.

It usually surfaces in four places:

• Inflated acquisition metrics. Campaigns look like they're attracting new visitors when they're bringing back old ones.
• Distorted attribution. Referral and affiliate channels appear more effective than they are because returning users are credited as new conversions.
• Wasted spend. Paid budget goes toward "new" users who already exist, pushing reported CAC away from the real number.
• Unreliable cohorts. Retention and monetization analysis breaks down when one person spreads across many fragmented identities.

Treating anonymous traffic as a measurement issue, not just a security one, is what connects it to growth and finance decisions, not only to the fraud queue.

Which abuse patterns are linked to anonymous traffic?

Anonymous traffic is most often linked to abuse where the user benefits from looking new, unrelated, or hard to trace. The same identity-masking setup tends to power a familiar set of cases:

• Multi-accounting and account farms, where one user runs many accounts to multiply whatever a single account earns
• Account sharing, where one account is used by many people to share a paid or limited service
• Fake account creation and registration abuse, inflating "new user" numbers with accounts that were never real people
• Free-trial, freemium, and subscription abuse, cycling fresh identities to claim a benefit again and again
• Referral fraud, bonus abuse, and promo abuse, claiming rewards repeatedly under identities made to look independent
• Ban evasion and restriction evasion, returning after a block under a profile that reads as brand new
• Survey and voting fraud, casting many "independent" responses from one source
• Sybil behavior and airdrop farming, multiplying wallets and identities to farm incentive campaigns

These look like different problems but usually share one root: a user using anonymity tools to manufacture false independence between actions that all trace back to one source. Identifying the traffic is what reconnects them, the mechanism behind preventing multi-accounting and the abuse cases above.

Identifying anonymous traffic with ShieldLabs

Correlating device, browser, OS, and network signals across every visit is real work, and the seams that give masked traffic away keep shifting as the tools update. ShieldLabs does that correlation for you. One JavaScript snippet identifies every visitor in about five minutes from install to first anonymity signal, so a "new" visitor and a returning one stop looking the same.

For each visit, ShieldLabs returns a risk score that weighs the contradictions across layers and flags the session when the visit is masked or a returning visitor or user reappears as new. It comes with a full set of anonymity signals, including anonymous proxy detection, VPN, and Tor, among others, and the whole read happens in the background with no friction for the visitor. This is website visitor identification read from the device rather than from a cookie or a form, so an anonymous session still resolves to a visitor you can recognize.

Continuity is the part masking tries to break, so a stable identifier ties a "fresh" visit back to a returning device even after cleared cookies and rotated IPs. That link surfaces the cross-session behavior behind multi-accounting, like changing IDs on one account or many accounts on one device, through pre-built patterns. The analytics dashboard rolls the same reads up to traffic quality, broken down by acquisition channel, campaign, and UTM source, with each channel, paid search, social, referral, and the rest, carrying its own traffic-risk score, so your team can see which paid campaigns are bringing masked or anonymous traffic instead of real visitors, tell anonymous traffic apart from clean traffic at a glance, and watch it as a trend over time rather than one visit at a time.

The risk score and anonymity signals reach your stack through an API and webhooks, so ShieldLabs surfaces the evidence while your team acts in its own flow and your rules decide the outcome to prevent abuse and fraud.