Customer data platforms for SaaS marketing

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.

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.

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.

Monthly events	Packaged CDP	Composable setup	Notes
1M	Free to low hundreds	Warehouse cost plus reverse ETL entry tier	Packaged usually wins on total effort
10M	Low to mid thousands	Warehouse compute plus mid tier reverse ETL	Roughly the crossover zone
100M	Often five to six figures annually	Warehouse compute plus higher reverse ETL tier	Composable usually wins on cost
Engineering time	Low, mostly configuration	0.25 to 0.5 FTE ongoing	The hidden cost in the composable column

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.

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 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.

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 walks through the inventory, and the martech cost per customer calculator will show you what the duplication is costing.

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 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) and the surrounding purchases in the SaaS marketing stack. The architectural question underneath this one is covered in all in one or best of breed, and the tools that sit downstream of a resolved identity graph are in marketing automation for SaaS companies and the customer marketing and advocacy stack.