Identity Resolution Explained: How to Track Users Across Devices and Browsers

A single user might visit your site from a phone on the train, a laptop at work, and a tablet on the couch. In each case, your analytics sees a different visitor. Identity resolution is the process of recognizing that these three visitors are actually one person. Without it, your analytics overcounts users, your funnels break across devices, and your CRM sends the same person three different onboarding emails.

This post explains the two main approaches to identity resolution -- claim-based and graph-based -- how Gurulu implements both, and the privacy considerations you need to keep in mind. Whether you are building a custom identity system or evaluating analytics platforms, understanding these fundamentals will save you months of work.

Claim-Based vs. Graph-Based Identity

Claim-based identity resolution works by collecting explicit identifiers -- claims -- from user interactions. When a user logs in with an email, that email is a claim. When they verify a phone number, that is another claim. Each claim is attached to the session where it was observed. If two sessions share the same claim (e.g., the same email), they are merged into one identity. This approach is deterministic: it only merges sessions when there is a provable link.

Graph-based identity resolution builds a network of relationships between identifiers. Instead of simple pairwise matching, it constructs a graph where nodes are identifiers (emails, phone numbers, device IDs, cookies) and edges represent co-occurrence. Graph-based systems can resolve transitive relationships: if Session A shares an email with Session B, and Session B shares a phone number with Session C, all three sessions belong to the same person. The tradeoff is complexity -- graph resolution requires careful tuning to avoid false merges where unrelated users get linked through shared devices or recycled identifiers.

Deterministic vs. Probabilistic Matching

Deterministic matching requires an exact match on a stable identifier -- same email, same user ID, same phone number. It is highly accurate but has limited coverage: it only works when users provide identifying information. Probabilistic matching uses statistical models to infer identity from weaker signals like IP address, browser fingerprint, screen resolution, and behavioral patterns. It offers broader coverage but introduces false positive risk. Gurulu uses deterministic matching as the primary resolution strategy, with probabilistic signals used only for session stitching within a single browser context -- never for cross-device merges.

Why deterministic wins for analytics. False merges in your identity graph corrupt every downstream metric. If two unrelated users get merged, their combined session history distorts funnels, inflates engagement metrics, and confuses your CRM. Deterministic matching avoids this entirely by only merging when the evidence is definitive.

When probabilistic is acceptable. For anonymous session stitching within a single browser -- recognizing that a user who visited yesterday and today is the same person -- probabilistic models are safe. The false positive cost is low (slightly inaccurate session counts), and the coverage gain is significant.

Gurulu's 6 Claim Types

Gurulu's identity system is built around six claim types. Each claim is a piece of evidence that links a session to a canonical identity. When the system sees overlapping claims across sessions, it merges them.

• user_id -- Your application's internal user identifier. This is the strongest claim because it is unique and stable. Set via gurulu.identify().
• email -- Email address, normalized to lowercase. Collected when users sign up, log in, or submit forms with email fields.
• phone -- Phone number in E.164 format. Useful for mobile-first products and two-factor authentication flows.
• oauth_id -- OAuth provider plus external ID (e.g., google:118234567890). Collected automatically when users authenticate via social login.
• session_token -- Server-side session identifier. Links anonymous browsing to an authenticated state when the user logs in mid-session.
• device_fingerprint -- A privacy-safe device hash derived from viewport, language, and timezone. Never used for cross-device merges; only for same-device session continuity.

The identify() Call

The primary way to feed claims into Gurulu's identity system is the identify() API call. When a user authenticates in your application, you call identify() with their user ID and any additional properties. This creates a user_id claim and optionally email and phone claims, linking the current anonymous session to a known identity.

// Deterministic identity: link anonymous session to known user
gurulu.identify('user_12345', {
  email: '[email protected]',
  phone: '+1-555-0123',
  name: 'Jane Doe',
});

// The SDK sends a claim of type "user_id"
// Server-side, Gurulu merges all sessions with
// matching email, phone, or user_id into one
// canonical identity node.

Once identify() is called, all previous anonymous events in the current session are retroactively attributed to the resolved identity. If this email or user ID has been seen before in a different session -- on a different device or browser -- the sessions are merged into a single canonical profile. This is how cross-device identity resolution works in practice: the user logs in on their phone, and suddenly their desktop browsing history appears in the same profile.

Cross-Browser Merge Example

Consider this scenario: A user visits your site from Chrome on their laptop and browses three product pages. The next day, they visit from Safari on their phone and sign up with their email. On the third day, they return to Chrome on their laptop and log in. At this point, Gurulu has three sessions across two devices and two browsers. When the user logs in on day three, the identify() call creates a user_id claim. The system finds that this user_id matches the email from the phone session (because sign-up created both claims). All three sessions -- Chrome anonymous, Safari sign-up, and Chrome login -- merge into one canonical identity with a complete cross-device timeline.

This merge is instantaneous and retroactive. The user's profile in your CRM now shows the full journey: anonymous browsing, sign-up, and return visit. Funnels that span devices work correctly, and attribution models can trace the conversion back to the original traffic source that brought the user to your site on day one.

Privacy Considerations

Identity resolution inherently involves connecting user data across sessions and devices, which carries privacy implications. Gurulu's approach is designed to be consent-aware at every layer. Claims are only collected when the user actively provides them -- logging in, submitting a form, or authenticating. No passive fingerprinting or cross-site tracking is used. The identity graph is scoped to your site; there is no data sharing between Gurulu customers. And all claims are stored as pseudonymized hashes, not plaintext, so a database breach would not expose user emails or phone numbers.

For organizations operating under GDPR, KVKK, or similar frameworks, Gurulu supports consent-level gating on identity resolution. You can configure the system to only resolve identity for users who have granted analytics-level consent, while still collecting aggregate metrics for users who have not. This gives you the best of both worlds: accurate identity resolution for consenting users and compliant aggregate data for everyone else.