Adobe Buys B2C Marketing Automation Leader Neolane: One Gap Filled, But Where's CRM?

Adobe today announced plans to acquire Neolane, the largest remaining independent B2C marketing automation vendor (excluding email-focused providers like Responsys and Silverpop). Price was $600 million, which is roughly in line with the 8x revenue paid for ExactTarget and Eloqua recently.  (Neolane announced $58 million revenue in 2012 and has been growing around 40% per year, which would yield about $80 million 2013 revenue.)

The deal is not particularly surprising. Adobe was on everyone’s list of potential buyers, and Neolane was ripe for acquisition or an initial public offering. It reinforces suspicions that Adobe was the mystery bidder for ExactTarget mentioned last month by Salesforce.com.  Indeed, my take on the ExactTarget deal explicitly mentioned an Adobe/Neolane possibility. That frankly didn’t take much insight, but I’ll brag a bit more about having pegged Adobe as needing to add marketing automation as far back as this post in 2009 and again in 2010.

Neolane is more of a mid-tier solution than an enterprise product, which may be a slight mismatch with Adobe.  I’d say that reflects a lack of enterprise systems available for Adobe to purchase, more than any particular desire to target the mid-market.

Predictable or not, this deal does fill a gaping hole in Adobe’s marketing cloud. It still doesn’t put Adobe on equal footing with Oracle, Salesforce, SAP or Microsoft, since they all have major CRM platforms which Adobe does not. Adobe obviously has a leadership position in content creation, although I’ve never felt that does much good in selling customer management systems. (To be more precise, content creation COULD give Adobe an advantage if it very tightly coupled auto-personalized marketing treatments with content creation, but that doesn't seem to be happening.)

More important, Adobe also has an unmatched position in Web analytics, Web advertising, and Web content management. In fact, adding Neolane gives it a profile very similar to IBM, which also has strong Web and marketing automation products but not CRM (and which also shares Adobe’s digital-is-everything mono-vision).

Come to think of it, the contrast still comes down to the dueling strategies I described in 2011: Web-plus-marketing automation (Adobe and IBM) vs. CRM-plus-marketing automation (Oracle, Salesforce, SAP, Microsoft). Everything will eventually converge Web-plus-CRM, with marketing automation baked in so deep you can't see it.  But that’s still some way off, except arguably for Oracle, which has all the pieces but hasn’t fully integrated them. In the meantime, we’ll see which approach is more popular – and what becomes of the stand-alone marketing automation vendors who are caught in between.

[x+1] Origin Digital Marketing Hub Offers Cross-Channel Decision Management

My recent posts on real time decision systems have all described products from vendors of batch-oriented, outbound campaign management systems. Expansion to real time decisions helps those vendors cement their strategic position as a complete solution for marketing departments. But technically the two sets of systems have little in common: outbound systems create lists for direct mail and email, while real time systems generate recommendations for Web sites and call centers. Knowing this, you might suspect there are other real time decision management vendors with roots in Web marketing. You would be correct.

[x+1] Origin Digital Marketing Hub is one example. [x+1] originally began as Poindexter Systems, which offered real-time Web ad optimization based in predictive models and anonymous user profiles. This was an early form of what now called a Data Management Platform (DMP), which one articulate blogger defined as “a very smart, very fast cookie warehouse with analytical firepower to crunch, de-duplicate, and integrate your data with any technology platform you desire.”

You could also see DMPs as a type of marketing database because they have the key characteristic of being organized around individual prospects and customers. It’s true that DMPs identify individuals with cookies, not a conventional name and address. But both types of systems can still perform the basic marketing database functions of sending messages to individuals and tracking their responses.

That original DMP is still the foundation of the [x+1] suite. But the company has also extended into Web ad buying (Origin Media DSP), Web site recommendations (Origin Site), attribution (Origin Analytics), and cross channel marketing (Origin Digital Marketing Hub). Supporting multiple channels and potentially storing names and addresses puts [x+1] Hub into direct competition with other real-time decision management products.

I’ll assess the Hub against my real time decision management framework in a minute. But first let's look at [x+1]’s features that are not found in a typical real time decision manager. These include:

- Web tag management: the system provides Javascript code to tag Web pages and advertisements, drop cookies on visitors’ computers, and then use those cookies to track visitor behaviors. The system also supports server-to-server connections that capture user behavior without relying on cookies. Most real time decision systems rely on external systems to capture this data.

-Web audience management: [x+1] Hub can integrate Web audience data from external compilers such as BlueKai and eXelate, enabling marketers to use that information for decisions and targeting. In theory, any decision manager could access the APIs of those providers, but [x+1] is designed specifically to integrate their data and manage the associated charges. [x+1] can also help sell the client’s own data to external syndicators.

- Web media buying: [x+1] can manage real-time bids and other Web advertising purchases. Users set up campaigns with budgets, cost targets, date ranges and other parameters for the system to execute automatically. The system can also track media purchases made outside of [x+1]. Reports provide detailed information on reach, frequency, pacing, inventory, and other advertising-specific metrics.

- attribution: the system tracks visitors through user-defined funnel stages, as defined by visits to specified Web pages or media exposures.  It then uses regression analysis to estimate the influence of each promotion and promotion attributes, such as ad size and format, on stage movement . This is much more sophisticated than the first touch, last touch, or fractional attribution methods available in standard marketing systems.


These features make clear that [x+1] Hub isn’t directly comparable to conventional real time decision systems. But [x+1] does offer itself for real time decision applications, and the whole point of decision management is to centralize decisions within a single system. This means that [x+1] Hub is inevitably competing with the other products to be the one thing that rules them all.

So, how does [x+1] Hub stack up against my decision management criteria?

- connecting to external systems. Like other real time decision managers, [x+1] Hub can connect to external systems via Web services and batch file imports.  It can also capture Web traffic via the Javascript tags and server-to-server connections. However, displaying the returned messages on a Web site requires code created outside of the system.  [x+1] Hub has existing integrations into call center, search, mobile, SMS, social, and email products.

Visitor profiles are stored permanently within the system and can contain whatever attributes the user chooses. The base set includes visitor behaviors, http header attributes (browser, operating system, location derived from IP address, etc.), information imported from external data vendors, and a history of messages presented to each individual. The system can link cookies from [x+1], the client, and third party vendors once these are identified as the same person. Partners including LiveRamp, i-Behavior and Datalogix can link online and offline identities.

Web behaviors and imported data can trigger actions including as assigning a visitor to a segment, adjusting a counter, exporting data, and sending a message through an external system. The results of these actions are stored in the [x+1] database where they can be inputs to other decision rules.

- making decisions based on rules and predictive models. Decision rules in [x+1] Hub are organized into two layers: the system first tests a visitor against one or more “targeted experience” definitions until it finds a match; then, it tests the visitor against a sequence of “targeting rules” associated with the winning experience. Each rule returns a specified offer or creative treatment. Offers and creatives can also have their own eligibility rules, which apply across all campaigns.

Rules can include if/then logic or predictive models. If the models are used, [x+1] can generate scores for multiple responses and pick the best option based on response probability, expected value, or other formulas. This lets the [x+1] select the best option for each individual even though the system always selects the first rule the visitor matches. There are also default choices in case the visitor fails to meet any other rule.

The models are set up by [x+1] technicians. Scoring formulas can incorporate external data, such as inventory levels or sales goals, so long as these are accessible to [x+1] via data import or API connections. Users can also specify the percentage of responses that will receive each option, allowing the system to deliver a fixed mix of results even if the models would favor some choices less or more often.

The system can return multiple offers in response to a single request. Users can block these from containing duplicate offers. Users can also set up “creative groups” of incompatible offers and have the system return only one offer from each group.

- integration with campaign and content systems. [x+1] Hub is not part of a suite with its own outbound campaign manager, although it can be integrated with other vendors’ campaign management products. Similarly, the system also doesn’t store or render content but can connect with third party content management systems. [x+1] does maintain a registry of content IDs that are sent back to execution systems, which look up and render the related messages.

- deployment model. The entire [x+1] suite is sold as a subscription. This can include the software only or software plus supplemental services. On-premise deployment is technically possible but no client has yet selected it. Pricing is based on system functions and volumes. It starts around $12,500 per month but can be lower if the client is also buying media through [x+1].

All told, [x+1] Hub seems functionally competitive with stand-alone decision managers. Still, the system’s main appeal will be to marketers who want the DMP, media buying and attribution features. Those marketers should find that [x+1] Hub lets them coordinate real-time customer treatments across all channels without purchasing a separate decision management system.

A Framework for Real Time Decision Management: How SAS RTDM Fits In

I’ve had a couple of consulting projects recently that involve real-time decision systems (a.k.a. real time interaction managers), which are used to select the best treatment during a Web visit, telephone call, or other interaction.  This type of software has been around for two decades or more and repeatedly proven its value, but still has relatively few implementations.

There are many possible reasons for the slow adoption.  Maybe marketers don’t realize how much  improvement they get from driving recommendation with predictive models rather than simple rules.  Perhaps the decision capabilities built into delivery systems are already adequate.  The delivery systems are controlled by Web and call center managers who are not incented to generate revenue and may not be interested in a shared decision engine to coordinate customer treatments. Maybe each of these plays a role.

Still, the interest among my own clients has been enough to spur a fresh look at the vendors in this field.  To gather this information systematically, I need a framework that lists standard features and options within those features.  This makes it easy to isolate critical differences among the products.

For real-time decision managers, the framework includes:

• connecting to external systems.  This includes the touchpoints (customer-facing execution systems), such as Web sites and call centers, and other systems with relevant data, such as order processing and marketing databases. Connections to touchpoints are typically through Web Services calls; connections to other sources are usually made through API calls and SQL queries. The connections are set up during system implementation and then used in real time to look up information about a specific individual during an interaction. One important difference among real time decision systems is whether they look up information each time they are asked for a decision, or whether they look it up once at the start of an interaction and then retain it in a session until the interaction is complete.  The session reducing workload and helps to run multi-step dialogues. Another difference is whether the system maintains its own permanent database of individual profiles and contact history or must query external systems for all data.

• making decisions based on rules and predictive models. Rules are always available; systems differ greatly in how hard they are to build and maintain. Predictive models are optional.  They be built outside of the system, built within the system in periodic (batch) processes, or built and updated automatically. Systems also differ considerably in how they choose among competing treatments, a process called “arbitration”. The ranking may be as simple as picking the offer most likely to be accepted, or it may involve complex user-specified considerations such as offer value, sales targets, and business priorities. Some systems let users apply weights to multiple factors.

• integration with campaign and content systems. Early decision systems were not connected to outbound campaign managers or to content stores. But today they are often part of a larger marketing suite that includes an outbound campaign manager. The decision system may share campaign flows, offer definitions, customer data, analytics, and other features with the campaign manager. This simplifies training and facilitates integrated, cross-channel customer treatments. But even the unified systems typically run the outbound campaigns and real-time decisions on separate engines, each optimized for its particular type of processing. Regarding content: the decision systems traditionally returned a content ID that the execution system converted to actual content internally. When the decision manager is part of a marketing suite that includes a content repository, it can return the content itself.

• deployment model. Most real-time decision managers are deployed the old-fashioned way, as on-premise software. This gives clients the greatest control over security and performance. Some are cloud-based or vendor hosted (not precisely the same thing, but close enough), which simplifies deployment. Several vendors offer both options.

With that framework in mind, let’s take a look at another product in this group: SAS Real Time Decision Manager (RTDM).

RTDM meets all the framework requirements: it receives a Web Services request from an external system for a decision, runs the request through rules and models, and returns one or more choices. The results are usually displayed in a slot on a Web page or call center screen, although they could also be presented in an email, mobile device, or other channel.

RTDM leans toward the simpler end of most framework options. Each request loads fresh data from the touchpoint and other source systems, even within a multi-step interaction. At best, users can create continuity by storing a session token at the end of one interaction and retrieving it at the start of the next interaction. The systems returns tags, IDs or URLs but not actual content.

Decisions are based primarily on rules. These can incorporate predictive models, but the models themselves are built outside of the system, using SAS or other products, and do not self-adjust based on results. The system can select among multiple results by sorting on one or more user-specified variables, although any more complex arbitration requires custom coding in the SAS language.  Such  formulas could be registered in the system and reused across campaigns. Users can define a group of treatments, called a “campaign set”, that share a single set of eligibility rules. Individual treatments can also have their own eligibility rules that are applied whenever the treatment is used.

RTDM is tightly integrated with SAS’s campaign management system, SAS Marketing Automation. It shares the same campaign flow interface, treatment library, and database of contacts and responses. Predictive models built with SAS tools are also available to both.  Both use other SAS platform components including data structures, reporting tools, and other general functions. RTDM can be installed on-premise or hosted by SAS.

RTDM has been around in some form since 2008, although integration with the Marketing Automation treatment library is more recent. The system has sold more than 50 licenses, although fewer than half have been deployed. SAS says most deployments have been single-channel, single-purpose projects. Deployment has come slower where RTDM is part of a larger multi-channel deployment involving other SAS marketing products.  The other components must be put in place before the client is ready for RTDM.

Pricing of the system is based on the number of decisions processed or call center seats.  Cost starts around $150,000.