Updated · 9 min read
CRM vs CDP: which tool do you actually need?
Ask three vendors what a CDP is and you'll get three answers. Ask what you need and you'll get three different product pitches. The category confusion is real — and it's expensive, because picking the wrong tool means either over-buying for capabilities you won't use or under-buying for needs you'll hit in six months. Here's the actual distinction between the categories and how to decide.
Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
The category definitions
CRM (Customer Relationship Management). Originally sales-tool software (Salesforce, HubSpot CRM, Pipedrive) tracking prospects, opportunities, and customer records. In consumer contexts, "CRM" often refers to the retention and lifecycle function broadly rather than a specific tool category.
CDP (Customer Data Platform). A centralised store of unified customer data, pulled from multiple sources (web analytics, product events, transactional systems), with the specific goal of serving that data to downstream tools for activation. Segment, mParticle, RudderStack, Tealium.
ESP (Email Service Provider). The system that sends emails (and usually push, SMS). Braze, Iterable, Klaviyo, Customer.io, Intercom. ESPs have their own segmentation, templating, and trigger capabilities; many modern ESPs are nearly CDP-like in their data model.
Marketing Automation. Overlapping with ESP, historically positioned at B2B (Marketo, Pardot). The feature set is ESP + form / landing-page tools + lead-scoring. The term is increasingly dated; most tools position as "ESP" or "marketing cloud".
The categories blur because vendors compete on feature overlap. A modern ESP has CDP-like data handling; a CDP has ESP-like activation; a B2B CRM has marketing automation. The question isn't "what's a CDP?", it's "what problem am I solving?".
What problem each category solves
| Category | Primary problem | When you need it |
|---|---|---|
| B2B CRM (Salesforce) | Tracking sales pipeline and account relationships | B2B, sales-led motion, pipeline revenue > $5M/year |
| CDP | Unifying customer data across many sources | Multiple data sources that need to talk to each other; more than 3 activation tools downstream |
| ESP / Marketing Cloud | Sending messages and triggering flows | Any program that sends email/push/SMS at scale |
| Data Warehouse + reverse ETL | The modern alternative to a CDP | Engineering-rich team that prefers to own the data model |
The question most lifecycle teams actually need to answer: "I have an ESP and I want to use my data warehouse data in it — do I need a CDP?". The answer is: sometimes, but less often than CDP vendors suggest.
The decision framework
Step 1: How many systems need the data? If just the ESP needs your user data for lifecycle messaging, you usually don't need a CDP — a direct pipe from data warehouse to ESP (via reverse ETL or native integration) is simpler. CDPs earn their cost when 4+ downstream tools (email, ads, web personalisation, support, analytics) all need the same unified user view.
Step 2: Where does data currently live? If clean, in a data warehouse (Snowflake, BigQuery), you're close to not needing a CDP. The warehouse is your single source of truth; CDP functionality becomes a reverse-ETL tool (Hightouch, Census). If your data is fragmented across product databases, marketing systems, and spreadsheets, a CDP's integration work earns its keep.
Step 3: What's the team's engineering capacity? Data warehouses + reverse ETL require SQL-capable marketing or data engineers. CDPs abstract that with GUIs and pre-built integrations. If your team has no SQL depth, a CDP is worth the premium. If you have strong data engineering, the warehouse path is usually cheaper and more flexible.
Step 4: What's your scale? CDPs are expensive — typically $50K–$500K+ annually. The cost is hard to justify below about $50M in revenue unless data fragmentation is an acute problem. Smaller programs often do better with a modern ESP (Braze, Customer.io, Klaviyo) that has 80% of CDP capabilities at 10% of the cost.
When to buy what
,
The ESP as an effective CDP-lite
Modern ESPs (Braze, Iterable, Klaviyo, Customer.io) have become surprisingly CDP-like. They accept events and user attributes, run real-time segmentation, compute derived attributes, and expose data for activation — most of what a pure CDP does.
For programs under ~$50M in revenue, the practical stack is often: data warehouse → reverse ETL → modern ESP. This covers 80%+ of CDP use cases without the CDP layer. The ESP acts as the operational data plane for lifecycle; the warehouse is the analytical data plane.
This is a significant shift from 5 years ago, when a CDP was the obvious right answer for unified customer data. The blurring has made the category question genuinely harder — and the right answer more often "modern ESP + warehouse" than "add a CDP".
The ESP comparison guide covers the data-capability differences across major ESPs.
Avoiding the category trap
The biggest mistake is buying a category rather than solving a problem. "We need a CDP" should be "we have a specific data-unification problem across X, Y, Z systems that costs us time in these specific ways". If you can't name the problem concretely, you're probably not ready for the tool.
Second biggest mistake: buying the most expensive option in each category because it feels safest. Salesforce, Segment, Braze stacked together costs $500K+/year before implementation and often delivers less than a well-picked $100K stack for programs that don't need every feature. Match the tool to the problem, not the brand to the budget.
covers the tool-selection question as part of the program architecture phase — the stack follows the program requirements, not the other way around.
Frequently asked questions
- I have Braze. Do I need a CDP?
- Probably not immediately. Braze has strong CDP-like capabilities — event ingestion, real-time segmentation, custom attributes. If your data is clean in a warehouse and you can sync it to Braze via a reverse ETL tool, you likely don't need a separate CDP unless you have 4+ downstream tools that need the same unified data.
- What's the difference between a CDP and a reverse ETL tool?
- A CDP is a data platform — it stores, transforms, and activates data, often with its own data model. A reverse ETL tool (Hightouch, Census) reads from an existing data warehouse and syncs to downstream tools, without storing data itself. If you have a warehouse, reverse ETL is simpler and cheaper; if you don't, a CDP gives you the warehouse-ish layer and activation together.
- Can HubSpot do everything?
- For B2B at small to mid scale, roughly yes — it's CRM + ESP + Marketing Automation + light CDP in one. The consolidation has real value (one vendor, one data model). The trade-off: each individual function is typically less powerful than a specialist tool. Teams often start with HubSpot all-in-one and graduate specific functions (usually ESP first) to dedicated tools as they scale.
- What about Salesforce Marketing Cloud?
- A specific product (separate from Salesforce CRM) that competes with ESPs and marketing automation. Historically powerful but complex; increasingly losing share to modern ESPs (Braze, Iterable) that have cleaner data models. Often paired with Salesforce CRM for B2B enterprise; rare to see as a standalone choice in 2026.
- I'm a small program — what's the minimum viable stack?
- Modern ESP (Klaviyo or Customer.io, $200–$2K/month depending on list size) + a product analytics tool (Mixpanel, Amplitude, or Heap, from free up to $2K/month) + email-capable form tools. No CDP, no warehouse, no CRM unless you have B2B sales motion. This stack handles lifecycle for most programs up to ~$10M revenue.
- What signals I've outgrown my current stack?
- Integration work blocks projects (every new campaign requires engineering). Data inconsistency across tools (a user's status differs between email and product). Can't answer a basic question about a user without joining three systems manually. When multiple of these hit, you have a stack problem — not an individual tool problem — and the next investment is usually a data warehouse + reverse ETL rather than replacing the ESP.
Related guides
Browse all →Building a lifecycle team: the roles, the order, the size
Lifecycle marketing is a craft, an ops function, and a strategic lever all at once — so it's hard to staff. Here's the progression: which role to hire first, when to add the next one, and how to know if you need a CRM manager, a lifecycle strategist, or a marketing ops engineer.
B2B lifecycle marketing: what changes when the buyer isn't the user
B2B lifecycle looks like B2C on the surface — emails, flows, segmentation — but the mechanics underneath are different. Buying committees, account-level intent, sales hand-offs, and product-led overlaps all change the playbook. Here's what's actually different.
The lifecycle metrics dashboard: what to track, what to ignore
Most lifecycle dashboards show 40 metrics and answer no questions. A good one shows 8 and tells you what to do next. Here's the eight-metric dashboard that actually runs a lifecycle program.
The monthly newsletter still works — here's the structure
Email newsletters have been declared dead every year since 2015. They're not. A well-run monthly newsletter does real work for a lifecycle program — brand equity, re-engagement, non-promotional relationship. Here's what separates the ones that work from the ones that feel mandatory.
Quarterly planning for lifecycle: what actually goes in the plan
Most lifecycle roadmaps are calendar lists of campaigns. A good quarterly plan is different — it's a set of priorities tied to the metrics you want to move, with tests, investments, and explicit trade-offs. Here's the format that produces decisions, not lists.
Lifecycle for startups: the three flows to build before anything else
Early-stage programs waste months building the wrong lifecycle flows. Here are the three that compound value at every stage — welcome, trial-to-paid (or first-repeat), and winback — and why everything else can wait.
Found this useful? Share it with your team.