Free scan
Visitor de-anonymization · troubleshooting

Something on my site is identifying anonymous visitors by name

That is a visitor de-anonymization tool, and it is doing exactly what it was bought to do. A script on your pages sends a signal about each visitor to a vendor, the vendor matches it against an identity graph assembled from other sources, and a name, company, or email address comes back to your CRM or Slack.

The short answer

These are marketed as website visitor identification, and the category includes both company-level tools (which resolve an IP address to an organization) and person-level tools (which return an individual's name and often a work email). The distinction matters enormously and is frequently blurred in the sales pitch — company-level resolution is a long-standing B2B practice, while person-level identification of someone who never submitted anything to you is a different proposition.

If nobody on your team can say which one you have, that is the thing to establish first, before the consent question.

Last reviewed: September 1, 2026Diagnostic + fix checklistGeneral information, not legal advice

What it looks like

The giveaway is usually not in the browser, it is in your notifications: a Slack channel or CRM feed announcing that a named person from a named company visited a specific page, for people who never submitted a form. In the network tab, look for a small script loading early and posting page-view payloads to a vendor domain — rb2b, vector, clearbit, koala, 6sense, demandbase and similar all appear as ordinary third-party requests.

Frequently nobody currently on the team installed it. It arrived with a growth consultant, a previous marketer, or as a bundled feature of an ABM platform.

DevTools → Network — fresh incognito, banner untouched:
GET s.rb2b.com/… (or vector, koala, clearbit) ← small script loads with the page
POST vendor endpoint, payload: page + visitor signal ← sent before any banner interaction
(your Slack/CRM) "Jane Doe from Acme viewed /pricing" ← no form was ever submitted

Find it in five minutes

You are answering three questions: what is installed, is it company-level or person-level, and does it run before consent.

  1. Follow the notification backwards. Open the Slack channel or CRM record where the identified visitors arrive. The integration settings name the vendor — that is the fastest identification, faster than reading the network tab.
  2. Load the site clean. Fresh incognito window, DevTools → Network, Preserve log on, banner untouched. Sort by time and read every third-party domain. De-anonymization scripts are small and load early; anything you cannot identify, search the domain.
  3. Read one payload. Click the vendor's POST request and open the request body. You will see what is actually being transmitted about the visitor — usually page, referrer, and one or more identifiers. This is the concrete answer to "what do they collect".
  4. Establish company-level versus person-level. Ask the vendor directly, in writing: does the product return an individual's identity for visitors who have not submitted a form on our site, and what is the source of the matching data? Their answer belongs in your files.
  5. Check whether it is gated. If the script runs before you answer the banner, it is transmitting a visitor signal pre-consent, exactly like any other tracker.
  6. Check your own privacy policy. Does it disclose that visitors may be identified, and does your opt-out mechanism cover this vendor? Most policies written before the tool was installed do not mention it at all.

What a healthy result looks like: You should be able to name the vendor, describe in one sentence what it transmits, say whether it identifies individuals, and say whether it waits for consent.

Why it happens

1. It was installed as a growth experiment

These tools are cheap, install in one script tag, and produce immediately visible results — a named lead in Slack within an hour. That combination means they often skip whatever review process a larger purchase would trigger.

2. It arrived bundled inside an ABM or intent platform

Account-based marketing and intent-data suites include visitor identification as a feature. The buyer evaluated the platform; the identification component came along and was enabled by default.

3. Its category is ambiguous in the CMP

A visitor-identification script is not obviously analytics, advertising, or functional. Consent platforms often leave it uncategorized, and uncategorized frequently defaults to allowed.

4. Nobody updated the privacy policy or the opt-out

The tool changed what personal information the site collects and, potentially, how it is shared — but the policy, the notice at collection, and the opt-out mechanism were written for the previous stack.

The risk context

California's Invasion of Privacy Act (CIPA), Penal Code § 631, prohibits intercepting a communication without the consent of all parties. Since 2022, plaintiff firms have applied that decades-old wiretapping statute to websites — arguing that transmitting a signal about each visitor to a vendor that matches it against an identity graph and returns the person's identity before the visitor consents is an intercepted communication. Statutory damages under § 637.2 run up to $5,000 per violation, and plaintiffs argue each affected visitor session is a separate count, which is why even small sites receive demand letters. Similar all-party-consent statutes in Pennsylvania (WESCA), Florida (FSCA), and Massachusetts have produced parallel filings.

Two things are worth separating. The pre-consent timing question is the same as for any tracker. The second question is specific to this category: identifying a visitor by name involves personal information obtained from sources other than the visitor, which is the territory of California's rules on notice, opt-out rights, and — for the vendors themselves — data broker registration with the CPPA.

To be precise about what a network log can tell you: a tracker firing before consent is a technical finding — it establishes when a script transmitted data, not whether any law was broken. But timing is exactly what these claims are built on, which is why fixing the timing is the practical response.

How to fix it

What this is called

Terminology bridge

Vendors call this website visitor identification, visitor de-anonymization, or identity resolution; the matching database behind it is an identity graph, and the practice sits inside account-based marketing (ABM) and intent data. The important distinction is company-level (reverse IP lookup to an organization) versus person-level (an individual's name and email). In California's vocabulary, a company that collects personal information about consumers with whom it has no direct relationship, and sells it, may be a data broker required to register with the CPPA — a public registry you can search.

What a scan can and can't tell you

A scan can tell you a de-anonymization script is present and when it runs. It cannot tell you where the vendor's matching data came from, whether their sourcing is lawful, or whether your use of it is — those answers come from the vendor's documentation, their contract, and your attorney. This page is general information, not legal advice.

Sources

  1. CPPA: California data broker registrycppa.ca.gov
  2. California Civil Code § 1798.140 — definitions of sell, share, and consentleginfo.legislature.ca.gov
  3. California Civil Code § 1798.100 — notice at collectionleginfo.legislature.ca.gov
  4. California Penal Code § 631 (leginfo.legislature.ca.gov)leginfo.legislature.ca.gov

Check your own site

RegSentry loads your site in a real browser, records when each third-party tracker first contacts its server, and flags everything that fires before consent — with the fix for each one. Continuous monitoring re-runs it and emails you when something new appears.

Free real-browser scan

See every pre-consent tracker on your site — free, 30 seconds, no signup.

Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.

Common questions

How can a website know a visitor's name without a form?
A de-anonymization script sends a signal about the visitor to a vendor, and the vendor matches it against an identity graph built from data collected elsewhere. Company-level tools resolve an IP address to an organization; person-level tools return an individual's name and often a work email. The identification comes from the vendor's data, not from anything the visitor gave you.
Is visitor identification allowed?
These are commercially available products and companies use them, but they raise questions ordinary analytics does not: whether visitors received notice, whether the transmission happens before consent, whether your opt-out mechanism covers the vendor, and where the vendor's matching data came from. California maintains a public data broker registry, which is a reasonable place to start checking. This is general information, not legal advice.
How do I find which identification tool is installed?
Fastest route: open the Slack channel or CRM integration where the identified visitors arrive — the integration settings name the vendor. Otherwise load your site in a fresh incognito window with the DevTools network tab open and look for a small early-loading script posting visitor payloads to an unfamiliar domain.

Keep reading

Guide: the Do Not Sell link that still shares dataMy privacy policy does not match my trackersCalifornia CCPA / CPRA explainedReport: the state of website trackingFree scan & monitoring plans