Attribution Will Be Critical for AI-Based Marketing Success

I gave my presentation on Self-Driving Marketing Campaigns at the MarTech conference last week. Most of the content followed the arguments I made here a couple of weeks ago, about the challenges of coordinating multiple specialist AI systems. But prepping for the conference led me to refine my thoughts, so there are a couple of points I think are worth revisiting.

The first is the distinction between replacing human specialists with AI specialists, and replacing human managers with AI managers. Visually, the first progression looks like this as AI gradually takes over specialized tasks in the marketing department:

The insight here is that while each machine presumably does its job much better than the human it replaces,* the output of the team as a whole can’t fundamentally change because of the bottleneck created by the human manager overseeing the process. That is, work is still organized into campaigns that deal with customer segments because the human manager needs to think in those terms. It’s true that the segments will keep getting smaller, the content within each segment more personalized, and more tests will yield faster learning. But the human manager can only make a relatively small number of decisions about what the robots should do, and that puts severe limits on how complicated the marketing process can become.

The really big change happens when that human manager herself is replaced by a robot:

Now, the manager can also deal with more-or-less infinite complexity. This means we no longer need campaigns and segments and can truly orchestrate treatments for each customer as an individual. In theory, the robot manager could order her robot assistants to create custom messages and offers in each situation, based on the current context and past behaviors of the individual human involved. In essence, each customer has a personal robot following her around, figuring out what’s best for her alone, and then calling on the other robots to make it happen. Whether that's a paradise or nightmare is beyond the scope of this discussion.

In my post a few weeks ago, I was very skeptical that manager robots would be able to coordinate the specialist systems any time soon.  That now strikes me as less of a barrier.  Among other reasons, I’ve seen vendors including Jivox and RevJet introduce systems that integrate large portions of the content creation and delivery workflows, potentially or actually coordinating the efforts of multiple AI agents within the process. I also had an interesting chat with the folks at Albert.ai, who have addressed some of the knottier problems about coordinating the entire campaign process. These vendors are still working with campaigns, not individual-level journey orchestration. But they are definitely showing progress.

As I've become less concerned about the challenges of robot communication, I've grown more concerned about robots making the right decisions.  In other words, the manager robot needs a way to choose what the specialist robots will work on so they are doing the most productive tasks. The choices must be based on estimating the value of different options.  Creating such estimates is the job of revenue attribution.  So it turns out that accurate attribution is a critical requirement for AI-based orchestration.

That’s an important insight.  All marketers acknowledge that attribution is important but most have focused their attention on other tasks in recent years.  Even vendors that do attribution often limit themselves to assigning user-selected fractions of value to different channels or touches, replacing the obviously-incorrect first- and last-touch models with less-obviously-but-still-incorrect models such as “U-shaped”, “W-shaped”,  and “time decay”.  All these approaches are based on assumptions, not actual data.  This means they don’t adjust the weights assigned to different marketing messages based on experience. That means the AI can’t use them to improve its choices over time.

There are a handful of attribution vendors who do use data-driven approaches, usually referred to as “algorithmic”. These include VisualIQ (just bought by Nielsen), MarketShare Partners (owned by Neustar since 2015) Convertro (bought in 2014 by AOL, now Verizon), Adometry (bought in 2014 by Google and now part of Google Analytics), Conversion Logic, C3 Metrics, and (a relatively new entrant) Wizaly. Each has its own techniques but the general approach is to compare results for buyers who take similar paths, and attribute differences in results to the differences between their paths. For example: one group of customers might have interacted in three channels and another interacted in the same three channels plus a fourth. Any difference in results would be attributed to the fourth channel.

Truth be told, I don’t love this approach.  The different paths could themselves the result of differences between customers, which means exposure to a particular path isn’t necessarily the reason for different results. (For example, if good buyers naturally visit your Web site while poor prospects do not, then the Web site isn’t really “causing” people to buy more.  This means driving more people to the Web site won’t improve results because the new visitors are poor prospects.) 

Moreover, this type of attribution applies primarily to near-term events such as purchases or some other easily measured conversion.  Guiding lifetime journey orchestration requires something more subtle.  This will almost surely be based on a simulation model or state-based framework describing influences on buyer behavior over time. 

But whatever the weaknesses of current algorithmic attribution methods, they are at least based on actual behaviors and can be improved over time.  And even if they're not dead-on accurate, they should be directionally  correct. That’s good enough to give the AI manager something to work with as it tells the specialist AIs what to do next.  Indeed, an AI manager that's orchestrating contacts for each individual will have many opportunities to conduct rigorous attribution experiments, potentially improving attribution accuracy by a huge factor.

And that's exactly the point.  AI managers will rely on attribution to measure the success of their efforts and thus to drive future decisions.  This changes attribution from an esoteric specialty to a core enabling technology for AI-driven marketing.  Given the current state of attribution, there's an urgent need for marketers to pay more attention and for vendors to improve their techniques. So if you haven’t given attribution much thought recently, it’s a good time to start.

__________________________________________________________________________
* or augments, if you want to be optimistic.

Blueshift CDP Adds Advanced Features

I reviewed Blueshift in June 2015, when the product had been in-market for just a few months and had a handful of large clients. Since then they’ve added many new features and grown to about 50 customers. So let’s do a quick update.

Basically, the system is still what it was: a Customer Data Platform that includes predictive modeling, content creation, and multi-step campaigns. Customer data can be acquired through the vendor’s own Javascript tags, mobile SDK (new since 2015), API connectors, or file imports. Blueshift also has collection connectors for Segment, Ensighten, mParticle, and Tealium. Product data can load through file imports, a standard API, or a direct connector to DemandWare.

As before, Blueshift can ingest, store and index pretty much any data with no advance modeling, using JSON, MongoDB, Postgres, and Kafka. Users do have to tell source systems what information to send and map inputs to standard entities such as customer name, product ID, or interaction type. There is some new advanced automation, such as tying related events to a transaction ID. The system’s ability to load and expose imported data in near-real-time remains impressive.

Blueshift will stitch together customer identities using multiple identifiers and can convert anonymous to known profiles without losing any history. Profiles are automatically enhanced with product affinities and scores for purchase intent, engagement, and retention.

The system had automated predictive modeling when I first reviewed it, but has now added machine- learning-based product recommendations. In fact, it recommendations are exceptionally sophisticated. Features include a wide range of rule- and model-based recommendation methods, an option for users to create custom recommendation types, and multi-product recommendation blocks that mix recommendations based on different rules. For example, the system can first pick a primary recommendation and then recommend products related to it. To check that the system is working as expected, users can preview recommendations for specified segments or individuals.

The segment builder in Blueshift doesn’t seem to have changed much since my last review: users select data categories, elements, and values used to include or exclude segment members. The system still shows the counts for how many segment members are addressable via email, display ads, push, and SMS.

On the other hand, the campaign builder has expanded significantly. The previous form-based campaign builder has been replaced by a visual interface that allows branching sequences of events and different treatments within each event.  These treatments include thumbnails of campaign creative and can be in different channels. That's special because many vendors still limit campaigns to a single channel. Campaigns can be triggered by events, run on fixed schedules, or executed once.

Each treatment within an event has its own selection conditions, which can incorporate any data type: previous behaviors, model scores, preferred communications channels, and so on. Customers are tested against the treatment conditions in sequence and assigned to the first treatment they match. Content builders let users create templates for email, display ads, push messages, and SMS messages. This is another relatively rare feature. Templates can include personalized offers based on predictive models or recommendations. The system can run split tests of content or recommendation methods. Attribution reports can now include custom goals, which lets users measure different campaigns against different objectives.

Blueshift still relies on external services to deliver the messages it creates. It has integrations with SendGrid, Sparkpost, and Cheetahmail for email and Twilio and Gupshup for SMS. Other channels can be fed through list extracts or custom API connectors.

Blueshift still offers its product in three different versions: email-only, cross-channel and predictive. Pricing has increased since 2015, and now starts at $2,000 per month for the email edition version, $4,000 per month for the cross-channel edition and $10,000 per month for the predictive edition. Actual fees depend on the number of active customers, with the lowest tier starting at 500,000 active users per month. The company now has several enterprise-scale clients including LendingTree, Udacity, and Paypal.

CaliberMind Offers B2B Orchestration with a Twist

I spent quite a bit of time debating with myself how to classify CaliberMind. But instead of presenting my conclusion and defending it, I’ll just tell you what CaliberMind does. We’ll circle back to classification at the end.

Unify B2B data. CaliberMind ingests data from Salesforce Sales cloud and Marketo, Oracle Eloqua, Salesforce Pardot, and HubSpot marketing automation systems. It reports on missing data and fills in the blanks using data from external vendors. It also uses those vendors to find identifiers belonging to the same person (such as multiple email addresses or alternative company names) and to link contact and lead records to accounts. The system can accept feeds from major advertising systems (GoogleAdwords, Bing, Facebook Ads), from Web analytics (Google Analytics, Mixpanel), and various data stores (MySQL, Amazon Redshift and S3, MongoDB, Apache Hive, etc.). CaliberMind has embedded a third-party data load and transformation tool to manage such inputs. The system stores structured data in Redshift, semi-structured data in MongoDB, and unstructured data in S3.

Report on journeys. CaliberMind system builds an account-level journey visualization that shows different types of events (outbound contacts, inbound contacts, account created, opportunity created, deal won, etc.) on parallel time lines. It imports opportunity stages or account statuses from the source systems rather than creating its own journey stages. Attribution reports show the timing of different types of contacts relative to the date of the final sale, aggregated across multiple accounts. The system doesn’t explicitly report the impact of different contacts but it does consider their effects when recommending which messages to send next.

Create personas. Users can define a list of personas and then assign them profile attributes such as job titles or company sizes. More interesting, they can also submit texts related to each persona. These might be job descriptions, advertising copy, blog posts, video transcripts, email messages, or anything else written in English. (Other languages will be added in the future.) The system uses natural language processing to analyze these and build a profile of what they have in common. This can later be used to determine how closely other texts match each persona. The system can also classify new contacts by persona, based on their profile attributes and associated texts such as content consumed or emails written. The assignments can be adjusted over time as new information becomes available.

Match content to individuals. CaliberMind also uses the texts associated with each contact to build a personal profile. Because the language processor can understand things like level of interest, buyer role, and stage in the purchasing process, it can identify new and generate alerts about important events. The system can also pick up references to other individuals and infer their own roles and interests.

Push results to other systems. CaliberMind draws on its individual-level profiles to push personality insights, engagement tips, and content recommendations to sales people. These can be loaded into the CRM database or displayed in a window on the CRM desktop. CRM users can also see the account-level journey reports and revenue summaries including forecasts. Marketing automation systems could get the same details but usually take more general information, such as persona codes used in segmentation. User-created rules can pick records meeting specified criteria and send them to different marketing automation campaigns. A Salesforce app is pending approval on the App Exchange and Salesforce single sign-on is scheduled for later this year.

Expose detailed data. CaliberMind’s own interface lets users examine the data loaded into the system. Individual-level reports can display details down to the level of single emails or Web visits. These reports are used by marketing, enablement and sales operations teams, not sales people.

These facts should give you an idea why classifying CaliberMind is such a challenge. Its two most notable features are data unification and the personas and recommendations based on natural language processing. The unification and access features make it a Customer Data Platform, while the personas and recommendations make it a Sales Enablement tool. That’s an unusual combination because the marketing and sales domains usually remain separate. You might label CaliberMind an Account Based Marketing system, which also straddles those domains. But there are so many types of ABM systems that it's not a useful classification. CaliberMind itself calls the system an orchestration engine.  That's also accurate, since CaliberMind does indeed coordinate messages across channels. But orchestration is another vague term that if understates the main value of CaliberMind, which is less about coordinating messages than finding the best ones. So must best suggestion is to leave categories aside and consider CaliberMind on its own merits.

CaliberMind was released last summer and currently has eleven clients including a mix of mid-size and enterprise B2B companies. Pricing is based on number of contacts and data sources and starts at $2,000 per month.

Optimove Optibot Automates Campaign Optimization

I finally caught up with Optimove for a briefing on the Optibot technology they introduced last September. For a bit of background, Optimove is a Journey Orchestration Engine that focuses on customer retention. It assigns customers to states (which it calls microsegments) and sends different marketing campaigns to people in each state. See my original Optimove review from three years ago (!) for a more detailed explanation.

What’s new about Optibot is that defining microsegments and picking the best campaign actions per segment have now been automated. Optimove previously analyzed performance of microsegments to find clusters within the microsegment with above or below average results. When it found one, it gave users a recommendation to treat these clusters as separate microsegments and potentially stop promoting to the poorly performing group. Optibit takes the human out of this loop, automatically splitting the microsegments into smaller microsegments when it can.

Optibot also automatically tests different actions against people within each microsegment. If it finds that different actions work better for different clusters, it will assign the best action to each group. (In practice, it slowly shifts the mix in favor of the better actions, to be more certain it is making a sound choice while minimizing the opportunity cost of poorly-performing actions.) The system gives reports that compare actual performance with what performance would have been without the additional segmentation and optimization. That’s a helpful reassurance to the user that Optibot is making good choices, and of course a nice little demonstration of Optimove’s value.

Finally, Optibot provides users with recommendations for things they can do, such as create new actions for microsegments that are not responding well to existing actions. I’ll assume that Optibot does this because it really can’t create new actions by itself, and not just so marketers have something to do other than watch cat videos all day.

I’m probably making Optibot sound simpler than it really is. There’s a lot of clever (and fully automated) analysis needed to find the right clusters, given that there are so many different ways the clusters could be defined. Optibot also needs a goal to pursue so it knows which actions and clusters are giving more desirable results. Defining those goals is also still a job for human marketers.  Fortunately, it only has to be done when a program is being set up, so it won’t cut too deeply into precious cat video viewing time.

Sarcasm aside, the real value of Optibot isn’t that it automates what marketers could otherwise do manually. It’s that it manages many more segments than humanly possible, allowing companies to fine-tune treatments for each group and to uncover pockets of opportunity that would otherwise be overlooked. Marketers will indeed need to create more content, and will no doubt find other productive uses for their time. And, frankly, if Optibot meant fewer 60 hour work weeks, that would be okay too.

History of Marketing Technology and What's Special about Journey Orchestration

I delivered my presentation on the history of marketing technology last week at the Optimove CONNECT conference in Tel Aviv. Sadly, the audience didn’t seem to share my fascination with arcana (did you know that the Chinese invented paper in 100 CE? that Return on Investment analysis originated at DuPont in 1912?) So, chastened a bit, I’ll share with you a much-condensed version of my timeline, leaving out juicy details like brothel advertising at Pompeii.

The timeline* traces three categories: marketing channels; tools used by marketers to manage those channels; and data available to marketers.  The yellow areas represent the volume of technology available during each period. Again skipping over my beloved details, there are two main points:

• although the number of marketing channels increased dramatically during the industrial age (adding mass print, direct mail, radio, television, and telemarketing), there was almost no growth in marketing technology or data until computers were applied to list management in the 1970’s. The real explosions in martech and data happen after the Internet appears in the 1990’s.

• the core martech technology, campaign management, begins in the 1980’s: that is, it predates the Internet. In fact, campaign management was originally designed to manage direct mail lists (and – arcana alert! – itself mimicked practices developed for mechanical list technologies such as punch cards and metal address plates). Although marketers have long talked about being customer- rather than campaign-centric, it’s not until the current crop of Journey Orchestration Engines (JOEs) that we see a thorough replacement of campaign-based methods.

It’s not surprising the transition took so long. As I described in my earlier post on the adoption of electric power by factories (more arcana!), the shift to new technology happens in stages as individual components of a process are changed, which then opens a path to changing other components, until finally all the old components are gone and new components are deployed in a configuration optimized for the new capabilities. In the transition from campaign management to journey orchestration, marketers had to develop tools to track individuals over time, to personalize messages to those individuals, identify and optimize individual journeys, act on complete data in real time, and to incorporate masses of unstructured data. Each of those transitions involved a technology change: from lists to databases, from static messages to dynamic content, from segment-level descriptive analytics to individual-level predictions, from batch updates to real time processes, and from relational databases to “big data” stores.

It’s really difficult to retrofit old systems with new technologies, which is one reason vendors like Oracle and IBM keep buying new companies to supplement current products. It’s also why the newest systems tend to be the most advanced.** Thus, the Journey Orchestration Engines I’ve written about previously (Thunderhead ONE , Pointillist, Usermind, Hive9 ) all use NoSQL data stores, build detailed individual-level customer histories, and track individuals as they move from state to state within a journey flow.

During my Tel Aviv visit last week, I also checked in with Pontis (just purchased by Amdocs), who showed me their own new tool which does an exceptionally fine job at ingesting all kinds of data, building a unified customer history, and coordinating treatments across all channels, all in real time. In true JOE fashion, the system selects the best treatment in each situation rather than pushing customers down predefined campaign sequences. Pontis also promised their February release would use machine learning to pick optimal messages and channels during each treatment. Separately, Optimove itself announced its own “Optibot” automation scheme, which also finds the best treatments for individuals as they move from state to state. So you can add Optimove to your cup of JOEs (sorry) as well.

I’m reluctant to proclaim JOEs as the final stage in customer management evolution only because it’s too soon to know if more change is on the way. As Pontis and Optimove both illustrate, the next step may be using automation to select customer treatments and ultimately to generate the framework that organizes those treatments. When that happens, we will have erased the last vestiges of the list- and campaign-based approaches that date back to the mail order pioneers of the 19th century and to the ancient Sumerians (first customer list, c. 3,000 BCE) before that.




_________________________________________________________________________________
*Dates represent commercialization, not the first appearance of the underlying technology. For example, we all know that Gutenberg’s press with moveable type was introduced around 1450, but newspapers with advertising didn’t show up until after 1600.

** This isn’t quite as tautological as it sounds. In some industries, deep-pocketed old vendors with big research budgets are the technical leaders. 

ABM Vendor Guide: State-Based Flows to Orchestrate Account Treatments

Next up in this series on ABM sub-functions described in the Raab Guide to ABM Vendors: State-Based Flows.

ABM Process	System Function	Sub-Function	Number of Vendors
Identify Target Accounts	Assemble Data	External Data	28
	Select Targets	Target Scoring	15
Plan Interactions	Assemble Messages	Customized Messages	6
	Select Messages	State-Based Flows	10
Execute Interactions	Deliver Messages	Execution	19
Analyze Results	Reporting	Result Analysis	16

Your first reaction that may well be, What the heck is a State-Based Flow?  That's no accident.  I chose an unfamiliar term because I didn’t want people to assume it meant something it doesn’t. The Guide states:

Vendors in this category can automatically send different messages to the same contact in response to behaviors or data changes. Messages often relate to buying stages but may also reflect interests or job function. Messages may also be tied to a specific situation such as a flurry of Web site visits or a lack of contacts at a target account. Flows may also trigger actions other than messages, such as alerting a sales person. Actions are generally completed through a separate execution system. Movement may mean reaching different steps in a single campaign or entering a different campaign. Either approach can be effective. What really matters is that movement occurs automatically and that messages change as a result.

In other words, the essence of state-based flows is the system defines a set of conditions (i.e. states) that accounts or contacts can be in, tracks them as they move from one condition to the next, and sends different messages for each condition. This is roughly similar to campaign management except that campaign entry rules are usually defined independently, so customers don’t automatically flow from campaign to campaign in the way that they flow from state to state. (Another way to look at it: customers can be in several campaigns at once but only in one customer state at a time.) Customers in multi-step campaigns do move from one stage to the next, but they usually progress in only one direction, whereas people can move in and out of the same state multiple times. Journey orchestration engines manage a type of state-based flow, but they build the flow on a customer journey framework, which is an additional condition I’m not imposing here.

This may be more hair-splitting than necessary. My goal in defining this sub-function was mostly to distinguish systems where users manually assign people to messages (meaning that the messages won’t change unless the user reassigns them) from systems that automatically adjust the messages based on behaviors or new data. This adjustment is the very heart of managing relationships, or what I usually call the decision layer in my data / decision / delivery model.

Speaking of hair-splitting, you may notice that I’m being a little inconsistent in referring to message recipients as accounts, customers, contacts, individuals, or people. A true ABM system works at the account level but messages may be delivered to accounts (IP-based ad targeting), known individuals (email), or anonymous individuals (cookie- or device-based targeting, although sometimes these are associated with known individuals). Because of this, different systems work at different levels. The ideal is for message selection to consider both the state of the account and the state of the individual within the account.

As with the Customized Message category I described yesterday, vendors who qualify for State-Based Flows fall into two broad groups: those whose primary function is cross-channel message orchestration (Engagio, MRP, YesPath, ZenIQ, Mintigo*) and those that do flow management to support delivery of messages in a single channel (Evergage, GetSmartContent, Kwanzoo, Terminus, Triblio). Marketers who are looking for a primary tool to manage account relationships will be most interested in the first group.

Differentiators to consider with this group include:

• orchestrates activities at account level (doesn't treat each lead independently)
• assigns Web site visitors to segments during each visit using current data
• automated models to classify content, define segments, and select best content per segment
• automated models to assign contacts to personas and select best content per persona
• automated models to recommend best actions per account
• present sets of content in sequence or all at once
• continue same experience over time across different channels
• prioritization to ensure highest value message is always presented
• accounts can be in multiple programs simultaneously
• contacts can be limited to one program at a time
• limit number of messages sent to each contact within a specified time period

As you no doubt realize, this is the area that most directly overlaps with marketing automation and journey orchestration systems that are not ABM specialists.  They key feature to watch out for when evaluating those systems for ABM programs is the abillity to work at the account level.  That was not part of many older marketing automation systems, although several vendors have now retrofitted their products to support to some degree.
______________________________________________________________________
* via its Predictive Campaign integration with Eloqua

YesPath Takes Its Own Route to Managing ABM Journeys

Account based marketing is clearly an important technique for B2B marketers, but I don’t see it displacing all other approaches. For exactly that reason, I also don’t see specialized ABM systems replacing the core marketing databases and decision engines that coordinate all marketing efforts. Today, the core roles are most often filled by marketing automation, although there are emerging alternatives such as Customer Data Platforms and Journey Orchestration Engines. Most of these tools will eventually add ABM features if they don’t have them already.

But marketers whose current tools don’t support ABM will need to something new if they want to participate in the ABM gold rush. This gives ABM database and orchestration specialists an opportunity to sell to clients who would otherwise be uninterested in new core systems. The long term, though often unstated, goal of most ABM specialists is to replace the incumbents as their clients’ primary marketing platforms.* But before they can do that, they need to get their foot in the door by making ABM easier than it would be with clients’ existing tools.

The main function provided by ABM specialists is account-level data aggregation.  This in turn makes possible account-level analytics and orchestration. But data and analytics don’t create revenue by themselves, so vendors naturally stress their orchestration features. Hence “plays” from Engagio (discussed here ) and “recipes” in ZenIQ (discussed here).  It’s important to recognize that both those systems also build an account-oriented database and provide ABM analytics. They are also similar in relying primarily on external systems to deliver the messages they select.  This is a primary difference from conventional marketing automation products, which deliver email and often other types of messages directly. (Special bonus: by relying on marketing automation to deliver their messages, the ABM orchestrators also show that they don’t intend to replace existing marketing automation systems, removing one objection to their purchase. What they don’t say is they are diminishing the role of marketing automation from the central marketing platform to a simple delivery system, clearing the way for the ABM vendors to eventually take over the central role.  But don’t tell anyone I told you.)

YesPath is another ABM orchestrator (ABMO?). It too builds an account-oriented database, provides ABM analytics, and selects messages to be delivered by other systems. Of course, every system is unique.  Here are some important details that distinguish YesPath:

- focus on unknown prospects. YesPath relies heavily on Bombora intent data to find companies and individuals (or, more precisely, anonymous cookies) that are interested in topics relevant to a marketer’s products. This lets YesPath programs (which are rather unimaginatively called “programs”) determine which companies on the client’s target list are in active buying cycles, even before they have visited the company Web site or responded to an outbound promotion. YesPath can then reach those companies and individuals through a just-announced integration with the Madison Logic display ad network.

- persona-based programs. Marketers set up YesPath programs by uploading a list of target accounts and then defining the selection criteria for individuals to enter the program. These criteria can be considered a persona definition because they identify a set of similar individuals: in this sense, each program relates to a single persona. To create the selection criteria, users select a target audience of people who have shown interest in one or more topics and YesPath machine learning builds a model that scores how similar other individuals are to that target group. Model inputs include content consumption as sourced from Bombora, behaviors captured by a YesPath Javascript tag on the marketers’ own Web site and emails, and campaign responses imported from CRM (Salesforce.com only so far) and marketing automation (the first integration will be announced shortly). Selection criteria can also include data such as title imported from CRM. Accounts can be assigned to multiple programs but each individual is assigned to only one program at a time, based on whichever program’s target group they match most closely. This means that individuals from the same company with different personas will be in different programs and potentially receive different experiences.

- stage tracking within programs. In addition to assigning an account list and defining individual selection criteria, program set-up includes creating rules to classify accounts into buying stages. These rules draw on behaviors of all individuals within the account, looking primarily at direct interactions with the company Web site, CRM, and marketing automation. YesPath monitors behaviors as they occur and will reassign the account’s stage as appropriate. All individuals in the same account are considered to be in the same stage in a given program. Although stages could be used to describe a customer journey, the fact that each program has its own stage definitions means they can be used in other ways as well.

- stage-based actions. The final task in program set-up is defining actions to occur when an account reaches a new stage. Web site actions, including banner ads, modals, popups, and sliders, can be executed by YesPath itself, using its Javascript tag to identify visitors and display messages. Other actions would be sent by API to execute Madison Logic display advertising, Salesforce.com sales campaigns or other tasks, marketing automation campaigns, or acquire net new lead names from an external source. The system could apply machine learning to select content delivered by an action, but most YesPath clients have so far preferred to select the content in advance.  The system can run split tests to assess alternative actions..

- engagement scores and reporting. YesPath assigns points to interactions such as downloads and page visits. It sums these points for all individuals in an account to create an engagement score that is its primary measure of account activity. For example, program effectiveness is measured by showing the change in engagement after the program began. Other account and program reports show the number of accounts by stage within each program; account details such as stage, days in stage, engagement and visitor counts; distribution of visitors by department and level; interest in different topics; and drill-down to individual activity details. Like other ABM vendors, YesPath says its clients have been very eager to see account reporting on its own, even  before any programs were created.

This is an intriguing mix of features. Using intent data to identify active prospects early in the buying cycle makes sense but in practice will miss many potential buyers. This isn’t a fatal flaw, since marketers can  advertise to target accounts regardless of whether they show up on intent lists, and internal data from Web, CRM, and marketing automation will add precision once prospects start engaging with the company directly. But it does mean this feature is likely to be less powerful than users might expect.

My greater concern is the system’s approach to journey management. Automatically moving individuals among programs and moving accounts to new program stages sounds great: the system dynamically reacts to individual behaviors without defining every path in advance. But users must manually assign accounts to programs, select the individuals used to train the machine learning models, write stage definition rules, and assign actions to stages and messages to actions. It will take a very savvy user to design these elements so they interact in a way that delivers the desired customer experience. The challenge is even greater because actions can only be triggered by a stage change: this means that even a simple multi-step campaign would require multiple stages with tightly written rules to ensure the timing works as intended and that individuals are not reassigned to other programs midstream. And, since stages are assigned at the account level, additional cleverness would be needed to run people through the program at different times. YesPath managers argue their approach makes it easier to manage complex customer journeys than traditional campaign workflows, but I’m not so sure. Perhaps YesPath will find its niche as a way to manage relatively simple experiences, such as account-based advertising campaigns keyed to the buying cycle.

Pricing of YesPath is based on the number of accounts in the system and starts at $3,000 per month for 500 accounts. The system was launched in March 2016 and had ten clients as of June.
______________________________________________________
* I’m talking here about ABM database and orchestration systems, not ABM data providers or advertising vendors.  Data inputs and message delivery are needed regardless of what core marketing systems a client uses.

Usermind Makes Journey Orchestration Simple

Maybe you’ve been waiting with increasing impatience for me to finish reviewing the set of Journey Orchestration Engines (JOEs) I first mentioned in March.  More likely, it slipped your mind entirely. But I do worry about such things so I’m especially pleased for finish out the set by telling you about Usermind.

Usermind Journey

I'm not saying that Usermind calls itself a JOE.  Its self-description is “the first unified platform for orchestrating business operations”.  But the company uses the language of journeys and customer data stores. So although they see themselves as enabling all kinds of business processes, I think it’s fair to view them largely in the context of customer management.

Usermind is all about simplicity.  Its main screen sets the tone by offering just three tabs: Analytics, Journeys, and Integration. Deploying the system actually starts with the last of these, Integration, which is where the user connects to external systems that are both data sources and execution engines. The company lists about a dozen standard integrations including major marketing automation, CRM, email, customer service, collaboration, and analytics systems. Another half-dozen are “coming soon.”

A key feature of Usermind is it makes integration easy by reading the contents of the source systems automatically, so any custom data elements or objects are incorporated without user effort.  This also means it adjusts to changes in those systems automatically. Users do build maps that show which fields to use to link customers (or other entities) across systems: for example, a map might use email address to link marketing automation to CRM, and customer ID to link CRM to customer service. The system can also map on combinations of fields and do fuzzy matching on inconsistent data. There can be separate maps for individuals, companies, products, customers, partners, or whatever other entities the user wants to work with. Usermind figures out relationships among tables or objects within each source system, so users simply see a list of available fields without having worry about the underlying data structures.

Once the maps are in place, Usermind copies selected data elements into its own database, where they are available to use in journeys. Each journey is a sequence of milestones, which can each contain one or more rules. Each rule has selection conditions and one or more actions to take if the conditions are met. Actions can push data or tasks to back to the source systems.  Rules can be triggered by events or executed on schedule.

Usermind Rule

And that’s pretty much it. The Analytics tab reports on movement of customers through journeys, providing counts, conversion rates and drop-out rates for each milestone. It also analyzes the impact of actions on results.  The system can be connected to business intelligence tools for more advanced reporting. But there’s no predictive analytics, content creation, or message execution. True to its description, Usermind is designed to orchestrate actions in other systems, not take actions itself.

Don’t let that simplicity fool you. Usermind (and other JOEs) address the critical challenge of unifying customer data from different sources and coordinating customer treatments. Tools to make this easy are rare; tools to send emails and deliver other messages are not. So Usermind fills an important gap – which is why the company has attracted $22 million in venture funding since it was founded in 2013, and why its investors waited until this year for it to launch the actual product. (Whether they waited patiently is a question I didn’t ask.) As of March, the company reported 15 live customers and was actively looking for more.

You may be wondering whether Usermind can truly be called a JOE since I've defined the essence of JOE-ness as a system that discovers the customer journey for itself rather than relying on the user to define it. Usermind doesn’t pass that test. In fact, Usermind journeys are individual processes rather than an overview of the customer’s lifetime experience. But Usermind still looks JOE-ish because it’s capturing events that occur naturally, not creating its own events like messages in a nurture flow. And its ability to use the journey as a framework for managing customer treatments is exactly what JOEs are all about. So marketers looking for a JOE should put Usermind on their list.

Pointillist Journey Orchestration Discovers Customer Paths for Itself (Marketing Automation is Doomed, I Tell You)

This post will resume the tour I started in March of journey orchestration engines – our new friend JOE. But first I’ll interrupt myself to announce that I have officially decided to predict that JOEs will replace campaign management and marketing automation as the core system for marketing departments. I usually hedge my bets with this sort of prediction, but will abandon my typical caution because I’m convinced that campaign management and marketing automation are too deeply rooted in the old world of batch list generation to meet today’s need for continuous optimization of customer treatments. Their core architectures just aren’t up to it.

I’m not saying that JOEs will have no competition.  Plenty of other vendors have the potential to make the transition – in particular, products developed for real time interactions and Web personalization. I am saying the competition won’t come from today’s campaign management and marketing automation leaders.*

Now that I’ve shared this exciting bit of news with you, let’s get back to the topic at hand. That would be Pointillist, a just-released “customer intelligence platform” that has been incubating inside financial services technology vendor Altisource since 2014.

As Pointillist’s self-chosen label suggests, its own roots are in customer data analytics, not execution. Sure enough, the system is built around a custom data structure that (if my notes are accurate) they describe as a “combination graph relational time series”, which certainly sounds like something out of Dr. Who.

Put in terms simple enough for me to understand, Pointillist stores all data as events, which can have  attributes including customers, products and campaigns. Different event types contain different sets of attributes but there are no formal data tables or relationships among tables. This sounds broadly like Hadoop and other NoSQL data stores, although I’m sure there are Important Technical Differences that matter deeply to people care about such things. What matters from a marketer’s perspective is this approach makes it easy to add new types of information and to update information very quickly.

Also as with Hadoop and friends, the Pointillist data store needs some added structure to allow fast access and analysis, and that structure imposes some limitations. Pointillist has optimized for customer analysis, meaning that customer behaviors can be analyzed almost instantly but combining information about customers is harder. For example, it could be tough to find out which products two customers bought in common. All data is stored persistently on a disk somewhere in the Amazon cloud, but accessible data is loaded into memory.  This makes things really quick.

That’s probably more than you care or need to know about Pointillist’s technology. Let’s get back to the surface where things are bright and shiny. What makes Pointillist a journey orchestration engine is that it can describe and act against customer journeys. The acting part is especially important, because it makes Pointillist more than simply an analysis tool.

What Pointillist really does from a user point of view is let you pick sets of customers and events to analyze. Users drag the events onto a workspace and connect them with lines to indicate the sequence to analyze. The system then scans its data to find how many customers had an instance of each event and draws lines whose thickness indicates how many passed customers from one event to the next. In other words, it creates a journey map.

Or, and this is my favorite part, you can tell Pointillist to discover the most important paths on its own.  It does this using magic machine learning to determine which paths have the highest combination of frequency, exclusivity, and correlation to a goal (a user-specified event). Users can adjust the balance among those three factors and can further train the algorithm by telling it which connections they feel are important. Because Pointillist is doing the analysis in memory and considerately visualizes its results, you can  watch it test different connections until it settles on a final set. Hours of fun, for sure.

But there’s more. Pointillist can report on the disposition of people within each event, replacing its icon with a little circle graph showing how many people reached the final goal, moved to the next event (but never reached the goal), dropped out, or stayed behind. It can also display other statistics in graphs next to the flow diagram, as well as letting users analyze subsets of the audience or even a trace the path of a single individual. The analysis can run backwards or forwards, finding either where an initial set of customers ended up or where a final set of customers came from. Heck, that’s weeks of fun when you think about it.

Taking action within Pointillist works exactly as you’d think: for any event on the chart, the system can generate a list of customers that it will send to an external system. The list could include all people in the event or a subset with specified behaviors. When I spoke with Pointillist a few weeks ago, the list would be a file export, but API connections were close to being ready. They’ll probably be done by the time you read this.

Also under development when we spoke was an automated cluster builder that would find clusters most related to (or distant from) the target event. This is different, and often more useful, than traditional clusters that find groups that are similar or distant from each other. Pointillist was also working on letting users create calculated variables, such as a lifetime value or engagement score, that would be available for analysis or segmentation. And on automated tools to help load unstructured data and clean dirty data. And on connectors to push data out to other systems. And on fuzzy matching to supplement the existing, and quite powerful, tools to unify customer data from different sources. Because nobody ever had too much fun.

Speaking of data loading, Pointillist has its own Javascript tag to capture Web behaviors, uses third party connectors to import data from many common systems, and can import batch files from nearly any source. Mapping new event types requires some basic technical skills but Pointillist is working to make it simpler. While APIs to push data to other systems are under development, APIs that let external systems pull data from Pointillist are already available.  These can access customer data but not other data types (remember those special data structures?)

In short, Pointillist both builds a robust, unified customer database and presents exceptional tools to analyze and act on the customer journey. It is the very model of a modern journey orchestrator.

_______________________________________________________________________________
*Nor, to be perfectly clear, am I saying that campaign management and marketing automation systems will go away. They will simply retreat to the execution layer where they will deliver emails and other outbound messages, playing an important role alongside other channel delivery systems like Web sites and call centers. But the fundamental decisions about which messages to send will be made by the orchestration engines.

Thunderhead ONE Provides Powerful Journey Orchestration

As I wrote a couple of posts back, I’ve recently noticed a new set of vendors offering “journey optimization engines”*. The key feature of these systems is they select customer treatments based on movement through a journey map. The treatments are usually executed through external systems such as email service providers, CRM, or Web content management. The systems also assemble the unified customer database needed to track customer journeys. This, of course, is a function they share with Customer Data Platforms. But CDPs don’t necessarily have journey mapping or treatment selection functions. On the other hand, journey optimization engines don’t always expose their data to external systems, which is a core requirement for CDPs. Journey optimization engines also provide at least some tools to analyze customer journeys and choose the best customer treatments. These may include predictive models, machine learning, and automatic creation of journey maps, but don’t have to.

Thunderhead ONE Engagement Hub is a charter member of this new little club. UK-headquartered Thunderhead itself was founded way back in 2001 and launched its original customer engagement product (highly personalized customer communications such as account statements) in 2004. ONE was developed by a U.S.-based engineering team.  It was released in Europe in 2015 and in the U.S. earlier this year.

Let’s look at how ONE handles the three core journey optimization functions:

- Data assembly. ONE provides its own Javascript tag to capture Web and email interactions and a SDK to connect with mobile apps. Other systems can feed data into ONE using a REST API or batch file imports. There are prebuilt API connectors for Salesforce.com CRM, Microsoft Dynamics CRM, and SAP Cloud for Customer. The system will automatically replicate the structure of imported data, maintaining relationships between different data elements. This allows ONE to store nearly any kind of data including not just customer attributes and identifiers, but also interaction and purchase details, touchpoint configurations, and product information.

Data is time-stamped to allow trending and give access to previous values of individual elements. Users can define calculations to create derived values such as engagement score, customer type, preferences, or interests. In addition to storing the imported information in a persistent database, ONE can lets users define in-memory profiles available for real-time access during interactions. These are updated immediately as new data is gathered, so the system is always working with the most current information.

ONE can link data using customer identifiers from different sources so long as there is a common element somewhere in the chain, such as an email address that is attached to a Web browser cookie through a form fill and to a mobile device through app registration. This allows the system to start tracking anonymous users when they first appear and later connect them to a personal profile when they identify themselves. But ONE does not standardize customer attributes, such as name or address, or use “fuzzy” matching to infer likely relationships.

All told, this is an exceptionally broad set of data management features. Many systems that build profiles – both CDPs and journey optimization engines – lack ONE's ability to store information about entities such as touchpoints or products. Nor do they always provide both a persistent data store and in-memory access. And while most can stitch together identities using shared identifiers, some rely on external systems to provide a common ID.

- Journey mapping. ONE lets users assign journey stages to activities and then classify interactions by activity type.  Interactions can also be tagged with other attributes such as channel, product, and marketing asset. The system uses this information to create many varieties of journey maps, including one that shows movement between stages broken out by channels, which is delightfully similar to the Customer Experience Matrix** I’ve been working with since 2006.*** Other versions filter the inputs to show maps for specific products, customer segments, or touchpoints within a channel (such as specific Web sites, retail stores, or phone agents). Maps can also compare attributes of different groups, such as customers who advanced towards purchase vs those who dropped out. Slicing the data in yet another way, maps can show the impact on engagement score of specific actions.  Hours of fun, eh?

- Execution. Users can create “conversations” that send messages to customers who match a specified combination of journey stage, customer attributes, and channels.  Eligibility and relevance rules can ensure the chosen messages are truly appropriate. One conversation can include several  messages in different channels.  Message contents can be drawn from a repository within ONE or from an external asset library.

The system uses machine learning to estimate how each customers will respond to each conversation and to calculate the value of the conversation. An arbitration function can then find the highest value conversation in each situation. The system can deploy conversations in real time, presenting CRM agents with recommended actions (along with a detailed customer profile and history) or Web pages with personalized contents (deployed in user-specified locations on the page). Personalized content and data can also be pushed to other execution systems such as email through API connections, either in batch or real time. External systems can access individual customer records through the ONE API.  Data can also be extracted from ONE to standard SQL databases, which external systems could then query.

Pricing for ONE starts at $30,000 per year and is based on the volume of interactions and personalization recommendations, with unit costs varying by channel.  The system has 38 clients in Europe and about a dozen in North America.

______________________________________________________________________________

*I would love to call these JOEs but don’t have the heart to inflict another obscure acronym on the industry. You’re welcome.

** Originally developed by my colleague Michael Hoffman. Click here for his take on it.

*** I’m not suggesting that Thunderhead based their map on the Customer Experience Matrix. Many people have come up with similar ideas. I do like to think that Hoffman and I were ahead of our time.