A CMO I worked with last year had a slide in her board deck titled "single source of truth." Under it was a CDP logo and a six-figure annual number. The board approved it. Nine months later the CDP was live, the profiles were unified, and the sales team still could not tell you which accounts had opened the pricing page that week.
The problem was never that the data lived in too many places. The problem was that nobody had decided what an account was. Their CRM had 4,100 company records for roughly 2,600 real companies. Marketing tracked website visitors by email domain. Product tracked usage by workspace ID. Nothing joined. The CDP dutifully unified all of it into one profile per person and produced a beautiful, expensive, still-useless view.
I have now sat through this conversation with maybe a dozen companies between 30 and 300 employees. The pattern repeats. Someone reads that a customer data platform gives you a unified customer view, they look at their own mess, and the two things seem to match. They usually do not.
Here is the honest version of when a B2B company needs a CDP, when it needs something much cheaper, and how to tell the difference before you sign anything.
What a CDP actually does
Strip the marketing away and a customer data platform does three jobs.
It ingests data from sources that do not talk to each other: your website, your product, your CRM, your ad platforms, your support desk, your billing system.
It resolves identity, which means deciding that the anonymous visitor from Tuesday, the person who filled a form on Thursday, and the user who logged into the product on Friday are all the same human. In B2B it should also decide which company that human belongs to.
It activates, which means pushing the resulting profile back out to the tools that need it. Send this segment to LinkedIn. Update this lead score in HubSpot. Trigger this email in Customer.io.
That is it. Ingest, resolve, activate. Everything else in the demo is a dashboard.
A CRM does something different. It is a system of record for relationships and deals. It holds the contact, the company, the pipeline, the notes, the emails, the tasks. It is where a human works. A CDP is not where a human works. It is plumbing.
The confusion happens because both vendors use the phrase "360 degree view of the customer." Only one of them means it as an interface a person looks at.
The number that should give you pause
Gartner's 2025 marketing technology survey found that 62% of organisations above $500M in revenue reported measurable ROI from their CDP. For companies under $100M, that number dropped to 29%.
Share of companies under $100M in revenue reporting measurable ROI from a CDP deployment, against 62% for companies above $500M. Source: Gartner 2025 Marketing Technology Survey.
Read that again. Fewer than one in three smaller companies got a return they could point to. And these are self-reported numbers from the people who bought the thing, which means the real figure is probably worse. Nobody enjoys telling a survey that the platform they championed did nothing.
Separately, industry estimates put CDP project failure at 30% to 40%, and the reason given is almost always the same: data readiness. The data going in was not clean enough for the resolution logic to do anything useful with it.
This is the part vendors are quiet about. A CDP is a multiplier, not a fixer. Point it at organised data and it gives you reach. Point it at a CRM with duplicate accounts, inconsistent country fields, and three competing definitions of "customer" and it gives you the same confusion at higher resolution and higher cost.
The B2B problem nobody solved for a decade
Most CDPs were built for consumer companies. The mental model is one person, one profile, one purchase decision. Retail, media, gaming, travel. That model works beautifully when the buyer and the user are the same human.
B2B breaks it immediately. Your buying committee has six to ten people. The person who signs is not the person who uses the product. The champion changes jobs and takes the relationship with them. Two of your contacts work at subsidiaries of the same parent company and you are running the same campaign at both.
What B2B actually needs is account-level identity resolution: an account graph that maps every person, every anonymous session, every product workspace and every billing record back to a single company node. Person-level resolution alone gets you nowhere. If your CDP unifies six perfect profiles but cannot tell you those six people work at the same target account, you have not made a single decision easier.
Some platforms handle this now. Salesforce Data Cloud does it natively because it sits on top of a B2B CRM. Adobe Real-Time CDP has a B2B edition with account objects. Hightouch resolves whatever your warehouse can join. But plenty of tools still sell person-level unification to B2B teams and let them find out later.
Ask any vendor this exact question in the first call: show me the account object and how a contact gets attached to it when the email domain is a Gmail address. The answer tells you almost everything.
In B2B, identity resolution that stops at the person is half a product.
The unit of revenue is the account. If the platform cannot build a reliable account graph, unified person profiles will not change a single thing about how your team sells.
The five questions that decide it
I run this with every client who brings up a CDP. If you answer no to the first three, stop. You do not have a CDP problem.
1. Do you have high-volume behavioural data that lives outside your CRM?
Not form fills. Not email opens. Those already sit in HubSpot or Marketo and they are fine there. I mean product events at real volume: feature usage, session data, in-app actions, API calls. Thousands of events per account per month.
If you sell a product-led SaaS tool where 4,000 free accounts generate signals you want to score on, that data will never live comfortably in a CRM. CRMs choke on event volume and price you painfully for the privilege. That is a genuine CDP use case, and it is the most common legitimate one I see in B2B.
If your entire dataset is form fills, email engagement, and deal history, you have a CRM. Use it.
2. Do you have more than one activation destination that your CRM cannot reach?
A CDP earns its cost by pushing audiences somewhere. If everything you do runs through HubSpot workflows and HubSpot ads, the CRM is already the activation layer. Adding a CDP inserts a hop with nothing at the end of it.
If you are pushing suppression lists to LinkedIn and Google, feeding a personalisation engine on your website, syncing to a support tool, and triggering lifecycle emails from a separate platform, the case gets stronger. Four or more destinations is roughly where the maths starts working.
3. Do you have multiple regions or business units on separate stacks?
This is the underrated one. If you acquired a company and now run two Marketo instances and one HubSpot, or if EMEA and North America bought different tools, a CDP is often the cheapest path to a joined view without a two-year consolidation project.
I would still argue for consolidating the stack. But I have watched enough migration projects slip that I understand why a CFO prefers the tool that avoids one.
4. Is your CRM data actually clean enough to be worth unifying?
Run this before anything else. Pull your company object and count records where the domain field is empty. Count duplicate accounts by normalised domain. Count contacts with no account association. Check how many deal records have a close date in the past and an open stage.
If more than 15% of your account records are broken in one of those ways, the CDP will spread the problem wider. Fix the CRM first. We wrote up the full audit process in the CRM data quality guide, and the decay maths behind why it gets worse quietly is in the data decay piece.
5. Do you have someone who will own it?
A CDP needs a technical owner. Not a marketer who is good with tools. Someone who can read a schema, write SQL, and reason about identity rules. If that person does not exist and you are not hiring them, the platform becomes shelfware in month four. I have seen this three times.
The cheaper thing that works for most B2B teams
Here is what I build for companies between 30 and 300 people, and it covers maybe 80% of what they wanted the CDP for.
A warehouse. BigQuery or Snowflake, sometimes Postgres if the volume is modest. Everything lands there: CRM, product events, billing, website analytics.
An ingestion layer. Fivetran or Airbyte for the standard connectors. For anything custom, n8n running on our own infrastructure, which also keeps EU client data inside the EU.
Identity resolution as SQL. This is the part people find surprising. B2B identity resolution is mostly a join on normalised email domain, plus a manual mapping table for the exceptions: free-mail addresses, subsidiaries, agencies buying for clients. It is a few hundred lines of dbt. It is not magic and it is much easier to debug than a black-box matching engine, because when it is wrong you can see exactly why.
Activation with reverse ETL. Hightouch or Census pushes the computed fields back into HubSpot, LinkedIn, the support tool, wherever. Hightouch starts around $350 a month on paid plans. That is the whole architecture we walk through in the reverse ETL guide.
The licence gap is real but it is not the main argument. The main argument is that you own the logic. When the CEO asks why an account got scored the way it did, you open a SQL file and answer in two minutes. When a packaged CDP scores it wrong, you open a support ticket.
The counter-argument, which is fair: this needs someone who writes SQL. If you have that person, build it. If you do not, and you cannot hire one, a packaged tool with support may genuinely be cheaper once you price the alternative properly. Be honest with yourself about which situation you are in.
What the composable shift changed
The category split in the last two years. Packaged CDPs like Segment store their own copy of your data. Composable ones like Hightouch read directly from your warehouse and never hold a second copy.
More than a quarter of CDPs now support a warehouse-centric architecture, and the composable vendors grew headcount roughly six times faster than the category average in the second half of 2025. That is not a fad. It reflects the fact that most companies already had a warehouse by the time they considered a CDP, and paying to duplicate data you already store is a hard sell.
For B2B specifically, composable also happens to fit better. Your account graph needs custom logic. Your ICP definition changes every two quarters. Your product's usage model is unique to you. All of that is easier to express as SQL against your own tables than as configuration inside somebody else's schema.
Where CDPs earn their money in B2B
I do not want to be unfair to the category. There are three situations where I have watched a CDP pay for itself.
Product-led SaaS with a big free tier. When 20,000 workspaces generate usage signals and 300 of them look like buying committees forming, you need something built for event volume. The scoring model that comes out of it, wired properly, is the difference between an SDR team guessing and an SDR team working a ranked list. The mechanics of that are in the PQL scoring guide.
Multi-brand or post-acquisition groups. Three CRMs, two marketing platforms, one board asking for group-level customer numbers. A CDP is often faster than consolidation, and consolidation can follow later.
Companies where paid media is the main channel. If you spend seven figures a year on ads and your suppression and lookalike audiences are built on stale CSV exports, the activation loop alone justifies the licence. Getting closed-won lists into ad platforms within hours rather than months changes what the spend does. That feeds straight into the attribution work as well.
Everyone else, in my experience, wanted three things: fewer duplicate accounts, a lead score they trusted, and one report the CEO stopped arguing with. None of those need a CDP. All of them need someone to sit down and define the account model properly, which is unglamorous and is the actual job. If you want that done, it is exactly what our CRM and RevOps work covers, and the automation side handles the sync layer around it.
The test I would apply
Write down the three decisions you want to make differently once the data is unified. Be specific. Not "better targeting." Something like: "route any account with two or more product-qualified users to an AE within one hour" or "suppress every open-opportunity account from acquisition ads."
Now ask whether each one is blocked by missing data or by missing definitions. In my experience it is definitions, roughly four times out of five. Nobody agreed what a product-qualified user is. Nobody decided which contact owns the account. The data was there the whole time.
If it really is missing data, and the volume is genuinely beyond what a CRM handles, and you have the technical owner, then buy the thing. Go in with the account-graph question ready and make them show you rather than tell you. If it is definitions, save the money and spend six weeks fixing the account model instead. That work is boring, it does not make a good board slide, and it is the one that changes the numbers.
Not sure whether you have a data problem or a definition problem?
Book a free 30-minute audit. We will look at your account object, count the duplicates, and tell you honestly whether a CDP would help or just cost you money.
Book an audit →FAQ
What is the difference between a CDP and a CRM?
A CRM is a system of record where people work: contacts, companies, deals, tasks, email history. A CDP is infrastructure that collects data from many sources, decides which records belong to the same person or account, and pushes segments out to other tools. Nobody logs into a CDP every morning. Reps live in the CRM daily. If your problem is that sales cannot see what they need, that is usually a CRM problem, not a missing CDP.
Does a B2B company need a CDP if it already has HubSpot or Salesforce?
Usually not. Modern CRMs handle contact and account data, engagement history, scoring and workflow activation on their own. A CDP starts to make sense when you have high-volume product event data that the CRM cannot hold economically, four or more activation destinations the CRM cannot reach, or several disconnected stacks across regions or business units. If none of those apply, better use of the same budget is fixing the CRM data model and adding reverse ETL for the one or two syncs you actually need.
How much does a customer data platform cost?
Licences run roughly $12,000 to $60,000 a year for an SMB and $200,000 to $500,000 or more at enterprise scale, before implementation and connector fees. Composable options are cheaper on licence: Hightouch paid plans start around $350 a month, though your warehouse compute is a separate line. Budget for implementation too, which is commonly 30% to 50% of first-year licence cost, and for the internal owner whose time it will take.
What is a composable CDP?
A composable CDP reads and writes directly from your existing data warehouse instead of storing its own copy of your data. Your warehouse holds the records, dbt or SQL handles the identity logic, and the CDP layer handles activation to downstream tools. It costs less, gives you full visibility into the matching rules, and suits B2B well because account graphs usually need custom logic. It does require someone in-house who can write SQL.
Why do CDP projects fail?
The most common cause is data readiness. Industry estimates put failure at 30% to 40% of projects, and the pattern is almost always the same: duplicate accounts, inconsistent field values, and no agreed definition of what an account or a qualified user is. A CDP resolves and distributes whatever you give it. Give it a mess and it distributes the mess faster. Clean the CRM and settle the definitions first, then evaluate whether you still need the platform. A fair number of teams discover they no longer do.