How website visitor identification works

You paste a snippet into your site. Later, a name, a job title and a LinkedIn link arrive in Slack for someone who never filled in a form. It feels like magic.

It is not magic, and website visitor identification is two different things sold under one name. This post explains both, walks through what one public script does in the browser, and lists what a site owner has to do before installing one.

Disclosure first. I founded looot and I maintain looot-reveal, an open-source tool that does the company-level half, so I have a stake. For this article I signed up nowhere and installed nothing on a live site. It is a read of public pages and of one public script, done on 2026-10-11. Every claim below is marked as confirmed, inferred or unknown.

What is the difference between company-level and person-level identification?

Company-level identification answers "which company is this visitor from". Person-level identification answers "which person is this". They use different data and carry different risk.

Company-level works from the IP address. A reverse IP database maps an address to the network that owns it. When that network belongs to a company office, you get the company. It works in any country. It fails on home broadband, mobile networks, VPNs and shared offices, where the address resolves to the internet provider or the building's operator. IPinfo warns about the shared office case in its own documentation.

Person-level needs an identity graph: a database that ties hashed emails to cookies, devices and IP addresses, built from logins and form fills on other sites. An IP registry names a network. A graph can return a candidate person for a browser or an address, and a candidate is not a certain identity. The script's job is to collect enough signals for the graph to answer.

What does a visitor identification script do in the browser?

I read one, the script RB2B loads on its own home page for every visitor. I picked it because RB2B publishes more about its method than other vendors I read. I read the file and decoded its text. I did not run it. A plain request for the file was refused, and a request with the headers a browser sends from rb2b.com returned it.

Confirmed from the public script.

1. It checks for consent. When the site uses CookieYes, the script waits for the visitor's consent.
2. It filters bots, using a long list of crawler names and a check for automated browsers.
3. It asks an IP geolocation service for the visitor's country and whether the address is a proxy. The answer is cached in a cookie.
4. It calls third-party services from the visitor's browser, with that browser's cookies attached. Two calls are clear in the code. One loads the LiveIntent LiveConnect script, which has public documentation, and asks it for MD5 and SHA-256 hashes of an email. The other fetches a reply that carries an MD5 hash of an email. A third address sits in the script too, and which step uses it is my inference. The hashes are kept in cookies that last 30 days.
5. It posts those hashes, a few cookie ids, the page address and the location result to a server run by RB2B.
6. The person-level send only happens when the country is the US. A visitor flagged as a proxy is skipped for company collection too.

I also searched the decoded text for browser fingerprinting probes such as canvas, WebGL, audio and font checks. None appear. I found no reference to Global Privacy Control either. Absence in one obfuscated file is evidence, not proof, and it says nothing about what RB2B's servers or its partners do with an opt-out.

Confirmed from the vendor's own pages.

• Person-level identification is US only, and company-level is global, per RB2B's explainer and its global tracking documentation. Its page on the premium tier also mentions broader international resolution, and I could not tell what that returns outside the US. Ask the vendor before you plan on it.
• Company identification comes from Demandbase, which RB2B names as its partner for that half.
• RB2B names Retention.com as the data engine behind its person-level product.
• Matches with low confidence are discarded. The explainer says "Incomplete or low-confidence matches are discarded".

Inferred, my reading.

• How a hashed email becomes a name and a LinkedIn profile. That step runs on the vendor's servers and is not public.
• Which graph answers any single visit.

Unknown.

• Who operates two of the three services the script calls. I could not find an owner for either domain.
• Whether every identification comes from those three browser calls. The script proves it asks them. It does not prove they are the only source.
• How the full service treats a Global Privacy Control signal.

How accurate is website visitor identification?

Nobody outside the vendors has published a test I could find, so the only numbers are vendor claims. RB2B's explainer says person-level works for "approximately 40-45% of qualified US-based traffic". That is the vendor's claim, and I did not test it.

Two cautions when you read any match rate. A person rate and a company rate describe different outcomes, and adding them together counts some visits twice. And a match from an identity graph is a candidate, not a certainty. On a shared or home network, the person the graph returns may not be the person who loaded the page.

Why does person-level identification only work in the US?

Because the vendor built it that way, for legal reasons it states itself. On its GDPR and CPRA page and its compliance FAQ, RB2B describes "IP ringfencing to only resolve US traffic" and says its database "only contains profiles that have been matched to US home addresses". For European visitors it says "we do not engage in any further identification processes".

The script matches the claim. It checks the country before it sends any hash.

The vendor's privacy policy states its own legal basis in its European section: it processes personal data "in reliance on your consent or on legitimate interest". I draw no legal conclusion from that, and neither should you without a lawyer.

What must a site owner do before installing one?

This is the part vendors keep short. RB2B's compliance pages say the site owner "owns compliance" and that the vendor does not check it. They list what the owner should do:

• Update the privacy policy to say that data partners may link a visit to other personal information, including an email address. RB2B suggests wording.
• Add an opt-out link for California residents.
• Update the cookie banner, and wire the script to it. The consent wait is automatic only with CookieYes. Other consent tools need manual setup.
• Disclose the other trackers on the site.

Two limits are worth knowing before you sign. The same page says RB2B "does not support configuring its script to exclude tracking in specific regions", so you cannot switch it off for one US state. And browser opt-outs, per the vendor's privacy policy, "apply only to the browser in which you set them".

Regulators are active near this area. California has reached settlements with large companies over ignored Global Privacy Control signals, and its privacy agency has fined data brokers under the Delete Act. None of the cases I read names a visitor identification vendor. That is "not found", not "none exists".

None of this is legal advice. If you run person-level identification, ask a lawyer who knows US state privacy law to read your setup.

What does an open-source company-level version look like?

looot-reveal is the company-level half, MIT licensed. Its page on looot lists the endpoints it calls with their live prices. A small snippet records the visit. The server looks up the IP address, stops when the address belongs to an internet provider, a mobile carrier, a host or a VPN, and enriches the company only when the network looks like a business.

What it leaves out, on purpose:

• No person-level identification. It never returns a name.
• No email finding.
• No hosted multi-user mode. You run it yourself.

Its limits are real too. No paid run was made while building it, so the parsers come from provider documentation and fixtures. The collect route was not load tested, and its rate limit of 60 requests a minute per address lives in memory in one process. If you go on to find people who work at a company it identified, those are contacts at the account. They are not the visitor.

Try it: look up the company behind an address

The enrichment step uses the same endpoints as the company list recipe, and the prices are in the public catalog.

What this article cannot tell you

• What happens on any vendor's servers.
• A measured match rate. I ran no test.
• Whether a given setup is lawful where you operate.

Last checked 2026-10-11. Written by Walid Boulanouar, who founded looot. Related: what the same enrichment costs at each provider.