Website Visitor Identification GDPR Guide: How the Mechanics Work and What to Ask Your DPO

There is no blanket yes or no, because "visitor identification" covers architectures with very different privacy weights. Company-level identification, inferring which business network a visit came from, is commonly operated under GDPR’s legitimate interest basis with a documented assessment. Person-level identification, resolving an anonymous visitor to a named human without their involvement, is a much heavier processing activity that is hard to justify for EU traffic.

So the useful question is not "is this legal?" but "what exactly does this tool collect, store, and infer, and can we justify each step?" This article walks through the mechanics and the regulatory hooks so you can put precise questions to your DPO. It is not legal advice.

Visitor identification starts from the visitor’s IP address, so the first regulatory fact is this: IP addresses are generally treated as personal data under GDPR. Recital 30 names IP addresses among the online identifiers that, combined with other information, may be used to create profiles of natural persons and identify them.

The Court of Justice of the EU went further in Breyer v Germany (C-582/14, 2016): even a dynamic IP address, one that changes between sessions, can be personal data for a website operator, because legal means can exist (via the visitor’s ISP) to link it to an individual. The operator does not need to hold the linking information itself.

The practical consequence: a visitor identification tool is processing personal data the moment it touches the IP, even if its output is only a company name. That processing needs a lawful basis, and the vendor’s handling of the raw IP, stored, hashed, or discarded, is a question you are entitled to ask.

GDPR Article 6 lists the lawful bases for processing. For B2B visitor identification, the basis vendors and customers most often rely on is Article 6(1)(f), legitimate interests: processing necessary for the legitimate interests of the controller, except where overridden by the interests, rights, and freedoms of the data subject.

Legitimate interest is not a free pass. The ICO’s guidance breaks it into a three-part test that must be documented before processing starts, usually as a Legitimate Interests Assessment (LIA):

1. Purpose test: is there a genuine legitimate interest? Identifying which businesses show buying interest in your B2B product is the interest typically claimed.
2. Necessity test: is the processing necessary for that purpose, or is there a less intrusive way to achieve it?
3. Balancing test: do the visitor’s interests, rights, and freedoms override yours? This is where data minimization, company-level-only output, and visitor expectations do real work.

Two more obligations follow. Visitors must be informed, which in practice means your privacy notice should disclose the identification processing and name the processor. And where legitimate interest is the basis, visitors have a right to object; for direct marketing purposes the ICO notes that right is absolute.

GDPR is not the only regime in play. Article 5(3) of the ePrivacy Directive requires consent for storing information, or gaining access to information already stored, on a user’s terminal equipment, unless strictly necessary for the service. This is the legal root of cookie banners, and it applies regardless of whether the information is personal data.

The EDPB’s Guidelines 2/2023 (final version adopted October 2024) clarify how far Article 5(3) reaches into newer techniques, with use cases covering URL and pixel tracking, unique identifiers, and notably tracking based on IP only. The relevant question for any visitor identification tool is architectural: does it set or read cookies, local storage, or fingerprint-like state on the device, or does it work purely from the request the browser already sends (IP address, user agent, referrer)?

Tools in the first group sit inside classic consent territory. Tools in the second group still process personal data under GDPR (the IP), but the ePrivacy analysis differs, and the EDPB guidance is exactly what your DPO will want to map the specific technique against. Get the vendor’s answer in writing rather than assuming.

GDPR protects natural persons. Data about a company as such, its name, industry, headcount, is not personal data. That is why company-level identification, whose output is "someone from a network associated with Acme Corp visited your pricing page," is the defensible end of this category: personal data (the IP) is processed briefly as an input, and the retained output is organizational.

Person-level identification inverts that. The output is a named individual attached to their browsing behavior, typically resolved through third-party identity graphs the visitor has never heard of. That is profiling of a natural person, the transparency and lawful-basis hurdles are far higher, and it is no coincidence that vendors offering it largely restrict it to US traffic and exclude the EU.

One nuance worth stating plainly: "company-level" does not always mean "no personal data in the output." In a five-person company, "someone at Acme viewed pricing" can point at an identifiable individual. A careful balancing test acknowledges edge cases like this instead of hiding behind the category label.

Since we sell in this category, here is our architecture in the same terms we have used to evaluate everyone else. This is a description, not a compliance certificate; your DPO makes that call.

• Company-level only. PageFox resolves visits to organizations. It does not resolve anonymous visitors to named individuals and does not buy access to person-level identity graphs.
• No raw IPs at rest. IP addresses are used to derive the company match and are stored hashed, not in raw form.
• Person identity only when volunteered. A visitor becomes a named lead only when they submit their own details, through the chat widget or a form.
• Transparent scoring. Lead scores are built from signals you can inspect, so you can explain to anyone, including a regulator, why an account was flagged.
• Passive mode. You can run identification with no visible widget; the processing disclosure then lives in your privacy notice, where it belongs either way.

We built it this way because the balancing test is easier to pass when the tool simply holds less: less raw personal data, less inference about individuals, fewer surprises for the visitor.

Bring your DPO answers, not adjectives. These are the questions that make the assessment fast:

1. What exactly does the tool collect, and does it store raw IP addresses? For how long?
2. Does the script store or access anything on the visitor’s device (cookies, local storage, fingerprinting), or does it work from the request alone?
3. Is the output strictly company-level, and how does the vendor handle small-company edge cases where a company match approximates a person?
4. What lawful basis are we claiming, and has a Legitimate Interests Assessment been written down before launch?
5. Does our privacy notice disclose this processing and name the processor, and is a Data Processing Agreement in place?
6. How do we honor objections and deletion requests, and can the vendor exclude specific visitors or regions?
7. Where is the data processed and stored, and what is the sub-processor list?

If a vendor cannot answer these in writing, that is your answer. If they can, your DPO has what they need to run the assessment properly, and you can adopt visitor identification with a straight face instead of a hopeful one.