This blog has mentioned BlueConic in passing a couple of times but never quite gotten around to reviewing it in detail. Until now.
The delay may seem surprising, since BlueConic qualifies as a Customer Data Platform, a type of system I’ve been arguing will play an increasingly central role in marketers’ futures. For those of you who haven’t been paying close attention, a CDP is defined as a
• marketer-controlled system that
• supports external marketing execution based on
• persistent, cross-channel customer data.
This definition distinguishes CDPs from traditional marketing automation products, which do their own execution, and from real-time interaction managers, which lack persistent data stores. CDPs are important because few marketers have been able to build adequate cross-channel databases and because connecting those databases with execution systems has been difficult. The databases and connections are needed because today's customers expect personalized, coordinated treatments across all channels. Call it the “Amazon fallacy”: customers believe that since Amazon.com can give them highly personalized treatments, so can everyone else.
Anyway, back to BlueConic. The system has two main capabilities, which are to maintain customer profiles and to deliver targeted messages. The profiles can be based on data imported from other systems via batch processes or APIs or captured by BlueConic itself. It does this with “listeners” that can read data from forms or monitor behaviors via Javascript tags on Web pages, emails, and other media. “Listeners” can also create interest rankings and scores based on user behavior. All of these become available as attributes on the customer profile, which in turn can create customer segments and drive targeted messages.
The messages are delivered by what BlueConic calls “dialogues”, each of which sends a single message to a single location (email, text message, section on a Web page, etc.) to a specified customer segment. Messages tailored to customer interests would require creating a separate segment for each message. Similarly, presenting a sequence of messages would require a separate dialogue for each step in the sequence. If a customer is eligible for several dialogues at once, the system currently relies on an optimizer to pick best-responding option and will soon let users create rules to further guide the results. There is no built-in predictive modeling but the optimizer can continuously test alternative messages within a dialogue and automatically deploy the winner. Users can also apply a frequency cap to dialogues to limit the number of times any customer sees the same message.
BlueConic’s integration features are more extensive than its decision management. The system can capture data entered into forms even if the form ise not submitted. Users can insert message contains into an existing Web page without writing HTML code. Profiles capture customer identifiers provided by other systems and are automatically merged when two profiles are linked to the same external ID. Data is exchanged with other sources and execution systems via REST APIs. There are standard integrations with Twitter, Facebook, and Salesforce.com, as well as a system development kit for integration with mobile apps. The underlying data store is Apache Cassandra running on Amazon Web Services, which is highly flexible and scalable at moderate cost.
Integration and data management are what make BlueConic most interesting from a CDP perspective, since those are the core CDP functions. A “pure" CDP would provide only those services while leaving decision management and message delivery to other systems. I expect “pure” CDPs to appear, but most marketers prefer a broader solution, like BlueConic, to assembling the components for themselves. Pure CDPs will become more attractive as integration becomes easier through more standard APIs and connectors, a promise that cloud-based systems often make but are just starting to deliver.
BlueConic’s pricing is already data-centric: fees are based on numbers of profile and channels, not interactions or messages. Prices start around $1,000 per month although most clients pay more. Current implementations are mid-size and enterprise firms in B2C industries including retail, publishing, financial services, utilities, telecommunications, sports and travel. The system has about 70 current customers and is sold both directly and to partners such as ad agencies, other software vendors, and marketing service providers.
Showing posts with label real time decision management. Show all posts
Showing posts with label real time decision management. Show all posts
Saturday, September 27, 2014
Wednesday, June 19, 2013
AgilOne Combines Marketing Database, Analytics and Execution: Yep, That's a Customer Data Platform
Well, this is embarrassing.
Here I am, all excited about discovering a new category of Customer Data Platform systems, which combine marketing database management, predictive modeling, and decision engines. Then I bump into Omer Artun, CEO of AgilOne , which he founded seven years ago to combine marketing database management, predictive modeling, and decision engines. It makes me feel much less clever.
But I guess I can’t hold that against AgilOne. As Artun tells the story, the company was created to provide marketers with a packaged, cloud-based version of the advanced data management, analytics, and execution capabilities that are usually available only to the largest and richest firms. The key is a set of 400 standard metrics, which AgilOne derives by mapping each client’s unique data into a standard structure. This, combined with advanced machine learning techniques, lets AgilOne build ten standard predictive models (engagement, next product, lifetime value, etc.) and three standard cluster models (products, behaviors, and brands) with minimal effort. The system builds on these to deliver packages of standard alerts, reports, guided analytics, individual customer profiles, and campaign lists. It also makes its data and predictions accessible to external systems such as call centers and Web sites via real time API calls, so those systems can use them to guide their own customer treatments.
This quick summary doesn’t do justice to the cleverness or sophistication of AgilOne’s approach. Clever, because the standardization allows it to quickly and cheaply deliver a full stack of capabilities, starting with database building and ending with advanced analytics, recommendations, and execution. Sophisticated, because it tailors the standard structures to each client’s business, so what it delivers isn’t some simple, cookie-cutter output.
Some of the tailoring is unavoidably manual, such as mapping client data sources to the standard data model. But much is highly automated, such as predictive models, clusters, and recommendations. I was particularly intrigued by the standard alerts, which look for significant changes in key performance indicators such as churn, margin, or average order value. That sort of alerting is exactly what I've long felt marketers really wanted from their analytics tools. AgilOne takes this a step further by automatically listing the data attributes with the greatest statistical impact on each item. The company refers to these items as goals to prioritize, which is a bit of a stretch – the most powerful variable isn’t necessarily the one marketers should focus on the most. But, as Damon Runyon said*, that’s the way to bet.
The system also recommends actions related to each alert, such as certain types of marketing campaigns. Again, there’s a bit less here than meets the eye, since the recommendations are drawn from a knowledgebase that’s the same for all clients. But that’s still better than nothing, and clients can customize their copy of the knowledgebase if they want.
The other especially noteworthy strength of AgilOne is data preparation. My original concept of the Customer Data Platform included customer data integration, which involves standardizing and matching customer records from different systems. I’ve pulled back from that because almost none of the vendors actually do such processing. Most assume it will be done elsewhere, or not at all, and only associate records with an exact match on a key such as a customer ID. AgilOne does the hard stuff: quality checks, outlier detection, name parsing, address standardization, geocoding, phonetic matching, persistent ID management, and more. This is also highly automated and uses the company’s own technology. The lack of these capabilities prevents many companies from building a truly integrated customer database at many companies, so it’s extremely valuable for AgilOne to provide it.
If AgilOne has a weakness, it's at the execution end of the process. Users can set up campaigns that generate lists on demand or on a regular schedule. But I didn't see multi-step campaign flows or sophisticated decision management, such as arbitration across multiple eligible offers. Some of that can probably be managed through advanced filters and custom models, which the system does provide. However, making it truly accessible to non-technical users requires a specialized interface that the system apparently lacks.
While AgilOne just recently appeared on my personal radar, plenty of other people had already noticed: the company says nearly 100 brands are using the system. Sales efforts have been concentrated among mid-size B2C organizations, typically with at least 200,000 customers and $15 to $20 million in revenue. Pricing is published on the company Web site and is based on the features used and number of active customers. Entry price for the complete set of features starts around $9,000 per month.
_________________________________________________________________________________
*“The race is not always to the swift nor the battle to the strong, but that's the way to bet.” Runyon himself credited Chicago journalist Hugh Keough.
Here I am, all excited about discovering a new category of Customer Data Platform systems, which combine marketing database management, predictive modeling, and decision engines. Then I bump into Omer Artun, CEO of AgilOne , which he founded seven years ago to combine marketing database management, predictive modeling, and decision engines. It makes me feel much less clever.
But I guess I can’t hold that against AgilOne. As Artun tells the story, the company was created to provide marketers with a packaged, cloud-based version of the advanced data management, analytics, and execution capabilities that are usually available only to the largest and richest firms. The key is a set of 400 standard metrics, which AgilOne derives by mapping each client’s unique data into a standard structure. This, combined with advanced machine learning techniques, lets AgilOne build ten standard predictive models (engagement, next product, lifetime value, etc.) and three standard cluster models (products, behaviors, and brands) with minimal effort. The system builds on these to deliver packages of standard alerts, reports, guided analytics, individual customer profiles, and campaign lists. It also makes its data and predictions accessible to external systems such as call centers and Web sites via real time API calls, so those systems can use them to guide their own customer treatments.
This quick summary doesn’t do justice to the cleverness or sophistication of AgilOne’s approach. Clever, because the standardization allows it to quickly and cheaply deliver a full stack of capabilities, starting with database building and ending with advanced analytics, recommendations, and execution. Sophisticated, because it tailors the standard structures to each client’s business, so what it delivers isn’t some simple, cookie-cutter output.
Some of the tailoring is unavoidably manual, such as mapping client data sources to the standard data model. But much is highly automated, such as predictive models, clusters, and recommendations. I was particularly intrigued by the standard alerts, which look for significant changes in key performance indicators such as churn, margin, or average order value. That sort of alerting is exactly what I've long felt marketers really wanted from their analytics tools. AgilOne takes this a step further by automatically listing the data attributes with the greatest statistical impact on each item. The company refers to these items as goals to prioritize, which is a bit of a stretch – the most powerful variable isn’t necessarily the one marketers should focus on the most. But, as Damon Runyon said*, that’s the way to bet.
The system also recommends actions related to each alert, such as certain types of marketing campaigns. Again, there’s a bit less here than meets the eye, since the recommendations are drawn from a knowledgebase that’s the same for all clients. But that’s still better than nothing, and clients can customize their copy of the knowledgebase if they want.
The other especially noteworthy strength of AgilOne is data preparation. My original concept of the Customer Data Platform included customer data integration, which involves standardizing and matching customer records from different systems. I’ve pulled back from that because almost none of the vendors actually do such processing. Most assume it will be done elsewhere, or not at all, and only associate records with an exact match on a key such as a customer ID. AgilOne does the hard stuff: quality checks, outlier detection, name parsing, address standardization, geocoding, phonetic matching, persistent ID management, and more. This is also highly automated and uses the company’s own technology. The lack of these capabilities prevents many companies from building a truly integrated customer database at many companies, so it’s extremely valuable for AgilOne to provide it.
If AgilOne has a weakness, it's at the execution end of the process. Users can set up campaigns that generate lists on demand or on a regular schedule. But I didn't see multi-step campaign flows or sophisticated decision management, such as arbitration across multiple eligible offers. Some of that can probably be managed through advanced filters and custom models, which the system does provide. However, making it truly accessible to non-technical users requires a specialized interface that the system apparently lacks.
While AgilOne just recently appeared on my personal radar, plenty of other people had already noticed: the company says nearly 100 brands are using the system. Sales efforts have been concentrated among mid-size B2C organizations, typically with at least 200,000 customers and $15 to $20 million in revenue. Pricing is published on the company Web site and is based on the features used and number of active customers. Entry price for the complete set of features starts around $9,000 per month.
_________________________________________________________________________________
*“The race is not always to the swift nor the battle to the strong, but that's the way to bet.” Runyon himself credited Chicago journalist Hugh Keough.
Thursday, December 13, 2012
Sitecore Migrates from Web Content Management to Cross-Channel Customer Engagement
It’s more than three years since my original post about Sitecore’s plans to transform itself from a Web content management system to a platform for cross-channel customer experience management. It seems to be working out – since that time, revenue has grown 40% per year and the number of clients has nearly doubled from 1,600 to 3,000. The company has attracted additional funding, added support for producing dynamic print content, launched an “App Center” for pre-integrated third party products, built a cloud deployment on the Microsoft Azure platform, and extended to new channels via partnerships covering community management (Telligent), online video publishing (Brightcove), and social marketing campaigns (Komfo).
In other words, Sitecore has been steadily executing on the strategy they described in 2009. If there has been a change, it’s recognition that the company can’t build everything itself: hence the partnerships and app center, which use other developers’ products to extend Sitecore to other channels. Sitecore says this makes sense because giving customers a consistent experience across all channels requires only central data and central content management. Letting external systems deliver the actual interactions causes no particular harm.
This vision should sound familiar: it’s the idea behind the real time decision management systems I’ve been reviewing recently. The difference is architecture: the decision managers place decision logic at the center and see customer data and content as peripheral.
More specifically, the decision managers assemble a consolidated customer profile by pulling data on demand from external systems rather than storing it internally. This is actually a pretty minor difference, since in practice most companies will both maintain a central customer database with key profile information and make direct connections to other systems for details such as transactions. The Sitecore model is pretty much the same: it creates its own customer database and supports real time connections to other systems via Web services or database queries.
The approach to content is a more significant distinction. Most decision managers assume content is best stored with the touchpoint systems, while Sitecore wants to store most content itself. I chalk this up to their heritage as a content management vendor. Both approaches have their merits: central storage makes coordination easier but requires continued extension of system features to handle new formats; touchpoint storage makes it harder to know what content is actually available and appropriate. So far, Sitecore has been making the investments to manage new formats centrally, at least to the extent of making the contents visible to functions like message selection, access control, and approval workflows. It doesn’t necessarily extend to actually creating or modifying the contents themselves. Maybe that’s a good compromise.
The other important difference is decision rules. These are obviously the main focus of decision management products. Sitecore doesn’t talk about them much, although does deliver them in the form of campaigns flows and dynamic content rules. The campaigns can manage activities across multiple channels – such as sending an email response to a Web visit – although they are not as sophisticated as the multi-branch, looping logic, advanced decision arbitration, and integrated predictive modeling available in the best decision management systems.
On the other hand, Sitecore makes very powerful use of its close control over content. Each item can be assigned scores on several attributes, such as how much it relates to technology, product, or industry topics. The system then tracks the content consumed by each individual and compares their behavior to “profile cards” of personas such as frequent site visitors with high interest in business. Each person is assigned to the profile card they match most closely; people can be switched to a different card if their behaviors change. This nearest-fit approach is more flexible than the rigid inclusion criteria of traditional segments or lists. Cards are used in decision rules to select contents and treatments for each person.
Although I just compared Sitecore with decision management systems, its more immediate competitors are marketing automation vendors. Like Sitecore, they aim to be a company’s core marketing platform. Sitecore’s campaign flow, email and decisioning features are roughly comparable to the same features in mid-tier marketing automation products, while its Web site management and content creation are generally stronger. Marketing automation systems still probably have advantages in analytics and other areas, although it’s hard to generalize. Sitecore does offer the key B2B marketing automation capability to synchronize with CRM products including Salesforce.com and Microsoft Dynamics CRM.
One clear difference is that most marketing automation systems today are software-as-a-service products, while Sitecore is sold as licensed software, running either on-premise software or on the Microsoft Azure cloud. Pricing starts around $125,000 for an enterprise deployment. Smaller companies would pay less, but Sitecore will never be a system you can get for $1,000 per month.
In other words, Sitecore has been steadily executing on the strategy they described in 2009. If there has been a change, it’s recognition that the company can’t build everything itself: hence the partnerships and app center, which use other developers’ products to extend Sitecore to other channels. Sitecore says this makes sense because giving customers a consistent experience across all channels requires only central data and central content management. Letting external systems deliver the actual interactions causes no particular harm.
This vision should sound familiar: it’s the idea behind the real time decision management systems I’ve been reviewing recently. The difference is architecture: the decision managers place decision logic at the center and see customer data and content as peripheral.
More specifically, the decision managers assemble a consolidated customer profile by pulling data on demand from external systems rather than storing it internally. This is actually a pretty minor difference, since in practice most companies will both maintain a central customer database with key profile information and make direct connections to other systems for details such as transactions. The Sitecore model is pretty much the same: it creates its own customer database and supports real time connections to other systems via Web services or database queries.
The approach to content is a more significant distinction. Most decision managers assume content is best stored with the touchpoint systems, while Sitecore wants to store most content itself. I chalk this up to their heritage as a content management vendor. Both approaches have their merits: central storage makes coordination easier but requires continued extension of system features to handle new formats; touchpoint storage makes it harder to know what content is actually available and appropriate. So far, Sitecore has been making the investments to manage new formats centrally, at least to the extent of making the contents visible to functions like message selection, access control, and approval workflows. It doesn’t necessarily extend to actually creating or modifying the contents themselves. Maybe that’s a good compromise.
The other important difference is decision rules. These are obviously the main focus of decision management products. Sitecore doesn’t talk about them much, although does deliver them in the form of campaigns flows and dynamic content rules. The campaigns can manage activities across multiple channels – such as sending an email response to a Web visit – although they are not as sophisticated as the multi-branch, looping logic, advanced decision arbitration, and integrated predictive modeling available in the best decision management systems.
On the other hand, Sitecore makes very powerful use of its close control over content. Each item can be assigned scores on several attributes, such as how much it relates to technology, product, or industry topics. The system then tracks the content consumed by each individual and compares their behavior to “profile cards” of personas such as frequent site visitors with high interest in business. Each person is assigned to the profile card they match most closely; people can be switched to a different card if their behaviors change. This nearest-fit approach is more flexible than the rigid inclusion criteria of traditional segments or lists. Cards are used in decision rules to select contents and treatments for each person.
One clear difference is that most marketing automation systems today are software-as-a-service products, while Sitecore is sold as licensed software, running either on-premise software or on the Microsoft Azure cloud. Pricing starts around $125,000 for an enterprise deployment. Smaller companies would pay less, but Sitecore will never be a system you can get for $1,000 per month.
Wednesday, November 28, 2012
[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.
Tuesday, November 20, 2012
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.
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.
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.
Thursday, November 15, 2012
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:
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.
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.
Subscribe to:
Posts (Atom)
