Marketing Foundations Analysis Tool: Gap Analysis, Recommendations, and Benchmark for Your Marketing Systems

Way back in January, I began working with SAP on a set of worksheets to help marketers assess their customer management systems. The much-evolved fruits of that effort were released today as the Marketing Foundations Analysis Tool, a fully automated system that asks users a series of questions about their current systems, marketing programs, and company background, and returns recommendations for system changes and how to manage the transition. Survey-takers will also be shown how their current systems compare with everyone else who answered the questions.

The key insight powering this project was that there are relatively few types of marketing programs and systems.  That may not sound very important (or surprising), but it means the problem is simple enough to address with a relatively small amount of user input and business logic.  Specifically, it's practical for a survey to ask marketers which programs they want and what their current systems look like.  From there, it's fairly easy to specify the system capabilities required to run each program, to aggregate these into a consolidated set of requirements, and to compare the requirements with existing capabilities for a gap analysis.  This can be combined with information about the company to generate recommendations for what to do next.

In fact, if anything surprised me during this project, it was how much information could be derived from a relatively small amount of user input. The Analysis Tool asks about:
- nine types of marketing programs, ranging from customer profiling to real time interactions to loyalty programs to marketing measurement.  Users specify whether they currently run each program, want to run it in the future, or have no interest.

- thirteen types of customer-facing systems, ranging from email and Web sites to display ads, retail point of sale, and customer account management. These are rated on a spectrum of integration capabilities, from being totally isolated to allowing real time interactions.

- seven types of shared customer data processes, ranging from single customer view to predictive modeling to treatment selection to advanced analytics. Each process is rated on different capabilities, such as calculating scores for predictive modeling and handling unstructured data within the single customer view.

That's it -- just 29 items, although some do have subitems.  Based on those inputs, the Analysis Tool produces recommendations covering:

- general architecture (integrated suite, shared customer data platform, or application-based) and change strategy
- industry-specific issues to address, such as regulatory concerns
- opportunities to improve business results by running more marketing programs
- coordinating changes to marketing programs with changes to systems
- changes to customer-facing systems (over-all and whether to keep, enhance, or replace individual systems)
- changes to shared customer data processes (over-all and process-by-process)

That's a lot of information, and it doesn't even include the benchmark comparing your answers to everyone else's.  Not bad for free.  Thanks, SAP!


So how does this all work?  To peel back the covers just a bit, the recommendations are made by first classifying results into general categories such as “few active applications” or “mostly simple systems”, and then applying rules to select pre-written answers.  For example, a company with "few active applications" and "many desired applications" is told:

Assessment: Your company is running relatively few current marketing applications but wants to add many more. This could be a challenge given your relatively limited experience.

Recommendation: Prioritize the new applications so you don’t make too many changes at once. Start with applications that require relatively little change but also offer significant rewards. These should add capabilities that will also be used for subsequent new applications. Measure results carefully and prove success before moving on to make more changes.

Obviously I’m biased, but I think that level of advice is specific enough to be useful. It can’t replace the insight of a human analyst who can assess the situation in more detail and may see connections that simple rules will miss. But it certainly provides a starting point for discussions and a base of data to work with. Well worth a ten minute investment of your time.

Again, you can try the tool here.  You can take it anonymously and view the results on screen, or give SAP your email and have them send you a copy of the report.  Either way, give it a shot and let me know what you think.

Oracle Buys BlueKai and Puts Marketing Databases In the Spotlight

Oracle announced this morning  that it is buying BlueKai, a leading Data Management Platform (DMP) technology vendor and operator of one of the largest data marketplaces. Since I just wrote last Friday about how DMPs integrate with marketing automation to unify customer treatments in Web advertising and direct channels, I’m tempted to just point you to that post for an explanation of how this works and why it matters. I’m also tempted to remind you that I predicted this convergence as an industry trend back in December.  But instead I’ll expand a bit on the fundamental significance of this deal – which is that it promises a serious step toward solving the fundamental problem that increasingly hobbles advanced marketing technology: lack of a solid underlying customer database.

If you look at Oracle’s diagram of their newly expanded Marketing Cloud, you’ll see BlueKai sitting beneath Responsys and Eloqua, providing a “universal customer profile” that allows them to act as “marketing orchestration” systems which, in turn, support programs across all channels – social, search, email, display, mobile, web, commerce, direct sales, and channel sales.

“Marketing orchestration” is a considerable jump beyond the traditional role of “marketing automation”, but I’ll save that analysis for another day. What matters right now is that Oracle places BlueKai exactly where I’ve been placing the Customer Data Platform: as a multi-source database that feeds unified customer data to marketing applications.

This is the first time we’ve seen a major enterprise software vendor draw that picture quite so clearly. More typically, they just do some hand waving around the customer database without explaining how it magically appears. Deep in their hearts, what they really hope is that the database for their core application – CRM, email, Web site management, whatever – will be that central, shared database.  They hope this even though their application doesn’t really provide the database management tools needed to make it happen, and their database itself is often tailored too narrowly to the specific application to support the full range of other uses.

BlueKai, on the other hand, is all about the data. Like other DMPs, it is still mostly organized around cookies and advertising audiences, but it does offer the ability to import other types of data and can certainly track identified individuals if the user wants. The fact that it can combine anonymous and identified profiles is extremely important if marketers are to build a single unified customer data repository and use it to support all contact channels, including Web advertising. The fact that it’s a distinct, named product gives that central customer database the prominence that it deserves.

In short – and I don’t use this term loosely – the BlueKai acquisition could truly be a “game changer” that forces other enterprise software vendors to also give marketers the CDP-style database building tools they’ve needed so desperately. As of this morning, Oracle’s competitors have a new gap in their product lines. It will be interesting to see how they fill it.

Woopra Grows from Web Analytics to Multi-Source Customer Data, Insights and Actions

I stumbled over Woopra in their tiny booth during last month’s Dreamforce conference, where I was intrigued enough to let them scan my badge and promptly forgot why.  Fortunately, a diligent sales rep followed up by email and I remembered it was worth a closer look. If you’ve been reading my recent posts, you won’t be surprised that I’ve decided they are yet another Customer Data Platform.

In fact, the people most surprised by this news will probably be the folks at Woopra itself, which positions itself as “an insight company” and has deep roots in traditional Web analytics. On the other hand, Woopra does distinguish itself from conventional Web analytics vendors by stressing the fact that it tracks individuals, not Web pages. In fact, one of its tag lines is “easily track, analyze, and take action on live customer data”, which is a pretty decent statement of the CDP value proposition.

Tag lines notwithstanding, Woopra wouldn’t qualify as a CDP if it only tracked Web behavior. But Woopra offers the core CDP function of building a multi-source database.  It does this by directly capturing behaviors from Web site visits and mobile app interactions (via Javascript tags and API calls from iOS or Android) and by loading operational data such as purchases and customer service interactions. As its Dreamforce presence suggests, Woopra can integrate with Salesforce.com to both import CRM data and to display the information it has consolidated from multiple sources.  The system can combine data with different identifiers, such as a cookie ID, mobile device ID, and Web session ID, although – like many CDPs – it relies on the client to figure out which identifiers belong to the same person.

Woopra stores its data as a combination of customer attributes and time-stamped individual events. The event data lets it report on individual movement through funnel stages, performance of start-date cohorts, and paths through a Web site or app, in addition to the usual profile reports. It stores the information using proprietary technology that allows continuous real-time updates and ad hoc segmentations, so users can run any report against a subset of the customer universe. Users can also design their own custom reports.

Woopra provides an API that lets external systems access its database, although it places some limits on volume to avoid performance issues. This access meets the minimum requirement for a CDP.  The system can also continuously scan for user-specified events or conditions and execute user-specified actions when these occur. The actions can run Javascript on the client Web site, add tags to a customer record, send an email or push notification, or a call an external system via a Webhook. This allows marketers to manage some basic customer treatments within Woopra itself. But the system doesn’t have any predictive modeling or recommendation engines, so more advanced approaches would require external assistance.

Woopra was founded six years ago and relaunched in 2012. It has more than 3,000 paying customers in a wide range of industries, including many small businesses and several large ones. The system is offered in three editions with different sets of features, including a free version for simple visitor tracking. Pricing is based on activity volume and starts at $80 per month for the mid-level edition.

Optimove Helps Optimize Customer Retention (And, Yes, It's a Customer Data Platform)

As I wrote last week, it sometimes seems that every system I look at these days is a Customer Data Platform. Of course, this is partly because I’m choosing to look at that type of system, and partly because CDP vendors are reaching out to me. But I do believe another reason is that CDPs are an idea whose time has come: I’ve recently seen at least three CDPs that are just emerging from stealth or beta mode. All were developed because someone else recognized the huge unmet need for getting  better customer data to marketers.

One of the vendors that contacted me was Optimove, a Tel Aviv-based firm that calls itself a “retention automation platform” but definitely fits the CDP criteria. This means that Optimove is a marketer-controlled system that loads data from multiple source systems, puts it in a marketing-friendly format, and makes it available to external marketing execution systems.

Like many CPDs, Optimove also includes a campaign engine that pushes specific marketing actions to the external systems. Optimove’s approach is unusual in basing its campaign interface on a calendar that lays out the campaign schedule for each user-defined customer segment. This makes it easier for marketers to build a comprehensive contact strategy from multiple campaigns.

The campaigns themselves each have their own schedule, allowing them to run once, daily, weekly, or monthly. Users can also limit the number of messages sent to each customer by assigning an exclusion period to each campaign. Other campaigns can be instructed to respect or ignore these exclusion periods, ensuring that high priority messages are delivered in all circumstances. Each campaign triggers a single action, which can be directed to email, banner ads, direct mail, Facebook custom audiences, in-app pop-ups, SMS, app message boards, call centers, or other channels. The connections may be through file transfers or APIs.

Optimove's campaign interface is unusual, but the system is even more unusual in taking performance measurement very seriously. Its standard campaign setup requires users to assign a success measure and to either set aside a control group or set up a multi-way split of alternative treatments. This enables standard reports, including the campaign calendar itself, to show the incremental value provided by each campaign – the critical information needed for long-term optimization. By contrast, most marketing systems make success targets and testing optional if they support them at all. Users can also see a history of all campaign results for a given segment, making it even easier to identify the most productive programs.

The campaign segments themselves, which Optimove calls target groups, are built by accessing data that Optimove has loaded from the client’s data warehouse and operational systems. Optimove has standard data models for different industries, reflecting its current customer base: online gaming (bingo, casinos, poker, sports betting, etc.), foreign exchange trading, and ecommerce. The system assumes the data has already been coded with customer IDs, which something that makes reasonable sense given the focus on retention rather than acquisition. 

Data is typically loaded daily or weekly. After each load, customers are assigned to life stages (typically, new customers, active customers, and churned customers) and to multiple segments based on behaviors and attributes, such as location, product preferences, and spending levels. The system then uses the life stages and segment attributes to assign customers to "microsegments" that cluster analysis has found will behave similarly. It’s important to understand microsegments represent a current customer state that will change over time: that is, each customer belongs to different microsegments at different stages in her life cycle.

Optimove calculates the probability of moving from one microsegment to the next and uses this to predict how a given group of customers will behave in the future.  This is the basis for its lifetime value and churn predictions – key metrics in system reports. This type of forecasting is something else that really should be done by every marketing system, but rarely is. Optimove also provides cohort analysis reports, comparing performance of customers who joined during different time periods. This is yet another important type of information that is not always available.

Optimove does have some limitations. I was surprised there are no standard reports to highlight attributes that separate responders from non-responders within a promotion audience: this is pretty common information that helps marketers to refine their segmentations and better understand what is driving results. Nor does the system current recommend the best action to take with individual or a group. Both features are being worked on for future release.

Optimove was founded in 2009 and currently has about 70 clients, mostly in Europe. It has a few U.S. customers and is looking to expand in this market. Pricing is usually based on the number of customers and begins around $2,500 per month.

Gainsight Gives Customer Success Managers a Database of Their Own

I had a conversation last week with a vendor whose pitch was all about providing execution systems with a shared database that contains a unified view of customer information from all sources. Sadly, they were unfamiliar with the concept of a Customer Data Platform as I’ve been developing it over the past few months and didn’t realize that they fit the definition.

This post is not about that company.

Instead, it will be about another company I also spoke with last week, which I had originally considered a CDP but then decided wasn’t. After hearing their latest news, I still place them outside the border, but think they’re creeping closer and – for reasons I’ll explain later -- will some day reach the other side.

The company is Gainsight (formerly JBara), whose Web site positions it as ”a complete customer success platform”. That could easily be pure fluff – doesn’t every company contribute to its customers’ success? – but Gainsight actually means something concrete: it helps customer success managers identify churn risks and sales opportunities among their clients. As Gainsight sees it, this makes them the post-sales analogue to marketing automation systems (which manage acquisition) and CRM systems (which manage sales)*. This trichotomy** ignores customer service systems, which I'd consider the major post-sales management tools. But Gainsight is genuinely different from customer service, and in fact uses those systems as data sources. So even though Gainsight may not have created the third great category of customer-facing systems, it does do something important.

Specifically, Gainsight gathers information from online products, CRM, customer service, accounting, and customer surveys to create a complete view of how existing customers are using the products they own, whether they’re renewing or expanding their usage, what they’re paying, what sorts of service issues they’re having, and what attitudes they’ve expressed.  It tracks this over time and uses the information in a variety of ways: to profile and summarize the health of each account; to send alerts about problems or opportunities; to display trends in usage, satisfaction, and other measures; and to analyze the customer base by relationship stage, revenue range, and other factors. The information is presented through Gainsight’s own interface, which runs on Salesforce.com’s Force.com platform, making it easy to integrate with Salesforce itself.

Gainsight originally stored all its data within Force.com, but it has recently started using MongoDB and Hadoop, which will allow it store details such as clickstreams and product usage history. The company has also expanded its "big data science" resources to identify the attributes of customers likely to churn or to purchase new services. This will help users define the rules that drive alerts.  So far, there is no automated predictive modeling to build such rules, although that’s planned for the future. Data is typically loaded weekly, which Gainsight says is the most often that customers have requested.

Of course, once all that juicy customer data has been assembled in one place, companies could use it for more than customer success management. This is part of Gainsight’s master plan, which is to expand beyond customer success teams to account management, sales, and other departments.

This brings us (or me, at least) back to the question of whether Gainsight is a Customer Data Platform. It does build a multi-source customer database, which is the core CDP function. Although the data sources are largely limited to the client’s own systems, external sources are not essential for a CDP.  In any event, Gainsight could probably add external sources fairly easily if a client wanted – especially now that it isn’t bound by the limits of Force.com. Gainsight isn’t yet doing predictive modeling or decision management beyond rule-based alerts, but those common CDP features are also optional, and Gainsight is moving in those directions. Gainsight clearly meets the CDP requirement of building a database controlled by users outside of IT, even though in this case the users are not marketers.

Where Gainsight gets disqualified is that a CDP by definition makes its data available to other systems to guide customer treatments. The Gainsight database is technically exposed already: users could query the Force.com data via the Salesforce API or write direct SQL queries against the new Mongo / Hadoop back-end.  But so far Gainsight’s direction has been to use its data in its own applications and user interface. If Gainsight opened itself up as a data source, it would clearly be a Customer Data Platform.

Even as Gainsight stands today, it’s still more evidence supporting the CDP proposition that companies need a multi-source database – and a warning that multi-source databases themselves could proliferate into a new forest of single-purpose data silos if companies don't adopt a shared CDP instead. As this danger becomes clearer, Gainsight and other companies will need to either become general-purpose CDPs themselves or become applications that plug into a CDP built by someone else.

Gainsight was founded in 2009 and started taking paying customers in 2012. It now has about 20 clients, mostly large enterprises running an online service or Web site. Pricing is based on the number of modules used plus number of users, and averages around $50,000 to $60,000 per year for 20 to 50 users.



_____________________________________________________________________________________________
* Okay, CRM really is more than sales force automation, but that’s the term that Gainsight used and CRM is increasingly used in that narrower sense, mostly because that’s how Salesforce.com describes itself. Get over it.

** Yes, that’s a word.

Customer Data Platform Guide Reviews Tools to Build Marketing Databases

Raab Associates’ new Guide to Customer Data Platforms is now available [update: as of 2014, we no longer sell it].

You may not find that news to be fall-off-your-chair exciting. In fact, you’re more likely to wonder whether the world needs yet another report on anything at all. Fair enough. So before telling you what’s in the CDP Guide, I'll tell you why it exists.

Simply put, marketers need better databases. If you’re a working marketer, you almost surely know this from personal experience. But someone who only read industry news and vendor promotions might think all anyone had to do was to plug in the latest cool application and it would immediately be filled with fresh clean data like water from a tap. Dirty big data is our industry’s dirty little secret.


The problem isn’t new but it is getting worse. As customers interact across more channels, marketers need to not just meet them in every new location but recognize them and carry on a continuous conversation from one touchpoint to the next. Marketers can also become more effective by enriching that conversation with information from external sources such as Web pages, social media, and commercial databases. Both the carrot of better results and the stick of customer expectations are ever-more-urgently driving marketers towards building better databases.

The good news is that plenty of smart vendors have also recognized this need and are trying to help marketers on their journey. I call their systems Customer Data Platforms and define them as “a marketer-controlled system that supports external marketing execution based on persistent, cross-channel customer data.”

If there’s one absolutely critical point in that definition, it’s that CDPs put marketers in charge of building their own database. Taking control is the only way that marketers will ever get the databases they desperately need. It’s why CDPs are so important.

But too few marketers know who the CDP vendors are, what they do, and how they differ. The Guide to Customer Data Platforms is designed to provide this information. If the CDP vendors are tour guides on the path to better data, the CDP Guide is the reviews you read to decide which one you’ll hire. As far as we know, no other study serves this purpose.

Given its goal, the heart of the Guide is the vendor profiles: three to five pages on each vendor, describing capabilities for data management, predictive modeling, marketing campaigns, and message delivery, plus background on the vendor’s technology, clients, company history, and pricing. You’ll want to read those closely when you’re selecting a vendor. But first you’ll have to decide whether a Customer Data Platform is something to consider. Here is some information to help make that judgment.

- CDPs are something new. CDPs are systems that help marketers build and update customer databases, and make those databases available to support marketing programs. That may not sound very new, but most B2B marketing automation products today build very limited databases while most B2C marketing automation products rely entirely on an external data warehouse. The systems that do build databases are designed to be used by IT departments, not marketers. And many CDPs provide predictive modeling or best-treatment recommendations that go well beyond the storage functions of a basic data warehouse.

- You still can’t do this at home. CDPs may be tools for marketers, but that doesn’t mean that marketers build the databases themselves. Rather, CDP vendors provide services that build the database with varying degrees of marketer involvement. The difference is that the marketers work directly with the CDP vendors, instead of relying on IT staff that often has other priorities and an imperfect understanding of marketing needs. This makes it much easier and quicker for marketers to get the database they need.

- CDPs are an outgrowth of existing system types. Most CDP systems were created for a purpose that happened to require the same database-building capabilities as a CDP. These purposes fall into three groups which I discussed in last week’s post, so I won’t repeat them here. They’re worth understanding because vendors in each group have a different set of skills, one of which will probably come closest to your needs.

- Convergence is coming. Even though the CDP vendors started with different applications, their shared abilities for identity matching, database management, analytics, and integration will allow them to support more of the same functions over time. As marketers understand the value of their databases more clearly, CDP vendors will be able to focus on selling their data platform features rather than applications the platform supports. Of course, once the platforms themselves are common, vendors will climb the value chain by offering better predictive analytics and cross-channel treatment optimization.

- Details count. CDP features may eventually converge, but for now the systems differ in many small ways that make a big difference. To take one example, nearly every CDP creates predictive models. But some can only predict response to specific promotions, based on who has responded before. Others can do the much more sophisticated analysis needed to predict which offer will best advance a long-term goal such as becoming a new customer. And even among those that model against long-term goals, some can actually estimate the incremental impact of a specific offer and others can just see most common correlations. We found similarly subtle differences in how data is collected (via the vendor’s own Web tags or by importing from other systems), the range of data sources (just marketing automation and CRM or those plus many others), natural language processing to extract useful information from text sources such as Web pages, how much history is kept and how it’s used, program execution, and end-user control. The CDP Guide clarifies these distinctions, but it’s still up to marketers to evaluate which differences will matter in their own business.

The CDP Guide itself contains quite a bit of other useful information, including a formal definition of CDPs, detailed explanations of what to look for in a CDP, and a history of marketing databases starting with ancient Sumer (don’t worry, I skipped the boring parts). Again, the goal is to provide one package with everything you need to get started along the path of buying a CDP system.  From there, it's up to you.