Why one person can appear as more than one website visitor

Learn how browser storage creates analytics visitor and session IDs, why those counts do not equal people, and how to check identity splits without collecting personal data.

A visitor ID describes a browser context, not a verified person

A dashboard shows 240 visitors this week. It is tempting to read that as 240 different people, but browser analytics usually cannot prove that. A browser can keep a first-party identifier and send it with later events. That helps group activity from the same storage context; it does not establish a real-world identity.

In the current WhoVisited tracker, the browser creates a random visitor UUID and stores it in `localStorage` under a key scoped to the site ID. It creates a separate session UUID in `sessionStorage`. Event payloads carry both IDs so the service can associate page views and custom events with a browser record and a visit session. The tracker does not read a visitor's name or email from a form.

These IDs are useful for understanding journeys, returning visits, and conversion sessions. They are not a count of verified customers, accounts, or humans. Treat the dashboard's visitor total as a count of browser identifiers observed in the selected period.

Why the same person can produce multiple visitor records

They use a work browser and a personal browser, or switch between browser profiles. Each profile has separate storage.
They visit from a phone and a laptop. The browser storage on one device is not shared with the other.
They clear site data, use private browsing, or the browser blocks persistent storage. The tracker may generate a new ID after the old value is unavailable.
The tracker runs while storage access is unavailable. WhoVisited catches storage errors and keeps an in-memory ID for that page; a later page load may not be able to reuse it.
The browser is using a different site ID or origin. `localStorage` belongs to an origin, and WhoVisited also includes the site ID in its storage key.

The reverse can happen too: several people using the same browser profile can share the same stored visitor ID. If a shared kiosk or office computer is used by multiple people without clearing browser storage, the activity may appear under one browser record.

Browser privacy controls matter. MDN documents that `localStorage` is tied to the document origin, can be unavailable under browser policy, and is cleared for private browsing when the last private tab closes. A blocked or cleared value is an expected boundary of browser-based measurement, not proof that a new person arrived.

Do not confuse a visitor with a session

WhoVisited keeps the visitor ID in `localStorage` and the session ID in `sessionStorage`. The session ID is associated with a browser tab and is renewed after more than 30 minutes without a tracker event. A reload in the same tab can keep the session, while a new tab may start a different session even when it reuses the visitor ID.

That distinction explains why one visitor can have several sessions, and why a person opening the same site in another browser profile can appear as a second visitor. Session totals describe visits under the product's session rule; visitor totals describe stored browser identifiers. Neither metric alone proves how many unique people or purchases occurred.

For the exact storage behavior, compare the product code with the browser platform: MDN notes that `localStorage` is shared by pages with the same origin and persists across browser sessions, while `sessionStorage` is partitioned by origin and tab and ends with the page session.

Check a suspected split with a clean, synthetic visit

javascript

function whoVisitedStorageStatus(siteId) {
  const status = { visitorIdSaved: false, sessionSaved: false };

  try {
    status.visitorIdSaved = Boolean(
      localStorage.getItem(`wv:visitor:${siteId}`),
    );
  } catch {
    // Storage may be unavailable under browser policy.
  }

  try {
    const session = JSON.parse(
      sessionStorage.getItem(`wv:session:${siteId}`) || "null",
    );
    status.sessionSaved = Boolean(session?.id);
  } catch {
    // A missing or unreadable session value is not a person identifier.
  }

  return status;
}

console.table(whoVisitedStorageStatus("YOUR_SITE_ID"));

Run this only in the browser console on your own test website, replacing the placeholder with that install snippet's site ID. It reports whether the tracker's storage keys exist; it deliberately does not print their UUID values. A missing key can mean the tracker has not initialized, storage was cleared or blocked, or the page is on a different origin/site ID. Check the Network panel and consent settings as well before drawing a conclusion.

Open your test page in one ordinary browser profile, allow collection as configured, and make one synthetic page visit. Confirm a visitor record appears.
Reload the same page in the same profile. The stored visitor ID should be reused when localStorage is available; a new session is possible if the prior session has been idle for over 30 minutes.
Open the test page in a separate browser profile or private window. It should have separate storage and may create a separate visitor record.
If results differ, compare the site ID, full origin, consent state, and whether storage is available. Avoid using a real customer's email or account details as a debugging property.

Use account data for people and browser analytics for journeys

Do not try to make visitor counts look like people counts by attaching email addresses, account IDs, order numbers, or fingerprinting signals to events. Those values can expose personal or sensitive information, and they do not repair the browser's storage boundaries. WhoVisited stores the visitor ID and session ID sent by the tracker; a separate, authorized identity source is needed before a browser record can be associated with a known person.

For unique signups, booked demos, or paid orders, use the application's own server-side records as the source of truth. Use website analytics to understand the page and campaign journeys around those outcomes. This keeps operational counts dependable while preserving the useful context that browser analytics can provide.

If you are investigating sessions rather than browser identity, see the [guide to repeat visitors and session attribution](https://whovisited.net/blog/understand-repeat-visitor-sessions-attribution). For differences between hostnames, use the [subdomain tracking explanation](https://whovisited.net/blog/understand-analytics-across-subdomains).