Why Are There So Many Types of Customer Data Platforms? It's Complicated.

I spend much of my time these days trying to explain Customer Data Platforms to people who suspect a CDP could help them but lack clear understanding of exactly what a CDP can do. At the end of our encounter they’re often frustrated: a simple definition of CDP still eludes them. The fundamental reason is that CDPs are not simple: the industry has rapidly evolved numerous subspecies of CDPs that are as different from each other as the different kinds of dinosaurs. Just as the popular understanding of dinosaurs – big, cold-blooded and extinct – has little to do with the scientific definition, a meaningful understanding of CDPs often has little to do with what people initially expect.

Let’s start with the big picture. I’ve for years divided customer management systems into three broad categories, which are best seen as layers in a unified architecture. Frequent readers of this blog can feel free to recite them along with me (throwing rice at the screen is optional): data, decisions, and delivery.

Refining this notion just a bit:, the data layer includes systems that create customer data and systems that store it in a unified customer database. Decision systems include several categories such as marketing planning and content management, but the most relevant here are analytics, including segmentation and predictive models, and personalization*, which selects the best message for each individual. The delivery layer holds both systems that send outbound messages such as email and advertising and interactive systems such as Web sites and call centers. An important point is it’s hard to do a good job of delivering messages, so delivery systems are large, complex products.  Picking the right message is just one of many features and often developers’ main concern.

A complete architecture has entries in each of these five categories. But many companies have multiple source and delivery systems that are disconnected: these are the infamous silos. The core technology challenge facing today’s marketers can be viewed as connecting these silos by adding the customer database, analytics, and personalization components that sit in between.

By definition, the CDP fills the Customer Database gap. Some CDPs do only that – I will uncreatively label them as “Data CDPs”.

I’ll also take a slight detour to remind you that the customer database must be persistent – that is, it has to copy data from other systems and store it. This is necessary to track customers over time, since the source systems often don’t retain old identifiers (such as a previous mailing or email address) or, if they do keep them, don’t retain linkages between old identifiers and new ones. There’s also lots of other data that source systems discard once they have no immediate need for it, such as location, loyalty status or life-to-date purchases at the time of a transaction. Marketing and analytical systems may need these and it’s often not possible or practical to reconstruct them from what the source systems retained.  This is especially true in situations where the data must be accessed instantly to support real time processes.

But I digress. Back to our Data CDP, which obviously leaves the additional gaps of analytics and personalization. Why wouldn’t a CDP fill those as well? One answer is that some CDPs do fill them: we’ll label CDPs with a customer database plus customer analytics as “Analytics CDPs” and those with a customer Database, analytics, and personalization as “Personalization CDPs”, again winning no prizes for creativity.  A second answer is that some companies already have chosen tools they want for analytics or personalization.  Like message delivery, those are complicated tasks that can easily be the sole focus of a “best of breed” product or products.

This variety of CDPs also addresses another question that some find perplexing: why one company might purchase more than one CDP.  As you’d expect, different CDPs are better at some things than others. In particular, some systems are especially good at database building while others are good at analytics or personalization.  It often depends on the origins of the product.  The result is that a company might buy one CDP for its database features and have it send a unified feed into a second CDP for analytics and/or personalization. There are some extra cost and effort involved but in some situations they're worth it.

Are you still with me?  I’ve presented three different types of CDPs but hope the differences in what they do and which you’d want are fairly clear.**  Now comes the advanced course: other systems that either call themselves CDPs or offer CDP alternatives.

These fall into many categories but can all be mapped to the same set of five capabilities. Let’s start with Marketing Suites, by which I mean delivery systems that have expanded backwards to include a customer database, analytics and personalization. Many email vendors have done this and it’s increasingly common among Web personalization and mobile app marketing products.   In most cases, these vendors now deliver across multiple channels. Adobe Experience Cloud also fits in here. 

To qualify as a CDP, these systems would need to ingest data from all sources, maintain full input detail, and share the results with other systems. Many don’t, some do. We could easily add another CDP category to cover them – “Marketing Suite CDP” would work just fine. But this probably stretches the definition of CDP past the breaking point. For CDP to have any meaning, it must describe a system whose primary purpose is to build a persistent, sharable customer database. The primary purpose of delivery systems is delivery, something that’s hard to do well and will remain the primary focus of vendors who do it. So rather than over-extend the definition of CDP, let’s think of these as systems that include a customer database as one of their features.


We also have some easier cases to consider, which are systems that provide customer analytics and personalization but don’t build a unified customer database. Some of these also provide delivery functions – examples include marketing automation, CRM, and ecommerce platforms. Others don’t do delivery; we can label them as Orchestration. In both cases, the lack of a unified, sharable customer database makes it clear that they’re not CDPs.  Complementing them with a CDP is an obvious option. So not much confusion there, at least.

Finally, we come to the Customer Experience Clouds: collections of systems that promise a complete set of customer-facing systems. Oracle and Salesforce are high on this list. Both of those vendors have recently introduced solutions (CX Unity and Customer 360) that are positioned as providing a unified customer view. It’s clear that Salesforce does this by accessing source data in real time, rather than creating a unified, persistent database. Oracle has been vague on the details but it looks like they take a similar approach. In other words, the reality for those systems shows a gap where the persistent customer database should be. Again, this makes CDPs an excellent complement, although the vendors might disagree.

So, there you have it. I won’t claim the answers are simple but do hope they’re a little more clear. All CDPs build a unified, persistent, sharable customer database. Some add analytics and personalization.  If they extend to delivery, they're not a CDP.  Systems that aren’t CDPs may also build a customer database but you have to look closely to ensure it’s unified, persistent and shareable. Often a CDP will complement other systems; in some cases, it might replace them.

Still disappointed?  I am genuinely sorry.  But if it helps bear this in mind: while simple answers are nice, correct answers—which in this case means getting a solution that fits your needs – are what matter most.




_______________________________________________
*I usually call this ‘engagement’ but think ‘personalization’ will be easier to understand in today’s context. For the record, I’m specifically referring here to selecting the best message on an individual-by-individual basis, which isn’t necessarily implied by ‘personalization’.

**If you want to know which CDP vendors fit into each category, the CDP Institute’s free Vendor Comparison report covers these and other differentiators. Products without automated predictive modeling can be considered Data CDPs; those having automated predictive but lacking multi-step campaigns could be considered Analytics CDPs; those with multi-step campaigns could be considered Personalization CDPs. There are many other nuances that could be relevant to your particular situation: the report lists 27 differentiators in all.

Salesforce Buys MuleSoft and Offers It as a Data Unification Solutions

The Customer Data Platform industry is doing very well, thank you, with new reports out recently from both Gartner  and Forrester  and the CDP Institute launching its European branch.  But the great question hovering over the industry has been why the giant marketing cloud vendors haven’t brought out their own products and what will happen when they do. Oracle sometimes acts as if their BlueKai Data Management Platform fills the CDP role, while Adobe has made clear they don’t intend to do more than create a shared ID that can link data stored in its separate marketing applications. Salesforce has generally claimed its Marketing Cloud product (formerly ExactTarget) is a CDP, a claim that anyone with experience using the Marketing Cloud finds laughable.

The flaws in all these approaches have been so obvious that the question among people who understand the issues has been why the companies haven’t addressed them: after all, the problems must be as obvious to their product strategists as everyone else and the attention gained by CDP makes the gaps in their product offerings even more glaring. My general conclusion has been that the effort needed to rework the existing components of their clouds is too great for the vendors to consider. Remember that the big cloud vendors built their suites by purchasing separate products.  The effort to rebuild those products would be massive and would discard technology those companies spent many billions of dollars to acquire. So rationalization of their existing architectures, along with some strategic obfuscation of their weaknesses, seems the lesser evil.

We got a slightly clearer answer to the question on Tuesday when Salesforce announced a $6.5 billion purchase of Mulesoft, a data integration vendor that provides connectors between separate systems. In essence, Salesforce has adopted the Adobe approach of not pulling all customer data into a single repository, but rather connecting data that sits in its system of origin. In Salesforce’s own words, “MuleSoft will power the new Salesforce Integration Cloud, which will enable all enterprises to surface any data—regardless of where it resides—to drive deep and intelligent customer experiences throughout a personalized 1:1 journey.”

This is a distinct contrast with the CDP approach, which is to load data from source systems into a separate, unified, persistent database. The separate database has some disadvantages – in particular, it can involve replicating a lot of data – but it also has major benefits. These include storing history that may be lost in source systems, using that history to build derived data elements such as trends and aggregates, and formatting the data in ways that optimized for quick access by marketing systems and other customer-focused applications.

Although the difference between these two approaches is clear, some practical compromises can narrow the distance between them. Most CDPs can access external data in place, reducing the amount of data to be moved and allowing the system to use current versions of highly volatile information such as weather, stock prices, or product inventories. Conversely, a system like Mulesoft can push data into a persistent database as easily as it can push it to any other destination, so it can build some version of a persistent database. In fact, many CDPs that started out as tag managers have taken this approach.

But pushing data into a persistent database isn’t enough. Mulesoft and similar products work with well-defined inputs and outputs, while CDPs often can accept and store data that hasn’t been mapped to a specific schema. Even more important, I’m unaware of any meaningful ability in Mulesoft to unify customer identities, even using relatively basic approaches such as identity stitching. It’s possible to build workarounds, such as calls to external identity management systems or custom-built matching processes. Again, these are solutions employed by some CDP vendors that also lack advanced identity management. But such solutions can be costly, complex, and incomplete. From a buyer’s perspective, they are compromises at best. No one – except a salesperson – would argue they’re the ideal approach.

In short, Salesforce’s purchase of Mulesoft offers a partial solution to the needs that have driven the growth of CDPs. It’s probably the best that Salesforce could do without making the impractical investment needed to rebuild its existing marketing cloud components.  Get ready for a lot more confusion about the best way to build unified customer data. To avoid getting distracted, focus on what marketers really need and let that, not theory or vendor hype, drive your evaluation of the alternatives.

Cheetah Digital Debuts in Las Vegas

I spent the latter part of last week still in Las Vegas, switching to the client conference for Cheetah Digital, the newly-renamed spinoff of Experian’s Cross Channel Marketing division. Mercifully, this was at a relatively humane venue, the big advantage being I could get from my hotel room to the conference sessions without walking through the casino floor or a massive shopping mall. But it was still definitely Vegas.

The conference offered a mix of continuity and change. Nearly every client and employee I met had been with Cheetah / Experian for at least several years, so there was a definite feeling of old friends reconnecting. Less pleasantly, Cheetah’s systems have also been largely unchanged for years, something that company leaders could admit openly since they are now free to make new investments. Change was provided by the company’s new name and ownership: the main investor is now Vector Capital, whose other prominent martech investments include Sizmek, Emarsys, and Meltwater. There’s also some participation from ExactTarget co-founder Peter McCormick and Experian itself, which retained 25% ownership. The Cheetah Digital name reflects the company’s origins as CheetahMail, which Experian bought in 2004 and later renamed, although many people never stopped calling it Cheetah.

Looking ahead, newly-named Cheetah CEO Sameer Kazi, another ExactTarget veteran, said the company’s immediate priorities are to consolidate and modernize its technology. In particular, they want to move all clients from the original CheetahMail platform to Marketing Suite, which was launched in 2014. Marketing Suite is based on the Conversen, a cross-channel messaging system that Experian acquired in 2012. Kazi said about one third of the company’s revenue already comes from Marketing Suite and that the migration from the old platform will take four or five years to complete.

Longer term, Kazi said Cheetah’s goal is to become the world’s leading independent marketing technology company, distinguishing Cheetah from systems that are part of larger enterprise platforms. Part of the technical strategy to do this is to separate business logic from applications, using APIs to connect the two layers. This will make it easier for marketers to integrate external systems, taking advantage of industry innovation without requiring Cheetah to extend its own products.

Cheetah will also continue to provide services and build customer databases for its clients. Products based on third party data, such as credit information and identity management, have remained with the old Experian organization.

With $300 million in revenue and 1,600 employees, Cheetah Digital is already one of the largest martech companies. It is also one of the few that can handle enterprise-scale email. This makes it uniquely appealing to companies that are uncomfortable with the big marketing cloud vendors. The company still faces a major challenge in upgrading its technology to optimize customer treatments in real time across inbound as well as outbound channels.  It's a roll of the dice.

MarTech Stack Jenga: Official Rules

I spent some time in Atlanta last week, including a Friday afternoon visit with Sangram Vajre at Terminus to discuss his upcoming FlipMyFunnel conference. I’ll be keynoting the part of the conference devoted to technology stacks. Our conversation naturally turned to MarTech Jenga, my recent random thought of using the popular stacking game to illustrate how marketers assemble their technologies. Lacking adult supervision, Sangram and I spent too much time on the actual game design and came up with a seemingly workable idea. We're still debating the details – Sangram favors simplicity and my style is more complex* – but here are the official rules for MarTech Jenga** at the moment. Public comment is welcome:

Object of the game: assemble the most complete marketing stack before everything collapses.

Equipment: standard set of Jenga blocks, divided into nine groups of six. Groups are numbered 1-9 and (optionally) assigned a color and type of marketing system. Blocks are marked on each end with their group number and color. Individual blocks can also be marked with the logo of a specific vendor*** although this has no effect on the game play. Numbers 1-4 are marked with an asterisk to indicate that those groups are required for a complete stack.****

Setup: blocks are stacked three-across in alternating directions, as in standard Jenga. 

Game play: each player in turn may remove one block from the stack or pass. Players retain all blocks they remove in their own stack, whose contents must remain visible to other players. Play continues until the stack falls or all players have passed in sequence.

Scoring: the player who causes the stack to collapse loses. If at least one player has acquired all the required blocks, then players who have not acquired all the required blocks lose (if this rule is adopted). Remaining players are given one point for each group that is present in their stack. There are no points for additional blocks within the same group. Player with the most points wins.

Sangram promises me that he’ll have some version of the game available at FlipMyFunnel, but I’m not holding him to it. On the other hand, this seems the perfect thing to have at a vendor booth. The opportunities for customization are self-evident, as are things like a leaderboard for high scores through the conference.  I'll leave the drinking game versions up to the Internet.


____________________________________________________________________________
*No surprise there: he's a practitioner and I'm a consultant.

**The name Jenga is actually trademarked so we’ll have to pick something else if this ever gets beyond the blogging stage.

***a sponsorship opportunity.

**** Whether to have required blocks is a particular point of debate. It originally reflected the reality that certain types of systems are essential in a marketing stack. But from a game design point of view, it adds strategy considerations such as picking the required blocks sooner and blocking other opponents from completing their stack. That makes the game considerably more interesting.  The question is whether that takes too much thinking for a casual game. The only real way to resolve this is through play testing, where we could fiddle with a number of variables such as number of groups in total, number of required groups if any, and whether to play topless (i.e., allowing players to remove blocks from the top of the stack).

A Tale of Two Sittings: Best of Times with HubSpot and Teradata

Yes, that title is a pun on Dickens’ Tale of Two Cities. Just be glad I don’t review housewares, or this could be about rating knives and forks: A Tale of Two Settings: It Was The Best of Tines, It Was The Worst of Tines.

But I digress. Where was I? Ah yes, in Las Vegas, at ONE: Teradata Marketing Festival, which is Teradata's conference for users of its marketing applications. Despite the location and title, the program did not include jousting.

What the conference did offer was a detailed look at Teradata’s current marketing applications, vision, and product roadmap. These were solid and comprehensive, although Teradata continues to make an unfashionable distinction between “omni-channel” marketing, which is conventional relationship marketing across all channels, and “digital” marketing, which is Web and email marketing. Teradata argues that many digital marketing departments still function independently of relationship marketing groups and therefore want their own tools. That’s probably true, especially at the big enterprises who are Teradata’s primary clients. But the trend is towards closer integration and you’d think Teradata would rather lead than follow. I do suspect that at least part of the reason for the distinction is internal: the omni-channel products are based on Teradata’s original marketing automation products, Aprimo and Teradata Relationship Manager, while the digital products are based on eCircle email the company purchased in 2012. To avoid misunderstanding, let me stress that Teradata does let users integrate the omni-channel and digital products if they want to and that digital includes text messages, mobile apps, social media monitoring and publishing, and Web landing pages as well as email.

Teradata’s marketing applications also extend beyond standard marketing automation to include marketing resource management and analytics. Indeed, there’s a case to be made that the company’s scope is superior to most competitive “marketing clouds”, which are usually pretty light on MRM and analytics and are often barely integrated. On the other hand, Tereadata seems to have something of a blind spot regarding advertising and anonymous customers: I got mixed messages from the various Teradata presentations about whether it considers support for paid media as part of its marketing applications.  The clearest statement I can extract from my notes is that they will store anonymous identifiers such as cookies in their database but not use them until they are linked with an identifiable individual. As readers of this blog know well, I feel all media (owned, earned, paid) and all users (anonymous and known) should be managed together.

Teradata itself sees its primary differentiator as analytics. It presents an appealing vision of “adaptive self-learning marketing automation” that combines historical data, predictive models, and prescriptive models. By “prescriptive”, it means recommending the types of marketing programs to create, as opposed to predicting which existing marketing campaigns are best for an individual customer. This all strikes me as correct, if not downright futuristic.

But down at the practical level, Teradata’s near-term roadmap was considerably less visionary. Maybe that’s the nature of roadmaps. Perhaps inspired by the venue, the Teradata folks did a lot of (metaphorical) kimono opening at the event, detailing their product plans in ways I rarely see in public. What they revealed were mostly incremental enhancements such as improved user interfaces to make marketing activities easier and more nimble. There were some more fundamental promises, including better integration across suite components, more open access by external systems, and a more unified view across campaigns of the customer journey. It’s solid but not flashy, which is a pretty good summary of the Teradata style.

I was barely home from Vegas before I headed up to Boston for HubSpot’s Open House, a small event for primarily for business partners. (HubSpot’s main user conference is the INBOUND show in September. No jousting there, either.) Although the Open House style was low key, there were a couple of substantial announcements: the company’s free CRM system is now generally available (and still free); expansion of its $50/month Sidekick sales productivity tool; and eleven new integration partners including some predictive technologies (BrightInfo and Infer) and paid media retargeting (PerfectAudience). These are interesting extensions beyond the current set of partners, who mostly support operational tasks such as content creation, events management, analytics, and CRM integration. There was also some modest boasting about HubSpot’s continued growth – which actually accelerated slightly to 58% year on year in the most recent quarter – and other achievements including 15,000+ customers, 2,300 partners, 900+ employees, and top satisfaction rating in industry surveys.

HubSpot was less forthcoming than Teradata about future directions, perhaps because they see little change from the current course. Their general intention is to continue serving their existing target market (companies from 10 to 2,000 employees) with marketing and sales tools. There is a bit of redefinition to being a “growth engine” that solves additional marketing and sales problems, but this is an incremental change at most. The company’s announced focus is the improve the existing product with a mantra of faster, lighter, and easier, not to lead major changes in how businesses interact with their customers. Or perhaps HubSpot feels that most companies have virtually no automation in how they market and sell, getting more companies to adopt the existing HubSpot tools and best practices would itself be a major change. Fair enough.

On the other hand, co-founder and CTO Dharmesh Shah did tell me HubSpot is about a year away from supporting custom objects in its data model, which would open up some major new opportunities for the software. So perhaps there’s a bit more vision than they’re talking about publicly. People in Boston aren’t quite so free about opening their kimonos.

Marketo Adds Custom Objects. It's a Big Deal. Trust Me.

My first question when Marketo announced its new mobile app connector this week wasn’t, “What cool new things can marketers do?” but “Where is the data stored?”

It's not that I'm obsessed with data.  (Well, maybe a little.)  But one of Marketo’s biggest technical weaknesses has always been an inflexible data model. Specifically, it hasn’t let users set up custom objects (although they’ve been able to import custom objects from Salesforce.com or Microsoft Dynamics CRM). This was a common limitation among early B2B marketing automation products but many have removed it over the years. Indeed, even $300 per month Ontraport is about to add custom objects (and does a good job of explaining the concept in a typically wry video).

Sure enough, when I finally connected with Marketo SVP Products and Engineering Steve Sloan, he revealed that the mobile data is being managed through a new custom objects capability – one that Marketo didn’t announce prominently because they felt Marketing Nation attendees wouldn’t be interested. I suspect that underestimates the technical savvy of Marketo users, but no matter.

For people who understand such things, the importance is clear: custom objects open the path to Marketo supporting new channels and interactions, removing a major roadblock to competing as the core decision engine of an enterprise-grade customer management system. This will be more true once Marketo finishes its planned migration of activity data to a combination of Hadoop and HBase.  This will give vastly greater scale and flexibility than the current relational database (MySQL). Sloan said that even before this happens, data in the custom objects will be fully available to Marketo rules for list building and campaign flows.

The strategic importance of this development to Marketo is high. Marketo is increasingly squeezed between enterprise marketing suites and smaller, cheaper B2B marketing automation specialists. Its limited data structure and scale were primary obstacles to competing in the B2C market, where custom data models have always been standard. Even in B2B, Marketo’s ability to serve the largest enterprises was limited without custom objects. While this one change won’t magically make Marketo a success in those markets, its prospects without the change were bleak.

All that being said, the immediate impact of Marketo’s new mobile and ad integration features is modest. The mobile features let Marketo capture actions within a mobile app and push out messages in response. This is pretty standard functionality, although Marketo users will benefit from coordinating the in-app messages with messages in other channels. Similarly, the advertising features make it simpler to export audiences to receive ads in Facebook, LinkedIn, and Google and to find similar audiences in ad platforms Turn, MediaMath, and Rocketfuel. Again, this is pretty standard retargeting and look-alike targeting, with the advantage of tailoring messages to people in different stages in Marketo campaigns. The actual matching of Marketo contacts to the advertising audiences will rely on whatever methods the ad platform has available, not on anything unique to the Marketo integration.

In fact, I’d say the audience reaction to the announcement of these features during the Marketing Nation keynote was pretty subdued. (They were probably more excited that they can now manage their email campaigns from their mobile devices.) So maybe next time, Marketo should make the technical announcements during the big speech: at least the martech geeks will be on their chairs cheering, even if everybody else just keeps looking at their email or cat videos or whatever it is they do to amuse themselves during these things.

Note: for an excellent in-depth review of what Marketo announced, look at this post from Perkuto.