Identity resolution

Identity resolution stitches together user activity across devices, sessions, and the login boundary — so that a person who browses your app before signing up and then logs in on a different device is recognized as the same user.

This powers everything on the platform: targeting, personalization, behavioral segmentation, and response history all depend on knowing who you're talking to, even when the same person shows up with different identifiers at different times.

For the story behind why this matters, see the blog post.

How it works

1. You send identifiers. When you call identify(), you send one or more identifiers — a user ID, email, phone number, device ID, or any combination.
2. We match. getuserfeedback.com checks whether any incoming identifier already belongs to an existing user profile. Matching is deterministic — exact type and value after normalization.
3. We merge. If the incoming identifiers match more than one existing profile, those profiles are merged into one. All history moves to the merged profile.
4. The profile grows. Each new interaction can add identifiers. Over time, a single profile accumulates every identifier the user has ever been seen with.

Supported identifier types

Type	Example	Priority
User ID	user_123	Highest
Email	jane@example.com	High
Phone	+1234567890	High
Device ID	device_abc	Medium
Advertising ID	ad_xyz	Medium
Device token	token_abc	Medium
Custom IDs	Any key-value pair specific to your business	Configurable

You don't need to send all of these. Send what you have. Most teams start with a user ID and an email and that's enough.

The identifier mapping is configurable — you can change which fields map to which identifier types in your integration settings.

How matching works

When an event arrives with identifiers, the system:

1. Normalizes each identifier (lowercased email, trimmed whitespace, etc.).
2. Searches for existing profiles that share any (type, value) pair.
3. Only considers active, non-merged profiles.

This is purely deterministic. No probabilistic models, no fingerprinting, no third-party data. Only first-party identifiers you explicitly send.

How merging works

When identifiers match more than one existing profile, the system merges them:

1. Pick the destination. Profiles are ranked by: number of shared identifiers (more wins), identifier type priority (higher priority wins), then age of the earliest identity (oldest wins).
2. Merge into the destination. All other matched profiles are folded in. Their identifiers are moved to the destination profile.
3. Move history. Responses, trait assignments, and targeting state move to the merged profile. Nothing is lost.
4. Mark sources. The source profiles are marked as merged and won't match future events.

Pre-login and post-login continuity

A common pattern: a user interacts with your app before logging in, then creates an account or signs in. Without identity resolution, that's two separate profiles with separate history.

With identity resolution, when the user logs in and you call identify() with their user ID, the system links their pre-login activity to their post-login profile. Their earlier interactions — survey views, responses, targeting state — are all connected to the right person.

This works across devices too. If the same user logs in on a different device, a different browser, or a different session, their activity is linked to the same profile as long as they share at least one identifier.

Reversible by design

If you realize an integration was sending incorrect data — for example, mapping the wrong field to a user ID and accidentally merging unrelated users — you can remove that integration and its impact on identity resolution is fully undone. The profiles are restored to the state they were in before that integration's data arrived.

This means you can experiment with identity configurations safely. Bad data doesn't permanently corrupt your user profiles.

What resolution powers

• Targeting — rules like "show this survey to Pro users who haven't responded" work correctly across sessions and devices.
• Response history — responses from pre-login and post-login sessions are connected. You won't accidentally re-survey someone.
• Behavioral segmentation — segments reflect the full picture, not just one session or one device.

Normalization

Identifiers are normalized before matching:

• Emails are lowercased and trimmed.
• Phone numbers are trimmed.
• All string values are trimmed of leading/trailing whitespace.
• Placeholder values like <user_id>, <email>, 0 are filtered out automatically.

Examples

These examples show how identity resolution plays out in common scenarios.

New user signs up

1. A visitor lands on your site. The widget assigns them a session identifier.
2. They browse a few pages, see a survey, and submit a response.
3. They sign up. Your app calls identify("user_456", { email: "jane@example.com" }).
4. The system links the session identifier, user_456, and jane@example.com into one profile. The earlier response is now attached to Jane.

Same user, different device

1. Jane is already identified as user_456 on her laptop.
2. She logs in on her phone. Different device, different session — but same user_456.
3. The new session identifier is added to her existing profile. One person, one profile, every device.