Reasons behind the trend & why Brands should look for a Capability instead of Software
“There’s no such thing as a composable CDP”—you hear industry specialists exclaim. Yet many vendor RFPs and creds decks will reference the term. And to add to the injury, some of the packaged or “buy” CDPs have now started adding “composable” elements to their proposition.
Whether you believe it’s an actual platform type or it’s just a marketing ploy (in which case, one must admit, it’s a brilliant one—the term “composable” gets ~4x more searches on Google than Hightouch or Rudderstack—according to Google Trends, US, last 5 years); the term has gained traction and when everyone in MarTech has heard of it, it makes sense to include it in the Dictionary.
You can’t really talk composable CDPs and not mention Hightouch—and their blog on the subject covers the main principles & background, albeit also suggesting the simplicity of the solution & portraying packaged CDPs as a black box—both points you can debate at length.
In a nutshell, Composable CDP will sit on your Data Warehouse – so you are not duplicating your data. Packaged CDPs will create & store a copy of your data. Note a crucial difference: composable CDP should still be a CDP.
As Tejas Manohar himself pointed out, the composable topic got hot and out of hand rather quickly—sit on the CDP institute’s slack channel for a fortnight and you will see at least one company ask if they are now a CDP. The answer is always the same—unless you offer the baseline functionalities, you’re not.
David Raab has suggested a term “Warehouse CDP” in his latest blog to differentiate and this is already being used by some vendors, however it will take some time & effort for this to become mainstream.
In the meantime. the industry confusion continues, especially when some of the packaged CDPs are starting to join in.
“If you can’t fight them, join them” – seems to have been the motto this summer with modular components being introduced by packaged vendors who have been pure “Buy” players to date. Not talking platforms who have historically offered a modular approach, but rather new features being brought out as an optional extra.
Does this make you “Composable”? – well if you go by the differentiation of Data Warehouse vs Data Copy & Storage – it does not. What is rather concerning is that the “Composable” element seems to have given permission to charge extra for modules that otherwise would have been included as part of the standard platform innovation.
Perhaps instead of arguing the composable part, the industry should define what it is and draw a line between being a Composable (aka DW CDP) vs a Component.
Perhaps this is also where the initial fallacy was – we have largely overlooked the part where you form a Composable CDP by adding 1 piece of software on top of a DW. That should be clearly separated from having a modular stack or a {Composable} MarTech Infrastructure that, in combination, creates a CDP Capability for a business – thus moving you closer to a “Build” approach.
Note the differentiation between Software & Capability. If you will be adding 4-5 different pieces of kit to create a CDP, that’s a Stack, not a Composable CDP. And if you can only deliver 1/5 of the functionality required – you’re a Component, not a Composable.
That is not to say it’s the wrong approach – selecting the absolute best specialist platforms in the market and forming state of the art MarTech Stack is a formidable feat and for those of us, with the budget, tech resources and a legitimate business case, that could be the best way forward.
And if you go down that route, you are very likely to build a CDP Capability – even if you do not buy the software. That doesn’t make your approach Composable (unless you’ve used a DW CDP), but the output mimics what a CDP would do. That’s not a traditional “Build”, “Buy” or “Compose” – it’s a CDP Capability – delivered through a combination of platforms, processes and teams.
And perhaps that’s a way to approach with the business – “you need to be able to do this, because it will deliver this value outcome”. How you’ll go about it and what forms your specific kit is then specific to your situation & your goals. Thinking capability vs piece of software enables a broader discussion, spanning cross-functions – which incidentally what CDP does.
Approaching it as a needed capability from the business POV has another benefit – you outline your requirements first. This way, if i.e. you have a strong Snowflake setup and an established customer 360, you will naturally go down the Composable/DW CDP route. And if your priority is real-time Marketing activation – you’ll pick a true real-time CDP.
One should note that cost-savings when approaching the Composable CDP from a capability point of view, might dwindle once you add the Snowflake cost. On the upside, your when shopping for real-time, you will automatically discount any vendors that might charge you extra for real-time as a “composable/ modular” piece – if it’s a core proposition, it should sit within the core licence fee.
Whether you’re a supporter or sceptic – Composable concept cannot be ignored. Classifying CDPs into DW vs Packaged and drawing a clear equation between Composable = DW CDP would reduce the confusion. And perhaps that should be enough - Analytics, ID Resolution, ServerSide Tracking, MA, CRM, Personalisation, Journey Orchestration tools do not equal CDP. But you can build a CDP Capability for your business by adding some of them (and more) if you wish.
It will not be a composable CDP, or not even a CDP in conventional terms, but you’ll be able to deliver to your business goals. How effectively, is a conversation for another day.
Get in touch if you would like to know more.
Caveat: Loop Horizon are a platform agnostic consultancy—we work with packaged as well as composable solutions and we believe ultimately the best solution is the one that fits the business’ MarTech & data ecosystem, operational setup & strategic goals best.