Usability is the Real Customer Data Problem
Zeotap’s Emma Currie and Shravan Maheshwaran explain why enterprise customer data challenges are rarely about volume and often about usability, identity resolution and the ability to activate data at speed.
Topics
Customer data platforms have been marketed for years around a familiar promise: the elusive 360-degree customer view.
But inside large enterprises, the decision to invest in a CDP rarely begins with a neat ambition to unify data. More often, it starts when growth slows, personalisation stalls, paid media becomes less efficient, and teams realise they cannot act on the customer data they already have.
That gap between possessing customer data and being able to use it at speed is becoming harder to ignore. Marketing teams are under pressure to personalise in real time, reduce media waste, prove efficiency, and prepare their organisations for AI-led execution.
Yet many are still working across fragmented systems, inconsistent identifiers, and workflows that leave campaign activation dependent on technical bottlenecks rather than business urgency.
For Zeotap, that disconnect sits at the heart of the modern CDP conversation. The company positions its platform around identity resolution, customer unification, and faster activation across marketing and data teams.
In this interview, Emma Currie and Shravan Maheshwaran of Zeotap discuss what really drives CDP buying decisions, why identity resolution is often misunderstood, where customer data projects break down, and why a single customer view is better seen as an evolving foundation than a one-off goal.
Excerpts from the interview;
Emma Currie, Growth Specialist, Zeotap
When you first speak with prospective customers, what problem do they think they’re trying to solve, and what problem are they actually trying to solve?
What enterprise teams say they need is rarely what they actually need. Conversations almost always start with the same shortlist: “we need better personalisation”, “we need an AI strategy”, “we need a single customer view”. These sound like solutions, but they are symptoms.
Sit a layer underneath, and a different picture emerges. Marketing teams cannot access or trust their own customer data. Every campaign request gets stuck in a data-engineering queue. Customer data exists in volume, but it cannot be activated at the speed the business needs.
Different channels are talking to different versions of the same customer, and nobody on the team can confidently answer the most basic question: who is this customer?
The real problem most brands are trying to solve is not a data problem; it is a usability problem. They have the data. They cannot move fast enough to use it. The brands that recognise that distinction tend to build a sharper, more honest business case for change, and they get to value faster.
Every company says they want a single customer view. In your experience, what usually triggers the decision to finally invest in a CDP?
Very few organisations wake up and decide they need a CDP. The category itself is rarely the trigger. What usually moves a project from “we should look at this” to a funded initiative is a specific operational pain point that becomes impossible to ignore.
The patterns are remarkably consistent. CRM performance plateaus, and the easy levers stop working. Paid-media costs climb without a matching lift in efficiency. Personalisation programmes stall because the underlying audiences cannot be built or kept fresh.
A warehouse modernisation programme completes and exposes the gap between having data and being able to act on it. Loyalty launches surface data silos. Privacy regulation forces structural change. Leadership begins asking pointed questions about AI readiness, and the answer comes back: our data is not ready.
Strip those triggers back, and they all express the same underlying frustration: “We know the data exists. We cannot move fast enough to use it.”
That sentence, not the desire for a single customer view, is the real buying trigger. Once a team articulates it out loud, a CDP conversation stops being a technology evaluation and starts being a business decision.
What misconceptions do enterprise teams commonly have about identity resolution before they see how it works in practice?
The biggest misconception is also the easiest to miss: enterprise teams don’t actually start by thinking about identity resolution.
They start somewhere far more tangible: better CRM performance, less media waste, sharper personalisation, a stronger loyalty experience, the ability to activate data sitting in the warehouse, AI readiness, an end to teams pulling from different datasets and arguing about whose number is right.
Identity resolution rarely shows up on that list. It tends to be perceived as a technical nice-to-have, a back-office capability, owned by data engineering, that the business itself does not need to understand.
And that assumption is precisely where the gap opens up. Identity resolution is not a technical line item. It is the layer that decides whether any of those business outcomes are achievable in the first place.
- You cannot personalise to a customer you cannot reliably recognise.
- You cannot reduce media waste if your audiences are built on fragmented IDs.
- You cannot run a loyalty programme that treats the same customer as three different people across channels.
The misconception, in short, is not that identity resolution is too complex, too risky, or too privacy-sensitive. It is that it sits one level below the conversation enterprise teams are actually having and stays invisible until a marketing or CX leader sees, for the first time, a campaign outcome that only worked because the identity layer underneath was right.
At that point, identity resolution stops being a technical detail and starts being treated as the strategic capability it always was.
Shravan Maheshwaran, Technical Account Manager, Zeotap
Once a customer is onboarded, what are the first signs that a CDP implementation is heading toward success or trouble?
The moment of truth isn’t go-live — it’s discovery. We work to a simple principle I call the reverse-engineering model: begin with the end in mind. The first real sign of success is a strong architectural conversation with the right counterparts on the client side, usually in the first workshop.
I think of that workshop as an onion-peeling exercise: you go layer by layer through use cases, data sources, integration points, batch versus real-time flows, and field-fill rates across systems. When both sides finally hit that moment of shared clarity, you’ve quietly won about 60% of the battle before a single thing has gone to production.
Trouble looks like the opposite, and it’s almost always self-inflicted. There’s commercial pressure after a long sales cycle, so the temptation is to compress discovery and start “doing”, testing against assumptions instead of validated reality.
I’ve lived that. We rushed the early phase once, assumed steps rather than confirming them, and six weeks later, the first structure looked nothing like what the client had pictured. You don’t just lose the weeks; you open up a trust deficit before you’ve earned any credit.
The thing that saved that engagement was calling the risk out loud, early: “if we move this fast and skip the groundwork, here’s what will happen.”
It happened exactly as I’d flagged. We went back, did discovery properly, no blame games, and it became a genuine success story, and the relationship came out stronger, because the client stopped seeing me as a vendor and started treating me as the expert who’ll tell them the uncomfortable truth. You cannot skip discovery.
A few extra days at the start routinely save you two or three weeks later.
Where do customer data projects typically break down: data collection, identity resolution, activation, or measurement?
If I’m honest, the answer usually traces back to identity resolution but the way it breaks is more subtle than people expect, and it’s rarely a clean single point of failure. It’s a cascade, and it tends to surface in production rather than the sandbox.
Three culprits come up again and again. First, unplanned scale. The sandbox is really a capability test; production is a throughput, volume and spike test. When real data lands at real scale, you hit boundary conditions and cost ceilings you didn’t provision for, and cloud doesn’t mean infinite; it means metered. Second, the unification gap.
Your ideal-state profile stitching assumes clean inputs, but the actual collection streams are messier and more disjointed, so your unification rate comes in lower than modelled. Third, and this is the one that quietly hurts most, ID fill rate.
You can have a beautiful unification rate across every stream and still be in trouble if your highest-value identifier isn’t filling, because that’s the currency everything downstream draws on.
I see the role as part magician, part gatekeeper, part problem-solver. I’ll bend the systems and the data flows as far as they’ll go, but as a product company, my job is also to scope honestly: what can be delivered, and what can’t.
A big part of avoiding the break is insisting on retrospective analysis of the client’s current state. Teams are often reluctant to show how they built things before, because they assume we’ll just copy it, but those past learnings are exactly what stop us from repeating the same mistakes.
Get identity and current-state clarity right, and activation and measurement tend to follow. Get them wrong, and they fail downstream.
Many organisations talk about achieving a 360-degree customer view. From a technical perspective, is that goal realistic — or is it often misunderstood?
It’s realistic, but it’s widely misunderstood. The single customer view is a genuine north star: fresh, actionable, all-encompassing, a single source of truth that every downstream system can reference. The misunderstanding is treating it as a switch you flip rather than a foundation you build.
It’s a bit like Lego, or like any overnight success: it’s actually staged. Each use case you unlock is a level-up. For some clients, that takes a couple of weeks, for others a quarter; either way, you’re moving steadily toward the picture, not arriving at it in one go.
The most common misconception is that 360 just means “find one common ID and join everything together.” It sounds simple, and it stays simple right up until you go past two or three sources.
We’ve started engagements with nothing more than an Excel relationship diagram across the data streams, and the moment you map the real joins across multiple sources, multiple ID types and different granularities, that diagram explodes, and there’s an audible “oh, we didn’t anticipate that.”
That’s exactly where the mechanics earn their keep: a configurable unification engine, the ability to bring in complex data, transformations and aggregations after ingestion, and rules that bend to each customer’s reality rather than forcing a lift-and-shift.
So yes, 360 is achievable, provided everyone accepts it’s a living, evolving reflection of how that customer actually operates, built incrementally toward clarity, not a one-shot dream state.
ALSO READ: Artificial Intelligence Alone Cannot Fix Broken CX
