Analytics dashboards call it different things: visitor ID, client ID, anonymous ID, device ID. Underneath, it is the same idea. A tracking system needs some way to tell "this is probably the same visitor as five minutes ago" without knowing anything about who that visitor actually is, and a visitor ID is that placeholder.
How a visitor ID gets created
The exact mechanism varies by tool, but the sequence is consistent. A browser or app hits a tracked page or link for the first time. The tracking system generates a random or hashed value, since nothing about the visitor's real identity is known yet, and stores it, most commonly in a first-party cookie, sometimes in local storage, sometimes server-side keyed to a hashed IP address. That value is the visitor ID. Every subsequent hit that carries the same cookie, or comes from the same hashed IP within the tool's matching window, gets grouped under that same ID. Nothing about the process requires a login, an email address, or any voluntary input from the visitor.
This is worth stating plainly because it is where a lot of confusion starts: a visitor ID is generated automatically for anonymous traffic. It is the default state of tracking, not an advanced identification feature layered on top.
Anonymous visitor ID vs user ID vs session ID
These three get used almost interchangeably in casual conversation, and they should not be, because they answer different questions and behave differently over time.
| Session ID | Anonymous visitor ID | User ID | |
|---|---|---|---|
| Created | At the start of each visit | On first contact, before login | At account creation or login |
| Lifespan | Minutes to a few hours, expires on inactivity | Weeks to months, until cookies clear | Persists as long as the account exists |
| Tied to real identity | No | No | Yes, by definition |
| Survives a device switch | No | No, a new device gets a new ID | Yes, if the visitor logs in on both |
| Survives clearing cookies | No | No | Yes, since it lives on the account, not the browser |
The practical read: a session ID is the shortest-lived and the least useful for anything beyond a single visit. An anonymous visitor ID bridges multiple visits within one browser or device, which is what lets a tool report "returning visitor" as opposed to "new visitor." A user ID is the only one of the three that is actually tied to a real, known person, and it only exists once someone has logged in or otherwise identified themselves voluntarily.
The mistake almost everyone makes with visitor ID counts
This is the part most explanations skip. A "unique visitors" number built from anonymous visitor IDs is not a count of unique people, it is a count of unique browser-and-device combinations that showed up during the reporting window. The same person checking a site on their phone during lunch and their laptop that evening generates two different visitor IDs, because neither device knows the other exists, and gets counted as two visitors unless something stitches them together, almost always a login event that converts both anonymous IDs into the same user ID. Clearing cookies, switching browsers, or using a private window all produce the same effect: a returning visitor looks new. This is not a bug in any particular tool. It is a structural limit of anonymous, cookie-based identification, and it means "unique visitors" is best read as a directional number, not an exact headcount.
How Raydar uses a visitor ID
Raydar assigns a visitor ID to clicks on the links and pages it hosts, built from a hashed version of the visitor's IP address, paired with an explicit high-confidence and low-confidence tier rather than a single blended score. It is not a data broker lookup and it does not claim to resolve every click to a known person. Paired with first-touch and last-touch cookies, it is enough to answer a narrower and more useful question than "who is this person": which post or campaign this specific visit came from, and whether it is likely the same visitor returning through a different link. That scope matters. It only covers activity on links Raydar actually serves, the same boundary that applies to website visitor tracking generally. It is also why tracking visitors across a whole site is a harder, less complete problem than tracking clicks on a handful of links (and part of why first-party setups tend to hold up better than third-party ones, covered in what is first-party tracking).
Why the anonymous-to-known handoff matters
The single most valuable moment in any tracking setup is the point where an anonymous visitor ID converts into a known user ID, because that is the only moment a business can connect prior anonymous behavior to a real account. A visitor who browsed five pages anonymously, then signed up, lets a well-built system retroactively attribute those five page views to the new account. A system that does not perform this handoff loses that history the moment the visitor logs in, and the anonymous visitor ID simply stops updating, orphaned. This is the mechanism behind "how did this new customer find us" reporting that actually works, versus reporting that resets to zero at signup.
Where a visitor ID shows up outside analytics dashboards
The same concept underlies more than pageview counting. A/B testing tools use a visitor ID to keep the same browser in the same test variant across a session. Ad platforms use a comparable identifier to cap how many times one browser sees the same ad. Email marketing tools that track link clicks assign a visitor ID the moment a recipient clicks through, so a follow-up visit to the site can be tied back to that email campaign even though the recipient never logged in. In every case, the pattern is identical: an anonymous token created early, used to group related activity, discarded or reset the moment its underlying cookie or session expires. This is also the mechanism underneath most event tracking setups, where individual actions on a page get tied to the same visitor ID rather than treated as isolated, unconnected hits.
What a visitor ID cannot do
On its own, a visitor ID does not prove who someone is, and it carries no legal weight as an identifier. It also does not survive a visitor clearing cookies or switching devices, at least not without a login stitching the two together. Treating a high volume of unique visitor IDs as a precise headcount, or treating a visitor ID match as equivalent to a verified identity, both overstate what the token actually represents. It is a tracking convenience, built to group probably-related activity together. Nothing more certain than that.