# 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, Runner's own naming or a provider account you connect, and where they are sets the ceiling.

Canonical: https://www.runtheworld.ai/guides/website-visitor-identification

Updated: 2026-11-10

## 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.

## 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, through Runner's own naming on AI included, or through an identity provider you connect 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.

Runner's own naming and the identity provider are that stricter case. With AI included, an owner or admin turns naming on for a product, and each person named uses AI credits while a miss costs nothing. The identity provider is an account with an outside identity service that a project owner or admin connects for a product and switches on by approving its certification. What either 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.

## Runner 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.

## 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.

## Where it stops

The person level runs on evidence the visitor volunteered, on a switch they turned on themselves, or, in the US, on Runner's own naming or 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 those two US paths, a visit is attached to a person only through something the visitor did on your site — signing in, submitting a form, turning Recognition on.