The CDP connector myth

At a recent CDP demo I attended, a nervous client asked the vendor if they had a connector to Salesforce Sales Cloud. The vendor replied affirmatively, and the client breathed a sigh of relief. But the truth is — most customer data plaftorm (CDP) vendors have disappointing packaged connectors. Read on for why that is and what you can do about it.

A bit of history: The enterprise ‘portlets’ race

This encounter reminded me of the “enterprise portal” era. Please indulge me while I look back to the late 2000s and early 2010s — a time most customers and vendors would care to forget but that still carries lessons today. 

Enterprise portals were supposed to provide a single, convenient interface into a potentially broad array of enterprise applications, displayed as separate blocks on a screen in a dashboard motif. The technology underpinning those individual blocks went by many names, but for now, let’s call them “portlets.” 

It quickly became clear that portal programs were fundamentally highly complex integration projects, so enterprises naturally sought to leverage pre-fab connector code. Vendors responded with portlet catalogs, and an arms race ensued. “We have 250 portlets,” a vendor would brag.

These portlets would vary dramatically in provenance, support, usability, performance, security and (crucially) technical underpinnings. A “portlet” was typically a reference instance of some Java or C# code somebody wrote for a single client implementation. More often than not, the code needed to be overhauled, sometimes from scratch. 

Vendors retorted — not unfairly — that problems often originated in how remote systems were configured rather than with the portal platform itself. Maybe so, but enterprises eventually got jaded about portlets. Amid other technology and business changes in the digital world, portal platform technology gradually fell out of fashion.

The new CDP connector race

Fast forward to today, and the world is coming to understand CDPs as integration environments (among other things). Every CDP selection team we work with strives to find vendors with pre-built connectors to match up against their incumbent platforms. Yet, nearly every CDP implementation finds expensive developers significantly modifying or rewriting those connectors.

CDP vendors are seemingly succumbing to the pressures their portal brethren endured. If customers value a diverse catalog of connectors, then as a CDP vendor, you must display many of them, ready or not. In CDP demos, connectors appear on the screen as neat blocks (with the connected platform logo appearing prominently) that you can drag around — almost like portlets! 

Well, not so fast. Like portlets, CDP vendor connectors may result simply from the output of a single implementation. More importantly, in some cases, a single connector cannot possibly address the complexity of the martech platform on the other end. 

Consider Salesforce Sales Cloud, mentioned above. The platform suffers from an problematic object model that most licensees contort or heavily extend. It can be like connecting to a very angry octopus. And Salesforce is by no means alone here. In such situations, a CDP vendor’s connector can only provide the basic scaffolding and leave the rest up to a developer. 

Is the enemy us?

Portals died out for another reason. If eyes are windows to the soul, portals were windows into enterprise intestines. A portal was only as useful as the underlying applications. Often, those applications were messy, lacked common content and metadata models, employed diverse access control regimes, exhibited different UX models and sometimes exposed low-quality data. 

At my company, we see a similar phenomenon with CDPs. Depending on how you scope a CDP effort (and different patterns are emerging here), the CDP may expose the immaturity of your broader customer data management regime — all the more reason to match any prospective CDP to your broader data architecture. 

Dig deeper: How to ID and organize data with a new CDP

Watch out for CDP vendors claiming to have diverse connector catalogs

As always, forewarned is forearmed. First, reconsider overweighting a vendor who claims to have connector catalogs that match up well against your stack. Among other reasons, simply moving CSV files around can solve many (non-real-time) use cases. When you need packaged connectors, specific integration experience becomes useful but doesn’t inherently hedge against substantial development in your future. The key is to find out how much development.

Hopefully, you’re following an agile CDP selection process that concludes with a competitive bake-off and a more technical proof of concept (PoC) with one or two finalists. A PoC is a great environment to test a few essential connectors. You’ll then come to understand the level of effort to overhaul where necessary — and that could be often.

Like their portal vendor predecessors, CDP vendors will promise “quick start” packages to accelerate an initial implementation. Don’t believe it. Once again, some delays may stem from the time you’ll need to get your own data house in order, but also, I can guarantee you that someone will be doing connector development, and this work gets measured in quarters, not months. Budget your resources accordingly.