Person-Level Visitor ID Is Harder Than Companies Admit

I'm going to say something that's going to annoy half the vendors in our space. Most of the companies claiming "person-level" visitor identification are not actually doing person-level visitor identification. They're doing probabilistic matching that hits some of the time, and they're calling that person-level because the marketing reads better.

I want to break down why this is hard, what's actually happening behind the scenes, and how you can spot the difference as a buyer.

What "identification" actually means

When a visitor lands on your website, you get an IP address, a user agent, and a session. That's it. Out of those signals, you need to deduce a specific human being — name, work email, employer, role.

The IP address gets you company-level identification, sometimes. About 35-40% of B2B traffic resolves to a recognizable company IP. The rest is residential, mobile, or VPN. So even company-level is incomplete the moment someone reads your site on their phone at home.

Going from company to person requires a whole second layer of data. And that layer is where the games start.

The three games vendors play

Game one: "persons at the company." The vendor identifies the company, then surfaces a list of people who work there. Technically those people exist. You have no idea if any of them were the actual visitor. The vendor calls this "person-level" because there's a person's name attached. It's company-level with a fig leaf.

Game two: "100% match rate, 173 countries." No identity provider has 100% coverage. Anyone claiming this is either resolving against a tiny universe (only US visitors in big tech companies, where coverage really is near-complete) or quietly fabricating a match by guessing the most likely person from the company directory. The buyer reads "100%" and assumes magic. The vendor knows the truth and writes the disclosure in a footer somewhere.

Game three: stale data sold as fresh. The data underneath these tools decays fast. Phone numbers change, people leave companies, emails forward. A vendor with a 12-month-old database can claim huge coverage numbers that don't survive contact with reality. Look at the bounce rates. Those tell you what the coverage actually is.

What real person-level identification requires

An identity graph that ties browsing signals to specific individuals — not just companies — and is fresh enough to be useful. That graph has to be built from cooperating publisher networks that have explicit consent to share that data. It has to be re-verified continuously, because people change jobs and emails decay. And it has to be honest about its confidence: a 70% match should be labelled as a 70% match, not promoted to a certain match.

That's expensive to build. That's why most vendors don't actually build it. They license a third-party dataset and slap a UI on top.

How to tell the difference as a buyer

Ask three questions on any sales call:

1. "What's your match rate, and how do you define a match?" A real answer includes a number under 100% and a clear definition of what counts. A bad answer is a number over 80% with no definition.
2. "What's the bounce rate on emails I send to your matched contacts?" Anything over 5% means the underlying data is rotting. If they don't have an answer, they don't measure this.
3. "Where does your identity data come from?" A specific answer about cooperating networks and consent flows is good. A vague answer about "proprietary algorithms" is bad.

You'll learn more from those three questions than from any case study.

Why I'm writing this

Because the category is getting noisier and buyers are getting burned. Someone shows up at our trial having spent six months with a vendor that promised the world and delivered a list of generic contacts at the right companies. They lost a year of pipeline trying to make that work. I'm writing this so the next round of buyers asks better questions on the first call.

We don't have 100% coverage. Nobody does. Anyone telling you they do is selling you something else.

Talk next week,
— George