Adobe Adds Experience Cloud Profile: Why It's Good News for Customer Data Platforms

"A CDP by any other name still stores unified customer data."

Adobe on Tuesday announced the Experience Cloud Profile, which it described as a “complete, real-time view of customers” including data from outside of Adobe Cloud systems. The announcement was frustratingly vague but some ferreting around* uncovered this blog post by Adobe VP of Product Engineering Anjul Bhambhri, who clarified that (a) the new product will persistently store data ingested from all sources and (b) perform the identity stitching needed to build a meaningfully unified customer view. Adobe doesn’t use the term Customer Data Platform but that’s exactly what they’ve described here. So, unlike last week's news that Salesforce is buying MuleSoft, this does have the potential to offer a viable alternative to stand-alone CDP products.

Of course, the devil is in the details but this is still a significant development. Adobe’s offering is well thought out, including not just an Azure database to provide storage but also an open source Experience Data Model to simplify sharing of ingested data and compatible connectors from SnapLogic, Informatica, TMMData, and Microsoft Dynamics to make dozens of sources immediately available. Adobe even said they’ve built in GDPR-required controls over data sharing, which is a substantial corporate pain point and key CDP use case.

The specter of competition from the big marketing clouds has always haunted the CDP market. Salesforce’s MuleSoft deal was a dodged bullet but the Adobe announcement seems like a more palpable hit.** Yet the blow is far from fatal – and could actually make the market stronger over time. Let me explain.

First the bad news: Adobe now has a reasonable product to offer clients who might otherwise be frustrated by the lack of integration of its existing Experience Cloud products. This has been a substantial and widely recognized pain point. Tony Byrne of the Real Story Group has been particularly vocal on the topic. The Experience Cloud Profile doesn’t fully integrate Adobe’s separate products, but it does seem to let them share a rich set of customer data. That’s exactly the degree of integration offered by a CDP. So any Adobe client interested in a CDP will surely take a close look at the new offering.

The good news is that not everyone is an Adobe client. It’s true that the Cloud Profile could in theory be used on its own but Adobe would need to price it very aggressively to attract companies that don’t already own other Adobe components. The could of course be an excellent acquisition strategy but we don’t know if it’s what Adobe has in mind. (I haven’t seen anything about the Cloud Profile pricing but it’s a core service of the Adobe Experience Platform, which isn’t cheap.) What this means is that Adobe is now educating the market about the value of a persistent, unified, comprehensive, open customer database – that is, about the value of CDPs. This should make it much easier for CDP vendors to sell their products to non-Adobe clients and even to compete with Adobe to deliver CDP functions to Adobe’s own clients.

I’ll admit I have a vested interest in the success of the CDP market, as inventor of the term and founder of the CDP Institute. So I’m not entirely objective here. But as CDP has climbed to the peak of the hype cycle, I’ve been exquisitely aware that it has no place to go but down – and that this is inevitable. The best CDP vendors can hope for is to exchange being a “hot product” for being an established category – something that people recognize as a standard component of a complete marketing architecture, alongside other components such as CRM, marketing automation, and Web content management. I’ve long felt that the function provided by CDP – a unified, persistent, sharable customer database – fills a need that won’t go away, regardless of whether the need is filled by stand-alone CDPs or components of larger suites like Adobe Experience Cloud. In other words, the standard diagram will almost surely include a box with that database; the question is whether the label on that box will be CDP. Adobe’s move makes it more likely the diagram will have that box. It’s up to the CDP industry to promote their preferred label.



________________________________________________________________________
*okay, the first page of a Google search. No Pulitzer Prize for this one.
** yes, I’ve just combined references to Karl Marx and William Shakespeare in the same paragraph, garnished with a freshly mixed metaphor. You’re welcome.

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.

Picking the Right First Project for Your Customer Data Platform

For the past year, the most common question about Customer Data Platforms has been how they differ from Data Management Platforms. Recently that seems to have changed.  Today, the question everyone seems to be asking is what project they should pick as their first CDP use case.

That’s certainly progress but it’s a much harder question to answer than the one about DMPs. Like any good consultant, I can only answer that question with “it depends” and by then asking more questions. Here are some of the factors that go into a final answer.

• What resources do you have available? The goal for your initial use case is to get something done quickly that returns substantial value. Getting something done quickly means you want a project that uses existing resources to the greatest degree possible. Ideally, the only new element would be the CDP itself, and even the CDP deployment would use a small number of data sources. So, an ideal first project would use data in existing systems that is well understood, known to be of high quality, and can easily be extracted to feed the CDP. Alternately, the first project might involve new data collected by the CDP itself, such as Web site behaviors captured by the CDP's own page tag. If the first project is purely analytical, such as customer profiling or journey analysis, then you don’t need to worry about connecting to execution systems, although you do need staff resources to properly interpret the data and possibly some analytical or reporting systems. But if you happen to have good execution systems in place, it may make sense for the first project to connect with them. Or, you may pick a CDP that provides its own execution capabilities or can feed lists or offer recommendations to external delivery systems.

• What use case will provide value? This is where good delivery resources can be helpful: it’s much easier to deliver value with a use case that involves direct customer interaction and, thus, the opportunity to increase revenue or reduce costs. Often this can still be quite simple, such as a change in Web site personalization (involving just one channel for both source and delivery), an event-triggered email, or a prioritized contact list for sales teams. If execution isn’t an option, an analytical project can still be valuable if it presents information that wasn’t previously available. This may mean combining data that was previously kept separate, reformatting data couldn’t be analyzed in its original form, or simply pulling data from an inaccessible system into an accessible database. The trick here is for the analysis to generate insights that themselves can be the basis for action, even if the CDP isn’t part of the execution process.

• How much organizational change will be needed? Technical obstacles are often less significant barriers than organizational resistance. In particular, it can be difficult to start with projects that cross lines of authority either within marketing (say, separate Web and email teams) or between marketing and other departments (such as operations or customer support). When considering such changes, take into account the needs to revise business processes, to provide adequate training, to align compensation systems with the new goals, to provide reporting systems that track execution, and to measure the value of results. As a practical matter, the fewer parts of the organization affected by the initial project, the easier it will be to deploy and the higher the likelihood of success.

• Where’s the pain? It’s tempting to search for an initial project that is primarily easy to deploy. But even an easy project is competing with other demands on company resources in general and on staff and managers’ time in particular. So it’s important to pick a first project that solves a problem that’s recognized as important. If the problem is big enough – and it’s clear the CDP can solve it – then you have a good chance of convincing the company to make a substantial investment from the start. Ultimately, this is the right approach: after all, the CDP isn’t an end in itself, it’s a tool for improving your business. You may see a broad range of applications for your CDP but for those who don’t share that vision, you’ll need to show its value at every step of the way.

Eager to Sell Your Personal Data? You'll Have to Wait

Should marketers pay consumers directly to access their personal data? The idea isn’t new but it’s become more popular as people see the huge profits that Google, Facebook, and others make from using that data, as consumers become more aware of the data trade, and as blockchain technology makes low cost micro-payments a possibility.

One result is a crop of new ventures based on the concept has popped up like mushrooms – which, like mushrooms, can be hard to tell apart. I’ve been mentioning these in the CDP Institute newsletter as I spot them but only recently found time to take a closer look. It turns out that these things I’ve been lumping together actually belong to several different species. None seem to be poisonous but it’s worth sharing a field guide to help you tell them apart.

Before we get into the distinguishing features, let’s look at what these all have in common. They’re all positioned as a way for consumers to get value from their data. I’ve also bumped into a number of data marketplaces that serve traditional data owners, such as Web site publishers and compilers. They can often use some of the same technologies, including micro-payments, blockchain, and crypto-currency tokens. Some even sell personal data, especially if they’re selling ads targeted with such data. Some sell other things, such as streams from Internet of Thing devices. Examples of such marketplaces include Sonobi, Kochava, Narrative I/O, Datonics, Rublix and IOTA. Again, the big difference here is the sellers in the traditional marketplaces are data aggregators, not private individuals.

Here’s a look a half-dozen ventures I’ve lumped into the personal data marketplace category (which I suppose needs a three letter acronym of its own).

Dabbl turns out to be a new version of an old idea, which is to pay people for taking surveys. There are dozens of these: here's a list.  Dabbl confused me with a headline that said “Everyone’s profiting from your time online but you.” Payment mechanism is old-school gift cards. On the plus side: unlike most products in this list, Dabble is up and running.

Thrive pays users for sharing their data, but only in the broad sense that they are paid to fill out profiles which are exposed to advertisers when the users visit participating Web sites. The advertisers are paying Thrive; individual users aren’t deciding who sees their data or paid to grant access on a buyer-by-buyer basis. Payments are made via a crypto-token which is on sale as I write this. The ad marketplace is scheduled for launch at the end of 2018. That sequence suggests there’s at least a little cryptocurrency speculation in the mix. (Another hint: they’re based in Malta. Yet another hint: the U.S. Securities Exchange Commission won’t let you buy the tokens.)

Nucleus Vision is also in the midst of its token sale.  But they’re much more interested in discussing a propriety technology that detects mobile phones as they enter a store and shares the owner’s data using blockchain as an exchange, storage, and authorization mechanism. Store owners can then serve appropriate offers to visitors. This sounds like a lot of other products except that Nucleus’ technology does it without a mobile app. (It does apparently need some cooperation from the mobile carrier.) Rewards are paid in tokens which can be earned for store visits, by using coupons or discounts, by making purchases, or by selling data. Each retailer runs its own program, so this isn’t a marketplace where different buyers bid for each consumer’s data.  Sensors are currently running in a handful of stores and the loyalty and couponing systems are under development.

Momentum is an outgrowth of the existing MobileBridge loyalty system.  It rewards customers with yet another crypto-token (on sale in late April) for marketer-selected behaviors. Brands can play as well as retailers but it’s still the same idea: each company defines its own program and each consumer decides which programs to join. The shared token makes it easy to exchange or pool rewards across programs. The published roadmap is ambiguous but it looks like they’re at least a year away from delivering a complete system.

YourBlock gets closer to what I originally had in mind: it stores personal data (in blockchain, of course), uses the data to target offers from different companies, and lets consumers decide which offers to accept. Yep, there’s a crypto-token that will be used to give discounts. Sales started yesterday (March 12) and are set to close by April 23. Development work on the rest of the platform will start after the sale is over, with a live product due this August.

Wibson calls itself a “consumer-controlled personal data marketplace” and, indeed, they fit the archetype: users install a mobile app, grant access to their data, and then entertain offers from potential buyers to read it. Storage and sharing are based on blockchain but payments are made via points rather than a crypto-token. At least that’s how it works at the moment: in fact, Wibson has just completed its initial mobile app and you can’t download it quite yet. During the initial stage, only Wibson will be able to buy users’ data and they’ll just use it for testing. If they’ve published a schedule for further development, I can’t find it.

So, that’s our little stroll through the personal data marketplace. Less here than meets the eye, perhaps – most players offer more or less conventional loyalty programs, although they use blockchain and crypto-tokens to deliver them.  True marketplaces are still in development. But it’s still an interesting field and well worth watching. As with mushrooms, look carefully before you bite.

State of Customer Data Platforms in Europe

The Customer Data Platform Institute will be launching its European branch later this month with a series of presentations in London, Amsterdam and Hamburg. We’ve seen considerable CDP activity in Europe – nearly one quarter of the CDPs in the Institute's latest industry update are Europe-based, several others with European roots have added a U.S. headquarters, and some of U.S.-based CDPs  have significant European business. A recent analysis of CDP Institute membership also found that one quarter of our individual members are in Europe. So what, exactly, is the state of CDP in Europe?

 It’s long been an article of faith on both sides of the Atlantic that the U.S. market is ahead of Europeans on marketing technology in general and customer data management in particular. That (plus the larger size of the U.S. market) is why so many European vendors have relocated to the U.S. This study from Econsultancy suggests the difference is overstated if it exists at all: 9% of European countries reported a highly integrated tech stack, barely under the 10% figure for North American companies. North American firms were actually more likely to report a fragmented approach (48% vs 42%), although that was only because European countries were more concentrated in the least advanced category (“little or no cloud based technology”) by 20% vs 13%.

 The assumption that cloud-based technology is synonymous with advanced martech is debatable but, then again, the survey was sponsored by Adobe.  What is clear is that European firms have generally lagged the U.S. in cloud adoption -- see, for example, this report from BARC Research.

Lower cloud use probably hasn’t directly impeded CDP deployment: although nearly all CDPs are cloud-based, a substantial number offer an on-premises option. (The ratio was seven out of 24 in the CDP Institute’s recent vendor comparison report, including nearly all of the Europe-based CDPs.) But the slower cloud adoption may be a hint of the generally slower pace of change among European IT departments, which could itself reduce deployment of CDPs.

A Salesforce survey of IT professionals supports this view. Answers to questions about leading digital transformation, being driven by customer expectations, and working closely with business units all found that U.S. IT workers are slightly but distinctly more business-oriented than their European counterparts. Interestingly, there’s a split within the European respondents: UK and Netherlands are more similar to the U.S. answers than France and Germany. I should also point out that I’ve highlighted questions where the U.S. and European answers were significantly different – there were quite a few other questions where the answers were pretty much the same.

Organizational silos outside of IT are another barrier to CDP adoption. A different Salesforce survey, this one of advertising managers, also found that North American firms are generally more integrated than their European counterparts. The critical result from a martech perspective is North American marketing and advertising departments were much more likely to collaborate on buying technology.

Then again, a Marketo survey found that European respondents (from a mix of IT, marketing, sales, and service departments) were generally more satisfied with their tools and performance, even though they lagged North Americas in slightly innovation and more clearly in strategic alignment with corporate objectives. This isn’t necessarily inconsistent with the previous results: being less integrated with other departments may free the Europeans to pursue their departmental goals more effectively, even if they’re less fully aligned with corporate objectives. Other surveys have given similar results: people are generally happier with technology when they buy it for themselves.

Not surprisingly, one area where the Europeans are clearly ahead in preparation for GDPR: a Spiceworks survey at the start of this year found that 56% of European companies had allocated funds for compliance compared with just 31% of U.S. companies. (Almost half the U.S. respondents believe GDPR wouldn’t affect them, even though GDPR applies globally.) While the result clearly relates to the fact that GDPR is a European Union regulation, it may also reflect a generally higher interest in privacy among European consumers: to take one example, ad blocking is much more common in Europe than the U.S. That’s good news for CDP vendors, since GDPR has emerged as one of the primary use cases.

On the other hand, a survey from Aspect found that U.S. consumers are generally more demanding than Europeans about customer service: they care more about having a choice of service channels, are more willing to pay extra for good service and are quicker to stop buying after a poor experience. This is probably bad news for European CDP vendors, since unified customer data is a foundation for modern customer service.

In sum, things really are a bit different in Europe. Integration, the primary CDP use case, is lagging compared to the U.S. So it makes sense that CDP adoption is also lagging.  But GDPR may be changing the equation and consumer attitudes are certainly adding external pressure.  The need for CDP is growing and we hope the CDP Institute’s European operations will make it a little easier for European companies find right solutions.