Let's face it, most composable CDP conversations are written for engineers, which makes sense, because engineers are the ones building the thing. The cost of that arrives later, and it arrives for the marketers who run the campaigns on top of the architecture, handed a finished system and told to make it work. I've written before about the inherited costs that creates. This piece is about the part that comes earlier, when the architecture is still a decision and not yet a fact.
The question a marketer should be able to ask in that room is plain. What are we responsible for now, and what happens to the things we used to count on the platform to do for us? In the sessions where I've watched it go unanswered, the answer wasn't bad. Nobody had asked the marketer into the conversation in the first place.
Composable is a plain idea in technical clothing. It means the CDP is assembled from separate tools you own and connect, a data warehouse plus the parts around it, instead of one packaged platform you buy whole.
Traditionally, the CDP is defined by four functions it bundles into a single product: it collects data, unifies it into one customer profile, segments that profile into audiences, and activates those audiences to your tools.
Composable removes none of that. It splits the four into separate modules, if preferred from separate vendors, and leaves part of the wiring to you. The functions are where the value sits, and the packaging is only a question of who holds each one. So the model is those same four functions, turned into questions about ownership once the architecture turns composable. If SQL and DAG don't ring a bell, don't worry, that's the engineers' end of the table and nothing here leans on it. This part fits in one sitting.
Matthew Niederberger
Data collection
The first area is collection. In a packaged CDP, you typically don't think much about what's being captured because the platform makes a lot of those decisions for you. The SDK picks up events. Attributes get stored. Defaults run on autopilot. In a composable setup, somebody is making those decisions explicitly. Probably the data team. Maybe with marketing input, maybe without.
The questions worth asking yourself is what events are being captured today, and who decided the schema, meaning the shape of the data being stored. Then a different question altogether: what's missing that you'd actually want for campaigns?
If the answer to the last one is "we'll add it later," that's a flag.
Composable architecture is great at giving you flexibility on data that's already flowing. Anything not collected today is a future change request, not a quick segment tweak.
Identity stitching
The second area is identity resolution. This is the one most marketers genuinely don't understand, and I have found myself in that camp before. The rules that say email_1@gmail.com and a particular cookie ID and a known mobile device ID all belong to the same person used to live inside the platform's identity graph. Black box, basically. With composable, those rules get written somewhere too. Often in the warehouse, sometimes in a specialised identity tool layered on top.
The marketer's question isn't how the rules work. It's where they live and who owns them. When a stitching rule breaks, who notices? When a segment behaves oddly because two profiles got merged that shouldn't have, who debugs it? The same ownership question reaches inside the profile. When two systems disagree about something like a customer's email opt-in status, which value wins, and is that rule written down anywhere? In packaged systems, the vendor sorts it. In composable systems, the work lands with your data team. Internal time, internal expertise. The cost goes somewhere, it doesn't disappear.
Matthew Niederberger
Segmentation
The third area is segmentation, the part of a CDP marketers actually put their hands on. In a packaged CDP this is the friendly surface: a builder where you assemble an audience by clicking conditions together, no engineer required. It is often the reason marketing wanted the CDP in the first place. In a composable setup that surface is not guaranteed. Segments might be defined in SQL in the warehouse, or in a separate audience tool layered on top, and the self-serve builder you were promised may or may not be part of what got assembled.
So the question is blunt. Can I build a segment myself, or do I file a ticket and wait? If audience creation routes through the data team, your campaign calendar now runs on their backlog. That is not automatically wrong, but it is a different operating model, and you want to know which one you are in before launch.
The second question is about trusting the numbers. When you run a segment count one day and a different count the next for what looks like the same logic, what changed underneath? In a packaged setup that inconsistency is a vendor conversation. In a composable setup it is a conversation with your own data team about how the models are versioned and refreshed. The segment didn't lie. Something under it changed, and in composable that something is yours to track down.
Activation to destinations
Fourth, activation. This is where the latency conversation actually matters for your day-to-day. Packaged CDPs typically advertise sub-second activation. Composable CDPs of the warehouse-native variety run on whatever the warehouse can produce, plus a reverse ETL layer, which is the piece that pushes audiences out of the warehouse and into your campaign tools. Often that's minutes to hours, not seconds.
For most marketing use cases, this is genuinely fine. A daily email send doesn't need real-time. An audience pushed to Meta for an ad campaign doesn't need real-time. Where it bites is the in-session personalisation use case, or the cart abandonment flow that needs to fire within minutes of the trigger event. Some destinations tolerate latency well. Some don't. Worth knowing which is which before you commit, because the workaround for slow activation usually involves a separate real-time path that lives outside the composable stack you just paid for.
The question to ask is a per-destination one. What latency does my email tool need versus my ad platform versus my web personalisation engine, and does this architecture deliver all of that, or only the destinations with longer tolerances?
What this changes for the marketer
Once these four areas are visible to you, the role of the marketer in an architecture decision becomes legible. You're operating the system, not building it. That's a different job and a valid one, but it comes with skin in the game. The trade-offs being made about latency, who gets to build an audience, and where the identity rules live are trade-offs you live with for the duration of that architecture.
Composable CDP is a good architecture for a marketing organization that wants more control, has the data team to run it, and is willing to absorb the operational responsibility that comes with the increased flexibility. It's a poor fit for a marketing organization that wants the vendor to keep doing the work and just send better campaigns. Both are valid positions. The mistake is making the choice without knowing which one you're making.
If you're sitting in the meeting where this decision is being made and you've not yet asked these four questions, you're being talked past. This is a vocabulary problem. The slides default to engineering language because engineering has been driving the conversation, and the marketing function has been treated as a downstream consumer rather than a participant.
The fix isn't complicated. Be in the room. Ask the four questions. If the answer to any of them is "we haven't figured that out yet," treat that as useful information, not a failure of competence.
The questions that aren't on the list
The four questions cover what a CDP does. They don't reach the part that changes when the single box comes apart, because the hard part of composable doesn't belong to any one function. It lives in the space between them, in the wiring a packaged CDP keeps out of view. Asking about that space tends to land well with the engineers, because it is the part they worry about most, and it marks you as someone who is paying attention rather than waiting to be handed a finished thing.
Start with the wiring itself. The data travelling from collection to identity to segmentation to activation is now real infrastructure, with schedules and failure modes, and it is the most common place things break. Who owns the connections between the tools, and what happens to my campaign when one of them fails overnight?
Then freshness, which is the one to ask loudest. In a packaged CDP, when the data stops flowing, the vendor usually tells you. In composable, a sync can fail silently and your morning audience is yesterday's data, or empty, with nothing to flag it. How would I know the data behind this segment is stale before I hit send?
Last, cost. A packaged CDP is a flat fee, so refreshing an audience is free at the point of use. Composable runs on warehouse compute and syncs that often bill by the row, so an audience rebuilt every hour has a meter running each time. Does this audience cost us money every time it refreshes, and who is watching that number?
One more question hovers just off the edge of marketing. When a customer opts out, that choice now has to reach every tool the data was copied into, not a single system. Worth raising in the room, even if it lands on someone else's desk to solve.
Ask these alongside the four, and you walk into the decision as someone who helped choose the system, not someone who got handed it.
If you want a starting point for the conversation in your own organization, the Martech Workshop is where I've put the framing that's worked in client rooms like ITV, Carfax, Faceland Clinics and more.
Use it before the architecture decision, not after.
Do you have any questions after reading this article?
Or need support with your Martech projects?
Discussion