Cross-Device Identity Resolution Without Tracking Cookies

Cross-device identity used to be a solved problem. Ad networks dropped a third-party cookie on every site you visited, stitched the cookie IDs into a graph, and decided that the laptop browsing at 9am and the phone tapping an ad at 7pm probably belonged to the same human. That entire era is ending. Apple killed it on Safari in 2017. Firefox killed it shortly after. Chrome has been threatening to kill it for so long the threat itself became a meme, but the direction is unambiguous: third-party cookies are not coming back, and the cross-device graphs that depended on them are degrading every quarter.

This article is about what replaces them. Specifically, what you can actually resolve across devices in 2026 without third-party cookies, what you cannot, and the four patterns that work — login-based identity, shared first-party identifiers, hashed email matching, and (briefly) why fingerprinting is the wrong answer even when it technically works.

I’ll be blunt up front: most websites do not need cross-device identity. If you run a content site, a small SaaS, or a single-checkout ecommerce store, the marginal value of stitching a session on a phone to a session on a desktop is usually less than the engineering and privacy cost of doing it. But if you do need it — multi-step B2B journeys, multi-session ecommerce, anything where the buy decision happens days after the research session — there are clean ways and dirty ways to get there.

Why Cross-Device Matters (When It Actually Does)

The classic case is a user researching on a phone during a commute and buying on a desktop in the evening. If your analytics treats those as two strangers, you’ll over-attribute the purchase to whichever channel happened to touch the desktop session, and you’ll under-value whichever channel actually planted the seed on the phone.

This matters for paid acquisition more than for any other use case. If you’re spending money on ads and your attribution model can’t see that the phone-tap led to a desktop-purchase three days later, you’ll pull budget from channels that are actually working. Organic and direct traffic also benefit from cross-device resolution, but the consequences of getting it wrong are smaller — you lose insight, not money.

It matters less for content sites. A blog reader who visits on three devices over six months looks like three readers in any cookieless analytics tool, but if you’re not running paid traffic to that blog, the three-vs-one distinction rarely changes a decision. For deeper background on cross-device journeys and why they’re hard even with perfect data, see our companion piece on cross-device identity resolution and connecting the dots.

The Death of the Third-Party Cookie Graph

The mechanism that powered cross-device identity for a decade was simple. Site A and Site B both loaded the same third-party JavaScript (an ad network or DMP). That third party set its own cookie in your browser. When you visited Site A on your phone, the third party logged “phone-cookie-X visited Site A.” When you logged into a known account on Site B from your laptop and the same third party was loaded, it could connect “laptop-cookie-Y” to “phone-cookie-X” if you’d ever logged into that account on your phone too. Repeat across thousands of sites and you have a probabilistic graph linking every device a person uses.

That graph is now broken in most places. Here’s the state of browser restrictions:

The practical consequence: if your cross-device strategy depends on third-party cookies, you’re already losing Safari, Firefox, and Brave entirely, and you’re losing a growing share of Chrome. This is not a future problem. This is a now problem.

The 4 Cookieless Cross-Device Patterns

There are four real patterns for resolving identity across devices without third-party cookies. Three of them work. One of them works technically but should not be used.

Pattern 4 (fingerprinting) deserves a specific note: it works in the sense that you can build a stable-ish identifier from canvas rendering, font lists, screen size, timezone, and a few dozen other signals. Apple actively fights this with Safari’s privacy features, and the EU’s ePrivacy Directive treats fingerprinting as equivalent to cookie-storage for consent purposes. Don’t build on it. The legal and technical ground is shifting under it constantly, and you’ll be re-engineering every six months.

Login as the Gold Standard

If your product has accounts, you already have the answer to cross-device identity. The user_id assigned at signup is a stable, first-party, privacy-clean join key that works across every device the user ever logs in from. SaaS does this naturally — every analytics event after login includes the user_id, and stitching sessions across devices is just a SQL join.

The only complication is the pre-login session. A user might browse your marketing site on their phone, sign up on their laptop a week later, and you want to credit the phone session to the eventual user. The standard pattern: assign a first-party anonymous ID (a cookie or localStorage value, scoped to your domain only) on every visit, then on signup, persist that anonymous ID alongside the user_id in your database. From that point, any future session — on any device — that logs in as that user can be backfilled to the original anonymous trail, but only on the devices where that anonymous ID was set.

This doesn’t solve cross-device for anonymous users (nothing does, cleanly) but it solves cross-device for logged-in users perfectly. For more on why first-party identifiers behave differently from third-party ones, our guide to first-party tracking explained without cookies walks through the mechanics.

Email Hash (LiveRamp / UID2 Style)

Email-hash identity systems try to solve cross-device for logged-in users across multiple sites. The mechanism: when a user gives their email to Site A and Site B, both sites SHA-256-hash a normalized version of that email and use the hash as a shared identifier. If the same email shows up on both sites, the hashes match, and the sites can stitch identity across their respective device populations.

UID2 (Unified ID 2.0, originated at The Trade Desk) and LiveRamp’s RampID are the two big implementations. Both rely on a couple of assumptions:

1. The user has explicitly given their email to each participating site (typically by logging in or subscribing)
2. The user has consented — explicitly or via legitimate-interest framing — to having that email used for identity resolution beyond the original site
3. The hash is treated as a token, often refreshed and salted by an operator to prevent the raw hash from acting as a permanent fingerprint

The regulatory question is unsettled. Hashed PII is still PII under GDPR — the hash is reversible by anyone who has both the hash and the original email. The European Data Protection Board has issued guidance suggesting that email hashes used for ad targeting still require consent, and several DPAs have signaled that “legitimate interest” is not sufficient. In the US, things are murkier and depend on state. If you’re considering an email-hash strategy, talk to a privacy lawyer first. Our notes on PII in web analytics cover the boundary cases in more depth.

Server-Side Stitching with First-Party IDs

For ecommerce, the cleanest cookieless pattern is server-side stitching keyed on first-party identifiers you already collect. The pieces:

1. Every session gets a first-party anonymous ID, set by your server (not a third-party JS).
2. At checkout, the user provides an email or phone number. You associate the anonymous ID with that email/phone in your customer database.
3. If the user returns on a different device and either logs in or completes another purchase with the same email, you can stitch the new anonymous ID to the same customer record server-side.
4. Analytics events flow through your server (not directly to Google/Meta), and your server resolves the anonymous ID to the customer ID before forwarding.

This requires a server-side tracking setup. The architecture is straightforward but the engineering is non-trivial — you’re building a small identity service and an event pipeline that touches your CDN, your application server, and your analytics destinations. Our deep dive on server-side vs client-side tracking covers the mechanics. The payoff is a cross-device identity layer you fully control, scoped to first-party data, with no dependence on browser cookie behavior.

What You CANNOT Resolve Anymore

Three things that worked in the third-party-cookie era no longer work cleanly:

• Anonymous prospects across devices. If a user visits your site on three devices and never logs in, never gives you an email, and never installs an app, you cannot — and should not try to — link those three sessions. They are three sessions. Treat them as such.
• True cross-site graphs. Knowing that the same person visited Site A, Site B, and Site C is what ad networks built their entire targeting business on. That’s gone, except where users explicitly consent to a federated identity (which is rare).
• Retroactive cross-device for historical data. If you didn’t capture a first-party identifier when the session happened, you can’t go back and stitch it later. This makes the decision to invest in identity infrastructure a forward-looking one — it pays off six months from now, not today.

The right mental model is: cross-device identity used to be a free side-effect of the ad-tech ecosystem, and now it’s a deliberate engineering choice with real costs. Decide whether the use case justifies the cost.

GA4’s Cross-Device Approach

GA4 has two cross-device features and both have meaningful caveats.

The first is Google Signals. If you enable Signals, GA4 uses Google’s own logged-in account graph (people signed into Chrome, YouTube, Gmail, Android) to stitch sessions across devices. This works fairly well — Google has the largest first-party login graph on the planet — but it requires the user to be signed into a Google service with ad personalization enabled, and it requires you to obtain consent. In the EU under Consent Mode v2, Signals data flows are gated by the user’s ad-storage consent.

The second is Reporting Identity, which has three modes: Blended (uses User ID, Signals, Device, and modeling), Observed (uses User ID, Signals, Device — no modeling), and Device-based (treats every device as a separate user). Modeling fills gaps where Signals or User ID aren’t available with statistical estimates, which is fine for trend analysis but unreliable for user-level analysis.

The honest summary: GA4’s cross-device works reasonably well for sites with EU/US traffic where users are signed into Google, and it’s free. But it depends on Google’s continued willingness to maintain the Signals graph, on your users consenting, and on you accepting that a meaningful portion of cross-device resolution is statistical modeling rather than deterministic match. For an overview of GA4 alongside other tools, see our 15 best Google Analytics alternatives in 2026 roundup.

Privacy-First Tools That Skip the Whole Problem

Plausible, Fathom, Umami, and most of the privacy-friendly analytics tools have a different answer: they don’t try. They don’t use third-party cookies, they don’t use first-party cookies for identity, and they explicitly do not stitch users across devices. A user on a phone and a user on a desktop are two different users in their reports. They use a daily-rotating salted hash of (IP + user-agent) to deduplicate within a 24-hour window, and that’s the entire identity model.

This is fine — and arguably correct — for content sites, marketing sites, and small SaaS where the analytics use case is “what content is performing, what referrers send traffic, what’s the rough audience size.” It’s not fine for paid-acquisition attribution at scale, where the cost of mis-attribution is measured in dollars per misallocated ad spend. If you’re choosing between two of the most-cited tools that take this stance, our Fathom compared with Umami piece weighs the trade-offs on event flexibility and self-host options.

The privacy-first vendors are honest about the tradeoff: they sell aggregate-level insight, not user-level insight. If you don’t need user-level identity, you don’t need to buy it. For more on why this approach exists and where it fits, our privacy-friendly website analytics complete guide has the full breakdown, and our standalone Fathom Analytics profile covers what you do and don’t get from one of the cleanest implementations of this pattern.

Implementation Patterns

What to actually deploy depends on the site type. Here’s the matrix:

For SaaS, the playbook is: assign a first-party anonymous ID on first visit, send it as a custom dimension to your analytics tool, persist it server-side in a session table, and on signup, write the user_id alongside the anonymous_id in your users table. After signup, set User ID in your analytics SDK to the user_id. Every event after that is stitched. The pre-signup-from-other-devices problem is genuinely unsolvable and that’s okay.

For ecommerce, the playbook adds: route checkout-tracking events server-side, attach the customer email-hash (or internal customer_id) to all post-checkout events, and on subsequent visits with the same email, backfill the anonymous trail. If you need cross-device for prospects, layer in a hashed-email identity provider — but understand the regulatory exposure.

For B2B with long sales cycles, the answer is usually CRM-driven: pass a first-party identifier through email links and form submissions, key everything off the contact record in your CRM, and accept that the marketing-site-anonymous prospect cannot be resolved cross-device until they convert. The companion piece on cross-device identity resolution walks through this in more detail.

Common Mistakes I See

Five anti-patterns that come up repeatedly in audits:

1. Treating every solution as a 1:1 replacement for the third-party cookie graph. It isn’t. The third-party cookie graph was effectively magic and nothing you build will match it. Adjust expectations.
2. Building on browser fingerprinting. Even when the vendor swears it’s “privacy-safe” — it isn’t, and Safari/Firefox/Brave will randomize away your stable identifier on a regular cadence. You’ll be debugging it forever.
3. Putting raw email or phone in URL parameters. Use a hashed or tokenized version. Raw PII in URLs leaks into referer headers, server logs, analytics tools, and bookmarks.
4. Forgetting the consent layer. Cross-device identity in the EU is a consent-gated activity in nearly every form. If your CMP doesn’t explicitly cover it, your stitching is non-compliant.
5. Ignoring the lookback problem. A user on a new device with no prior identity will look like a new user until they log in. If your reports treat that as a “new user” forever, your retention metrics are wrong. Most tools handle this with backfill — make sure yours does.

Frequently Asked Questions

Is browser fingerprinting legal?

In the EU and UK, fingerprinting is treated as equivalent to cookie storage under the ePrivacy Directive — meaning it requires opt-in consent before any non-essential fingerprinting takes place. Most ad-tech fingerprinting fails this test in practice. In the US it’s a state-by-state question, with California’s CPRA treating it as personal information. Technically functional, legally fragile.

How does GDPR view email hashes used for cross-device stitching?

EDPB guidance and several DPA decisions treat hashed emails as still personal data, because the hash is reversible by anyone with the underlying email. Using hashed email for cross-device identity in the EU generally requires consent — legitimate interest is increasingly being rejected as a basis. The salting and tokenization layers in UID2 push the line slightly but don’t move it.

Is GA4 cross-device tracking free?

Yes, both Google Signals and User ID-based cross-device reporting are part of standard (free) GA4. The catch is that Signals depends on Google’s user graph and on user consent under Consent Mode v2. The free tier is functional but data quality varies with consent rates.

When is it actually worth implementing cross-device identity?

Three signals: (1) you spend meaningful money on paid acquisition where attribution mistakes cost real budget; (2) your conversion path spans more than one session for a meaningful share of users; (3) you have the engineering capacity to maintain a first-party identity layer over time. If any of those are no, default to single-device tracking and don’t waste effort.

Is login-based identity enough?

For SaaS and any product where most engaged users log in: yes, login is enough. The pre-login funnel will have gaps, but those gaps are the same gaps you’d have with any other approach. The marginal value of stitching anonymous-pre-login sessions across devices is small for most SaaS businesses.

How much does running a server-side identity service cost?

If you’re already running server-side tracking (Cloudflare Workers, AWS Lambda, a small Node service), adding identity resolution on top is single-digit dollars per month for sub-1M-events workloads. The cost is mostly engineering time — initial build is a few days for a clean implementation, and ongoing maintenance is light if you keep the scope tight.

Does Google Consent Mode v2 fit into this?

Consent Mode v2 is the layer that gates whether GA4’s cross-device features (Signals, ad-personalization-dependent identifiers) actually fire for a given user. If a user denies ad-storage consent, Signals won’t stitch their devices in your reports — Google will model the gap statistically instead. Consent Mode is not itself an identity solution; it’s a gating mechanism on top of Google’s existing identity solutions.

Bottom Line

Cross-device identity without third-party cookies is harder than it used to be, and that’s by design. The four patterns that work in 2026 are login-based identity (best for SaaS), shared first-party identifiers via server-side stitching (best for ecommerce), email-hash systems like UID2 with consent (best for ad-supported sites with email collection), and Google’s own Signals graph (best as a free baseline if you accept its dependencies).

The pattern that doesn’t work is browser fingerprinting, no matter how it’s marketed. Don’t build on it. The pattern that you should consider before any of the above is: do I actually need cross-device identity, or am I solving a problem my use case doesn’t have? For most content sites and small SaaS, the honest answer is “I don’t need it” and the right move is to use a privacy-first tool and skip the entire problem.

For the use cases where cross-device matters — paid acquisition, multi-session ecommerce, long B2B funnels — the work is real but bounded. Build on first-party identifiers, key everything off your own server, and treat the third-party cookie graph as a thing that used to exist and never will again.