I replaced a five-figure-a-year customer data platform with one that costs about $30 a month. The infrastructure was the easy part. The real work went into a single decision no vendor can make for you: which records, scattered across six different systems, describe the same human being.
If your customer records live in a CRM, a payment processor, and a few marketing tools, you already have this problem whether or not you have named it. One system stores a phone number. Another keeps an email captured at checkout. A third has the name spelled a little differently. Ask any of them how many customers you have and you get a confident answer, and every answer is wrong in its own direction.
At Leverage Companies I was the first head of marketing across three brands that made money in very different ways: the lender Brick City Capital, the wholesaling operation Leverage Homes, and the Deals & Dollars education business. Customer records lived in two separate Salesforce orgs, plus GoHighLevel, Stripe, Whop, and QuickBooks. More than a million records across the two CRM orgs alone. Nothing agreed on who a person was, and because the business ran on the phone, one buyer could show up three times under three numbers and two email addresses.
A customer data platform is the layer that ends this argument. It reads every source, decides which records are the same human being, and returns one clean profile per person. Vendors package that and charge for it by the year. I did not have a year to spend on procurement, so I built my own on Amazon Web Services. Here is how, and the single decision that turned out to be the entire job.
Six systems, six versions of the same person
The instinct is to treat this as a storage problem: pour every source into one place and assume the mess resolves itself. It does not. Once the records sit side by side, the real problem finally becomes visible, which is that none of the columns line up.
You cannot fix this by choosing a column and joining on it. Join on email and the buyer who used one address on a form and another at checkout becomes two customers. Join on name and two different investors who share a common name become one. Every naive key either splits a single person into several or fuses several strangers into one, and both failures are invisible until a report is already lying to you.
Why the phone number is the primary key
The first real decision was which signal to trust most. In a business built on phone calls, people keep the same mobile number for a decade because changing it is a hassle, and they hand out throwaway addresses to anything that asks.
In a phone-sales business the phone number is the primary key. People guard their number for years and burn through their emails.
Phone-first has its own traps, and they have to be designed around. Numbers get recycled and reassigned. Office main lines and shared handsets belong to no single person. So a phone earns trust only when it is verified, by a passed code or a two-way reply, or when it shows up on more than one system attached to the same name. And rather than build the person's identifier out of the phone number itself, I minted a stable surrogate ID once, then attached the phone, the emails, and any other keys to it as aliases. A stronger key arriving later adds evidence without ever changing who the person is.
Bronze, silver, gold: three copies with three jobs
The architecture is a pattern borrowed from data engineering called a medallion, which is just three copies of the data with escalating cleanliness. It runs on cheap cloud object storage with a query engine on top, which is why the bill lands near $30 a month.
Bronze is the raw landing zone: exact copies of what each system sent, written once and never edited, so there is always an untouched record to fall back to. Silver is where the work happens. Every phone gets forced into one international format, every email lowercased and stripped of junk, disposable and role addresses flagged, and then the identity crosswalk assigns each cleaned record to a single Global Person ID. Gold is what the business reads: a current best view of each person, a ledger of every transaction, and the gross-profit-against-acquisition table that the whole company steers by.
Identity resolution is a confidence problem
The crosswalk is where most homemade versions of this go wrong, because people treat matching as a yes-or-no question. Every possible match carries a strength.
Identity resolution is a confidence problem. Two records merge at 95% certainty; at 70% they wait for more evidence. Merge on a maybe and you corrupt the record forever.
Each match key carries a weight, from a verified phone at the top down to a lone email at the bottom. Merges that combine records across the two separate orgs fire only at 0.85 and above. Anything weaker parks the record and waits, and that patience is the whole point. On top of the weights sit guardrails: a number that suddenly maps to a dozen people gets downgraded, a phone reassigned to someone new within the last few months needs a second signal before it can attach, and a manual override table lets a human force a merge or a split that the rules should never make on their own. The system is allowed to be unsure. What it is not allowed to do is guess and pretend it did not.
Where the real cost lived
By the time this was running, the technical cost was rounding error and the lesson was clear. Anyone can stand up cloud storage and a query engine in an afternoon. All of the difficulty lived in the rules that decide identity.
The expensive part of a CDP is deciding what same person means. No vendor can decide that for you.
That clean person layer is what makes everything downstream honest. It is the reason platform numbers stop lying, which I dug into in why your marketing attribution is broken. It is the identity feed under the LTGP:CAC operating system, since you cannot compute lifetime gross profit per acquisition dollar until you know which loan, course seat, and deal belong to the same person. And it is the measurement layer of the growth operating system, the quiet foundation the reporting stands on.
If your data is scattered across a CRM, a payment processor, and marketing tools that disagree about who anyone is, you do not necessarily need a six-figure platform. You need to decide what same person means in your business, encode that decision with confidence scores and guardrails, and let cheap storage do the rest.
If you are staring at systems that each hold a different version of your customer, this is the kind of layer I build. Let's talk.