Key takeaways
- Identity resolution connects the records, devices, and events that belong to the same person, so marketing systems can treat them as one customer.
- Most platforms link anonymous and known activity when a visitor logs in or signs up, using an identifier that appears on both sides of that moment.
- Deterministic matching relies on exact identifiers and suits higher-stakes actions. Probabilistic matching relies on statistical likelihood and suits lower-stakes uses.
- How confident you are in a match should decide what you do with it, from aggregate reporting to individual messages.
- Identity and consent are separate questions. Knowing who someone is never grants permission to contact them.
Marketing platforms handle identity resolution by collecting activity under temporary identifiers, then linking that activity to a known profile when a shared identifier connects the two. The most common moment is a login or sign-up: the visitor’s browser or device ID and a verified account ID appear together, and the platform uses that overlap to connect earlier anonymous activity to the known customer.
This guide explains how that process works, the two main matching methods, how to decide what a match is allowed to support, and what to check when evaluating a platform.
What is identity resolution?
Identity resolution is the process of determining which records, devices, identifiers, and events belong to the same person. The result is a unified customer profile that marketing systems can use for personalization, suppression, and measurement.
Without it, one customer can look like several. A person who browses on a laptop, buys in a mobile app, and opens emails on a tablet may appear as three separate records, each with an incomplete picture. That leads to irrelevant messages, such as promoting a product someone already bought, and to inflated audience counts.
Many platforms store these connections in an identity graph: a map of which identifiers (email addresses, account IDs, device IDs, cookies) are linked to which person, and why.
Identity resolution quality depends on four things:
- The identifiers available: Exact, verified identifiers produce more reliable matches than inferred ones.
- The matching rules: Rules decide how much overlap is required before two records are treated as the same person.
- Confidence: Some matches are certain; others are likely. Good systems keep that difference visible.
- Governance: Consent, data quality checks, and a way to correct mistakes determine whether a match can be used safely.
How platforms connect anonymous and known profiles
Most platforms follow the same four steps. The details vary by vendor, but the sequence is consistent.
- Collect: Record activity and identifiers before and after the visitor identifies themselves.
- Match: Check whether records share enough information to be treated as the same person.
- Merge: Connect the matched activity to one profile, while keeping a record of where each piece came from.
- Activate: Use the unified profile for marketing actions that the match and the customer’s consent support.
To see how this works, imagine a shopper who views the same running shoe twice on a laptop, then creates an account the next day.
1. Collect activity before and after identification
Before the shopper logs in, the website records their product views under an anonymous identifier, usually a first-party cookie or device ID. The platform knows something happened on that browser, but not who did it.
| Signal | What it tells the platform |
|---|---|
| Anonymous activity | A browser or device viewed pages, products, or app screens |
| Device or browser ID | Several events came from the same technical source |
| Login or sign-up event | The visitor has provided account details |
| Verified customer ID | A known customer, such as an account ID or verified email, is now present |
Anonymous activity is useful even before identification. A platform can tailor the on-site experience for a browser that has viewed the same product twice. It cannot, however, tell who the visitor is, connect them to other devices, or contact them by email or SMS.
2. Match records under defined rules
When the shopper signs up, the sign-up event carries both the anonymous browser ID and the new account ID. That overlap is what lets the platform connect the two. Matching rules decide whether the overlap is strong enough.
Good matching rules account for four risks:
- Bad identifiers: Block malformed, shared, or recycled values, such as a placeholder email like test@test.com.
- Wrong entity: Match at the right level. A person, a household, and a business account are different things.
- Overconfidence: Keep exact matches distinct from inferred ones.
- High-stakes use: Require stronger matches before triggering actions with real customer impact.
3. Merge the profile without losing the history
Once the rules approve the match, the platform connects the shopper’s earlier product views to their new account. The profile now shows a known customer who viewed the running shoe twice before signing up.
A well-built system keeps the lineage of that merge: the record of which identifiers, events, and rules produced it, and when. Lineage matters when something goes wrong. If two people’s activity is merged by mistake, lineage is how operators find the cause and undo it.
4. Activate only what the match supports
The merged profile can now change what marketing does next. The shopper might enter a new-customer journey, receive content about the shoe they viewed, or stop receiving reminders once they buy it. The type of action should match how confident the platform is in the connection. The next two sections explain how.
Deterministic vs. probabilistic matching
Platforms use two main methods to decide whether records belong to the same person.
Deterministic matching connects records that share an exact, verified identifier, such as an account ID, a verified email address, or a loyalty number. If both records carry the same value, they match.
Probabilistic matching estimates the likelihood that records belong to the same person based on several weaker signals, such as IP address, device type, location, and behavior patterns. It produces a confidence score, not a certainty.
| Method | How it matches | Confidence | Best for | Main risk |
|---|---|---|---|---|
| Deterministic | Exact shared identifier | Generally high | Actions with real customer impact | A shared or wrong identifier creates a false match |
| Probabilistic | Statistical likelihood from several signals | Varies with the score | Reporting, analysis, and low-stakes relevance | A likely match gets treated as certain |
| Hybrid | Both, with separate rules for each | Tracked by method | Programs with a mix of use cases | Teams lose track of which matches are which |
Neither method is better in general. The shopper’s login is a deterministic match and can support individual messages. If the shopper also uses a tablet shared with their household, a probabilistic model might link that tablet to them based on location and usage patterns. That link might be reasonable for measuring reach, but it isn’t strong enough to send the shopper a personal message based on what was browsed on the tablet.
Deterministic matches still need quality checks. An exact match only means two records share a value, not that the value is correct. A family that shares one email address will match perfectly and still be several people.
Match confidence should decide what you do with a match
The most important rule in identity resolution is to tie each level of confidence to the actions it can support. The higher the stakes of an action, the more certain the match needs to be.
| Match type | Appropriate uses | Safeguards |
|---|---|---|
| Deterministic, validated | Individual messages, suppression after purchase, account-level actions | Identifier quality checks and a correction process |
| Probabilistic, high confidence | Light personalization within the channels a customer already uses | Use-case limits and monitoring for false matches |
| Probabilistic, low confidence | Aggregate reporting and analysis only | No individual-level actions |
| Conflicting | Nothing until resolved | Pause and investigate |
Write these rules down before activating matched profiles, and retest them whenever matching rules change.
Cross-device, household, and account relationships
Identity resolution connects more than one type of relationship, and mixing them up is a common source of errors.
| Relationship | Typical signals | Question it answers | Common mistake |
|---|---|---|---|
| Cross-device person | Logins and verified identifiers across devices | Is this the same person on different devices? | Assuming one device equals one person |
| Household | Shared address, subscription, or device | Do these people share a home or account? | Treating several people as one |
| Business account | Account ID, company domain, contact roles | Is this action for the company or a specific contact? | Treating account activity as one person’s activity |
| Channel permission | Email, SMS, or push opt-in | May you contact this person on this channel? | Assuming a connected profile means consent |
Connect devices without merging people
Consider the shopper again. They browse on their laptop, buy in the mobile app, and occasionally use a tablet shared with their family. Their logins on the laptop and phone support a confident cross-device match. The shared tablet does not, because several people use it.
Keep individuals and groups as separate records with explicit labels. A household record can support planning and frequency limits, such as not sending the same promotion to every device in a home. It should not feed one person’s profile with another person’s activity.
Keep consent separate from identity
A matched profile tells you who someone probably is. It does not tell you how you’re allowed to contact them. Consent is recorded per channel and per purpose, and it must be checked separately every time. If the shopper opted into email but not SMS, connecting their phone number to their profile doesn’t change that.
Real-time vs. batch updates
Platforms update profiles either as events happen or on a schedule. Choose based on how quickly the decision needs to change.
| Decision timing | Processing approach | Example |
|---|---|---|
| Immediate | Real-time (event-driven) | Stop a cart reminder the moment the shopper buys |
| Within minutes or hours | Near-real-time with checks | Start a welcome journey after sign-up |
| Scheduled | Batch | Refresh household groupings monthly |
Real-time matching matters most for suppression and in-session personalization, where a delay creates a visibly wrong experience. Batch processing is fine for enrichment and reporting, and a scheduled reconciliation can catch errors that fast updates miss.
Privacy, consent, and correcting mistakes
Identifiers used for identity resolution are often personal data under privacy law. The EU’s General Data Protection Regulation, for example, notes that people may be identified through online identifiers such as IP addresses and cookie identifiers, and U.S. state laws such as the California Consumer Privacy Act set their own rules. Requirements vary by jurisdiction, so review your approach with legal counsel.
Build six controls into any identity resolution program:
- Permission: Confirm that collecting and using each identifier is allowed.
- Purpose: Use data only for the reason it was collected.
- Method: Label whether each match is deterministic or probabilistic.
- Threshold: Match the required confidence to the stakes of the action.
- Lineage: Keep the sources, rules, and timestamps behind every merge.
- Correction: Document how operators pause activation and fix bad matches.
Plan for false merges and false splits
Identity resolution fails in two directions. A false merge combines two people into one profile. A false split leaves one person spread across several profiles. False merges are usually more harmful, because they send one person messages based on someone else’s behavior.
For example, if the shopper’s family shares one email address, a deterministic match can merge a teenager’s browsing into the shopper’s profile. The shopper then receives recommendations for products they never looked at. When that happens, operators need to be able to:
- See the consent state, source, and timestamp behind the match.
- Pause activation for the affected profile.
- Investigate which identifiers, events, and rules created the merge.
- Correct it by splitting the profile or adjusting the rule.
- Document the fix and monitor for repeats.
Eight questions to ask when evaluating identity resolution
Test any platform with your own data and a real use case. Run an anonymous visit, a sign-up, a shared device, an opt-out, and a correction through the system, then trace each result to the marketing action it would trigger.
- Which identifiers and signals can the platform connect? Test with data from your actual environment, not a demo set.
- What event and rule link anonymous and known activity? Review both accepted and rejected matches.
- Does the platform separate deterministic and probabilistic matches? Operators should be able to tell them apart.
- How does confidence limit what a match can trigger? Test personalization, suppression, reporting, and account actions separately.
- How are households and business accounts represented? Look for labels that prevent group activity from landing on one person.
- What updates in real time, and what runs in batch? Compare the timing with your fastest decisions, such as suppression.
- Can operators see lineage, consent, and conflicts, and correct errors? Ask to see the correction process, not just hear about it.
- How do matched profiles reach the systems that act on them? Trace one match all the way to a message, suppression, or report.
A large profile count says little on its own. What matters is whether reliable matches reach the right marketing decisions with consent and correction in place.
Frequently asked questions
1. How does identity resolution connect anonymous and known customer profiles?
Identity resolution connects anonymous and known profiles when an identifier appears on both sides of an identification event. For example, when a visitor signs up, the sign-up carries both their anonymous browser ID and their new account ID. Matching rules check whether that overlap is strong enough, and if so, the platform links the visitor’s earlier activity to their known profile.
2. What is the difference between deterministic and probabilistic identity resolution?
Deterministic identity resolution matches records that share an exact, verified identifier, such as an account ID or verified email address, and generally produces high-confidence matches. Probabilistic identity resolution estimates the likelihood of a match from several weaker signals, such as IP address and device patterns. Because probabilistic matches are estimates, teams should limit them to lower-stakes uses like aggregate reporting.
3. Can identity resolution work without third-party cookies?
Yes. Account IDs, verified email addresses, app identifiers, first-party cookies, and server-side events can all support identity resolution without third-party cookies. First-party data still requires consent, reliable collection, and sound matching rules.
4. What is an identity graph?
An identity graph is a map of which identifiers, such as email addresses, account IDs, device IDs, and cookies, belong to which person, along with the reason each link exists. Platforms use it to look up a unified profile from any single identifier. A well-governed identity graph records whether each link is deterministic or probabilistic and when it was created.
Put identity resolution to work
Identity resolution is only as useful as the decisions it supports. Match with the most reliable identifiers you have, tie each level of confidence to the actions it can support, keep consent separate from identity, and make it easy to see and fix mistakes.