0 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.

0 Infor Epiphany Marketing and Interaction Advisor: Good Examples of B2C Marketing Automation

Epiphany was one of the high-fliers of an earlier marketing automation boom: launched in 1997 with an initial public offering in 1999, it traded stock for a full suite of marketing and CRM systems before its price collapsed. The remains were scooped up in 2005 by SSA Global, which was itself purchased in 2006 by enterprise software vendor Infor. Through all this, the company’s products continued to sell with little change. The crown jewel turned out to be RightPoint, a pioneering real-time interaction manager now called Interaction Advisor.

Infor has recently renewed its commitment to the Epiphany line, increasing investment in the product and its marketing. Recent improvements include a unified interface for inbound and outbound campaigns, tighter integration among its components, greater scalability, support for more channels, and pre-packaged solutions for specific applications. The vendor has integrated with Orbis Global for marketing resource management and has an AppExchange integration with Salesforce.com. A new user interface is planned for next year.

As I noted in yesterday’s post, B2C marketing systems like Epiphany have actually been more popular acquisition targets than B2B products. Since many readers of this blog are unfamiliar with the B2C products, it’s worth taking a detailed look at Epiphany’s components.

Let’s start with the marketing automation product, Infor Epiphany Marketing. This sits on a marketing database built outside of the system; part of the set-up is mapping that to Epiphany. This is already a contrast to B2B marketing automation, where the database is part of the system and structures are largely limited to contacts, accounts, and marketing interactions.

In addition to the external data, Epiphany does maintain its own database of operational components. These are arranged in a standard model including programs, which can contain multiple campaigns, which in turn can have multiple communications (messages) and cells (contact groups). Communications can be shared by multiple cells, and one cell can use multiple communications. Each communication may contain one or more creatives, which are specific bits of marketing content. Campaigns, communications, and cells can all be assigned to output channels.

The model also contains segments (sets of customers or prospects), events (campaign triggers, which can be based on time, channel, behavior, queries, or feeds from external Web services), and packages (sets of campaigns used for Interaction Advisor). Campaigns can be divided into waves, each with its own schedule. The schedules can have a fixed date, recur at fixed intervals (from minutes to weeks), or be triggered by events.

Events can be captured as they happen, but the system still pushes the responses to a queue to batch the replies.  The queue might be cleared as often as each minute for near-real-time messaging such as a purchase confirmation email. It might wait longer for media such as direct mail, where there are significant economies of scale.  Bear in mind that this limit applies only to outbound campaigns: Interaction Advisor provides true real-time response to inbound interactions.

Users can also create global marketing rules that apply across campaigns.  These help to enforce regulatory constraints, such as age restrictions or opt-out compliance, or company policies such as limits on the number of messages within a time period.

The structure I've just described is substantially more complicated than most B2B marketing automation systems. That complexity adds some cost, but it also lets users can more easily manage shared components and analyze results by communication, channel, program, segment, and other groupings. This is hugely important in managing marketing programs with hundreds or thousands of components, a typical B2C requirement.

Epiphany campaigns are set up by assembling segments in a hierarchical tree, splitting them into cells if desired, and assigning a communication to each cell. Rules and segmentations are built with a powerful query builder that can read any data in the system, including transaction details, and supports relative dates, value ranges, events, ranking (e.g. 100 highest-revenue customers), and negatives (e.g., has not bought a specific product). Again, this is typical of B2C systems, while B2B query builders are sometimes more limited.

Beyond campaign management, Epiphany Marketing provides integrated data mining and predictive models; advanced reporting and visualization, including use of report cells as campaign segments; an executive dashboard; global permissions and security management; and the Orbis Global integration for marketing calendars, workflow, digital asset management, and financials. These are rarely available in B2B marketing automation systems, although exceptions exist.

Epiphany Marketing has its own email engine.  It actually supports two kinds of dynamic content.  One is your everyday dynamic content, where rules within the email determine what’s shown to each recipient. The other, which Infor calls “true” dynamic content, can change the contents after a message is delivered. It does this by calling back to Interaction Advisor for a selection based on current information. Neat trick.

On the other hand, Epiphany Marketing currently lacks an end-user tool to build emails or landing pages. This is one feature found in even the mostly lowly B2B systems. But gap exists because Epiphany and other B2C systems were designed primarily for large organizations where content is created by full-time designers or external agencies. Infor plans to add a content builder next year, and other B2C vendors will probably do the same if they haven't already.

So much for Epiphany Marketing. It’s neither the best nor the worst B2C marketing system.  But it’s a good example of what those products provide and how they differ from B2B marketing automation products.

Interaction Advisor, on the other can at least make a plausible claim to leading its industry. With nearly 200 installations, it may well have more clients than any competitor – systems including Oracle Real Time Decisions, IBM Unica Interact, Pega Next-Best-Action Marketing, SAP Real-Time Offer Management, and a host of others.

These systems all work roughly the same way. They connect with external customer-facing platforms, usually Web sites or call centers, which alert them when a customer or prospect starts an interaction. The systems pull information about the customer from the external system and other sources, apply rules and predictive models to recommend a treatment, and send the recommendation back to the customer-facing system for delivery.

The connections with external systems are made through Application Program Interfaces (APIs) provided by those systems, so the interaction managers handle those pretty similarly – although there are some differences in the types of connections they support.  The more important variations are in their internal decision-making process. Specific considerations include the complexity, scope and difficulty of creating rules; the predictive modeling methods and user requirements; and how the system reconciles conflicting priorities in making its final recommendation.


Interaction Advisor handles all these quite nicely. The vendor divides the process into four steps: dynamic profiling (gathering the data); business rules (selecting options to consider); real-time analytics (self-managing predictive models); and arbitration (selecting the best option based on user objectives).

In practice, the process starts with a call from an external system. This could be triggered by a tag embedded in Web page or call center screen. The call contains information about the current customer and the context. It carries the identity of an Interaction Advisor event, which tells the system what campaigns to apply and how many recommendations to return. The system might need several responses to display multiple ads on a Web page or to give a call center agent some choices.

When the call is received, Interaction Advisor creates a session that will remain open until the interaction is complete. It stores the data it received in memory and then queries other systems, such as the company’s marketing database, customer files, and inventory systems, to assemble whatever other data it needs. This is also stored in memory: there is no persistent customer profile within Interaction Advisor although some information generated during the interaction will be stored permanently.

The system then executes the rules, which first activate the specified marketing campaigns and then determine which offers within those campaigns are available to this customer in this situation. (For example, the system might exclude offers within the campaign for products the customer has already purchased or recently rejected.) There might be additional constraints such as ensuring that offers relate to the contents of the originating Web page or don’t include conflicting products.

Once the eligible offers are identified, the system activates its predictive models. Interaction Advisor supports two types of predictions: Bayesian models that estimate the likelihood of the customer responding to one specific offer, and collaborative filtering that identifies offers most commonly selected together. Both are self-generating and self-tuning, so human model-builders are not needed. The Bayesian models do provide reports on which attributes have the most influence on the likelihood score.  These provide useful business insight and let users check that the models are reasonable.  The system keeps a record of offers made and accepted, which is essential for the Bayesian modeling technique.

The final step is arbitration. This looks at the likelihood scores for the eligible offers, the value (revenue or profit) from each offer, and perhaps other considerations such as inventory levels or sales quotas. Users set up arbitration rules depending on their priorities: they might want to make the offer most likely to be accepted, the offer with the highest value, or the offer with the highest expected value (i.e., likelihood x value). One arbitration scheme can apply across multiple events, even if they involve different campaigns and offers.

Once the offers are chosen, the system passes the customer-facing system a content ID that tells it what to display. Interaction Advisor could also store the content internally and send it instead of an ID.  But most users prefer to let the customer-facing system to manage its own content.

The call-and-response cycle just described applies to a single interaction. Interaction Advisor doesn’t execute multi-step dialogs like a call center script or sequence of Web pages. Users could accomplish that indirectly by creating different events that call different rules, or by creating eligibility rules that take into account previous activities. Since sessions remain active for a user-specified period of time, previous events within the sequence are all immediately available. However, sessions are channel-specific, so a customer simultaneously looking at a Web page and talking to a call center agent would have two independent sessions active. At best, the data in those sessions could be shared by posting it to an underlying database. Posting also makes the interaction history available to in the future.

Products like Interaction Advisor often generate substantially more revenue than manual recommendations.  They are priced accordingly: a single-channel Interaction Advisor installation starts around $150,000 and could run much higher. Fees are usually based on the number of users in a call center or sales agent environment, or the number of recommendations or visitors in an automated environment like a Web site. Most clients install InteractionAdvisor on-premise, although hosted options are available.