Identity resolution when half your customers check out as guests

The retention numbers arrive and they are worse than anyone expected. Repeat purchase rate is low, the average customer appears to buy once and disappear, and the board asks why loyalty is not working.

Then someone exports the order table and searches for their own name. Four records. Two guest orders under a personal address, one under a work address from when they bought a gift, one under an account created later because a returns form required it. Three different spellings of the same street.

This is not a loyalty problem. It is a counting problem, and it is common wherever guest checkout is the default path. Every order that arrives without an account creates a new row, and a business that never resolves those rows will permanently understate how often people come back.

Measure the fragmentation before you buy anything

Vendors sell identity resolution as a product. Before anyone evaluates one, find out how much of the problem exists in your own data and what shape it has. Most of it can be answered with SQL in a day.

The figures worth producing:

• Share of orders in the last year placed without an account, split by channel and by device.
• Number of distinct order records sharing an email address, and the distribution of that count.
• Share of orders where the email is present but the account is absent.
• Share of customer records with no contactable identifier at all — marketplace orders, click-and-collect, phone orders taken by a store.
• How often the same postal address appears with different names, which is the household case you must decide about deliberately.

Produce those five numbers before any tool conversation. In our experience the exercise itself reframes the project: teams often discover the majority of fragmentation collapses on email alone, and a large platform purchase was never the right first step.

Normalise before you match

Most matching failures are formatting failures. The same person, entering the same details twice, will produce two records that no exact join will ever connect.

Set a normalisation layer in the warehouse that runs before any matching rule:

• Lower-case and trim email addresses, strip the plus-suffix where your business rules allow, and treat the dot variants of common providers consistently.
• Reduce phone numbers to a canonical international format, dropping spaces, hyphens and leading zeros.
• Standardise addresses through one address service, keeping both the raw input and the standardised result.
• Strip titles and punctuation from names, and store a simplified form alongside the original.
• Keep the raw value on the record forever. Normalisation is a derived column, never an overwrite.

That last point saves you later. When a rule turns out to be wrong — and one will — you need the original input to rebuild from. The same principle applies to every derived field in a single customer view: derive, do not destroy.

Write the rules as tiers, with a confidence level attached

Treat matching as a set of explicit, ordered rules rather than a black box. Each rule produces a link between two records, and each link carries a confidence level that downstream systems can act on differently.

A structure we use often:

1. Certain. Same verified account identifier, or same login. These records are one person and can be merged.
2. Strong. Same normalised email address, or same verified phone number. Merge for reporting and for marketing, with an exception process.
3. Probable. Same standardised address plus the same normalised surname, or the same payment token across orders. Link for analytics, do not merge for marketing.
4. Weak. Shared device or browser identifier only. Use for on-site personalisation within a session and nothing else.

The critical design decision is that the tier controls what is allowed, not just what is recorded. A probable link can improve a lifetime value figure without ever being permitted to add someone to a mailing list or to expose one person's order history to another.

Household matching belongs firmly in the probable tier. Two people at one address are frequently two customers with different tastes, different consent and, occasionally, a good reason not to see each other's purchases.

Merging is destructive, so treat consent as the limit

A merge is one of the few operations in a CRM stack that cannot be quietly undone. Two profiles become one, and the question of what happens to their marketing permissions has to be answered before any rule goes live, not during the incident review.

Our standing rules:

• Consent never merges upward. If one record is subscribed and the other is not, the merged record inherits the more restrictive state.
• Suppression always wins. An unsubscribe, a complaint or a deletion request on either record applies to the merged one.
• Each consent decision keeps its own timestamp, source and channel scope, so you can still prove the basis for contacting someone.
• Every merge writes an audit row: which records, which rule, which tier, and when.
• There is a documented unmerge path, and someone has tested it on a copy of production.

Guest orders make the consent question sharper rather than looser. Someone who bought once without creating an account did not join a programme, and matching them to an older subscribed profile is not permission to start emailing about the new purchase. The honest route is to ask. This is why the consent work we set out in what broke in measurement matters more once identity is joined up. Better joins increase how much you know, not how much you may do.

Expect the reporting to change, and say so in advance

When matching lands, several headline numbers move at once. Customer count falls. Repeat purchase rate rises. Average orders per customer rises. Lifetime value rises. Acquisition cost per new customer rises, because some of what was counted as new was returning.

Announce this before the change ships. A retention metric that jumps without explanation is treated as an error, and the credibility cost lands on the team that did the right thing.

Run both definitions in parallel for a quarter where you can, with the old and new figures side by side, then retire the old one on a stated date. Re-baseline any target that was set on the old counting method.

There is a second-order benefit worth naming. Once orders resolve to people, your behavioural data becomes usable in a way it was not before. Event tracking from signed-in sessions joins to purchase history, and the result is first-party data that keeps working whatever browsers do next. That durability is the same argument we made in planning without the cookie clock.

Where to start

• Run the five fragmentation queries and put the results in front of whoever is asking about repeat rate.
• Build the normalisation layer first, as derived columns beside the raw values, and match nothing until it is in place.
• Write the four tiers with the permitted actions spelled out per tier, and get consent rules signed off before the first merge runs.
• Add one low-friction prompt to create an account after a guest order, and measure it on account creation, not on opens.