Adobe, Salesforce and Oracle all made announcements regarding Customer Data Platform products this week. None are world-changing: Salesforce described a planned extension of Customer 360; Abobe announced triggered journey campaigns that draw on its “real time CDP”, and Oracle described CDP services from systems integrators. But the fact that all three vendors are addressing the topic raises some interesting questions.
Why does this matter to technology and marketing professionals? Customer Data Platforms have been a hot topic for the past three years. The reason is simple: they promise to solve a pressing problem that has not been solved by anything else. That problem is the need of marketers (and others) to combine data from all sources into easily accessible customer profiles. Those profiles are needed for accurate targeting and consistent, satisfying customer experiences.
The problem is unsolved because alternate solutions fall short in different areas. Data warehouses are largely limited to structured data. Data lakes are not unified or easily accessible to non-technical users. Data Management Platforms are limited to summary data about mostly anonymous individuals. CRM and marketing automation systems don’t easily combine data from external sources.
By contrast, CDPs promise to ingest all data sources, retain all details, and share the resulting profiles with any system that needs them. But CDPs have been developed by relatively small specialist vendors, which many enterprise buyers are reluctant to consider. So having Salesforce, Adobe, and Oracle promote CDPs will prompt more enterprise buyers to give the category serious consideration.
It also doesn’t hurt that Forrester issued its first CDP wave this week, that Dun & Bradstreet just bought CDP Lattice Engines, and that Martech Advisor’s Talking Stack podcast devoted an entire session to the topic (humble-brag disclosure: I’m a panelist on Talking Stack).
So, yeah, CDP is getting a lot of attention right now.
What’s new in these announcements and what’s not? Adobe, Salesforce and Oracle have all previously announced something that they positioned as addressing the needs met by a CDP.
• Adobe’s original approach was to map a single customer ID across all its systems and create transient customer profiles by pulling together data on demand. It changed direction in March 2018 with news that its Experience Platform would create persistent profiles. It released this a year later and described it as including a "Real-Time CDP". Nothing about that changed with yesterday’s announcement, which described an Adobe Campaign application using the CDP data. All this is separate from the Open Database Initiative, a still-undelivered project announced last September to build shared database model with Microsoft and SAP.
• Oracle announced CX Unity last October. It included a persistent data store from the start but is just now starting beta deployments. The latest Oracle announcement describes collaboration with Accenture and Capgemini to provide services around CX Unity projects. It doesn’t include anything new about the product.
• Salesforce’s Customer 360, also announced last September, was another master customer ID used to access source system data on demand. Salesforce now says they’ll release that product this November. The bigger news is they’re developing a next-generation Customer 360 that will store its own data, bringing them in line with Adobe and Oracle. There’s no release date although they hope to start pilot projects this fall.
It's taken a while but all three vendors now acknowledge that a CDP must store its own data. That will remove some confusion from the CDP market. Cynics might say it also confirms that software vendors define user requirements based on what their systems currently do, not what users actually need. It’s hard to interpret the CDP story in any other way, since the need for a persistent data store has always been clear to anyone who tried to support core CDP use cases such as attribution, prediction, and journey analysis.
What benchmarks should these CDP products be measured against? The CDP Institute (which I head) believes that buyers expect a CDP to ingest all types of data, capture the full detail of the ingested data, retain that data as long as the user wants, assemble unified customer profiles, and make the profiles available to any external system. We codify those as requirements in our RealCDPTM certification program. The original Adobe and Salesforce approaches certainly didn’t store the data and had other limits about the types and detail they captured. On the other hand, they did include real-time access to current source data, which is not part of RealCDP but is important for many CDP use cases. Many other CDPs also provide real-time access as well as segmentation, predictive modeling, personalized message creation, and sometimes even message distribution. Oracle, Salesforce, and Adobe have separate products for most of those functions so they are not part of their CDPs.
What should we look for next from these vendors? The main thing to watch is how quickly the announcements turn into released products. Only then will buyers be able to judge the details of how well these vendors deliver on their promises and how their offerings compare with other, more mature CDPs. In particular, pay close attention to how easily each system connects with other products. Because the marketing clouds are built from acquisitions that remain technically separate, integrations for each component are developed and delivered in whatever sequence the vendor thinks best. Connections to other vendors’ systems are an even lower priority. Buyers will often be left to develop their own connectors using a CDP API – which should itself be examined closely to see what it does and how hard it is to use.
Once the vendors flesh out the core CDP capabilities of their offerings, the focus will shift to improvements in user experience. This includes end-user functions such as segmentation and more technical capabilities for connecting to data sources and destinations. Reducing the technical work required to set up and maintain a CDP can have a significant impact on time to value and operating cost. More important, it can help the CDP achieve its mission of including all data and sharing it with all other systems. Also expect the vendors to create industry-specific packages with prebuilt data models, connectors, predictive models, workflows, and reporting. These will further ease deployment and help the vendors to compete with industry-specialist CDPs.
In most of the CDP market, vendors are extending their systems by adding more activation functions such as marketing campaigns, personalized message selection, and message delivery. Many users are eager to buy one system that combines as many functions as possible. But because the marketing clouds offer these functions as separate modules, they are unlikely to expand their CDPs in that direction. This will probably reduce their competitiveness in the mid-market.
Who else might toss their hat into the CDP ring? There have been four significant CDP acquisitions to date: Datalicious/Veda by Equifax (2016); Datorama by Salesforce (2018); Treasure Data by Arm (2018), and Lattice Engines by Dun & Bradstreet (2019). Salesforce is the only marketing cloud vendor on this list and they've positioned Datorama as a campaign analytics product, not a CDP. Since Oracle and Adobe are far along in their CDP development, neither is likely to purchase an independent CDP vendor – although that might happen if they feel pressure to deliver a mature CDP more quickly. That Equifax and Dun & Bradstreet have bought CDPs suggests other data compilers might do the same, with the goal of adding more value than just their data.
Other potential acquirers include ad agency holding groups and consultancies who want to bulk up their data management capabilities. Moving from the other direction, companies that offer message delivery and interactions, such as email delivery, Web site personalization, mobile app development, call center, and customer support systems, might add a CDP to expand their footprint, make their products harder to replace, and ultimately let them add delivery in other channels. Case in point: unified marketing, sales and support vendor Freshworks recently purchased Natero, a customer success system with CDP capabilities.
But the big clouds looming over the entire customer data ecosystem are, literally, the big clouds: Amazon Web Services, Google Cloud, and Microsoft Azure. So far, none has shown much interest in selling customer data management tools, although they already host plenty of CDP data. There’s a reasonable chance these vendors will eventually enter the CDP market. But that would be a few steps up the value chain from their current offerings, which still focus primarily on data storage. The cloud services vendors are starting that climb, adding cloud connectors, data transformations, in-database analytics, machine learning, and reporting tools. Google Cloud’s purchase of Looker is a recent step in this direction. Data quality services such as address standardization and master data management could be next. There's a way to go before these vendors are ready to add the specialized features needed for a CDP. They may also find themselves constrained by anti-trust and privacy issues. But don’t rule it out.
What do these announcements mean for current CDP vendors? At a fundamental level, these announcements confirm that there’s a real need for CDPs and that the CDP model of building a separate, persistent database is correct. That’s no small thing, given the fear, uncertainty and doubt that the marketing cloud vendors have previously spread about both. The result is to expand the market, since more potential buyers will now accept CDP as a valid option.
This does not mean the cloud vendors have given up their efforts to shape the conversation. They are now trying to redefine CDP as part of a larger integrated package – that is, of systems like their own. This isn’t likely to be successful, given how few enterprises actually limit themselves to one vendor’s products. So the ability of the current CDP vendors to work equally well with systems from any provider is likely to be even more appealing.
Still, it would be unrealistic to ignore the fact that many buyers would rather buy from the marketing cloud vendors. The long lead times between preannouncement of the marketing cloud CDPs and their actual delivery will lead some buyers to delay their purchases, which is exactly the cloud vendors’ intent. But the interval will also give potential buyers more time to think carefully about what they need in a CDP, making them smarter consumers when they do start an acquisition project. A rigorous, requirements-based acquisition process will often favor the existing CDP vendors, whose products are proven and mature.
How do these announcements relate to other developments in the CDP market? The CDP market is evolving rapidly. From its initial base in retail and media, it has spread to new industries including travel, financial services, B2B, telecommunications, healthcare, and education. Industry-specialist vendors are appearing with prebuilt data models, integrations with industry systems (such as point of sale in retail or reservations for hospitality), and staff expertise. Other specialists now focus on mid-size or small businesses and in particular geographic regions.
There’s also an increasingly clear split between CDP vendors who focus on data collection, unification, and access functions and those with marketing functions for analytics and personalization. One result is that some clients deploy one CDP for data unification and another for marketing applications. Some CDPs have extended their marketing features to include delivery systems such as email engines, Web site messaging, and even DMPs. These were previously beyond the scope of CDP products. Vendors with delivery capabilities still allow clients to use other delivery systems – otherwise they would not meet the definition of a CDP. You can see where this leads: CDPs with a full set of marketing applications become direct competitors of the marketing clouds. It also means that CDP becomes one feature among many in these products -- a change that may lead some to deemphasize their CDP capabilities and instead partner with data unification specialists. (See this post for a deeper exploration of that scenario.)
On the buyer side, CDPs are increasingly used beyond marketing to support sales, service, and business operations. This often means the CDP becomes a shared resource managed by corporate IT rather than marketing. Enterprise-wide digital transformation projects and increasing concern over compliance with privacy regulations have further increased involvement of central IT and compliance teams. In general, greater familiarity with CDPs has meant that buyers have a better understanding of what they do and what to look for, making them more sophisticated consumers and helping them to navigate the growing number of products in the market.
Entry of the big cloud vendors may accelerate the trend to industry-specific CDPs by pushing smaller vendors into niches where they can better compete with general purpose systems. The big cloud vendors may push also independent CDPs to deliver comprehensive marketing functions to the mid-market where they can be more integrated and more economical than the marketing clouds. CDPs that focus primarily on data management will probably face the greatest competition from the marketing cloud CDPs, since they compete for enterprise clients where the big cloud vendors are the strongest. But those CDP vendors also have the greatest technical lead and will find it easiest to support enterprise-wide use cases.
In short, entry of the marketing cloud CDPs will accelerate industry growth and reinforce current industry trends, not change the over-all direction. For CDP vendors and buyers alike, that is good news.
Monday, June 17, 2019
Tuesday, June 11, 2019
Tableau, Looker, and Origami Logic Acquisitions Show Analytics Is In Fashion
One of the unwritten laws of punditry is that one event is random, two events are interesting, and three events make a trend. By that measure, the purchases of data analytics vendors Looker by Google, Tableau by Salesforce, and Origami Logic by Intuit within a three week span must signify something. Is it that martech suites must now include business intelligence software?
I think not. Even though the acquired products were fairly similar, each of these deals had a different motivation. Conveniently, the buyers all stated their purposes quite clearly in their announcements.
- Intuit bought Origami Logic to advance its strategy to become an “A.I.-driven expert platform”. Specifically, they see Origami Logic as providing a “strong data architecture” that will “accelerate Intuit’s ability to organize, understand, and use data to deliver personalized insights that help customers quickly achieve success and build confidence whenever they use Intuit products.” Reading between the lines, Intuit recognized its existing data architecture can’t support the kinds of analysis needed to generate AI-based recommendations for its clients, and bought Origami Logic to close that technology gap. In other words, Origami Logic will be the foundation of new Intuit products.
- Google bought Looker “to provide customers with a more comprehensive analytics solution — from ingesting and integrating data to gain insights, to embedded analytics and visualizations — enabling enterprises to leverage the power of analytics, machine learning and AI.” That’s somewhat similar to Intuit’s purpose, but Looker is building applications on top of Google Cloud’s existing, extremely powerful data management capabilities rather than providing a new data management foundation. Indeed, Looker already runs on Google Cloud. So Looker is adding another layer of value to Google Cloud, letting it meet more needs of its existing clients.
- Salesforce bought Tableau so it can “play an even greater role in driving digital transformation, enabling companies around the world to tap into data across their entire business and surface deeper insights to make smarter decisions, drive intelligent, connected customer experiences and accelerate innovation”. That’s not exactly pithy, but we’re dealing with Marc Benioff. The key is digital transformation, which lets Salesforce participate in projects beyond its current base in sales and marketing departments. That is, the purpose isn’t to add products for existing customers but to serve entirely new customers. The huge size of Tableau’s customer community – “more than 1 million passionate data enthusiasts” -- clearly a draw for Salesforce. This makes complete sense for Salesforce, which is always straining to maintain its growth rate.
Is there some commonality here? Sure: each of these vendors is striving to offer products based on advanced data management and analytics. Intuit is focused on the data management foundation while Google Cloud and Salesforce are focused more on analytics. All are acknowledging that it’s easier to buy mature technology than to build it from scratch. But of the three buyers, only Salesforce is a martech vendor and their purpose is explicitly to serve customers outside the martech user base. So whatever these deals prove, it’s not that business intelligence is the latest martech must-have.
I think not. Even though the acquired products were fairly similar, each of these deals had a different motivation. Conveniently, the buyers all stated their purposes quite clearly in their announcements.
- Intuit bought Origami Logic to advance its strategy to become an “A.I.-driven expert platform”. Specifically, they see Origami Logic as providing a “strong data architecture” that will “accelerate Intuit’s ability to organize, understand, and use data to deliver personalized insights that help customers quickly achieve success and build confidence whenever they use Intuit products.” Reading between the lines, Intuit recognized its existing data architecture can’t support the kinds of analysis needed to generate AI-based recommendations for its clients, and bought Origami Logic to close that technology gap. In other words, Origami Logic will be the foundation of new Intuit products.
- Google bought Looker “to provide customers with a more comprehensive analytics solution — from ingesting and integrating data to gain insights, to embedded analytics and visualizations — enabling enterprises to leverage the power of analytics, machine learning and AI.” That’s somewhat similar to Intuit’s purpose, but Looker is building applications on top of Google Cloud’s existing, extremely powerful data management capabilities rather than providing a new data management foundation. Indeed, Looker already runs on Google Cloud. So Looker is adding another layer of value to Google Cloud, letting it meet more needs of its existing clients.
- Salesforce bought Tableau so it can “play an even greater role in driving digital transformation, enabling companies around the world to tap into data across their entire business and surface deeper insights to make smarter decisions, drive intelligent, connected customer experiences and accelerate innovation”. That’s not exactly pithy, but we’re dealing with Marc Benioff. The key is digital transformation, which lets Salesforce participate in projects beyond its current base in sales and marketing departments. That is, the purpose isn’t to add products for existing customers but to serve entirely new customers. The huge size of Tableau’s customer community – “more than 1 million passionate data enthusiasts” -- clearly a draw for Salesforce. This makes complete sense for Salesforce, which is always straining to maintain its growth rate.
Is there some commonality here? Sure: each of these vendors is striving to offer products based on advanced data management and analytics. Intuit is focused on the data management foundation while Google Cloud and Salesforce are focused more on analytics. All are acknowledging that it’s easier to buy mature technology than to build it from scratch. But of the three buyers, only Salesforce is a martech vendor and their purpose is explicitly to serve customers outside the martech user base. So whatever these deals prove, it’s not that business intelligence is the latest martech must-have.
Saturday, June 01, 2019
What's Next for the Customer Data Platform Industry?
Customer success platform Gainsight recently released a Customer Data Platform module for its system. This followed Freshworks’ acquisition of Natero, another customer success platform that builds a unified customer database. Totango, another customer success platform, also positions itself as CDP.
There's nothing questionable about these claims. Customer success platforms were among the earliest classes of systems identified as CDPs. Like predictive modeling systems, they originally built a unified database to support their primary application and later recognized that the database had even more value if it was shared with other systems. So a CDP positioning makes sense.
But the Gainsight announcement did prompt an industry colleague to ask me whether classifying products like Gainsight as CDPs would lead to each department building its own CDP, creating “CDP silos” and ultimately requiring a “CDP of CDPs” to unify them all. That contains enough irony to meet your minimum daily requirement for a week. But it’s a fair question that’s often posed by CDP buyers who don't want another silo in their server farm.
My first answer is that not all systems claiming to have a CDP are true CDPs, particularly when it comes to sharing their data with any external system. We’ve been trying clarify that with the RealCDP project, which includes data sharing as one of the five qualification requirements. But many vendors like Gainsight and Totango pass that test. So it doesn’t really address the question.
My second answer is to respond with another question: If a system meets the definition of a CDP, should we NOT call it one? That seems silly. Of course, it begs the question of the CDP definition itself: should we define a CDP as a system that only builds the unified database? This would exclude products that also provide integrated applications such as customer success management, predictive modeling, campaign management, personalization, and more. The narrow definition would certainly reduce confusion. But it doesn’t address the real-word situation, which is that many buyers want a CDP that includes some or even all of those applications. My response has been to suggest the “CDP Inside” concept, which says CDP is a function, not a software category. This function could be provided by a single-purpose system or by a system that offers other functions as well. The concept hasn’t been as widely adopted as I'd like but I think the world is moving in that direction regardless.
My third answer builds on the second. Companies can buy multiple products with a CDP capability and still not deploy all of them. This comes down to management: a company with several CDP-capable products can make one its primary CDP and push profiles from that system to the rest. That would be the best choice in most cases, I think. But a company might also build several complete CDPs by feeding the same data into each of them. Or it might build siloed CDPs that only connect to their associated applications. Those sound like bad ideas. But it’s not the CDP's fault if someone deploys it ineffectively.
Let’s game this out.
A reasonable analogy might be reporting systems. In the early days of the packaged software industry, application vendors competed to offer the best custom report builders within their products. Later, general-purpose reporting tools like Tableau came to dominate the market. Most application vendors then stopped presenting their report builder as a differentiator. They still deliver specialized reports as part of their systems but expect users to integrate with third party reporting tools for other needs.
I think the CDP industry will follow a similar trajectory. Many applications need unified customer profiles. Some will rely entirely on an external CDP to create those profiles and share them. Most will offer a lightweight CDP so customers without a separate CDP can still use their application. A few will build best-in-class CDPs that can be sold on their own. These best-in-class CDP modules will often be spun off as separate products.
Some of this is already happening.* CDP vendors themselves are increasingly distinguishing between CDPs that focus on building and sharing the unified database and CDPs that also deliver analytical, personalization, and other application capabilities. Some in the latter group position their CDP features as best-in-class but most will admit (with varying degrees of reluctance) that they are often deployed in combination with a separate CDP that specializes in data unification. So, just as companies often have a shared standard reporting tool that complements the reports built into applications, we can expect to see one shared CDP that complements specialist CDPs within applications.
It will take some time to sort this out, as vendors decide what kind of CDP to offer and buyers decide what they need. But I think the future of the industry is coming into focus.
__________________________________________________
*A little-cited corollary to the famous aphorism that predictions about the future are hard is that predicting the past is easy.
There's nothing questionable about these claims. Customer success platforms were among the earliest classes of systems identified as CDPs. Like predictive modeling systems, they originally built a unified database to support their primary application and later recognized that the database had even more value if it was shared with other systems. So a CDP positioning makes sense.
But the Gainsight announcement did prompt an industry colleague to ask me whether classifying products like Gainsight as CDPs would lead to each department building its own CDP, creating “CDP silos” and ultimately requiring a “CDP of CDPs” to unify them all. That contains enough irony to meet your minimum daily requirement for a week. But it’s a fair question that’s often posed by CDP buyers who don't want another silo in their server farm.
My first answer is that not all systems claiming to have a CDP are true CDPs, particularly when it comes to sharing their data with any external system. We’ve been trying clarify that with the RealCDP project, which includes data sharing as one of the five qualification requirements. But many vendors like Gainsight and Totango pass that test. So it doesn’t really address the question.
My second answer is to respond with another question: If a system meets the definition of a CDP, should we NOT call it one? That seems silly. Of course, it begs the question of the CDP definition itself: should we define a CDP as a system that only builds the unified database? This would exclude products that also provide integrated applications such as customer success management, predictive modeling, campaign management, personalization, and more. The narrow definition would certainly reduce confusion. But it doesn’t address the real-word situation, which is that many buyers want a CDP that includes some or even all of those applications. My response has been to suggest the “CDP Inside” concept, which says CDP is a function, not a software category. This function could be provided by a single-purpose system or by a system that offers other functions as well. The concept hasn’t been as widely adopted as I'd like but I think the world is moving in that direction regardless.
My third answer builds on the second. Companies can buy multiple products with a CDP capability and still not deploy all of them. This comes down to management: a company with several CDP-capable products can make one its primary CDP and push profiles from that system to the rest. That would be the best choice in most cases, I think. But a company might also build several complete CDPs by feeding the same data into each of them. Or it might build siloed CDPs that only connect to their associated applications. Those sound like bad ideas. But it’s not the CDP's fault if someone deploys it ineffectively.
Let’s game this out.
- Application vendors are incented to add CDP capabilities to their systems because some clients want them. Foolish clients may build several separate CDPs, especially in organizations where different groups prefer to function independently. So, yes, there’s some potential harm in making that easy by putting a possible CDP inside each system.
- Smart clients will avoid this mistake by choosing one system as their primary CDP. Each vendor will hope to play that role, since it adds value to their product and makes clients less likely to switch to another system.
- Over time, the smart clients will learn what they need in a CDP and push vendors to compete to build the best product. As this happens, vendors with limited resources will drop out of the competition to focus on their core applications. They'll still provide some data unification features but won't promote them as a CDP.
- Other vendors will double down on their CDP investment so they can win the competition. As these vendors develop best-in-class products, they’re likely to offer their CDPs as separate modules.
- The most demanding buyers will want the best possible CDP and will buy best-in-class products whether they come from specialist CDP vendors or application developers. As a result, best-in-class CDPs will be increasingly distinguished from lightweight CDPs embedded in application systems.
A reasonable analogy might be reporting systems. In the early days of the packaged software industry, application vendors competed to offer the best custom report builders within their products. Later, general-purpose reporting tools like Tableau came to dominate the market. Most application vendors then stopped presenting their report builder as a differentiator. They still deliver specialized reports as part of their systems but expect users to integrate with third party reporting tools for other needs.
I think the CDP industry will follow a similar trajectory. Many applications need unified customer profiles. Some will rely entirely on an external CDP to create those profiles and share them. Most will offer a lightweight CDP so customers without a separate CDP can still use their application. A few will build best-in-class CDPs that can be sold on their own. These best-in-class CDP modules will often be spun off as separate products.
Some of this is already happening.* CDP vendors themselves are increasingly distinguishing between CDPs that focus on building and sharing the unified database and CDPs that also deliver analytical, personalization, and other application capabilities. Some in the latter group position their CDP features as best-in-class but most will admit (with varying degrees of reluctance) that they are often deployed in combination with a separate CDP that specializes in data unification. So, just as companies often have a shared standard reporting tool that complements the reports built into applications, we can expect to see one shared CDP that complements specialist CDPs within applications.
It will take some time to sort this out, as vendors decide what kind of CDP to offer and buyers decide what they need. But I think the future of the industry is coming into focus.
__________________________________________________
*A little-cited corollary to the famous aphorism that predictions about the future are hard is that predicting the past is easy.
Subscribe to:
Posts (Atom)