Cross-Device Tracking: Linking Sessions Without Login

When a user visits your site on their laptop in the morning and their phone in the afternoon, most analytics platforms see two completely separate visitors. Our device identification algorithm can link these sessions probabilistically — without requiring login — by analyzing signal overlap and building device graphs.

The Cross-Device Problem

Traditional fingerprinting generates a unique ID per browser instance. Chrome on a laptop produces one ID; Safari on an iPhone produces another. Even on the same device, different browsers generate different fingerprints because they have different user agents, different feature support, and different rendering characteristics.

But users do not think in terms of browsers. They think in terms of sessions. They start a purchase on their phone during lunch and finish it on their laptop at home. They research a product on their tablet and buy it on their desktop. For fraud detection and personalization, understanding that these sessions belong to the same person is critical.

Probabilistic Signal Matching

Our cross-device linking is built around a person graph with three kinds of node: the visitor (one browser profile), the device (the machine underneath several browser profiles), and a hashed identifier derived from a signed email address or phone number that your own application passes to us. Edges between those nodes are what join two sessions into one person.

Deliberately absent from that list: the IP address and the ASN. Shared network is the tempting signal and the wrong one — an office, a campus or a carrier-grade NAT puts thousands of unrelated people behind one address, so an IP-based edge produces exactly the kind of false link that is most expensive to undo. The deterministic edges we do use — same device, same hashed identifier, same canonical visitor root — are ones a shared network cannot fake into existence.

There is a bounded probabilistic component on top: a visitor's confirmed behavioral pairs can be considered as attachment candidates, capped at a small number per visitor and only above a confidence floor. It widens a cluster that deterministic edges already anchor; it does not start one on its own.

Device Graph Construction

Each confirmed or high-probability link between sessions creates an edge in a device graph. The graph connects browser instances to device nodes, and device nodes to person nodes. Over time, as more sessions accumulate, the graph becomes increasingly accurate.

The graph construction uses a conservative approach. A deterministic edge — the same device resolved under two browser profiles, or the same hashed identifier supplied for two accounts — creates the link outright. Anything weaker is treated as a candidate rather than a link, has to clear a confidence floor, and is capped so that one visitor cannot drag an unbounded cluster behind it. A visitor or a bridge under quarantine is skipped entirely rather than merged on suspicion.

Fraud Detection Applications

Cross-device linking is particularly powerful for fraud detection. A fraudster running accounts across several browser profiles is identified when those profiles resolve to the same device underneath, or when the same signed identifier turns up behind two of the accounts. A stolen credit card used on a device that has never been associated with the cardholder's device graph triggers an immediate alert.

We have seen fraud rings where a single operator runs dozens of virtual machines to create fake accounts. Each VM presents a distinct browser fingerprint, but they are all hosted on the same physical hardware, and device resolution is what collapses them back onto one machine. That shared device node is the edge the graph is built on — it exposes the ring from a single detected account, without any appeal to a shared address.

Privacy-Preserving Design

Cross-device linking raises legitimate privacy concerns. Our approach mitigates these through several design decisions. First, the layer is off by default — it is not something that arrives with a deployment, it is switched on deliberately for a workspace, and until then no person graph is built at all. Second, linking happens server-side and is never exposed to the browser, so the linked graph is not readable from the client, and the mode is set on our side rather than by anything the page can send. Third, the identifier edge only exists if your own application chooses to supply a signed email or phone — we do not derive it from the visitor. Fourth, users can be provided with transparency about linked devices through your privacy interface.

Accuracy Metrics

The tradeoff is deliberate and it favours precision over recall: we would rather miss a link than create a false one. That preference is visible in the design rather than in a headline number — deterministic edges create links, weak signals only widen clusters that are already anchored, quarantined bridges are skipped, and every cluster is capped. A missed link costs you a fraud pattern you would have caught later by other means. A false link merges two real customers into one person, and that error propagates into every decision made afterwards.

Measure it on your own traffic before you rely on it. Cross-device recall depends on how many of your users authenticate at all — the identifier edge is the strongest one available, and it only exists where your application supplies it.