One customer profile instead of five partial ones

What this actually solves

You have five partial pictures of the same person and no complete one. The email tool knows they opened last Thursday's campaign. The website knows an anonymous browser looked at three products. The support desk knows somebody complained about a delivery. The shop knows an order was placed and later returned. Nothing connects them, so nobody in your business knows that all four are the same person having one continuous, deteriorating experience.

The consequence is not abstract. It is the email that arrives on Monday enthusiastically promoting the exact item the customer returned on Friday, sent by a system that had no way of knowing. It is the support agent who cannot see that this is a long-standing customer. It is an advertising audience that keeps paying to re-acquire people who already bought. Every one of those is a small, repeated act of not paying attention, and customers read it exactly that way.

A customer data platform fixes this by resolving identities into a single profile and then pushing that profile out to the tools that act on it. What it is not, and where these projects most often go wrong, is a purchase that solves the problem by being installed. The software is the straightforward part. Agreeing what a customer is, and encoding rules that decide when two records are one person, is the project.

What we do, and in what order

1. Define the use cases first, in specific terms. Not unified profiles as an aspiration — the three or four things you will actually do differently once they exist, and how you will know whether they worked. Everything downstream is scoped against this list, and it is what stops the platform becoming an expensive data collection exercise with no output. One to two weeks.
2. Agree the customer schema and the identity rules across departments. What a customer is, which attributes belong on the profile, which system is authoritative for each field when they disagree, and precisely which signals are allowed to merge two records. This is as much negotiation as engineering, and it is the step that decides the outcome. Two to four weeks.
3. Select the platform and instrument the sources. Each system sending events in an agreed shape with agreed identifiers, tested individually before anything is joined. This is where existing tracking quality either helps or has to be repaired first. Three to six weeks.
4. Map consent to purpose and enforce it. Which permission covers which use, how a withdrawal propagates to every downstream destination, and what happens to a profile assembled before consent was given. Built into the flow rather than applied afterwards. One to two weeks.
5. Build segments and connect the destinations. Advertising audiences, email flows, support context, on-site personalisation — each one tested against known profiles before it is allowed to send anything to a real person. Two to four weeks.
6. Test continuously, and keep testing after launch. Deliberately constructed edge cases — shared household emails, one person on several devices, a returning customer with a new address — run repeatedly, because the cost of an error here is a message reaching the wrong human. Runs alongside the final stages and continues past go-live.

What moves the price

How many sources, and how difficult the identities are. Matching on email addresses and phone numbers where customers log in is comparatively tractable. Stitching anonymous website behaviour to a known person, across devices, without over-merging, is the expensive end and it is where most of the engineering time goes.

Which platform, and what your stack already looks like. Well-supported mainstream systems have maintained connectors. Internal systems, older commerce platforms and bespoke applications need instrumentation built and maintained.

How much organisational alignment is required. This is the factor most often underestimated. A single decision-maker who can settle the definition of a customer in one meeting produces a very different project from four departments who each need to be convinced, and the difference shows up in weeks rather than hours.

What usually goes wrong

Someone says yes because the demo looked easy. Installing the platform genuinely is easy — a snippet and a few connectors and data starts arriving. Sending the right data, and correctly deciding that two records are one person, is not. Projects that started from the demo tend to stall around the third month with money spent, data flowing, and a profile nobody trusts enough to act on.

Instrumentation begins before the definition is agreed. Events get built against marketing's idea of a customer, finance disputes it, support has a third view, and the schema is rebuilt after implementation. The rework is expensive, but the real damage is that the platform arrives with a reputation for being wrong, and internal teams quietly keep using their own systems instead.

A wrong merge is treated as a defect to fix later. It is not a defect, it is a data protection event — one customer able to see another's history. Identity rules therefore need to fail toward separation rather than toward unification, unmatched profiles need to be acceptable rather than embarrassing, and any change to the matching logic needs testing against real historical records before it goes anywhere near production.