How to Track Users Across Devices Without Third-Party Cookies

The average B2B buyer uses 3.2 devices during their purchase journey. They research on their phone during a commute, compare options on a laptop at work, and complete a demo request on a tablet at home. Each device creates a separate anonymous session in your analytics. Without cross-device tracking, that single buyer appears as three different users with three disconnected journeys. Your traffic is inflated, your conversion rates are deflated, and your attribution model is blind to the actual path a person takes from awareness to conversion.

Third-party cookies were the duct tape that held cross-device tracking together for two decades. Chrome's deprecation of third-party cookies (now complete as of mid-2025), combined with Safari and Firefox's earlier blocking, means the old approach is dead. This guide covers the modern techniques for tracking users across devices using first-party data, deterministic matching, and privacy-compliant probabilistic methods that work without third-party cookies.

Why Third-Party Cookie Deprecation Broke Cross-Device Tracking

To understand the solution, you need to understand what broke. Third-party cookies allowed advertising and analytics platforms to set cookies from their domain (doubleclick.net, facebook.com, analytics-platform.com) on any website. Because the cookie belonged to the platform's domain, it was accessible on every site the user visited, creating a persistent identifier that followed the user across websites and, indirectly, across devices when combined with login signals.

When the user logged into Facebook on their phone and their laptop, Facebook's third-party cookie connected both devices to the same Facebook profile. Google did the same through Google accounts. These platform-level identity graphs powered cross-device targeting and measurement for the entire advertising ecosystem. Publishers and advertisers did not need their own cross-device identity solutions because they piggybacked on platform identity through third-party cookies.

With third-party cookies gone, this piggybacking no longer works. Your analytics platform cannot set a cookie that persists across sites. Advertising platforms cannot match users across devices through their own cookies on your site. The identity resolution that happened automatically now must be implemented deliberately by each company using its own first-party data and server-side infrastructure.

Method 1: Deterministic Cross-Device Matching

Deterministic matching is the gold standard for cross-device tracking. It uses a known identifier, typically an email address or user ID from authentication, to definitively link sessions across devices. When a user logs into your product on their phone and their laptop, both sessions are linked to the same user ID with 100% confidence. No guessing, no probability scores, no false matches.

Building the Identity Resolution Layer

The identity resolution layer is the system that connects anonymous session identifiers to authenticated user identifiers. When a user first visits your site, they receive a first-party cookie with an anonymous ID (a UUID generated by your analytics code). This anonymous ID is attached to every event the user generates. When the user authenticates (login, signup, form submission, email click), your system records a mapping: anonymous ID X belongs to authenticated user Y.

The critical step is retroactive stitching. When the identity mapping is created, you need to retroactively associate all previous events from anonymous ID X with authenticated user Y. This means your analytics system must support re-processing historical events to apply new identity mappings. Most modern analytics platforms (Kissmetrics, Mixpanel, Amplitude) support this natively through their identity resolution or aliasing features. GA4 supports this through User-ID tracking but with limitations on retroactive stitching.

When the same authenticated user visits from a second device and authenticates, their new anonymous ID (Z) is also mapped to user Y. Now all events from anonymous IDs X and Z are associated with user Y, creating a unified cross-device journey. The key requirement is authentication on each device. Without authentication, deterministic matching cannot link the device.

Maximizing Authentication Touchpoints

The effectiveness of deterministic matching depends on the percentage of sessions where users authenticate. If only 10% of sessions include authentication, you can only deterministically match 10% of cross-device journeys. Increasing the authentication rate increases cross-device visibility.

Strategies to increase authentication without degrading user experience: Offer content gates that exchange email for high-value content (research reports, tools, calculators). Use email magic links instead of passwords to reduce login friction. Implement social login options that authenticate with a single click. Send emails with unique tracking parameters that identify the recipient when they click through to your site (each email click becomes an implicit authentication event). Add saved preferences or bookmarks that require a login, giving users a reason to authenticate on each device.

The email click-through technique is particularly effective for B2B. When a contact in your marketing database clicks a link in your email, the link contains a unique identifier for that contact. When they land on your site, the anonymous session is immediately linked to the known contact. No explicit login required. This works across devices because the email is accessible on every device the user has configured with their email account.

Method 2: Probabilistic Cross-Device Matching

Probabilistic matching fills the gap where deterministic matching cannot reach: unauthenticated sessions. It uses signals from the device and session to estimate (with some probability) which anonymous sessions likely belong to the same user. The accuracy ranges from 60% to 85% depending on the signals used and the algorithm sophistication, which is significantly lower than deterministic matching but better than treating every session as a unique user.

Signals Used for Probabilistic Matching

IP address is the most commonly used signal. Devices on the same Wi-Fi network share an IP address, so sessions from the same IP within a time window have a higher probability of belonging to the same user or household. The limitation is that IP addresses change (dynamic assignment, VPN usage), and corporate networks can have thousands of users sharing one IP. IP alone produces too many false matches for reliable cross-device tracking.

Device fingerprinting combines browser characteristics (screen resolution, installed fonts, timezone, language settings, WebGL renderer, audio context properties) to create a semi-unique device identifier. When the same browser fingerprint appears across sessions, they likely come from the same device. This does not directly solve cross-device tracking (different devices have different fingerprints), but it improves same-device session stitching when cookies are cleared.

Behavioral signals add another layer. Two sessions from different devices on the same IP that both visited the same product pages in a similar sequence are more likely the same user than two sessions that visited completely different content. Navigation patterns, content interests, and interaction timing can increase matching confidence when combined with network-level signals.

Building a Probabilistic Matching Model

A practical probabilistic matching system works in layers. Layer one uses IP address and user agent to group sessions from the same network with compatible device profiles. Layer two applies behavioral matching within those groups: session timing patterns (same user tends to browse at similar times), content affinity (same user visits similar pages), and referral consistency (same user arrives from the same email campaigns or social profiles). Layer three uses your deterministic match data to train and validate the probabilistic model.

The training step is critical. Take your deterministically matched cross-device pairs and use them as ground truth to evaluate which probabilistic signals are most predictive for your specific audience. A model trained on your data will outperform a generic model because the behavioral patterns and network characteristics of your audience are specific to your context.

Method 3: Server-Side Tracking and First-Party Data

Server-side tracking shifts event collection from the browser to your server infrastructure. Instead of a JavaScript tag on the page sending events directly to an analytics platform, events are sent from the browser to your server, which processes them and forwards them to your analytics platform. This architecture gives you control over the identifier lifecycle that browser-based tracking has lost.

How Server-Side Tracking Improves Cross-Device Identity

When events pass through your server, you can attach server-side identifiers that persist beyond browser cookie expiration. Safari's Intelligent Tracking Prevention (ITP) caps first-party cookies set via JavaScript at 7 days (and 24 hours if the cookie domain is a CNAME of a tracking domain). But cookies set by your server via HTTP headers with the proper first-party domain are not subject to these restrictions. A server-set first-party cookie can persist for the full expiration period you configure (typically 1-2 years), providing a stable anonymous identifier for returning visitors.

Server-side tracking also enables you to maintain a server-side identity graph that is not accessible to browser-level privacy controls. When user Y authenticates, the identity mapping is stored on your server. When a new anonymous session arrives with signals that match user Y's profile (same IP, compatible device, similar behavior), you can probabilistically associate the session on the server side without needing any client-side mechanism that a browser could block.

Implementation with Server-Side Tag Management

Google Tag Manager Server-Side, Segment Connections, and RudderStack are the primary server-side tag management platforms. Each allows you to receive events from the browser, enrich them with server-side data (including identity resolution), and forward them to analytics and advertising platforms.

The typical architecture is: (1) A lightweight JavaScript snippet on the page captures events and sends them to your server-side endpoint. (2) The server-side endpoint receives the event, looks up the anonymous ID in your identity graph, resolves it to an authenticated user if a mapping exists, enriches the event with any server-side data, and forwards the enriched event to your analytics platform. (3) Your analytics platform receives events pre-resolved with user identities, producing accurate cross-device reports without needing to do its own identity resolution.

Method 4: Unified Login Ecosystems

The most reliable cross-device tracking comes from platforms where users are persistently logged in across all their devices. Google, Apple, and Microsoft achieve near-perfect cross-device tracking for their own services because users are authenticated everywhere. For most companies, achieving this level of persistent authentication across devices requires either a product that users access daily (SaaS applications, mobile apps) or a login ecosystem that provides enough value to motivate authentication on every device.

If your product has a web app and a mobile app, users who log into both are deterministically tracked across devices. The challenge is the marketing site and blog, where visitors are anonymous. One approach is to create a lightweight authenticated experience on the marketing site: saved searches, reading lists, personalized recommendations, or access to premium content. Even a simple "save this article" feature that requires login creates authentication events on the marketing site that enable cross-device matching.

Method 5: Cohort-Based and Aggregated Measurement

When individual-level cross-device tracking is not possible (due to privacy regulations, low authentication rates, or technical limitations), cohort-based measurement provides an alternative. Instead of tracking individual user X across devices, you track the behavior of cohorts: groups of users with shared characteristics (same acquisition channel, same content interest, same geographic region).

Google's Topics API and Attribution Reporting API (replacements for third-party cookie-based measurement) take this approach. They provide aggregated measurement data rather than individual-level tracking. You can learn that "users who saw ad campaign A had a 3.2% conversion rate" without knowing which specific users converted. For many marketing measurement use cases, this aggregated data is sufficient. For others (individual-level attribution, sales handoff, personalization), it is not.

The practical approach is layered measurement. Use deterministic matching for authenticated sessions (highest accuracy, individual-level), probabilistic matching for unauthenticated sessions on your own properties (medium accuracy, individual-level with caveats), and cohort-based measurement for cross-site and advertising measurement (lower accuracy, aggregate-level). Each layer serves a different use case, and together they provide a more complete picture than any single method alone.

Privacy and Compliance Requirements

Cross-device tracking is inherently privacy-sensitive because it involves identifying individuals across contexts. The regulatory landscape in 2026 is more restrictive than ever, and getting compliance wrong carries significant financial and reputational risk. Every technique described in this guide must be implemented within a consent and compliance framework.

GDPR Requirements (EU/EEA)

Under GDPR, cross-device tracking that identifies individuals requires explicit consent under the ePrivacy Directive (for cookie-based tracking) and a lawful basis for processing under GDPR (for identity resolution). The most defensible approach is to obtain explicit consent for analytics tracking through a compliant consent management platform, then perform identity resolution only on consented sessions. Users who do not consent should be tracked only with aggregated, non-identifiable methods.

GDPR also requires data minimization: collect only the data necessary for the stated purpose. If your stated purpose is improving website experience, you do not need to build a complete cross-device identity graph. If your stated purpose is measuring advertising effectiveness, you may need cross-device data but should minimize the personal data retained and establish clear retention periods.

CCPA/CPRA Requirements (California)

California's privacy laws require that cross-device tracking be disclosed in your privacy policy and that users can opt out of the sale or sharing of personal information. Cross-device identity resolution that links behavioral data to identified users typically constitutes "sharing" under CPRA, which means you must honor opt-out requests through the Global Privacy Control signal and provide a "Do Not Sell or Share My Personal Information" link.

Practical Compliance Implementation

Implement a consent management platform (OneTrust, Cookiebot, Osano) that captures and stores consent for analytics tracking. Gate your tracking code on consent: if the user has not consented, load only essential cookies and do not perform identity resolution. Store consent records for auditability. Implement automated data deletion for identity graph entries when users exercise their right to deletion. Hash or pseudonymize identifiers in your identity graph to reduce the sensitivity of the data stored.

Analytics Platform Comparison for Cross-Device Tracking

Not all analytics platforms handle cross-device identity equally well. The key differentiator is how each platform handles identity resolution: when it happens, how retroactive it is, and what matching mechanisms are supported.

Kissmetrics, Mixpanel, and Amplitude all provide robust retroactive identity resolution. When a user authenticates and you call the identity API, these platforms automatically merge the anonymous profile with the authenticated profile, retroactively attributing all anonymous events to the authenticated user. GA4's identity resolution is more limited: it supports User-ID and Google Signals (which uses Google account data for cross-device matching), but retroactive stitching depends on the reporting identity setting and is not as complete as purpose-built product analytics platforms.

Building Your Cross-Device Tracking Architecture

A production cross-device tracking system combines multiple methods into a layered architecture. Here is the recommended implementation order, from highest impact to most complex.

Phase 1: First-Party Identity Foundation (Week 1-2)

Set a server-side first-party cookie with a long-lived anonymous ID on your domain. Implement the identify call in your analytics platform that fires whenever a user authenticates (login, signup, form submission). Configure retroactive identity stitching in your analytics platform. This single step will resolve cross-device journeys for every user who authenticates on multiple devices.

Phase 2: Email-Based Identity Extension (Week 3-4)

Add unique tracking parameters to all marketing email links that identify the recipient. When a contact clicks through from an email, fire an identify call with their email (hashed) or contact ID. This extends deterministic matching to email-driven sessions without requiring explicit login. Configure your marketing automation platform to include the tracking parameter automatically in all emails.

Phase 3: Server-Side Event Pipeline (Week 5-8)

Migrate from client-side-only tracking to a server-side event pipeline. Set up a server-side endpoint that receives events from your client-side tracking, performs identity resolution against your identity graph, and forwards enriched events to your analytics platform. This gives you control over cookie management, identity resolution logic, and data enrichment that browser-based tracking cannot provide.

Phase 4: Probabilistic Matching Layer (Week 9-12)

Build a probabilistic matching model using your deterministic match data as training data. Apply probabilistic matching to unauthenticated sessions, assigning confidence scores to each match. Set a confidence threshold (typically 70%+) below which sessions remain unmatched rather than risk false matches. Monitor false match rates using a holdout set of deterministic matches.

Cross-device tracking in 2026 is harder than it was in the third-party cookie era, but it is not impossible. The shift is from passive tracking (cookies automatically following users) to active identity resolution (building your own first-party identity infrastructure). Companies that invest in this infrastructure gain a significant competitive advantage: they see the complete customer journey while competitors see fragmented device sessions. The investment is in server-side infrastructure, identity resolution logic, and consent management. The payoff is accurate attribution, realistic conversion rates, and a unified view of every customer that informs both marketing and sales decisions. Start with the first-party identity foundation and email-based identity extension. Those two phases cover the majority of cross-device journeys for B2B companies and can be implemented in under a month.