Cross-device tracking: why one person looks like three visitors

When an analytics script sees a visitor for the first time, it generates a random ID and stores it in that browser - a first-party cookie or localStorage entry. That ID is the "user." And storage is isolated per browser profile per device: the phone has its own, the laptop's Chrome has its own, the same laptop's Safari has another. Nothing in this mechanism knows a person exists.

So the multiplication is mechanical. One person with a phone and a laptop is at least two users. Add a work machine, a tablet, one session in a different browser and an occasional private window - which stores nothing and mints a fresh ID every time - and a single loyal reader can plausibly be five or six "visitors," most of them apparently new.

Even a single browser doesn't reliably stay one visitor. Safari's Intelligent Tracking Prevention caps script-written storage - cookies set by JavaScript, localStorage and friends - at 7 days without a visit, and at 24 hours when the visit arrived through a URL carrying click identifiers. Firefox ships related protections, and other browsers have moved in the same direction.

The practical effect: an iPhone reader who visits every second Friday is a brand-new user each time, on the same device, in the same browser. Sites with a mobile Safari-heavy audience see returning-visitor rates that look low not because loyalty is low but because the identifier doesn't live long enough to witness it. This is the same family of undercounting covered in dark traffic, operating on identity instead of pageviews.

Four distortions follow directly. User counts inflate: consumer research firm GWI puts the average digital consumer at about 3.6 connected devices, and every uncredentialed device is a separate "user" to analytics. New-versus-returning skews new, because a regular on a second device or post-cookie-expiry is a first-timer again. Per-user economics deflate: one customer's lifetime value, split across three anonymous IDs, reads as three cheap customers instead of one valuable one.

The fourth is the expensive one: journeys break at the device seam, and the credit lands in the wrong place. The phone session that discovered you from a social post ends without converting - a failure, apparently. The laptop session that converts starts with someone typing your name, so the conversion is credited to direct traffic or a brand search, and the attribution model never even sees the touch that did the work. Funnels show the same tear: research steps with no finish, a finish with no research, drop-off spikes that are really device switches.

GA4 names this problem explicitly in its reporting identity setting, which builds users from up to three sources in order: a User-ID your site provides at login, the device-level ID otherwise, and modeled estimates where consent gaps leave holes. A fourth source, Google signals - identity borrowed from signed-in Google accounts - was removed from reporting in February 2024, so cross-device unification in GA4 now happens only for people who log in to your site.

That makes the practical GA4 situation the same as everywhere else: without your own login identifier, every device is its own person, whatever the settings say. The blended identity smooths counts, it doesn't discover identities you never provided.

Fingerprinting - deriving an identifier from a device's configuration instead of storing one - gets marketed as tracking that survives cookie clearing, and within one device it partially does. But a fingerprint is made of device traits, so a phone and a laptop produce unrelated fingerprints by construction. The technique is incapable of crossing devices, which is the actual problem here.

It's also where privacy scrutiny is hottest. When Google's ads policies began permitting fingerprinting for advertisers in February 2025, the UK's Information Commissioner's Office publicly called the change irresponsible, on the grounds that users can't see, clear or meaningfully consent to fingerprints the way they can cookies. Mainstream analytics tools don't build identity on it, and a vendor claiming fingerprinting solves cross-device measurement is describing something that doesn't work, in a way regulators dislike.

The one reliable bridge between devices is the person telling you who they are. When someone signs up or logs in, your site can attach a stable, non-personal identifier - a user ID, not an email - to their activity, and the same ID appearing from the phone and the laptop is what lets a tool merge them into one person. This is deterministic: no guessing, no probabilistic matching, and it works exactly as far as authentication reaches.

The classic implementation mistakes are worth knowing whatever your tool. The ID has to accompany activity on every device after login, in exactly one format - an ID sent as a bare number from the app and a prefixed string from the web makes two people. And placeholder strings are poison: a logged-out state sent as the literal text "null" merges every logged-out visitor into one monstrous user. Send an ID or send nothing.

In Bigdelta, profiles are identified by email, user ID or an anonymous cookie, and they merge automatically the moment a visitor identifies themselves - the anonymous history recorded before signup attaches to the profile at login. In the cross-device story, that means the phone research and the laptop signup become one journey with its real source intact, from the first anonymous visit to the latest login.

The honest boundary is the same one this whole post draws: before anyone identifies, an anonymous phone visitor and an anonymous laptop visitor are two visitors in Bigdelta too, because no tool can honestly do otherwise. Nobody is identified unless you choose to identify them, and profiles can be deleted or anonymized on request - the merge is a consequence of someone signing up, not surveillance of someone who didn't.

Cross-device tracking has two lookalikes worth separating. Cross-domain tracking is one browser moving between your own sites - shop.example.com to pay.example.com - where the problem is carrying an existing ID across domains, usually via link decoration, and no person-level identity is involved. Cross-platform means web plus native app, which behaves like another device: the app has its own identity store, and only a shared login ID joins it to the site.

The unifying rule across all three: storage-based identity stops at every boundary - domain, device, platform - and only an identifier the user brings with them crosses all of them.

Treat anonymous user counts as counts of browsers, not people, and read every per-user metric with that discount in mind. Expect the distortion to concentrate where it hurts - inflated uniques, pessimistic loyalty, funnels torn at the device seam, credit misassigned to direct. Fingerprinting doesn't fix it and can't. Identification at signup fixes it exactly as far as signups reach, so instrument login identity carefully, keep the ID format consistent everywhere, and let the anonymous majority stay what it honestly is: anonymous.