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

Pitney Bowes Interaction Optimizer and Dialogue Offer Unified Inbound/Outbound Marketing Campaigns

In his classic Harvard Business Review article Marketing Myopia, Theodore Levitt argued that railroad companies could have survived the rise of the automobile had they considered their business to be providing transportation, not running trains. Someone at Pitney Bowes clearly got the message.  The postal equipment giant has aggressively moved to become a provider of “customer communication technologies”, making 83 acquisitions costing $2.5 billion since 2000.  Purchases have included Group 1 Software (2004), MapInfo (2007) and Portrait Software (2010), which are now part of a customer analytics and interaction group within the company’s software division.

Portrait itself brought an agglomeration of previous acquisitions, having expanded its original customer relationship management system by purchasing Quadstone analytics in 2005 and Million Handshakes marketing automation in 2008. Their descendants are now modules within integrated Portrait suite, including Portrait Explorer (visualization), Miner (predictive modeling), Uplift (model-based treatment selection), Foundation (data access and integration), Dialogue (multi-step outbound campaigns), and Interaction Optimizer (real-time decisions).

Dialogue and Interaction Optimizer are closely linked, sharing a user interface for campaign definition and both using Foundation to connect with external systems. The interface, called HQ, lets marketers define a hierarchy of campaigns linked to multiple marketing activities, which in turn contain multiple channels and offers. Offers are linked to products, which have customer-level eligibility criteria.

Marketing activities have budgets and response forecasts, which can be set for the activity as a whole or for each channel / message combination (called a treatment). An activity can be assigned an activity type, priority, and scoring rule, which are used to prioritize recommendations during inbound interactions. Activities can also be associated with tasks assigned to the user or others.

HQ provides dashboards showing a campaign calendar, personal and delegated tasks, and results by campaign, offer, and channel. The dashboard can be extended to include external data.

IO connects with touchpoints and other data sources through Foundation, which can accept via Web service calls or SQL queries. Foundation integrates the information it gathers and passes it to IO through a Web services interface. The system usually refreshes the data with each new request, but can be configured to retain data in memory during a multi-step interaction. IO is also integrated with GX Software BlueConic to track and segment Web site visitors. BlueConic-generated events can trigger IO messages and BlueConic-captured behaviors can be loaded to the IO database.

Recommendations in IO are based on marketing activities. Each recommendation has audience and message definitions. The audience can be defined by any combination of static lists, dynamic selections, and scoring rules. Messages belong to a single channel and provide content in a channel-specific format. The content may be an actual message or a pointer interpreted by the touchpoint. IO provides a HTML generator to create messages.  These can be personalized with data from the customer record. Messages can be linked to offers, although this is optional.

When IO receives a recommendation request, it checks against the audience and offer definitions of all active recommendations to identify those that are available to the current customer in the current situation. It sorts the options based on activity type, priority, and scoring results, which can be applied in whatever sequence the user defined during campaign setup. More advanced prioritization could be built into the scoring rules but requires a modeling specialist. After the recommendation is selected, it is sent back to the touchpoint for delivery.

Scoring models can be created and automatically updated within IO or imported from external systems. The self-updating models are less accurate than batch built models but make sense where conditions change quickly or very large numbers of models are needed. External models can be created in Portrait’s own modeling tools or with third party software. Scores are calculated within IO using current data.

IO recommendations are generally called by an external touchpoint but can also be embedded within a Dialogue campaign flow, used to generate outbound campaigns. Dialogue provides a drag-and-drop flow builder with a broad range of capabilities to manage data, direct data flows, send messages, and access social media. Campaigns can execute as batch processes or events triggered by database stored procedures. Other Pitney Bowes product offer additional features for database management, data quality, and message creation.

Both IO and Dialogue are available as on-premise software or hosted by Pitney Bowes. Pricing of IO is based on the database size and number of channels supported. It starts around $75,000 for a 100,000 row database for one channel for a perpetual on-premise license. The system has fewer than 50 installations.

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.