What website visitor identification can tell you, and where it stops
How website visitor identification works, and where it stops: a visit becomes a company on your account record, a person is named only through something they did on your site or, in the US, a provider account you connect, and where they are sets the ceiling.
Updated
The short version
- A visit's network can give you the company that holds it: no cookie, no fingerprint, and nobody identified as an individual.
- Where a visitor is sets how far identification can go, and your team can tighten that limit for a product while nothing in the product can raise it.
- A Global Privacy Control signal stops matching to a named person on every visit, from everywhere, and company counting carries on.
- A claim about a visitor is never a contact: a person reviews it, writes a reason, and it arrives with consent unknown.
A visit tells you one thing on its own: whose network it came from
A visit arrives on a network, and a network has a registered holder. That is the whole of company-level identification: the address the visit came from is matched to the organisation that holds that range of addresses — a company's office connection, say — and the visit is written to the record with that organisation's name on it. No cookie is set, no browser is fingerprinted, and nobody is identified as an individual.
This is how the category works at this level, whatever the tool. Where tools differ is what happens when the holder is not a company: an internet provider, or the registrant of an office block, is a fact about the network rather than a company. Runner writes no company in that case. The visit keeps its count, and the holder is shown as the visit's network line, so a provider's name never sits on your record as a customer.
Picture this
It's 11pm on a Thursday, and someone reads your pricing page from an office connection registered to Northwind, a made-up freight company. The visit lands on your record with Northwind's name on it. A minute later another visit arrives from a home broadband line whose holder is an internet provider. No company is written, the visit still counts, and the provider shows up as that visit's network line, never as a customer.
One line of script, and the visits are your own first-party events
The install is one script tag. Runner serves the file from its own origin with the major version pinned in the address: a policy change reaches every site running it within minutes without anyone redeploying, and a breaking change ships as a new version beside the old one, never as a change to the file you already run.
The script records one page view per page load and exposes a small interface your own site can call: track an event, or tell Runner who a signed-in user is. Before anything leaves the browser it strips a fixed list of sensitive fields from whatever it was handed, and no site can turn that list off. It never throws — a failure makes the collector inert, never the page — and writes nothing to the browser console.
The data is yours. Events land as your own first-party events, and the consent decision a visitor makes is written on your domain, not ours. A repeat-visit identifier is stored in the visitor's browser only where the site runs the persistent level, the visitor has said yes, and no Global Privacy Control signal is present. Everywhere else the script runs on an identifier that lives for one page load and is written nowhere.
Where a visitor is sets how far identification can go
Runner works out how far identification may go for each visit, from where the visitor is, before any lookup that could name a person. It runs on every visit, and you set nothing to get it.
In the US a visit can be claimed as a person — on evidence they volunteered, or through an identity provider you connect and switch on yourself, on your own key — and a teammate approves it before it becomes a contact. In Australia, Canada, the EU, Japan, Korea and the UK the same is possible only for a visitor who turned Recognition on in the site's notice themselves. Everywhere else you get the company, or just the count.
Evidence they volunteered means the visitor identified themselves — they signed in, or submitted a form — and that consent is on record. A claim that arrives without that evidence is judged as if it had been inferred from network metadata, which is the stricter ceiling.
The identity provider is that stricter case. It's an account with an outside identity service that a project owner or admin connects for a product and switches on by approving its certification, and what it returns is inferred rather than volunteered — so it's permitted only for visitors in the US, and never for one whose browser sends a Global Privacy Control signal.
Recognition is a switch in the site's notice. It is off until the visitor turns it on, and Accept does not turn it on. It is offered only where the site runs the persistent level, because on the cookieless level there is nothing a later visit could be attached to.
In South Korea nothing is worked out from traffic at all — neither the person nor the company — and the visit is still counted. Whether the law there allows an organisation to be worked out from a network address without asking first is an open question we have not had answered, and the system is set to the stricter reading until it is.
A region nobody has reviewed is capped at the company — a refusal to act on an unreviewed region, not a finding that anything there is off-limits.
The same bound, on the product pageRunner honours Global Privacy Control before it checks where the visitor is
A visit carrying a Global Privacy Control signal is not matched to a named person — on every visit, from everywhere, without first working out which country or state the visitor is in. It is checked before the location rule, so whenever it applies it is the reason written on the record.
The signal is read twice, and either reading is enough: the header the browser sends, and the setting the browser declares to the script, because the transport the collector prefers does not reliably carry the header. A declared signal can only ever reduce what is recorded; its absence permits nothing.
Company-level counting continues under the signal, because that level identifies an organisation rather than a person. The refusal is written down — what was attempted, what was permitted, and why — so the record can show that a visitor was not identified because they asked not to be, which is a different fact from nobody having been found.
Try it
Open your browser's console on this page and type runner.status(). The gpc field says whether your browser is declaring Global Privacy Control, and persistent says whether the script may keep a repeat-visit identifier. Switch Global Privacy Control on in a browser that offers it, reload, and ask again: gpc reads true and persistent reads false, whatever level the site runs.
Your team can tighten the limit for a product, and nothing can raise it
Say your counsel would rather your marketing site never went past the company, whatever a region allows.
Anyone with access to a product can set a stricter limit for it than a visitor's region allows — no identification at all, or the company at most. The setting only ever reduces what is collected. Nothing in the product can raise it above what the region permits, and it has no effect on a Global Privacy Control signal, which is already honoured for everyone.
It is applied last, after the region's rule, and enforced where the visit is written — in the database, from the tracking key — rather than trusted from the browser. When a claim is turned down, the reason names the thing you would actually have to change: if the region's rule already capped it, it says so rather than pointing you at a setting that would change nothing.
Runner files the visit on the account and leaves the decision to a person
By Monday morning, the weekend's visits are already on the record.
The visit becomes context on the account record: which company, which pages, when, and how often — history that stays on the record rather than in a separate reporting tool. Every identification decision lands there too, including the ones that were turned down.
Where a visit deserves a human's attention, Runner turns it into a signal rather than an action. You mark the pages on your site that mean something commercially — pricing, a comparison, a booking page — and a visit from an identified company to one of those pages becomes an entry in a review queue. The entry names the label you gave the page and how many of your marked pages matched — never the address itself, and never a person's name, email or anything at the person level.
That entry is evidence for prioritisation only — never consent, qualification, or a basis to contact anyone: it creates no eligibility, changes no opt-out and triggers no outreach. It decides what a person looks at first, never what may be done. The step that creates it reads the claim the rules already permitted, never re-judges or raises it, and a visit with no company produces nothing, whatever the visitor did.
A claim about a visitor is never a contact. Nothing is created automatically at any confidence level. A person reviews it, writes a reason, and only then does it become a contact — and that contact arrives with consent unknown, because identifying somebody is not permission to contact them.
Picture this
You mark /pricing as "Pricing". On Tuesday someone from Northwind, already an account on your record, opens /pricing?ref=newsletter. The query string is dropped before the match, the path matches, and the Northwind account gets a review-queue entry: A visitor from this company viewed a hot page: "Pricing". No address, no name, no email sent, no contact created. Whether it matters this week is a person's call.
Where it stops
Runner has no resolver of its own that names anonymous visitors, and is not the one selling identity data. The person level runs on evidence the visitor volunteered, on a switch they turned on themselves, or, in the US, on the identity provider you connected, as above. No match rate is stated anywhere on this site, because none has been measured.
A turned-down person claim lands on nothing, never on the company: the lookup made one claim, and inventing a company claim it never made would be a fabricated identification, not a graceful downgrade.
The script reads no fingerprinting signal, on any level. Outside that US provider path, a visit is attached to a person only through something the visitor did on your site — signing in, submitting a form, turning Recognition on.
One system for the whole path
The mechanism above is one of the jobs Runner does on one record, under one login. Access is by application.