# Customer data platforms for SaaS marketing

> Whether a SaaS team needs a CDP at all, what Segment class tooling costs at real event volumes, and the warehouse setup that replaces it for less.

Source: https://saas-marketing.net/guides/customer-data-platform-for-saas/
Topic: SaaS Marketing Tools
Type: guide
Published: 2026-09-11
Last updated: 2026-09-11
Publisher: SaaS Marketing (saas-marketing.net)
License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/guides/customer-data-platform-for-saas/

## Short answer

A CDP does three jobs: event collection, identity resolution and activation to downstream tools. Most SaaS companies under 10M ARR buy one to solve a tracking plan problem that a tracking plan would have solved. Packaged CDPs like Segment price on monthly tracked users or events and get expensive past 10M events a month. The composable alternative pipes events into Snowflake or BigQuery and activates with Hightouch or Census, usually for less at volume but with engineering time to maintain.

## Key takeaways

- Write the tracking plan before buying anything, because a CDP without one produces expensive, inconsistent data.
- A CDP earns its cost when a second activation destination needs the same identity graph, not before.
- Packaged CDP pricing scales with volume, so the cost curve bends sharply somewhere between 10M and 100M monthly events.
- The composable route shifts spend from licence fees to warehouse compute and engineering time, which is cheaper at volume.
- Identity stitching from anonymous to trial to paid account is the job most SaaS teams actually need solved.
- The worst outcome is three tools each holding a different version of the truth with no agreed source.

---

Most CDP purchases start the same way. Someone asks why the signup number in the product analytics tool does not match the number in the CRM, three people spend a week failing to reconcile them, and the conclusion is that the company needs a customer data platform.

The actual problem was that nobody had written down what a signup event is. That is a tracking plan problem, and a CDP will happily collect inconsistent events at scale.

## The three jobs a CDP does, and which you already have

A customer data platform does collection, identity resolution and activation. Separate them, because you probably already own one or two.

**Collection** is capturing events from your web app, product, server and mobile clients in a consistent schema. If you have a product analytics tool with a working SDK, you have partial collection already, just locked into one destination.

**Identity resolution** is stitching an anonymous visitor to a user to an account across sessions and devices. This is the job most SaaS teams genuinely need and least often have. It is also the hardest to build yourself.

**Activation** is pushing that resolved data into the tools that act on it: lifecycle email, in app messaging, the CRM, ad platforms. If you have one destination, a direct integration handles it. If you have five, you are maintaining five integrations that will drift.

Count your activation destinations that need user-level data. One or two, and you do not need a CDP. Five or more, and the integration maintenance cost alone probably justifies one, whether packaged or composable.

## Write the tracking plan first, and here is what it contains

This is the cheapest work in the whole exercise and the part that gets skipped. A tracking plan is a document listing every event you collect, its exact name, its properties, their types, and who owns the definition.

Without it, three teams instrument three variations of the same action and your CDP faithfully collects all three. Then you pay to store and route data you cannot trust.

**A minimum viable tracking plan**

Two days of work. It will resolve most of the reporting disagreements that triggered the CDP conversation, and it makes every subsequent tooling decision easier because you know what you are moving.

## What this costs at 1M, 10M and 100M monthly events

Pricing for this category changes and is heavily negotiated, so treat the table as the shape of the curve rather than a quote. The point is where the curve bends.

The row people ignore is the last one. A composable stack is cheaper in licence fees and more expensive in attention. If your engineering team has no capacity to own a pipeline, the composable route is not cheaper, it is just a cost recorded somewhere other than the marketing budget.

**0.25 to 0.5 FTE** Ongoing engineering ownership a composable customer data stack typically requires

My position: write the tracking plan first, buy the CDP only when a second activation destination needs the same identity graph. Until then you are paying a platform fee to solve a documentation problem.

## The composable route in practice

The shape is straightforward. An event pipeline collects and forwards to your warehouse. Snowflake or BigQuery stores raw events and your modelled tables. dbt or equivalent builds the customer and account models, including the identity graph. Hightouch or Census reads those models and syncs to Intercom, Salesforce, the ad platforms and your lifecycle tool.

What you gain is that the warehouse becomes the single agreed definition. When marketing and finance disagree about a number, there is one table to look at. That is a bigger benefit than the cost saving and it is the reason to choose this route even when the money is a wash.

What you lose is packaging. Nobody in the vendor's support team owns your identity logic. Schema changes break syncs. Somebody has to care about warehouse compute cost, which can surprise a team that has never watched it.

RudderStack sits between the two models: warehouse-first architecture with a packaged product on top, which suits teams that want the warehouse as the source of truth without building the pipeline themselves. The [warehouse native marketing stack](/guides/warehouse-native-marketing-stack/) covers the full setup in detail.

## Identity stitching from anonymous to trial to paid

This is the part worth paying for, packaged or not, and it is where SaaS differs from ecommerce badly enough that generic CDP advice misleads.

The typical B2B journey has at least three identity breaks. An anonymous visitor reads three comparison pages over two weeks on two devices. Someone at the same company signs up for a trial with a work email. A third person, often in finance, becomes the billing contact. All three belong to one account and none of them share an identifier by default.

The resolution logic has to work at the account level, usually via email domain, and it has to be written down because it is full of judgement calls. Free email domains break domain matching. Agencies and consultancies produce false positives where several real customers share one domain. Enterprise accounts with subsidiaries produce the reverse problem.

Matching on email domain works until you acquire a customer whose team uses Gmail, or until a consultancy signs up on behalf of four clients. Write the exception rules before you build the graph, and keep a manual override table. Every company I have seen skip this ends up with one account that contains 400 unrelated users.

Decide what you do with anonymous history at the point of signup. Retroactively attributing two weeks of pre-signup page views to the new account is enormously useful for content attribution and it is a specific implementation choice that neither packaged nor composable tools make for you.

## The failure mode: three tools, three truths

The worst outcome is not an expensive CDP. It is a CDP plus a product analytics tool plus a CRM, each holding a different customer record, with no agreement about which one is right.

It happens because each tool was bought by a different team to answer a different question, and each one defines the customer slightly differently. Product counts users. Sales counts accounts. Marketing counts contacts. All three are correct within their own tool and none of them reconcile.

The fix is governance, not tooling. Name the system of record for each object: account, user, subscription, opportunity. Write it in one paragraph. Then make every downstream tool read from that source rather than maintaining its own definition. The [martech stack audit template](/templates/martech-stack-audit-template/) walks through the inventory, and the [martech cost per customer calculator](/calculators/martech-stack-cost-per-customer/) will show you what the duplication is costing.

| Object | Typical system of record | Common wrong answer |
|---|---|---|
| Account | Billing system or warehouse | CRM, which contains unconverted prospects |
| User | Product database | Marketing automation contact list |
| Subscription and plan | Billing system | CRM opportunity amount |
| Marketing consent | Marketing automation | Whichever tool sent the last email |
| Product usage | Warehouse or product analytics | The CDP, which only has what you sent it |

## When to buy packaged anyway

There are three situations where I would buy Segment or an equivalent without hesitation, even at sub 10M ARR.

You have no data engineering capacity and no prospect of getting any. You are running a mobile app alongside web, where SDK maintenance across platforms is genuinely painful. Or you have a compliance requirement around consent and data deletion that a packaged vendor already handles, because building GDPR deletion propagation across a composable stack yourself is unpleasant work with real legal exposure.

Outside those cases, at early stage, the honest answer is usually a tracking plan, a direct integration to your one real destination, and the money spent elsewhere. [Free and near free SaaS marketing tools](/guides/free-saas-marketing-tools/) covers what you can do without the platform fee.

## What to do next

Count your activation destinations and write your tracking plan. Those two steps take under a week and they determine whether you have a tooling problem at all.

If you do need to buy, model the cost at your event volume for both routes including engineering time, then decide. Background on the category sits in [customer data platform (CDP)](/glossary/customer-data-platform/) and the surrounding purchases in [the SaaS marketing stack](/saas-marketing-tools/). The architectural question underneath this one is covered in [all in one or best of breed](/comparisons/all-in-one-vs-best-of-breed-martech/), and the tools that sit downstream of a resolved identity graph are in [marketing automation for SaaS companies](/guides/marketing-automation-for-saas/) and [the customer marketing and advocacy stack](/guides/customer-marketing-and-advocacy-tools/).

## Frequently asked questions

### Does a SaaS startup need a customer data platform?

Usually not before 10M ARR. If you have one activation destination and one analytics tool, a well-written tracking plan and a direct integration do the same job for nothing. A CDP earns its cost when several tools need the same identity graph and you are otherwise maintaining three separate integrations that disagree with each other.

### How much does Segment cost for a SaaS company?

Segment prices on monthly tracked users or API calls depending on plan, with free and team tiers for small volumes and negotiated business contracts above that. At around 1M monthly events most teams sit in the low hundreds to low thousands per month. At 100M events, annual contracts commonly reach six figures, which is the point where composable alternatives usually win on cost.

### What is a composable CDP?

A composable CDP assembles the same three jobs from separate parts: an event pipeline, your existing data warehouse such as Snowflake or BigQuery as the storage and identity layer, and a reverse ETL tool like Hightouch or Census to activate data into marketing and sales tools. You trade licence cost and packaging for engineering ownership and flexibility.

### What are the best Segment alternatives for SaaS?

RudderStack is the closest like-for-like with warehouse-first architecture and often lower cost at volume. Jitsu and self-hosted RudderStack suit teams comfortable running infrastructure. For activation specifically, Hightouch and Census sit on top of the warehouse you already have. The right choice depends on whether you have engineering capacity to own a pipeline.

### What is identity resolution and why does it matter for SaaS?

It is the process of stitching an anonymous website visitor to a trial signup and then to a paid account, so the whole journey belongs to one record. For SaaS it matters because the buyer, the signup and the billing contact are frequently three different people at the same company. Without account-level resolution, your conversion reporting is wrong in a way that flatters paid channels.

### Can our data warehouse replace a CDP?

It can replace the storage and identity layer, which is most of the value. It cannot collect events on its own, so you still need a pipeline, and it cannot push data to Intercom or Salesforce without a reverse ETL tool. That combination is what people mean by composable, and it typically costs less at high volume but needs someone to own it.