B2B Visitor Deanonymization and Consent: What's Legal

Why the person-level tools stop at the US border

Here's a detail that tells you almost everything you need to know. RB2B, one of the tools that reveals the actual name and LinkedIn profile of an anonymous website visitor, only works for US traffic. Not because the technology can't reach Europe. Because naming an individual EU visitor who never identified themselves, using a third-party identity graph and no consent, is a legal posture the company decided not to take.

That's the whole question in one anecdote. B2B visitor identification is a huge category now, and SaaS marketing teams reach for it to turn anonymous traffic into pipeline. Some of these tools are low-risk. Some are the kind of thing a data protection authority builds an enforcement action around. The difference comes down to two things: what the tool identifies, and whether a consented tracking cookie is doing the identifying.

"GDPR doesn't apply to B2B" is a myth that costs money

The most common thing B2B marketers get wrong is assuming privacy law is a B2C problem. It isn't. The GDPR protects natural persons, and it doesn't care whether that person is browsing for themselves or on behalf of an employer. A named individual's work email, their IP address, their LinkedIn identity, all of it is personal data under Article 4(1) the moment it's linked to an identifiable human.

The ePrivacy rules add a second layer that also applies to B2B sites. Setting or reading a tracking cookie on a visitor's device needs consent regardless of whether that visitor works at a company or shops for themselves. There's no B2B carve-out in the cookie rules. The UK ICO makes the same point in its Guide to PECR: business-to-business electronic marketing and tracking are covered, with only narrow differences from B2C. So the analytics or identification script on your marketing site needs consent in the EU/UK, whoever the visitor is.

Company-level and person-level are not the same product

Lumping these tools together is the mistake. There are two categories, and they carry very different risk.

Company-level identification (Leadfeeder, Albacross, Visitor Queue, and similar) uses reverse-IP lookup to tell you which organization a visit came from. "Someone at Acme Corp read your pricing page." No individual is named. This is the cleaner posture, because you're mostly working with company data rather than identifying a specific person. It still runs a tracking script that needs consent in the EU, but the output itself isn't a named human.

Person-level identification (RB2B, Clearbit reveal, Warmly, Vector, and the rest) tells you the individual: name, title, work email, LinkedIn profile. "Jane Smith, VP of Engineering at Acme, read your pricing page twice." This is deanonymizing a specific person using a third-party identity graph. Under GDPR that needs a real lawful basis, and for cold, unconsented visitors that basis is hard to establish. It's exactly why the aggressive person-level tools geofence out EU traffic or shut identification off entirely for EU IPs.

Two places consent has to hold

Deanonymization has two distinct legal gates, and teams usually think about only the first.

1. The tracking script. Whatever cookie or script the tool drops to recognize the visitor is subject to ePrivacy consent in the EU/UK. If it fires before the banner is answered, you have a cookie-consent violation before you've even used the data.
2. The identification itself. Turning "anonymous IP" into "Jane Smith" is a processing operation on personal data that needs its own GDPR lawful basis. Legitimate interest is the usual argument, and it can work for low-intrusion, company-level insight. For person-level reveal of someone who never gave you anything, the balancing test tilts hard toward the individual, and consent becomes the honest basis. Consent you almost never have from a cold visitor.

This is the same trap SaaS teams hit with product analytics, where a legitimate-interest argument for the processing doesn't rescue you from the separate cookie-consent requirement. We covered that split in SaaS cookie consent for product analytics.

The data-provenance problem nobody wants to discuss

Person-level tools work by matching your visitor's device or IP against a large identity graph assembled from other sources: form fills, data partnerships, SDKs embedded in unrelated apps. You didn't collect that graph. You don't know whether the people in it consented to being in it. When you use the match, you're relying on someone else's data collection, and if that collection had no lawful basis, neither does your use of the result.

Regulators have been circling this exact model. The chain of consent behind third-party identity data is the weak point, and "our vendor said it's compliant" is not a defense that has aged well. If you can't trace how a person ended up in the graph, you're carrying a risk you can't size.

A deployment that stays clean

You don't have to abandon visitor identification. You have to deploy it deliberately.

• Default to company-level. For most B2B marketing (account-based targeting, sales alerts, intent), knowing the account is enough. It's lower risk and often more useful than a single name.
• Make it region-aware. Run person-level identification for US traffic only, or gate it behind explicit consent for EU/UK visitors. Do not let a US-built tool quietly deanonymize European users.
• Gate the script behind your CMP. The identification tool should fire only after consent, same as any marketing tag. If it loads on page one before the banner, fix that first.
• Run a DPIA for person-level use. Deanonymizing individuals is high-risk processing. A data protection impact assessment isn't optional box-ticking here, it's the document that shows you weighed it. See our note on privacy by design in practice.
• Offer a real opt-out and honor deletion requests against the identified data, including anything you enriched.

Don't forget the rest of the B2B pixel stack

Deanonymization tools get the attention, but they sit alongside a familiar set of B2B marketing tags that all need the same consent treatment: the LinkedIn Insight Tag, HubSpot's tracking code, and intent platforms like 6sense and Demandbase. Every one of them stores or reads something on the visitor's device for a non-essential purpose, which puts them squarely in the consent-required bucket under ePrivacy. A common failure mode: the marketing site blocks the ad pixels but lets the "CRM" or "intent" scripts run free because they feel like internal tools. They aren't exempt. Categorize them as marketing and gate them.

How CookieBeam handles B2B tracking

Everything non-essential is blocked first. CookieBeam holds identification scripts, the LinkedIn Insight Tag, HubSpot tracking, and intent pixels until the visitor consents, so nothing deanonymizes anyone before the banner is answered.

Region-aware behavior. CookieBeam adapts consent behavior by visitor location using built-in framework presets (GDPR, UK GDPR, CCPA/CPRA, and US state opt-out rules), so you can run person-level identification for US traffic while enforcing consent-first for EU/UK visitors from a single deployment.

Continuous scanning. New tools get added to marketing sites constantly. CookieBeam's automated scanner flags trackers as they appear, so a visitor-ID script installed by the growth team doesn't sit uncategorized and firing pre-consent.

Consent logging. Each decision is recorded with timestamp and jurisdiction (consent logging and audit requirements), which is the evidence you'll want if anyone questions how a given visitor was identified.

The teams that get B2B identification right treat it like what it is: processing of personal data that happens to be about a professional. Company-level by default, person-level only where the law and your consent actually support it.