Every person who interacts with your product leaves a trail — anonymous page views before they sign up, then a name and email once they log in. Identity resolution is how UMAP360 stitches those trails together so each real customer has one complete profile, from first anonymous visit to their latest purchase.
Anonymous vs identified profiles
UMAP360 creates a profile the moment someone first visits, even before you know who they are.
| Profile type | What it has | When it's created |
|---|---|---|
| Anonymous | A device or browser signal only — no name, email, or user ID | Automatically, on the first page view |
| Identified | A confirmed user ID, email, or phone | When your app tells UMAP360 who the person is (for example, on login) |
The goal is to start anonymous and become identified as more is known — so the history that began before sign-up isn't lost.
How matches are made
UMAP360 connects profiles using two kinds of signals.
- Deterministic (exact) — an exact match on a strong identifier like email, user ID, phone, or external ID. These are treated as near-certain matches.
- Probabilistic (likely) — a softer signal like a device ID, browser fingerprint, or click ID that suggests two profiles are the same person without proving it. Each probabilistic match carries a confidence score.
Strong, exact signals merge profiles automatically. Likely-but-unproven matches are held back for you to review rather than merged on their own.
What happens when two profiles merge
A merge combines two profiles into one. UMAP360 follows a consistent rule:
- The older profile survives as the single profile going forward.
- All events and sessions from the other profile move onto it — nothing is dropped.
- The person's full history is preserved — their journey from first visit to conversion stays intact.
- Traits combine, so details collected at different moments live together on one profile.
The merged-away profile no longer shows up on its own in your profile list; its activity now lives on the surviving profile.
Merges can't be undone
Once two profiles are merged, the action is permanent. Only confirm a merge when you're confident the two profiles belong to the same person.
The Identity Graph
The Identity Graph (under 360 Tools) is where you see and manage how identities connect. It's organised into a few views:
- Profile Clusters — identity records grouped per profile, each with its type and a confidence bar.
- Merge History — an audit trail of past merges, showing where each one came from (an identify/login event, an automatic match, an integration, or a manual merge) and when it happened.
- Identity Signals — a flat list of the active signals tied to each profile, with confidence and when they were last seen.
- Potential Matches — likely-but-unconfirmed matches waiting for your decision, sorted by confidence and showing which signals lined up.
For each potential match you can Approve (which runs the merge) or Reject (which dismisses the suggestion). There's also a Manual Merge option in the header for when you already know two profiles are the same person — you supply the source and target profiles, and a confirmation step reminds you it can't be reversed.
Review potential matches regularly
Working through the Potential Matches queue is the easiest way to improve identity accuracy. Approve the ones that are clearly the same person, reject the rest, and your customer view gets cleaner over time.
You can also track your stitch rate here — the share of profiles successfully linked to a known identity. A higher stitch rate means more of your anonymous traffic is being tied back to real customers.
Tuning the rules (Stitch Engine)
The Stitch Engine (also under 360 Tools) is where you tune the logic behind matching, without touching code. Each rule defines:
- Signal type — which signal it acts on (email, phone, user ID, external ID, device ID, browser fingerprint, IP signal, or click ID).
- Match type — whether that signal is treated as deterministic (exact) or probabilistic (likely). Strong identifiers default to deterministic; softer signals default to probabilistic, and you can override.
- Confidence — the threshold a match must clear, on a scale where higher means stricter.
- Priority — the order rules are applied in. Reorder with the up/down arrows, and switch any rule on or off without deleting it.
Alongside the rules, the Stitch Engine shows which signals are actually driving merges and a history of recent merges, so you can see the effect of any changes you make.
Start with the defaults
Each signal type ships with a sensible match type and confidence already set. Begin with those, watch which merges happen, and only adjust once you understand your own data patterns.
Next steps
- Browsing profiles — read a single customer's full history.
- Audiences and segments — group resolved customers for targeting.
- Customers overview — how profiles and identity fit together.
- Identity stitching guide — for developers wiring up the signals.
Last updated 2026-06-11