Building a single customer view without buying a CDP

A CRM director shows us a vendor proposal and asks whether the platform will fix their personalisation problem. The proposal is for a customer data platform, the number has six figures in it, and the implementation timeline is nine months.

Then we ask what the first three use cases are. The answers are a win-back audience based on last order date, a replenishment trigger based on purchase quantity, and suppressing recent buyers from acquisition ads. Every one of those can be built from data already sitting in the company's warehouse.

This is the common case rather than the exception. Most teams asking for a CDP are asking for a single customer view and an activation path, and they already own most of the parts. What follows is how we build that, and the point at which buying the platform genuinely is the right answer.

Write down the use cases before you touch the data

A single customer view built without a list of things it must do becomes a modelling project with no end. Someone always finds another attribute worth adding, and nothing ships.

Start with six to ten concrete use cases, each written in the same shape. Which audience, defined by which fields, sent to which destination, refreshed how often. If a use case cannot be written that way, it is not yet a use case.

That list does two things. It tells you exactly which source tables you need, which is usually far fewer than a full migration. And it tells you the refresh frequency you actually require, which is almost always nightly rather than real time.

Keep the list visible. When a stakeholder asks for another twenty attributes, the question becomes which use case needs them, and most of the time the answer ends the request.

Identity resolution is a set of rules you must be able to defend

This is the part a CDP is genuinely selling you, and the part teams most often underestimate. Joining orders, email records, web events and support tickets into one person is where the work lives.

Resist the temptation to start with probabilistic matching. In almost every business we see, deterministic rules on a handful of keys resolve the large majority of records, and the remainder are better left unmerged than merged wrongly.

Write the rules explicitly, in this order:

1. Normalise first. Lower-case and trim email addresses, strip plus-addressing where your business rules say it is the same person, and put phone numbers into a single international format.
2. Pick a precedence of keys. Typically an authenticated account id, then a verified email, then a hashed phone number. Never match on name and postcode alone.
3. Define survivorship. When two records disagree on a field, which one wins, and why. Most often the most recently confirmed value, but marketing consent should follow the record that holds a timestamped source rather than the newest one.
4. Decide what a household is, and whether you will ever act on it. If not, do not model it.
5. Keep every merge reversible. Store the source record ids on the resolved profile so a wrong merge can be undone without a rebuild.

The last rule saves entire quarters. Identity resolution rules are always wrong at first, and a design that assumes they are permanent is a design you will rebuild.

Model it in the warehouse, not in the marketing platform

The instinct is to build the logic where the campaigns are, because that is where the marketer works. It is the wrong place. Logic built inside a sending platform cannot be tested, cannot be version controlled, and cannot be reused by the analytics team or by finance.

Build the models in the data warehouse with dbt, in the layers everyone already uses. Staging models that clean each source, intermediate models that apply the identity rules, and a small number of marts that the activation layer reads.

The customer mart should have one row per resolved person and a deliberately short column list. The fields the use cases named, plus consent state per channel, plus the identity keys. Anything else goes in a companion table, because a two-hundred-column customer table becomes impossible to reason about within a year.

Two things make this durable. Every model gets tests for uniqueness and non-null on the identity key, so a broken upstream feed fails loudly rather than quietly halving your audience. And every field gets a one-line definition in the model's documentation, written by whoever will be asked about it in six months.

If your data already sits in a lakehouse, the same layering applies without modification. We described that setup in more detail in building on a data lakehouse, and nothing about the identity work changes with the storage engine underneath.

Decide what genuinely has to be real time

Real-time requirements are what push teams towards buying a platform, and most of them do not survive examination.

Sort the use cases into three buckets. Attributes that can be a day old, such as lifetime value, segment membership and last order date. Attributes that need to be current within the hour, such as loyalty tier after a redemption. And events that must fire in seconds, such as an abandoned basket or a price-drop alert.

In most programmes the third bucket has two or three items in it. Those can be handled by streaming the specific event straight from the source system to the messaging platform, while everything else refreshes nightly from the warehouse.

That split is the single biggest cost decision in the whole project. Building the entire view for second-level freshness, when three journeys need it, is how a sensible plan turns into the nine-month one.

Activation is where these projects actually fail

A beautiful customer mart that nobody can send from is a reporting asset, not a composable CDP. The sync layer deserves as much design attention as the models.

Things to settle before you build:

• Which field is the sync key in each destination, and what happens when a person's email changes.
• How deletions and suppressions propagate, because a person removed from an audience must actually leave the destination.
• Sync frequency per destination, and the cost model of the reverse ETL tool, which is usually priced on records or rows changed.
• What happens when a model changes shape, since a renamed column will silently break a mapping.
• Who is alerted when a sync fails, and whether campaigns are held automatically when it does.

Load matters too. The volumes a nightly customer sync generates during peak trading are not the volumes you tested with in March, and we covered how to plan for that in running peak off the warehouse.

When buying the platform is the right call

There are cases where the packaged product wins, and pretending otherwise wastes a client's year.

Buy when you genuinely need anonymous-to-known identity stitching across a high-traffic site. Buy when you have no data team and no realistic route to hiring one. Buy when your compliance regime requires certified consent handling you cannot build in the time available. And buy when the business needs audiences live in weeks rather than quarters.

Everywhere else, the honest sequence is to build the mart, prove three use cases, and see what is still missing. That answer costs a fraction of the proposal, and if a platform is still needed afterwards, you will negotiate for it with a specification instead of a wish list. Our implementation work usually starts with exactly that test.