Lego Blocks, Pickup Trucks, and Why Bloomreach Bought Exponea

Yesterday brought news that CDP Exponea had been purchased by ecommerce recommendation engine Bloomreach. The deal almost exactly parallels last year’s merger between RichRelevance and Manthan, as well the smaller-scale combination of CrossEngage with Gpredictive. It also recalls other recent CDP acquisitions including Acquia buying AgilOne, Chapsvision buying NP6, SAP buying Emarsys, and Wunderkind buying SmarterHQ.

It’s easy (and correct) to see these deals as efforts to assemble comprehensive marketing suites. But it's not just that the buyers want to add a CDP their collection.  These deals all involve CDPs with marketing automation functions (that is, segmentation, message selection, campaigns, personalization, and cross-channel orchestration). CDP Institute labels these as “campaign" or "delivery”; others sometimes refer to them as “activation” or “execution” CDPs. This type of CDP provides the biggest headstart towards building a marketing suite. The drive to build suites clarifies why predictive analytics vendors Bloomreach, RichRelevance, and Gpredictive are such frequent partners: stand-alone predictive tools are missing nearly all the features needed for a full marketing platform, so they have the most to gain from buying a CDP that fills those gaps.

Of course, the biggest CDP acquisition of all, Twilio’s purchase of Segment, doesn’t fit this mold. Segment was more of a pure-play or "data" CDP, limited to assembling and sharing customer profiles. But Twilio isn’t looking to build a marketing suite; their core business is call centers and (after buying SendGrid) email messaging. They have their sights set on providing a communications layer to support all customer-facing operations, including sales and service. Still a suite, but a different kind.

The drive to construct comprehensive marketing suites is interesting because it conflicts with the current notion that marketers don’t want big, integrated products but instead want to create their own collections of components, building some parts with the latest self-service tools and connecting the rest through microservices, open APIs, and other technical wizardry. The pure vision is a distributed, non-hierarchical architecture, modeled roughly on the Internet itself, where any system can connect with any other system. The more practical vision is a platform-centric world where any system can plug into a central platform that provides basic services. In both visions, companies construct their own, highly customized collections of systems that are perfectly tailored to their needs.

Simply put, the vendors assembling these suites are betting that vision is wrong. They believe – based no doubt on what buyers are telling them – that companies still want to buy an integrated product that meets their needs without any assembly required. The purely practical reason is that companies don’t assemble systems for their own sake; they assemble them as tools to do what’s really important, which is to make money (usually by delivering goods and services to customers). Sure, you can build a pickup truck from Lego blocks and you might even do that for fun.  But if you actually need to haul something, you’ll go to a dealer and buy one.

In other words, we still live in a world ruled by Raab's Law, which is “Suites win”. (More formally: In the long run, suites always win the competition between suites and best-of-breed systems.) Platforms don’t change this as much as you’d think, because customers always want the platforms themselves to add more features and make them tightly integrated. It's true that buyers want third-party applications that can extend platform capabilities.  It's also in the platform vendors’ interest to be open to those applications since they add value to the platform at little cost to the platform owner. But there’s a time and effort cost to the user of selecting, connecting, and learning to use each new application, regardless of whether the app is “free” or how easily it connects. Users are very aware of these costs, which is why they want the core platform to offer as many features as possible. Put another way: the value of applications is they enable users to add features a platform lacks; but the more features a platform provides internally, the more value it provides from the start. This pushes platform vendors to add features that save users from the need to install apps. Of course, the art of platform management is knowing which features are popular and standardized enough to be incorporated.

As new features are added, platforms increasingly resemble integrated suites. The significant difference from suites is that platforms offer users the option to replace the platform’s default components with external alternatives. But if the platform builders do their jobs correctly, users will find less need to do that over time.

This is what makes campaign CDPs so attractive to companies attempting to construct a new marketing suite. The marketing features of the CDPs provide a core of functionality that marketers are looking for. In addition, and crucially, the core CDP features make it easier for the suite vendor to integrate components of its own system and also enable the vendor to offer platform-style flexibility by connecting with external systems.

What, then, do these acquisitions tell us about the future of the CDP industry? The first thing to realize is that most CDPs already fall into the campaign and delivery categories (70% of the industry, measured on company count or employment, according to our statistics).  Most of these firms actually started as marketing automation, personalization, or delivery systems and added CDP capabilities later. Some already provide an integrated marketing suite; the others can expand in that direction on their own or through combinations with other products.  

It will be increasingly difficult for this type of CDP to survive without a broad set of marketing functions. Competitive pressures will force them to improve those features while treating core CDP capabilities of building and sharing unified profiles as just one talking point.  We've already seen limit their investment in CDP features and instead partner with other data-oriented CDPs to meet those needs.  (We also expect these firms to increasingly specialize by industry and company size. This makes it easier for them to build connectors to operational systems such as point of sale in retail or reservations in travel, as well as building industry-specific features, hiring industry-expert staff, and fine-tuning delivery and pricing models to meet target price-points.)

The other 30% of the CDP industry are vendors specializing in data management and analytics. We uncreatively call these "data" and "analytics" CDPs.  Many started life as tag managers, data collection, or predictive modeling systems; others were built as CDPs from the begining. As the Twilio/Segment deal illustrated, data CDPs may also be acquisition targets, especially for companies that are aiming to build a corporate-level backbone rather than a marketing suite.  Firms that aren't acquired will be able to remain independent by offering best-of-breed customer data unification services to companies that need and can pay for a best-of-breed solution. These will likely be large enterprises. This type of CDP will increasingly be purchased by IT and data departments, rather than marketing, and will come to look more like IT tools than end-user applications. As such, they’ll find themselves increasingly competing with general purpose data management tools from other software providers and from data management and analytics tools built into the big cloud platforms (Google Cloud, AWS, Azure). So far, the specialized features of the most sophisticated data CDPs are more advanced than what’s available elsewhere. Some of these vendors will continue to innovate and ultimately emerge as strong leaders in this segment. Others will probably withdraw into niches or sell themselves to other companies that want to jumpstart their own CDP offerings.

One happy byproduct of these developments may be a final end to the theological debate over the proper definition of “Customer Data Platform”. As the campaign and delivery CDPs position themselves as marketing suites or platforms, they’re likely to move away from CDP as their primary label. But they’ll still need the world to know that they offer the core CDP capabilities of unified profile creation and sharing. With any luck at all, they’ll handle this by labeling those features as "CDP" when they describe their system capabilities. This should eventually lead to a more consistent use of the CDP term throughout the market and, thus, less confusion over what it means. The data and decision CDPs already define CDP in terms of the same core capabilities. Some of those firms are today pulling away from verbal confusion by labeling themselves as “infrastructure” or “pipeline” customer data platforms. If the narrower definition of CDP reasserts itself, they may come back to adopting the CDP label itself.

Salesforce Buys Datorama Customer Data Platform: It's Complicated

News that Salesforce had purchased Datorama crossed the wire just as I was starting on two weeks of travel, so I haven’t been able to comment until now. This was purchase was noteworthy as the first big CDP acquisition by a marketing cloud vendor. That the buyer was Salesforce was even more intriguing, given that they had purchased Mulesoft in March for $6.5 billion and that Marketing Cloud CEO Bob Stutz (who announced the Datorama deal) had called CDPs “a passing fad” and said Salesforce already had “all the pieces of a CDP” in an interview in June.

The Salesforce announcement didn’t refer to Datorama as a CDP and Datorama itself doesn’t use the term either. They do meet the requirements – packaged software building a unified, persistent customer database that’s open to other systems – but are definitely an outlier. In particular, Datorama ingests all types of marketing-related data, notably including ad campaign- and segment-level performance information as well as customer-level detail. Their stated positioning as “one centralized platform for all your marketing data and decision making” sure sounds like a CDP, but their focus has been on marketing performance, analytics, and data visualization. Before the acquisition, they told me some of their clients ingest customer-level detail but most do not. So it would appear that while Salesforce’s acquisition reflects recognition of the need for a persistent, unified marketing database (something they didn’t get with MuleSoft), they didn’t buy Datorama as a way to build a Single Customer View.

Datorama’s closest competitors are marketing analysis tools like Origami Logic and Beckon. I’ve never considered either of those CDPs because they clearly do not work with customer-level detail. Datorama competes to a lesser extent with generic business intelligence systems like Looker, Domo, Tableau, and Qlik. These traditionally have limited data integration capabilities although both Qlik and Tableau have recently purchased database building products (Podium Data and Empirical Systems, respectively), suggesting a mini-trend of its own. It’s worth noting that one of Datorama’s particular strengths is use of AI to simplify integration of new data sources. The firm’s more recent announcements have touted use of AI to find opportunities for new marketing programs.

Datorama is much larger than most other CDP vendors: it ranked third (behind Tealium and IgnitionOne) in the CDP Institute’s most recent industry report, based on number of employees found in LinkedIn. The company doesn’t release revenue figures but, assuming the 360 employees currently shown on LinkedIn generate $150,000 each, it would have a run rate of $54 million. (This is a crude guess: actual figure could easily be anywhere from $30 million to $80 million.) Sticking with the $54 million figure, the $800 million purchase price is 15x revenue, which is about what such companies cost. (Mulesoft went for 22x revenue.)  The company reports 3,000 clients, which again is a lot for a CDP but gives an average of under $20,000 per client. That’s very low for an enterprise CDP.  It reflects the fact that most of Datorama’s clients use it to analyze aggregated marketing data, not to manage customer-level details.

Seeing Datorama as more of an marketing analysis system than CDP makes it a little easier to understand why Salesforce continues to work with other CDP vendors. The Datorama announcement was followed a week later by news that Salesforce Ventures had led a $23.8 million investment in the SessionM CDP, which had announced an expanded Salesforce integration just one month earlier  SessionM builds its own database but its main strength is real-time personalization and loyalty. Salesforce in June also introduced Marketing Cloud Interaction Studio, a licensed version of the Thunderhead journey orchestration engine. Thunderhead also builds its own database and I consider it a CDP although they avoid the term, reflecting their primary focus on journey mapping and orchestration. The Salesforce announcement states explicitly that the Interaction Studio will shuffle customers between campaigns defined in the Marketing Cloud’s own Journey Builder, clarifying what any astute observer already knew: that Journey Builder is really about campaign flows, not true journey management.

So, how do all these pieces fit with each other and the rest of Salesforce Marketing Cloud? It’s possible that Salesforce will let Datorama, SessionM, and Interaction Studio independently build their own isolated databases but the disadvantages of that are obvious. It’s more likely that Salesforce will continue to argue that ExactTarget should be the central customer database, something that’s been their position so far even though every ExactTarget user I’ve ever spoken with has said it doesn’t work. The best possible outcome might be for Salesforce to use Datorama as its true CDP when a client wants one, and have it feed data into SessionM, Interaction Studio, ExactTarget, and other Marketing Cloud components as needed.  We'll see if that happens: it could evolve that way even if Salesforce doesn't intend it at the start.

Looking at this from another perspective: the combination of Datorama, SessionM, and Interaction Studio (Thunderhead) almost exactly fills every box in my standard diagram of CDP functions, which distinguishes the core data processing capabilities (ingest, process, expose) from optional analytics and engagement features.  Other Marketing Cloud components provide the Delivery capabilities that sit outside of the CDP, either directly (email and DMP) or through integrations.  The glaring gap is identity linkage, which Datorama didn't do the last time I checked.  But that's actually missing in many CDPs and often provided by third party systems.  Still, you shouldn't be too surprised to see Salesforce make another acquisition to plug that hole.  If you're wondering where Mulesoft fits, it may play a role in some of the data aggregation, indexing, reformatting, and exposing steps; I'm not clear how much of that is available in Datorama.  But Mulesoft also has functions outside of this structure.

In short, it's quite true that Salesforce has all the components of a CDP, especially when you include  Datorama in the mix.

The idea of stringing these systems together raises a general point that extends beyond Salesforce.  The reality is that almost every marketing system must import data into its own database, rather than connecting to a shared central data store. I’ll admit I’ve often drawn the picture as if there would be a direct connection between the CDP database and other applications.  This should never have been taken literally. There are indeed some situations where the CDP data is read directly, such as real time access to data about a single customer. But even those configurations usually require the CDP data to be indexed or extracted into a secondary format: absent special technology, you don’t do that sort of query directly against the primary “big data” store used by most CDPs.

Outside of those exceptions, a subset of CDP data will usually be loaded into the primary data store of the customer-facing applications (email, DMP, Web personalization, etc.). Realistically, those data stores are optimized for their own application and the applications read them directly.  There’s no practical way the applications can work without them.

This is a nuance that was rightly avoided in the early days of CDP as we struggled to explain the concept. But I think now that CDP is well enough understood that we can safely add some details to the picture to make it more realistic and avoid creating false expectations. I'll try to do that in the futre.

Teradata Adds a Data Management Platform To Its Marketing Cloud...Who Will Be Next?

Teradata on Tuesday announced it is adding a data management platform (DMP) to its marketing cloud through the acquisition of Netherlands-based FLXone.  This is interesting on several levels, including:

- It makes Teradata the third of the big marketing cloud vendors to add a DMP, joining Oracle DMP (BlueKai) and Adobe Audience Manager. I already expected the other cloud vendors to do this eventually; now I expect that will happen even sooner. I’m looking at you, Salesforce.com.

- Unlike Oracle and Adobe, Teradata has stated (in a briefing about the announcement) that it intends to use the DMP as the primary data store for all components of its suite. I see this as a huge difference from the other vendors, who maintain separate databases for each of their suite components and integrate them largely by swapping audience files with a few data elements on specified customers. (In fact, Adobe just last week briefed analysts on a new batch integration that pushes Campaign data into Audience Manager to build display advertising lookalike audiences. The process takes 24 hours.)

Of course, we’ll see what Teradata actually delivers in this regard.  It's also important to recognize that performance needs will almost surely require intermediate layers between the DMP's primary data store and the actual execution systems. This means the distinction between a single database and multiple databases isn’t as clear as I may be seeming to suggest. But I still think it’s an important difference in mindset.  In case it isn’t obvious, I think real integration does ultimately require running all systems on the same primary database.

- It is still more evidence of the merger between ad tech and martech. I know I wrote last week that this is old news, but there’s still plenty of work to be done to make it a reality. One consequence of "madtech" is complete solutions are even larger than before, making them even harder for non-giant firms to produce. That’s the primary lesson I took away from last week’s news that StrongView had been merged into Selligent: although StrongView’s vision of omni-channel “contextual marketing” made tons of sense, they didn’t have the resources to make it happen. (See J-P De Clerck's excellent piece for in-depth analysis of the StrongView/Selligent deal.)  I’m not sure the combined Selligent/StrongView is big enough either, or that Sellingent owner HGGC will make the other investments needed to fill all the gaps.

To be clear: I'm not saying small martech/adtech/madtech firms can't do well.  I think they can plug into a larger architecture that sits on top of a customer data platform and perhaps a shared decision platform. But I very much doubt that a mid-size software firm can build or buy a complete solution of its own.  If you're wondering just who I have in mind...well, Mom always told me that if I couldn’t say something nice, I shouldn’t say anything at all.  So I won’t name names.

Tealium Grows from Tag Manager to Customer Data Platform

It took me an embarrassingly long time to recognize why Tealium’s AudienceStream is just a bit odd. The oddity itself I saw immediately: while most marketing systems focus on sending messages to customers, AudienceStream is organized around overwriting data and sending it to other systems. The reason took longer to grasp: eventually I recalled that Tealium started as a tag management system and passing updated attributes to other systems is what tag managers do. So it’s perfectly natural for AudienceStream to offer precise control over which attributes are sent to which systems in which situations.

To some degree, the difference is just a matter of presentation. The data that Tealium sends to other systems can trigger customer messages from those systems.  So Tealium does support customer messaging.  But AudienceStream's heritage does give useful insights into what might otherwise seem a random set of strengths and weaknesses.

Let’s step back a bit. Like other tag management vendors, Tealium recognized several years ago that its core competency at capturing customer behavior could be applied to build unified customer profiles. This meant it could serve as a Customer Data Platform to support many other marketing applications. In fact, Tealium explicitly calls its product a CDP, using the tagline “build your own marketing cloud” to stress that it can connect systems from any vendor, not just components within a single vendor’s suite. That is indeed the essence of the CDP value proposition.

That doesn’t mean the Tealium is merely offering a relabeled tag manager. The company’s own diagram illustrates this clearly: the tag manager, Tealium iQ TMS (circled in red) is just one component of its CDP.  Here are key points to understand:

- scope is beyond Web channels. Conventional tags go on Web pages.  Tealium now offers connectors to gather data in other ways including APIs, batch file transfers, and system development kits (SDKs) for mobile apps.

- speed is real-time when possible. This is one benefit of the company’s tag management legacy, where real-time execution is required. It’s an important differentiator compared with other Customer Data Platforms, which often don’t support true real-time interactions.

- data storage is extensive. As the Tealium diagram implicitly indicates, a pure tag manager doesn’t need to permanently store much data. But Tealium incorporates several layers of persistent data, including semi-structured raw data in AudienceStore and EventStore (using Amazon Redshift), structured data in EventDB and AudienceDB, and an access layer in the AudienceStream iDMP (Data Management Platform).

- the system tracks individuals. The “i” in “iDMP” stands for individual, which pretty much says it all. Traditional DMPs are based on cookies, which are theoretically anonymous although they can often traced to specific individuals in practice. Tealium’s iDMP stores both cookies and personal identifiers such email addresses. It builds profiles by linking people to devices they have used for identity-revealing tasks such as opening an email or logging into an account. Devices used by the same person are then linked to each other. The system does not apply “probabilistic” or “fuzzy” matching to infer linkages using other data, such as simultaneous activities, shared locations, or similar names.  Users who want such links can import them from external services such as LiveRamp.  Tealium does link its cookies with major ad networks through other DMPs, although it won’t pass on individual identifiers.

- sophisticated rules support enhancement, segmentation, and triggers. This is another outgrowth of tag management, which sends different information to different partners. Derived attributes can be calculated with complex formulas including current data, time periods, ratios, rolling averages, random splits, and other functions. Similarly complex rules can assign people to audiences or segments and can set up triggers that change data values and send messages to external systems. Users can give higher priority to more important actions and can limit how many times an action is executed for the same person (for example, to avoid sending too many messages or repeating the same message). Again, this all happens in real time as data flows into the system.

- lots of connectors. Tealium cites integration with nearly 1,000 other systems. Most of these are for tag management but about 20 are to message delivery systems including ecommerce, email, marketing automation, CRM, and advertising vendors. Users can connect with additional systems through Webhooks, SDKs, or APIs. Reporting and analytical systems can query the underlying data directly, receive file extracts, or subscribe to a live stream from the collection server.

- it doesn’t do everything. Tealium offers a remarkably powerful data-layer CDP.  It extends a bit into decisions by applying segments, creating derived variables, setting up triggers, and sending audiences to execution systems. But it doesn’t do multi-step campaigns, predictive analytics, offer tracking, and supporting functions like content management. So, although AudienceStream can connect directly with message delivery systems to manage some types of campaigns, most users will combine it with a more robust decision system to properly manage relationships. It probably makes the most sense to view system’s segmentation, enhancement and (to a lesser degree) trigger capabilities as part of creating a rich customer database, not as directly managing customer relationships. This is perfectly consistent with Tealium’s own “do it yourself marketing cloud” goal of letting its clients work with whatever decision and delivery tools they wish.

Tealium introduced AudienceStream in late 2013.  It is currently used by about 100 of its 550 clients.  Pricing is based on events processed and starts around $12,000 for a small implementation. Mid-size and bigger customers can expect to pay more..

Marketo Conference: Small Changes, Big Picture

Marketo wrapped up its three day Marketing Nation conference yesterday, having once more displayed its own marketing prowess by attracting national media attention (see here and here) with an appearance by Hillary Clinton. Still, the real focus was on Marketo’s own announcements, which included several product changes and a new positioning. (I wasn’t at the conference but Marketo briefed me on their plans.)

The product changes were quite modest: new search engine optimization features for entry level users; a global marketing calendar; and relabeling of InsightEra, which Marketo purchased in December, as Marketo Real Time Personalization. The SEO and calendar features are still in beta and will be rolled out this spring and summer. Real Time Personalization already exists, obviously, and will remain a separate product that can work with any marketing automation system.

The company also announced a deal to use Acxiom data for personalization and, somewhat more interesting, to coordinate advertising messages purchased through Acxiom with email and Web site messages delivered by Marketo. This borders on integration of Web display with marketing automation, an extremely important trend. But it's Acxiom, not Marketo, doing the hard part of matching advertising audiences with identified individuals.

Marketo placed these changes in the context of unveiling itself as “customer engagement platform”. Ordinarily, I don’t pay much attention to these announcements: after all, Marketo has pivoted more than Ben Franklin dancing a gavotte. But Marketo had the hype-blasters turned to 11, so the news is impossible to ignore.

My main reaction was, what’s new? Marketo has described itself as a platform for at least a year now (see this press release, for example) and I’ve been talking about marketing systems as platforms for even longer. More important, the value of platforms has been widely recognized through the tech industry for decades: classic examples include Salesforce.com’s own AppExchange, Apple’s iPhone AppStore, Microsoft’s operating system software, and, going way back, the original IBM System 360. The appeal of the platform model is obvious: platform systems are quasi-monopolies (or actual monopolies), so their owners can charge high prices while the app developers compete brutally with each other and must keep prices low. Consumers are intuitively reluctant to accept the monopoly relationship, but usually trade away their freedom because no other choice available or in exchange for convenience and low total cost. App developers make a similar calculation, trading lower margins and less control for the larger marketplace and less development expense.

The trick to winning these benefits is becoming a platform in the first place. This requires a large customer base, easy access by app developers, enough power to be useful, and a barrier that keeps the monopoly intact. Salesforce.com, Oracle, IBM, Adobe, Microsoft, and other contenders to own “customer experience platforms” all did it the hard way, by first building up a big customer base for their conventional systems and then opening that universe as a platform to app developers.

Every major marketing automation vendor has tried to do the same.  But their customer bases are nowhere near as large, so what’s actually happened in most cases is that app developers have integrated their systems with multiple “platforms”.  One of the more subtle tricks in the platform playbook is to prevent this by making your system different enough from others that it isn't easy to support them as well.  This is usually done by means of a uniquely structured application program interface. But developers won’t put up with this unless a platform offers a big enough audience or other benefits to make it worthwhile. It’s doubtful that Marketo, or any other remaining independent marketing automation vendor, has the market power to do this.

Let me be clear. I’m not saying the platform approach is a bad one for Marketo.  I’m saying they lack the market strength to erect barriers to collect monopoly rents. They’ll have to keep their APIs simple enough that app developers can integrate with other marketing automation systems as well.  This means Marketo will be competing with other platforms for app developer relationships and can’t rely on Marketo-exclusive apps to attract new customers or prevent old ones from leaving. This is good news for app developers and marketers, if not for Marketo investors.

But it’s not enough to decide to be a platform. You have to decide whom the platform will serve and what functions it will include. In the case of customer management, the big question is whether the marketing system should be separate from sales and service systems. The obvious answer is they should be the same: after all, we want a unified customer experience across the entire life cycle, so all departments delivering those experiences should be on the same platform. Indeed, Marketo seems to imply as much with the term “customer experience platform”.

But in an excellent blog post describing the new positioning, Marketo VP Marketing and co-founder Jon Miller makes clear that Marketo believes marketers alone are in charge: “marketers are responsible for an all-consuming process that starts with attracting initial buyer attention and continues all the way to locking in customer loyalty and advocacy.” To remove any doubt, he later clarifies that the “customer engagement platform is the core system of record for marketing, just like CRM is the system for sales and Human Capital Management is the system for HR.”

I’d say this approach is debatable.  It will probably be harder for a marketing-owned system to integrate with customer-facing systems in other departments. Certainly other “marketing cloud” providers like Salesforce.com and Oracle would argue otherwise – that, at the least, there should be a shared customer database, and probably some shared processes to select customer treatments, even if those treatments are delivered by channel- or department-specific systems.

Marketo’s conclusion does position them as the best choice for marketing buyers, since they are the only marketing platform vendor with such a limited scope. To quote Miller again: “The marketing platform provider should be a partner to marketing, a company that truly understands what’s happening in marketing and that 'has marketing’s back'. Your marketing platform is not an add-on to sales technology, or a component of an IT solution. It’s the core foundation to all aspects of marketing success. That’s why at Marketo, we think that a marketing platform should come from a company 100% focused on marketing.” Fair enough.

The second big question is what’s included in the core platform and what’s provided by partners. In many ways, this is where the discussion moves from theory to reality, since there are specific choices to be made. Marketo’s published diagram lists three major functions at the platform layer – decisioning (a.k.a. “the brain”), database (“marketing system of record”) and analytics. They put an application layer on top of that, including marketing automation, interactions (real time personalization, search engine optimization, social marketing), and operations (marketing management). The third layer includes delivery in different channels (email, social, landing pages, sales, web/mobile personalization, search). APIs are available to connect each layer to third party applications.

My own definition of the platform layer is pretty much the same as Marketo’s. But Miller’s post lists six components of a marketing platform, corresponding to both the platform and application layers. And Marketo actually delivers functionality across all three layers. In other words, Marketo is not actually selling the platform by itself: it sells the platform in combination with applications and delivery systems, some of which are included and some of which are optional.

At first I thought this violated the platform concept, since the vendor’s own tools will likely have tighter integration with the rest of the system than the APIs make available to third parties. But, on reflection, there’s no requirement for a platform to be fully “application neutral”. Marketo seems to be proposing to sell a basic set of applications and delivery systems and let clients supplement them with third party applications as needed. APIs are an escape hatch for emergency use only, not Lego blocks that let users build a custom collection of products from scratch.

There’s a good case to be made for bundling the platform with applications and execution systems, boiling down to that it saves marketers from having to make a lot of choices before they get started. It also justifies a much higher price than the platform alone, especially if the monopoly position is unavailable. Of course, this ends up looking an awful lot like a traditional marketing software suite, which is exactly what Marketo was and remains under the hood. Marketers excited by the platform vision should look very closely at the reality before assuming that Marketo, or anyone else, can deliver the benefits they expect.

Oracle Buys BlueKai and Puts Marketing Databases In the Spotlight

Oracle announced this morning  that it is buying BlueKai, a leading Data Management Platform (DMP) technology vendor and operator of one of the largest data marketplaces. Since I just wrote last Friday about how DMPs integrate with marketing automation to unify customer treatments in Web advertising and direct channels, I’m tempted to just point you to that post for an explanation of how this works and why it matters. I’m also tempted to remind you that I predicted this convergence as an industry trend back in December.  But instead I’ll expand a bit on the fundamental significance of this deal – which is that it promises a serious step toward solving the fundamental problem that increasingly hobbles advanced marketing technology: lack of a solid underlying customer database.

If you look at Oracle’s diagram of their newly expanded Marketing Cloud, you’ll see BlueKai sitting beneath Responsys and Eloqua, providing a “universal customer profile” that allows them to act as “marketing orchestration” systems which, in turn, support programs across all channels – social, search, email, display, mobile, web, commerce, direct sales, and channel sales.

“Marketing orchestration” is a considerable jump beyond the traditional role of “marketing automation”, but I’ll save that analysis for another day. What matters right now is that Oracle places BlueKai exactly where I’ve been placing the Customer Data Platform: as a multi-source database that feeds unified customer data to marketing applications.

This is the first time we’ve seen a major enterprise software vendor draw that picture quite so clearly. More typically, they just do some hand waving around the customer database without explaining how it magically appears. Deep in their hearts, what they really hope is that the database for their core application – CRM, email, Web site management, whatever – will be that central, shared database.  They hope this even though their application doesn’t really provide the database management tools needed to make it happen, and their database itself is often tailored too narrowly to the specific application to support the full range of other uses.

BlueKai, on the other hand, is all about the data. Like other DMPs, it is still mostly organized around cookies and advertising audiences, but it does offer the ability to import other types of data and can certainly track identified individuals if the user wants. The fact that it can combine anonymous and identified profiles is extremely important if marketers are to build a single unified customer data repository and use it to support all contact channels, including Web advertising. The fact that it’s a distinct, named product gives that central customer database the prominence that it deserves.

In short – and I don’t use this term loosely – the BlueKai acquisition could truly be a “game changer” that forces other enterprise software vendors to also give marketers the CDP-style database building tools they’ve needed so desperately. As of this morning, Oracle’s competitors have a new gap in their product lines. It will be interesting to see how they fill it.

Marketing Automation's Unhappy Users: Trouble in Paradise?

As I mentioned in last week's post, I’m writing a paper on stages of marketing automation deployment. Key findings will be presented in a Webinar next Thursday, sponsored by TreeHouse Interactive; you can register here. The paper itself will be available to Webinar attendees.

The premise of the paper and Webinar is marketing automation has a problem: clients who don’t move beyond basic email functions are unhappy. Last week’s post provided statistics that show how many marketers fail to make this transition, but it didn’t actually show why this matters. So let’s look at some more data that illustrates the trouble in marketing automation paradise.

First we’ll start with the paradise itself: B2B marketing automation has indeed been growing quickly, at about 50% per year over the past few years according to my estimates.  I do expect that to slow somewhat in 2014 as the core market of tech companies approaches saturation and adoption in other industries remains spotty. The great hope is that acquisitions by Oracle, Salesforce.com, Adobe, and other big software vendors finally push the industry across this classic Geoffrey Moore chasm from the beachhead niche to mainstream users, but that’s by no means certain to happen.

If and when that growth does occur, it will be fueled by positive experiences of previous users. But the news on that front is mixed: a survey by one of the industry’s best analysts, Jim Lenskold, found 60% of marketing automation users reporting increases in the key value measures of lead quantity and quality. That’s a happy majority, but it also means that about 30% found no improvement or even a decline.

Questions about satisfaction give a similarly ambiguous result: just over two-thirds of users in a Winsper Group survey reported themselves satisfied with the business value of their system, again meaning that nearly one-third were neutral or actively dissatisfied.

Even more scary (and just in time for Halloween, if you're still looking for a costume): yet another survey, this by Holger Schulze, found that 31% of current marketing automation users anticipate changing their system within the next two years, nearly always because they want better or different capabilities.

Although these figures come from different sources, they all point to the same conclusion: about 30% of marketing automation users are not happy with their systems. The Schulze survey suggests that most believe a different system will give them better results, so they’re not yet ready to give up on marketing automation entirely.

But will those users really do any better with a different product? I’d be the last person to say that all marketing automation systems are the same, but it's also true that the vast majority of systems purchased have all the functions needed to run a successful marketing program. Some fraction of users really did buy the wrong product, but I’ve no doubt that most have problems due to flawed deployment.

One final survey reinforces this point. This one, from BtoB Online, found that just 26% of users had fully deployed their system – and nearly 40% had only some or moderate adoption.

I’d guess that the dissatisfied users in the earlier surveys are concentrated in the low deployment groups in this survey.  But if that’s true, those marketers are abandoning their systems before giving them a real chance. The BtoB survey does show that strong and complete adoption have increased considerably from 2012 to 2013, which is good news.  It also shows that full adoption will double next year, which would be even better news if it happened – but those figures probably reflect aspirations more than reality.


All of this brings us back to where we started: rather than blaming their tools, marketers need to work harder at ensuring full deployment of the systems they’re already purchased. Join me at next week’s Webinar for a roadmap to making this happen.