Identity Resolution for E-commerce: A 2026 Guide
Identity Resolution for E-commerce: How to Recognise a Returning Customer Without Cookies
Last updated: August 2026
Short answer: Identity resolution links the fragmented signals one person generates — devices, sessions, click IDs, email addresses, logins — into a single persistent profile. In e-commerce it decides whether a returning customer on a new device is recognised or counted as a stranger. Deterministic matching uses known identifiers like a hashed email and is exact but sparse. Probabilistic matching infers from behavioural and device signals and is broad but uncertain. Most stores need both, resolved before events reach the ad platforms rather than after.
Start with the case everyone has
A customer buys from you in March. Guest checkout, no account, on their phone.
In September they see a retargeting ad, click it on a laptop, browse, and buy again — guest checkout once more, different email autofill, different device.
To your stack that's two people. Two first-time buyers, two acquisitions, two separate attribution paths. Your repeat-purchase rate is understated, your customer lifetime value is halved, your retargeting audience excludes someone who just bought twice, and your ad platforms are optimising toward acquisition for a customer you already had.
Nothing is broken. Every event fired correctly, arrived intact and was recorded accurately. The pipeline did exactly what it was built to do. The failure is that nothing in it was responsible for deciding those two sessions were the same person.
That's the gap identity resolution fills, and it's why it isn't a subset of tracking. Tracking asks whether the event arrived. Identity resolution asks who it belonged to.
Why this got harder, briefly
You know the history, so the short version: third-party cookies are gone or going, Safari's ITP caps first-party cookie lifetime to days, Firefox blocks trackers by default, consent frameworks remove data lawfully, and mobile app tracking requires opt-in most users decline.
The consequence that matters isn't "we lost tracking." It's the persistence window collapsed. A cookie that used to identify a returning visitor for two years now identifies them for seven days. Any customer whose repurchase cycle is longer than a week — which is most e-commerce — looks new every time.
Longer detail on the mechanics in our cookieless tracking guide and first-party vs third-party cookies.
Deterministic and probabilistic matching
Two approaches, routinely presented as rivals when they're complements.
Deterministic matching links records using identifiers only one person plausibly has: a hashed email, a phone number, a customer ID, a login event. When a match happens, confidence is effectively total.
Its limitation is coverage. It requires the person to have given you a durable identifier. Guest checkout with a one-off email, a browsing session before any form fill, a gift purchase — none of it produces a deterministic key. Precision is excellent; recall is the problem.
Probabilistic matching infers that two records belong to one person from signals that individually prove nothing: device and browser characteristics, IP range, behavioural patterns, timing, navigation sequence. Any one is weak. Together they can support a confident inference.
Its limitation is that a confident inference is not a fact. Shared networks, household devices and common configurations produce false matches. Probabilistic matching expands recall and introduces error.
In practice you need both, with a confidence threshold you set deliberately. Deterministic where the identifier exists; probabilistic to bridge the gaps; and an explicit decision about how much uncertainty you'll accept, because that threshold is a business choice rather than a technical one. Merging profiles too eagerly corrupts your customer data. Merging too conservatively leaves you with the two-customer problem you started with.
Why match rates plateau, and what to do about it
This is the most useful section for anyone already running server-side tracking, because it explains a symptom teams find genuinely confusing.
You implement server-side tracking. Delivery improves — events that used to die in the browser now arrive reliably. And your match quality barely moves.
That surprises people because the two problems feel like one. They aren't.
Delivery is whether the event reaches the platform. Ad blockers, ITP and consent-stripped cookies attack delivery, and server-side tracking is the correct fix.
Match quality is whether the platform can tie that event to a person once it has it. Meta matches on the parameters you send — email, phone, name, location, external ID, click IDs. Send three weak parameters and the event still counts as a conversion while contributing almost nothing to audience building or optimisation.
So an event can arrive perfectly and match poorly. More reliable delivery of thin data is still thin data.
The fix is enriching the event with identity before it's forwarded — resolving the session against a persistent profile so the outbound event carries what you already know about that person, rather than only what this session happened to capture.
This is the specific job Ingest ID does. It assigns a first-party identifier on the first page load, captures click IDs like GCLID and FBCLID alongside it, and enriches the profile progressively as the person fills forms, signs up or converts — so identity persists for months rather than for the length of a cookie's life. Events are then forwarded already resolved rather than being sent thin and matched hopefully.
What an identity graph actually is
The term gets used loosely, so concretely: an identity graph is a store of identifiers and the links between them, with each link carrying a confidence level and a basis.
A single customer's node might connect a first-party ID assigned on first visit, two device fingerprints, a hashed email from a checkout, a customer ID from an eventual account creation, a GCLID from the ad that brought them in and an FBCLID from a later retargeting click.
Three properties decide whether it's useful.
Persistence. How long an identifier survives. This is the whole game. A graph built on identifiers that expire in seven days can't recognise a customer with a monthly repurchase cycle.
Progressive enrichment. The profile should improve with each interaction rather than being fixed at creation. Someone anonymous on visit one, identified by email on visit four and a known customer by visit six should be one strengthening profile — not three.
Bidirectionality. Resolution has to work in both directions: inbound, so incoming events attach to the right profile; and outbound, so what you know enriches the events you send to ad platforms, your CDP and your warehouse.
Background reading on the infrastructure side: first-party identity graph best practices.
The privacy question, answered honestly
Identity resolution sounds like surveillance, and the distinction that matters is a real one rather than a marketing line.
Third-party tracking followed people across sites they had no relationship with, using data they never knowingly provided. That's what regulation has spent a decade dismantling, correctly.
First-party identity resolution connects a person's interactions with your business, using data they gave you in the course of transacting with you. Recognising a returning customer is what a shopkeeper does. It's also what the customer generally expects — most people are more annoyed at being treated as a stranger by a brand they've bought from twice than by being remembered.
None of that exempts you from doing it properly. Consent still governs. Data minimisation still applies — collect what serves a purpose, not what's technically available. Deletion requests must propagate through the graph, not just the CRM. And identifiers should be hashed in transit and at rest.
The honest framing: identity resolution done on first-party data with consent is defensible. Done as a workaround for consent, it isn't, and no vendor claim changes that. See consent management.
How to tell whether you have this problem
Five checks, none requiring a purchase.
Compare unique customers to orders over 12 months. If your ratio implies almost every order came from a different person, you're probably splitting returning customers into new ones.
Look at your new-versus-returning split in GA4. A store with genuine repeat purchase showing 90%+ new users has an identity problem, not a loyalty problem.
Check your Meta Event Match Quality. Meta scores this 1–10. Consistently low scores while your events are arriving fine points at identity, not delivery.
Count the parameters you actually send. Open a purchase event payload and see what's attached. Many stores send an event ID, a value and little else.
Look at your guest checkout rate. The higher it is, the more your measurement depends on resolution rather than on logins. Most stores don't know this number.
If several point the same way, Site Intelligence will show what's currently firing and what's attached to it.
What to fix, in order
Capture identifiers you're already leaving on the floor. Click IDs, email at every legitimate opportunity, order-confirmation identifiers. Most stores discard more than they collect.
Assign a persistent first-party identifier on first page load, not at checkout. Identity that begins at conversion can never explain the journey that led there.
Enrich outbound events with ****resolved identity rather than session-only data. This is the change that moves match quality.
Set your probabilistic confidence threshold deliberately and write down why. It's a business decision about the cost of a false merge versus a missed one.
Then measure again, against a baseline you recorded before you started.
Frequently asked questions
What is identity resolution in e-commerce?
It's the process of linking the fragmented signals one person generates — different devices, sessions, click IDs, email addresses and logins — into a single persistent customer profile, so a returning customer is recognised rather than counted as a new one.
What's the difference between deterministic and probabilistic matching?
Deterministic matching links records using identifiers only one person plausibly has, such as a hashed email or customer ID. It's highly accurate but only works when that identifier exists. Probabilistic matching infers a link from device, network and behavioural signals. It covers more cases but introduces uncertainty and occasional false matches.
Why is my match rate low even though my events are arriving?
Delivery and matching are different problems. Server-side tracking fixes delivery — whether events reach the platform. Match quality depends on how many useful identity parameters each event carries. An event can arrive perfectly and still match on too little to be useful for audience building.
Does guest checkout hurt tracking?
It removes the most reliable identifier you'd otherwise get. Without an account, a returning customer often looks new, which understates repeat purchase rate and lifetime value and excludes real customers from retargeting audiences. Identity resolution is how you recover that without forcing account creation.
What is an identity graph?
A store of identifiers and the links between them, each link carrying a confidence level and a basis. A useful graph is persistent enough to outlive short cookie lifetimes, enriches progressively with each interaction, and works in both directions — attaching incoming events to the right profile and enriching outgoing events with known data.
Is identity resolution GDPR compliant?
It can be. First-party identity resolution using data customers provided while transacting with you, under consent, with data minimisation and propagating deletion requests, is generally defensible. Using it to work around consent is not, regardless of vendor claims.
Can I do identity resolution without cookies?
Yes. Persistent first-party identifiers assigned server-side don't depend on third-party cookies and aren't subject to the same browser restrictions as client-side cookies. Combined with deterministic identifiers such as hashed emails, this is how identity persists for months rather than days.
How is identity resolution different from a CDP?
A customer data platform stores and activates unified profiles. Identity resolution is the process that decides which records belong to the same person in the first place. A CDP with weak resolution is a well-organised store of fragmented profiles.