How Do You Track Leads Across Devices?

Cross-device lead tracking works by resolving identity, not by following cookies — because a cookie is stored on one device and cannot travel to another. Connecting a phone session to a laptop session requires a signal that exists on both: an email or phone number the person supplied twice, a durable visitor identifier, a click ID seen on both visits, or a weaker inference like matching IP address and user agent within a narrow window.

The practical consequence is that cross-device tracking is a function of what you collect, not what you install. A perfect pixel on both devices still produces two strangers if nothing links them.

Why do cookies fail across devices?

Because a cookie is a file on one machine, scoped to one browser on that machine.

When someone visits on their phone, the browser stores a cookie locally. That file exists on the phone. It is not synced, not shared, and not visible to a laptop, a tablet, or even a different browser on the same phone. There is no mechanism by which it could be.

So the lunchtime research session and the evening form submission are, from a cookie’s point of view, two unrelated anonymous visitors. The ad click that started everything sits on the phone session. The conversion sits on the laptop session. Last-click attribution credits the laptop’s source — usually Direct or organic — and the campaign that actually created the lead gets nothing.

This isn’t a tracking failure in the usual sense. Nothing broke. The tracking worked correctly on both devices; the two records simply have no field in common.

Three things make it worse for lead generation specifically. Consideration cycles are longer than in ecommerce, so more time passes between devices. The conversion is often a form rather than a purchase, so there’s no order record to match on afterwards. And the highest-intent research — reading comparisons, checking pricing — disproportionately happens on mobile during gaps in the day, while the actual form fill happens at a desk.

What signals can actually connect two devices?

Six, and they differ enormously in strength. The honest way to think about this is as a ladder: use the strongest signal available, and treat the weak ones as last resorts rather than as equals.

1. A shared visitor identifier. The strongest signal, but only within a browser — this is what recognises a returning visitor on the same device. It anchors everything else; without it you’re re-identifying strangers on every visit.

2. Email address. The workhorse of cross-device matching. If the person supplied an email on the phone (a newsletter signup, a partial form) and the same email on the laptop, the two sessions are provably the same person. Deterministic, and as reliable as identity matching gets.

3. Phone number. The same logic, and valuable because it fails differently from email. People maintain work and personal email addresses and use them in different contexts; almost nobody has two phone numbers they use interchangeably. Collecting both roughly doubles your chance of a deterministic match.

4. IP address plus user agent. A probabilistic signal, useful within a short window. Two sessions from the same IP with the same browser and OS a few minutes apart are plausibly the same person. Over a longer window, or on a shared network, they plausibly aren’t — an office, a household, or a mobile carrier range will produce false merges if this tier is trusted too far.

5. Device fingerprint. A hash of stable browser and device characteristics. It re-identifies a browser that cleared its cookies, which is genuinely useful, but it identifies a browser, not a person — so it doesn’t bridge devices on its own, and it needs a bounded window and a cap on how many sessions it can merge, or a common configuration will collapse strangers together.

6. Click identifier seen twice. If the same gclid or fbclid appears on two sessions, the same ad click landed in both — usually because a link was shared, reopened, or resumed on another device. Narrow, but decisive when present.

The ordering matters more than the list. A wrong merge is worse than no merge, because it doesn’t produce a gap in your data, it produces confident, wrong data: one person’s journey stitched onto another’s purchase. Any system that treats these six as interchangeable will report a higher match rate and a less truthful one.

Is device fingerprinting a good solution?

It’s a useful tier and a bad foundation, and it’s worth being precise about why.

Fingerprinting infers a device from characteristics the browser exposes — screen dimensions, timezone, language, rendering behaviour. It’s genuinely effective at recognising a browser that cleared its storage, which makes it a reasonable last resort behind deterministic signals.

Three limits, though. It identifies a browser rather than a person, so it doesn’t solve the cross-device problem it’s often sold as solving. Its accuracy decays as browsers actively reduce the entropy available — this is a moving target by design, not a stable technique. And common configurations collide: a stock laptop model running a default browser in a common timezone produces a fingerprint shared with many other people.

Which is why a bounded window and a hard cap on how many sessions a single fingerprint may merge aren’t optional refinements — without them, the tier quietly generates false identities at scale.

What can you do to improve cross-device matching?

Four things, and the first one matters more than the other three combined.

Ask for a second identifier. Every deterministic match depends on the person having given you something twice. A form collecting only an email has one chance; one collecting email and phone has two that fail in different circumstances. This costs some completion rate and it’s the single highest-leverage change available.

Capture identifiers before the conversion, not at it. If the only email you ever see arrives at the final step, every earlier session stays anonymous and can only be joined backwards. Capturing an identifier earlier in the funnel means the journey is already attached to a person by the time they convert.

Make the visitor identifier durable. Much of cross-device matching is actually multi-session matching that happens to span devices. A visitor ID written by JavaScript is capped at seven days in Safari; one set by the server as a first-party cookie isn’t. That difference decides whether a three-week consideration cycle can be joined at all.

Normalise before comparing. John.Smith@Gmail.com and johnsmith@gmail.com are the same mailbox and won’t match as strings. Phone numbers arrive in several formats for the same number. Normalising both sides — lowercase and trim for email, E.164 for phone — recovers matches that were always present in the data.

How does PartialLeads stitch cross-device leads?

By resolving every session into a person-level cluster across six ranked tiers, and by capturing identifiers early enough that the deterministic tiers have something to work with.

Capture as they type, not on submit. The tag records form fields on input with a short debounce, and flushes any pending field when the page is hidden or the form is submitted. A visitor who types an email on their phone and abandons has already supplied a deterministic match key for a purchase they make later on a laptop.

A six-tier cluster resolver. Sessions are unioned into one person by visitor ID, email, phone, IP plus user agent, device fingerprint, and click ID — in that order of confidence. Strong signals resolve first; weak ones only get consulted when nothing better exists.

Bounded weak tiers. The device-fingerprint tier operates inside a 90-day window and is capped at a fixed number of sessions it may merge, specifically to bound false merges. This deliberately costs some matches. That trade is the right way round.

A durable, ITP-resistant visitor ID. Stored in localStorage with a first-party cookie backup, and the cookie is set by the server rather than by script — so Safari’s seven-day cap on script-written cookies doesn’t apply. Long lead cycles stay joinable.

Visit-sibling inheritance for the within-visit breaks. Not every split journey spans days. A session that loses its attribution mid-visit can inherit it from a sibling session on the same client, IP and user agent within a 30-minute window. There’s a second variant for the case that defeats plain IP matching: the same browser with a matching ad-click cookie within ten minutes, with the IP allowed to differ — which is what happens when a phone drops off wifi onto mobile data partway through a checkout.

Normalisation handled centrally. Email is lowercased and trimmed; phone is converted to E.164 with a country-code fallback derived from the session’s geography. One canonical builder rather than per-call-site handling.

The stitched journey is visible per lead. The leads list renders each touch as a badge, so a row reads as a sequence — and the ring treatment on each badge encodes how that session was joined to the person, separately from which channel it came from. You can see that a session was matched by phone rather than by cookie without opening the record.

Honest boundaries. Three. A person who researches on a device you never saw, converts in a private window, and supplies an identifier you’ve never received is genuinely unmatchable — no method resolves that without guessing, and guessing is what produces confidently wrong attribution. The weak tiers are deliberately bounded, which means some real matches are declined to avoid false ones. And fingerprinting identifies a browser, not a person; it is a recovery tier for cleared storage rather than a cross-device solution.

Sources

1. WebKit — Tracking Prevention in WebKit: https://webkit.org/tracking-prevention/
2. Mozilla Developer Network — User-Agent header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/User-Agent
3. Wikipedia — E.164 international telephone numbering plan: https://en.wikipedia.org/wiki/E.164
4. Google Ads Help — About auto-tagging: https://support.google.com/google-ads/answer/3095550