Your data is fine. Your customer record isn't.

Every personalisation conversation starts in the same place: which model, which vendor, which channel. It is the wrong starting point, and you usually find that out about eighteen months in.

The question that decides the outcome is duller. Can you tell, reliably, that the person who bought in store on Saturday is the person who abandoned a basket on Tuesday?

One customer, six records

1. The account. An email address, created at the first online purchase.
2. The loyalty record. Often a phone number or a card, created in store by a colleague at a till.
3. The guest checkout. No account, a different email, possibly a different address format.
4. The marketplace order. The marketplace owns the customer; you receive an alias.
5. The service ticket. Created from whatever the customer typed while they were annoyed.
6. The card transaction. A payment token, sometimes with no identity attached at all.

Several of these carry the same email with different capitalisation. One carries a work address, because that is where the parcel had to go. One carries a name spelled the way it sounded to somebody on a phone.

Most retailers do not have a customer data problem. They have a customer identity problem, and it is far more tractable.

What the fragmentation actually costs

• Recommendations trained on a third of a person's behaviour.
• Lifetime value understated, so acquisition spend is misallocated against it.
• A loyal returning customer treated as brand new, in the one moment where recognition mattered.
• Service colleagues who cannot see the order the customer is calling about.

This is the failure mode people later describe as "the personalisation didn't work". Usually the model worked. It was reasoning about a fragment.

Today

Account

Loyalty

Guest order

Identity resolution Match · score · merge

Then

One view

Useful models

Models sit at the end of this chain. Most programmes start there.

Deterministic first, probabilistic second

The instinct is to reach straight for a probabilistic matching engine. Start narrower.

Deterministic matching

On the keys you actually control — normalised email, normalised phone, loyalty ID, payment token. Unglamorous, cheap, and in our experience it resolves the majority of the estate before anything clever is required.

Probabilistic matching

For the remainder — name and address similarity, behavioural signals, device. This is where the interesting work is, and where you need an explicit confidence threshold rather than a vendor default.

A human path

For anything below that threshold. A merge that is wrong is considerably worse than a merge that never happened, particularly when it exposes one customer's order history to another.

The order of work

1. Normalise the keys you already hold.
2. Deterministic merge, measured — how much of the estate resolved?
3. Only then, probabilistic matching on what is left.
4. Only then, models on top of the resolved view.

Teams that run it in this order tend to see value in the first phase, because a resolved customer view improves service and reporting immediately — long before anything is personalised. Teams that start at step four tend to spend a year proving that the data was not ready.