Picking the Right First Project for Your Customer Data Platform

For the past year, the most common question about Customer Data Platforms has been how they differ from Data Management Platforms. Recently that seems to have changed.  Today, the question everyone seems to be asking is what project they should pick as their first CDP use case.

That’s certainly progress but it’s a much harder question to answer than the one about DMPs. Like any good consultant, I can only answer that question with “it depends” and by then asking more questions. Here are some of the factors that go into a final answer.

• What resources do you have available? The goal for your initial use case is to get something done quickly that returns substantial value. Getting something done quickly means you want a project that uses existing resources to the greatest degree possible. Ideally, the only new element would be the CDP itself, and even the CDP deployment would use a small number of data sources. So, an ideal first project would use data in existing systems that is well understood, known to be of high quality, and can easily be extracted to feed the CDP. Alternately, the first project might involve new data collected by the CDP itself, such as Web site behaviors captured by the CDP's own page tag. If the first project is purely analytical, such as customer profiling or journey analysis, then you don’t need to worry about connecting to execution systems, although you do need staff resources to properly interpret the data and possibly some analytical or reporting systems. But if you happen to have good execution systems in place, it may make sense for the first project to connect with them. Or, you may pick a CDP that provides its own execution capabilities or can feed lists or offer recommendations to external delivery systems.

• What use case will provide value? This is where good delivery resources can be helpful: it’s much easier to deliver value with a use case that involves direct customer interaction and, thus, the opportunity to increase revenue or reduce costs. Often this can still be quite simple, such as a change in Web site personalization (involving just one channel for both source and delivery), an event-triggered email, or a prioritized contact list for sales teams. If execution isn’t an option, an analytical project can still be valuable if it presents information that wasn’t previously available. This may mean combining data that was previously kept separate, reformatting data couldn’t be analyzed in its original form, or simply pulling data from an inaccessible system into an accessible database. The trick here is for the analysis to generate insights that themselves can be the basis for action, even if the CDP isn’t part of the execution process.

• How much organizational change will be needed? Technical obstacles are often less significant barriers than organizational resistance. In particular, it can be difficult to start with projects that cross lines of authority either within marketing (say, separate Web and email teams) or between marketing and other departments (such as operations or customer support). When considering such changes, take into account the needs to revise business processes, to provide adequate training, to align compensation systems with the new goals, to provide reporting systems that track execution, and to measure the value of results. As a practical matter, the fewer parts of the organization affected by the initial project, the easier it will be to deploy and the higher the likelihood of success.

• Where’s the pain? It’s tempting to search for an initial project that is primarily easy to deploy. But even an easy project is competing with other demands on company resources in general and on staff and managers’ time in particular. So it’s important to pick a first project that solves a problem that’s recognized as important. If the problem is big enough – and it’s clear the CDP can solve it – then you have a good chance of convincing the company to make a substantial investment from the start. Ultimately, this is the right approach: after all, the CDP isn’t an end in itself, it’s a tool for improving your business. You may see a broad range of applications for your CDP but for those who don’t share that vision, you’ll need to show its value at every step of the way.

Surprising Results in Customer Data Platform Survey

The Customer Data Platform Institute (CDPI) recently surveyed its members about their customer-facing systems and CDP deployment plans.  (Click here to download the full report.)  While CDP Institute members are obviously not typical marketers (being smarter, richer, and better looking), the answers still provide some intriguing insights into the marketplace.

Let’s start with the general state of customer facing systems. One-third reported they had many disconnected systems, just over one-third reported (37%) they had many systems connected to a central platform of some sort (9% unified customer database, 9% unified database and orchestration system, or 19% marketing automation or CRM platform), 6% said one system does almost everything, and the remaining 23% said they had some other configuration or didn’t know.

I’ve compared these results below with several other surveys that asked similar questions.

The one thing that immediately jumps out in this comparison is the CDPI Member survey showed a much lower percentage of replies for “one primary system”. Otherwise, the answers across all surveys are very roughly similar, showing about 30% to 50% of companies having many connected systems and many disconnected systems. This suggests more integration than I’d expect, but it depends on how much integration those “many connected” systems really represent.

The CDPI Member survey also asked about plans regarding Customer Data Platforms. Nineteen percent had a CDP already deployed, 18% had deployment in progress, and 26% planned to start deployment within the next 12 months. The remaining 38% either planned to start after 12 months (4%), had no plans to deploy (19%) or didn’t know (14%). I haven’t seen any other survey that asks this question but have no doubt that CDP deployment and plans are much higher for CDPI members than the rest of the industry average.

Where things get really interesting is when we explore how the same people answered these two questions. At first blush, you’d assume the 19% with a deployed CDP would be the same 18% who said they had many systems connected to a unified customer platform, either by itself or with an orchestration engine attached. Not so much. Here’s the actual cross tab of the results.

What you see (in the yellow cells) is just 42% of the people who said they had a deployed CDP also said they had many systems connected to a unified database. If we allow that a deployed CDP could be present in companies where one customer-facing system does almost everything or the customer facing systems are connected to marketing automation or CRM, then 74% of the deployed CDPs are covered.

I take the remaining 26% as a healthy reminder that just having a CDP doesn’t guarantee all your systems will connect to that CDP, either by feeding data into it or reading data from it. In fact, we know that many CDPs support analytics without being connected to delivery systems, so this really shouldn’t come as a surprise.

On a more encouraging note, as the green cells highlight, a good majority of in-process and planned CDP deployments are at companies with many disconnected systems or many systems connected to a marketing automation or CRM.  Those are the companies most in need of data unification. So it does appear that the CDP message is reaching its target audience and CDPs are being used as intended.

The survey also asked about company revenue, business type (B2B vs B2C), and region. Comparing those with current systems and CDP deployment also gave some interesting and unexpected results. But there's no point in repeating them here since you can download the full report and see for yourself.  Enjoy!

Treasure Data Offers An Easy-to-Deploy Customer Data Platform

One of my favorite objections from potential buyers of Customer Data Platforms is that CDPs are simply “too good to be true”.   It’s a reasonable response from people who hear CDP vendors say they can quickly build a unified customer database but have seen many similar-seeming projects fail in the past.  I like the objection because I can so easily refute it by pointing to real-world case histories where CDPs have actually delivered on their promise.

One of the vendors I have in mind when I’m referring to those histories is Treasure Data. They’ve posted several case studies on the CDP Institute Library, including one where data was available within one month and another where it was ready in two hours.  Your mileage may vary, of course, but these cases illustrate the core CDP advantage of using preassembled components to ingest, organize, access, and analyze data. Without that preassembly, accessing just one source can take days, weeks, or even months to complete.

Even in the context of other CDP systems, Treasure Data stands out for its ability to connect with massive data sources quickly. The key is a proprietary data format that lets access new data sources with little explicit mapping: in slightly more technical terms, Treasure Data uses a columnar data structure where new attributes automatically appear as new columns. It also helps that the system runs on Amazon S3, so little time is spent setting up new clients or adding resources as existing clients grow.

Treasure Data ingests data using open source connectors Fluentd for streaming inputs and embulk  for batch transfers. It provides deterministic and probabilistic identity matching, integrated machine learning, always-on encryption, and precise control over which users can access which pieces of data. One caveat is there’s no user interface to manage this sort of processing: users basically write scripts and query statements. Treasure Data is working on a user interface to make this easier and to support complex workflows.

Data loaded into Treasure Data can be accessed through an integrated reporting tool and an interface that shows the set of events associated with a customer.  But most users will rely on prebuilt connectors for Python, R, Tableau, and Power BI.  Other SQL access is available using Hive, Presto and ODBC. While there’s no user interface for creating audiences, Treasure Data does provide the functions needed to assign customers to segments and then push those segments to email, Facebook, or Google. It also has an API that lets external systems retrieve the list of all segments associated with a single customer.  

Treasure Data clearly isn’t an all-in-one solution for customer data management.  But organizations with the necessary technical skills and systems can find it hugely increases the productivity of their resources.  The company was founded in 2011 and now has over 250 clients, about half from the data-intensive worlds of games, ecommerce, and ad tech. Annual cost starts around $100,000 per year.  The actual pricing models vary with the situation but are usually based on either the number of customer profiles being managed or total resource consumption.

Should Customer Data Platforms Be "Marketer-Controlled"?

Thomas Wieberneit argues in a thoughtful blog post that companies need one platform for consolidated customer data, but that Customer Data Platform isn’t it because the CDP is “marketer-controlled” by definition, and thus doesn’t support other departments.

This hits a nerve. Many of the CDP vendors have told me their systems are used outside of marketing. Just last week, RedPoint unveiled a “Customer Engagement Hub”* that it defines as extending beyond marketing to all customer touchpoints. When I was recently writing a paper for B2B CDP CaliberMind, they listed sales and customer success teams along with marketing as likely buyers of their product.

As these examples suggest, CDP technology can support all customer-facing departments. It’s true that different departmental applications will probably need the CDP data to be presented slightly differently. But applications within marketing also need different formats, and it’s already standard for CDPs to reformat their data for access by external systems. So there’s no technical reason to limit CDPs to marketing.

Indeed, as I argued in my last blog post, the era of isolated marketing technology systems may be coming to an end as companies return to centralized systems to ensure a seamlessly integrated customer experience. In this world, the CDP is a shared enterprise asset, and, as such, clearly not something that marketers build and control for themselves.

So what’s holding me back from changing the definition? Three things:

• History. The fact is that CDPs evolved from systems that were built specifically for marketing. This matters because it means marketing needs drove their design. CDPs built to support sales or customer success teams would probably look a bit different, even if they used the same underlying technology. To give a concrete example, systems built for customer success don’t need to advanced identity resolution because almost all the data they care about arrives with a customer ID attached. I know that history by itself isn’t a good reason to retain the marketer-centric definition of CDP since CDPs have outgrown their origins. But it doesn’t hurt to have something remind users outside of marketing that they should look closely at whether any particular CDP can fully support their needs.

• User control. The primary reason the CDP definition includes “marketer-controlled” is to distinguish CDPs from enterprise data warehouse (or data lake) projects run by corporate IT. That matters because such projects were historically multi-year undertakings that often failed altogether or required so many compromises among enterprise stakeholders that they didn’t meet all of marketing’s particular needs. Moreover, once built, such systems were slow and costly to update, so they didn’t adapt quickly to marketers’ fast-changing environment. This responsiveness is really the biggest change that CDPs introduced into the world of customer data management. As I noted earlier, department-controlled systems may soon be lost in a new round of centralization.  In theory, these new central systems will be vastly more responsive to user needs than the old central systems. But if I were a marketer, I’d be reluctant to give up my own systems until the new ones had proven their agility in practice.

• Departmental buyers. Whatever the long-term future of centralization, CDPs today are almost always bought by departments.  Even when corporate IT groups are managing the process, they are generally reacting to requests from departmental users rather than executing an enterprise master plan of their own. And when you start looking at which departments are making these purchases, marketing is by far the leader.  It’s true that other departments often find uses for a CDP once it’s deployed. Whether marketers really share control of their CDPs when this happens or simply treat other users as guests, I can’t say. From a seller’s standpoint, I can certainly see companies offering their technology in packages aimed at enterprise buyers, which is exactly what RedPoint just did. But abandoning the large marketing-department segment for the nascent enterprise-buyer segment doesn’t sound like a good idea.

So it seems I’ve backed myself into a corner. CDP technologies work at the enterprise level and, logically, CDPs should be enterprise assets. But the main buyers of CDPs are marketing departments and the CDPs' main attraction is departmental control.  So redefining the CDP as an enterprise system would probably reduce its appeal even though it was technically accurate. Replacing "marketer-controlled" with “user-controlled” or “department-controlled” would broaden the scope but still doesn’t describe an enterprise-wide role. We could drop “control” from the definition and get to the heart of the matter, which is responsiveness – so instead of “marketer-controlled” we could have something like “agile” or, more concretely, “easily changed”. But those seem too vague to be useful.

I’m tempted to offer something truly lame, like “Enterprise CDP” as an alternative to plain or Departmental CDP.  It might come to that, or I might ultimately just drop “marketer-controlled” without replacing it. After all, if enterprise systems really do become flexible enough to meet departmental needs in a way that past enterprise data warehouse projects did not, then the distinction will no longer matter.

Bottom line: I’ll leave “marketer-controlled” in place for now but suspect its days are numbered.


________________________________________________________________

*CEH is a Gartner term, which they define as “an architectural framework that ties multiple systems together to optimally engage the customer. A CEH allows personalized, contextual customer engagement, whether through a human, artificial agent, or sensors, across all interaction channels. It reaches and connects all departments, allowing, for example, the synchronization of marketing, sales and customer service processes.” As the term “hub” implies, this definition doesn’t specify creation of a persistent database, something I believe is required to build an effective customer profile. Come to think of it, I'm not sure that "architectural framework" is a system at all. 

LeadGenius Adds a Dash of Artificial Intelligence to Account Based Marketing

You may have noticed that I’m writing a little less about artificial intelligence than I had been. It may be that Skynet has imprisoned the real David Raab to block him from issuing dire warnings about its imminent threat to humanity and replaced him with a less alarmist simulation. You can’t actually prove that isn’t happening. But the David Raab, or Raab-bot, writing this will tell you it’s because he’s concluded that AI is destined to become so pervasive that it doesn’t make sense to treat it as a distinct topic. It will simply be embedded in everything and so should be evaluated as part of whatever it belongs to.

LeadGenius is a good example. The company is in the business of assembling B2B marketing lists – an industry dating back centuries to city directories and beyond. But LeadGenius was founded in 2011 to commercialize university research into combining AI with human inputs. It has since expanded from list gathering to all stages in the Account Based Marketing process, sprinkling in dashes of artificial intelligence at every step along the way.

Let’s look at those stages, using the four step structure of the Raab Guide to ABM Vendors.

1. Identify target accounts. This includes assembling data on potential accounts and selecting the right targets. Like many data gatherers, LeadGenius uses a combination of Web and other sources to build company and contact lists. Nearly every vendor who does this applies some form of natural language processing to extract information from unstructured sources. LeadGenius does this too. But it goes further by using artificial intelligence to identify records with questionably accurate information. It then sends these to humans for direct verification by telephone. The company guarantees 99% accuracy in its data, which is significantly better than most competitors can offer. AI's contribution here is to let LeadGenius call only the companies that need human contact, reducing over-all effort substantially. 

To find the right targets, LeadGenius loads a client's current CRM lists. It analyzes these for accuracy and completeness, providing users with reports that highlight problem areas. There’s probably some AI at work in that analysis. LeadGenius then identifies major file segments within the customer base and finds similar companies in the broader universe, estimating potential buyers and revenue by segment. Somewhat surprisingly , LeadGenius doesn’t create predictive lead scores, having found its more useful to prioritize prospects based on company attributes like size and industry. LeadGenius does use artificial intelligence, or at least its country cousin “fuzzy logic”, to map business titles into buyer roles, taking into account how different terms are used at different size companies to describe the same role.

2. Plan interactions. LeadGenius has a basic email campaign capability, including segment definition, email templates with personalization variables, and email sequences. There don’t seem to be any particular AI features here, although we’ll see in a moment that email does play a key role in LeadGenius’ AI utilization.

3. Execute interactions. LeadGenius sends emails through corporate or individual salespeople’s email accounts. It captures replies and uses AI-based natural language processing to classify them, distinguishing answers that indicate interest from out-of-office messages and clear rejections. Hot leads are pushed back to salespeople’s inboxes.  All response classifications are added to the database where they can be used in future selections. So AI does indirectly drive interaction flows. Response data can also be posted to Salesforce.com or Marketos, with additional integrations planned for the near future. Messages through other channels would have to be executed through marketing automation or CRM.

4. Analyze results. LeadGenius has the usual email and campaign reporting, enhanced with the AI-based response classifications.

As promised, you see a bit of AI magic at each of these process stages (assuming you count the AI-based email response as enabling the interaction planning). Certainly there’s room for more features and more AI use. But it’s already enough to illustrate how AI will add power throughout the ABM cycle.

LeadGenius is used primarily by large enterprises selling to small businesses. Those are the firms that can most benefit from its comprehensive data, market analyses, and prospect lists. Pricing is tailored to each client. The company has more than 150 B2B clients.

Quaero AdVantage CDP Bridges Identified and Anonymous Data

It’s a common pattern: several vendors proudly roll out new products they developed in secret, only to find they’re all very similar. The amazing coincidence isn’t really so amazing: everyone sees the same problems and has the same technologies available to solve them. So they come up with similar solutions.

Simultaneous rollout.  I've had this picture in my head for years.  Apologies to Dr. Seuss.

We’ve seen some of that in the Customer Data Platform industry, but there’s a twist. Many CDPs evolved from older systems and inherited some of their ancestors’ characteristics. One of those lineages goes back to marketing databases from simpler days, when postal mail and email were the main channels. The big challenges for those systems were loading complex data structures (addresses, transactions, message history, etc.), cleaning that data, and identifying records that belonged to the same individual. In that world, there was no such thing as an anonymous customer and most data was neatly structured. As I say, a simpler time.

Quaero’s AdVantage is a good example of a system with deep roots in the old methods – but updated to handle modern challenges. Quaero itself was founded back in 1999 as a marketing services provider (meaning they built custom marketing databases and attached tools like the Unica campaign manager). It was purchased in 2008 by CSG International, a telecom customer communications specialist, and repurchased by the original management in 2014. By then, the managers had already started work on a next-generation platform designed to handle both traditional and online data, using relational databases for one and a NoSQL system (in this case, Hadoop) for the other. The company has recently introduced this to the market as AdVantage.

The split architecture of AdVantage is actually pretty common among CDPs, since anonymous and identified customer data are often kept separate for privacy reasons. It’s also common to hold all the raw data in a NoSQL data lake and extract it to a relational database where it's refined and restructured for analysis. AdVantage does that too. It’s a bit less common for vendors to be so open about these details; Quaero management's transparency is probably another result of their maturity.


What’s truly unusual is the sophistication of AdVantage’s data processing itself. After nearly two decades of wrestling with customer identities, Quaero has mastered tricks that many newer vendors have yet to see.* More concretely, the system provides over 1,000 prebuilt “workflows” that perform tasks within data staging, loading, cleaning, transformation, aggregation, scoring, and measurement. These can be configured to specific situations, giving users a great deal of power without writing actual queries or scripts. Workflows can also be strung together to create larger flows, which AdVantage visualizes nicely.  This lets users trace exactly how the system got to its results. Configuring the workflows is still definitely technical work, which is either done by IT staff or the Quaero services team. But AdVantage makes it more efficient than hand coding and vastly more accessible to anyone other than the original coder.

Another important feature is that AdVantage flows work with metadata, meaning they are not mapped directly to the underlying data stores. This means an implementation can move to different platforms without losing most of the work. That makes it easier to adopt new technologies and to convert to more powerful platforms if a system outgrows its original installation.

AdVantage’s features for working with identified customers are especially mature, handling different kinds of “fuzzy” name and address matching as well as creating a “golden record” of best values from all sources. It also has strong features for unifying anonymous inputs, which it supplements with device matching services such as Tapad and Oracle Crosswise. AdVantage creates separate customer IDs for identified and anonymous profiles, and then, when possible, links them with a master ID

Once the data is assembled, AdVantage makes it available to marketing users and applications such as business intelligence tools and campaign managers. AdVantage provides its own interactive reports and segmentation interface. But most users will attach their own tools such as Tableau or Looker. AdVantage also connects to execution tools such as email engines. These tools can directly access both the relational and NoSQL data stores. Quaero has built standard connectors to common products, both to load data and access it. It builds new connectors as clients need them.

Existing AdVantage installations are hosted on Amazon Web Services, although a client could also run it on-premise if desired. Pricing is based on factors including number of sources, data volume, users, and applications. An average installation runs $15,000 to $25,000 per month although some are lower and higher. Quaero provides services with the product to help clients get set up properly and make changes over time.


__________________________________________________________
*Some others have, especially those with a similar background.

Can Customer Data Platforms Make Decisions? Discuss.

I’ve had at four conversations in the past twenty four hours with vendors who build a unified customer database and use it to guide customer treatments. The immediate topic has been whether they should be considered Customer Data Platforms but the underlying question is whether Customer Data Platforms should include customer management features.

That may seem pretty abstract but bear with me because this isn’t really about definitions. It’s about what systems do and how they’re built.  To clear the ground a bit, the definition of CDP, per the CDP Institute, is “a marketer-managed system that creates a persistent, unified customer database that is accessible to other systems". Other people have other definitions but they are pretty similar. You’ll note there’s nothing in that definition about doing anything with data beyond making it available.  So, no, a CDP doesn’t need to have customer management features.

But there’s nothing in the definition to prohibit those features, either. So a CDP could certainly be part of a larger system, in the same way that a motor is part of a farm tractor. But most farmers would call what they’re buying a tractor, not a motor. For the same reasons, I generally don’t to refer to systems as CDPs if their primary purpose is to deliver an application, even though they may build a unified customer database to support that application.

The boundary gets a little fuzzier when the system makes that unified database available to external systems – which, you’ll recall, is part of the CDP definition. Those systems could be used as CDPs, in exactly the same way that farm tractors have “power take off” devices that use their motor to run other machinery.  But unless you’re buying that tractor primarily as a power source, you’re still going to think of it as a tractor. The motor and power take off will simply be among the features you consider when making a choice.*

So much for definitions. The vastly more important question is SHOULD people buy "pure" CDPs or systems that contain a CDP plus applications. At the risk of overworking our poor little tractor, the answer is the same as the farmer’s: it depends it on how you’ll use it. If a particular system offers the only application you need, you can buy it without worrying about access by other applications. At the other extreme, if you have many external applications to connect, then it almost doesn’t matter whether the CDP has applications of its own. In between – which is where most people live – the integrated application is likely add value but you also want to with connect other systems. So, as a practical matter, we find that many buyers pick CDPs based on both integrated applications and external access.  From the CDP vendor’s viewpoint, this connectivity is helpful because it makes their system more important to their clients.

The tractor analogy also helps show why data-only CDPs have been sold almost exclusively to large enterprises. Those companies have many existing systems that can all benefit from a better database.  In tractor terms, they need the best motor possible for power applications and have other machines for tasks like pulling a plow. A smaller farm needs one tractor that can do many different tasks.

I may have driven the tractor metaphor into a ditch.  Regardless, the important point is that a system optimized for a single task – whether it’s sharing customer data or powering farm equipment – is designed differently from a system that’s designed to do several things. I’m not at all opposed to systems that combine customer data assembly with applications.  In fact, I think Journey Orchestration Engines (JOEs), which often combine customer data with journey orchestration, make a huge amount of sense. But most JOE databases are not designed with external access in mind.  A JOE database designed for open access would be even better -- although maybe we shouldn't call it a CDP.

To put this in my more usual terms of Data, Decision, and Delivery layers: a CDP creates a unified Data layer, while most JOEs create a unified Data and Decision layer. There’s a clear benefit to unifying decisions when our goal is a consistent customer treatment across all delivery systems. What’s less clear is the benefit of having the same system combine the data and decision functions. The combination avoids integration issues.  But it also means the buyer must use both components, even though she might prefer a different tool for one or the other.

Remember that there’s nothing inherent in JOEs that requires them to provide both layers. A JOE could have only the decision function and connect to a separate CDP. The fact that most JOEs create a database is just the matter of necessity: most companies don’t have a database in place, so the JOE must build one in order to do the fun stuff (orchestration).  Many other tools, such as B2B predictive analytics and customer success systems, create their own database for exactly the same reason. In fact, I originally classified those systems as CDPs although I’ve now narrowed my definition since the database is not their focus.

So I hope this clarifies things: CDPs can have decision functions but if decisions are the main purpose of the system, it’s confusing to call it a CDP.  And CDPs are certainly not required to have decision functions, although many do include them to give buyers a quick return on their investment. If that seems like waffling, then so be it: what matters is helping marketers to understand what they’re getting so they get what they really need.


_________________________________________________________________
*I’ll guess few of my readers are very familiar with farm tractors. Maybe the more modern analogy is powering apps with your smartphone. For the record, I did work on a farm when I was a lad, and drove a tractor.

ActionIQ Merges Customer Data Without Reformatting

One of the fascinating things about the Customer Data Platform Institute is how developers from different backgrounds have converged on similar solutions. The leaders of ActionIQ, for example, are big data experts: Tasso Argyros founded Aster Data, which was later purchased by Teradata, and Nitay Joffe was a core contributor to HBase and the data infrastructure at Facebook.  In their previous lives, both saw marketers struggling to assemble and activate useful customer data. Not surprisingly, they took a database-centric approach to solving the problem.

What particularly sets ActionIQ apart is the ability to work with data from any source in its original structure. The system simply takes a copy of source files as they are, lets users define derived variables based on those files, and uses proprietary techniques to query and segment against those variables almost instantly. It’s the scalability that’s really important here: at one client, ActionIQ scans two billion events in a few seconds. Or, more precisely, it’s the scalability plus flexibility: because all queries work by re-reading the raw data, users can redefine their variables at any time and apply them to all existing data. Or, really, it's scalability, flexibility, and speed, because new data is available within the system in minutes.

So, amongst ActionIQ’s many advantages are scalability, flexibility, and speed. These contrast with systems that require users to summarize data in advance and then either discard the original detail or take much longer to resummarize the data if a definition changes.

ActionIQ presents its approach as offering self-service data access for marketers and other non-technical users. That’s true insofar as marketers work with previously defined variables and audience segments. But defining those variables and segments in the first place takes the same data wrangling skills that analysts have always needed when faced with raw source data. ActionIQ reduces work for those analysts by making it easier to save and reuse their definitions. Its execution speed also reduces the cost of revising those definitions or creating alternate definitions for different purposes. Still, this is definitely a tool for big companies with skilled data analysts on staff.

The system does have some specialized features to support marketing data. These include identity resolution tools including fuzzy matching of similar records (such as different versions of a mailing address) and chaining of related identifiers (such as a device ID linked to an email linked to an account ID). It doesn’t offer “probabilistic” linking of devices that are frequently used in the same location although it can integrate with vendors who do. ActionIQ also creates correlation reports and graphs showing the relationship between pairs of user-specified variables, such as a customer attribute and promotion response. But it doesn’t offer multi-variable predictive models or machine learning.

ActionIQ gives users an interface to segment its data directly. It can also provide a virtual database view that is readable by external SQL queries or PMML-based scoring models. Users can also export audience lists to load into other tools such as campaign managers, Web ad audiences, or Web personalization systems. None of this approaches the power of the multi-step, branching campaign flows of high-end marketing automation systems, but ActionIQ says most of its clients are happy with simple list creation. Like most CDPs, ActionIQ leaves actual message delivery to other products.

The company doesn’t publicly discuss the technical approach it takes to achieve its performance, but they did describe it privately and it makes perfect sense. Skeptics should be comforted by the founders’ technical pedigree and demonstrated actual performance. Similarly, ActionIQ asked me not to share screen shots of their user interface or details of their pricing. Suffice to say that both are competitive.

ActionIQ was founded in 2014 and has been in production with its pilot client for over one year. The company formally launched its product last month.

Singing the Customer Data Platform Blues: Who's to Blame for Disjointed Customer Data?

I’m in the midst of collating data from 150 published surveys about marketing technology, a project that is fascinating and stupefying at the same time. A theme related to marketing data seems to be emerging that I didn’t expect and many marketers won’t necessarily be happy to hear.

Most surveys present a familiar tune: many marketers want unified customer data but few have it. This excerpt from an especially fine study by Econsultancy makes the case clearly although plenty of other studies show something similar.

So far so good. The gap is music to my ears, since helping marketers fill it keeps consultants like me in the business. But it inevitably raises the question of why the gap exists.

The conventional answer is it’s a technology problem. Indeed, this Experian survey makes exactly that point: the top barriers are all technology related.

And, comfortingly, marketers can sing their same old song of blaming IT for failing to deliver what they need.  For example, even though 61% of companies in this Forbes Insights survey had a central database of some sort, only 14% had fully unified, accessible data.

But something sounds a little funny. After all, doesn’t marketing now control its own fate? In this Ascend2 report, 61% of the marketing departments said they were primarily responsible for marketing data and nearly all the other marketers said they shared responsibility.

Now we hear that quavering note of uncertainty: maybe it’s marketing’s own fault? That’s something I didn’t expect. And the data seems to support it. For example, a study from Black Ink ROI found that the top barrier to success was better analytics (which implicitly requires better data) and explicitly listed data access as the third-ranked barrier.

But – and here’s the grand finale – the same study found that data integration software ranked sixth on the marketers’ shopping lists. In other words, even though marketers knew they needed better data, they weren’t planning to spend money to make it happen. That’s a sour chord indeed.

But the song isn't over.  If we listen closely, we can barely make out one final chorus: marketers won’t invest in data management technology because they don’t have the skills to use it. Or that’s what this survey from Falcon.io seems to suggest.

In its own way, that’s an upbeat ending. Expertise can be acquired through training or hiring outside experts (or possibly even mending some fences with IT). Better tools, like Customer Data Platforms, help by reducing the expertise needed. So while marketers aren't strutting towards a complete customer view with a triumphal Sousa march, there’s no need for a funeral dirge quite yet.

Hull.io Offers A Customer Data Platform for B2B Marketers

The need for a Customer Data Platform – a marketer-controlled, unified, persistent, accessible customer database – applies equally to business and consumer marketing. Indeed, many of the firms I originally identified as CDPs were lead scoring and customer success management vendors who serve primarily B2B clients. But as the category has evolved, I’ve narrowed my filter to only consider CDPs as companies that focus primarily on building the unified data.  This excludes the predictive modeling vendors and customer success managers, as well as the big marketing clouds that list a CDP as one of many components. Once you apply that filter, nearly all the remaining firms sell largely to B2C enterprise clients.

Hull.io is an exception. Its clients are mostly small, B2B companies – exactly the firms that were first to adopt software-as-a-service (SaaS) technologies including marketing automation and CRM. This is no accident: SaaS solves one problem by making it easy to acquire new systems, but that creates another problem because those systems are often isolated from each other. Hull addresses that problem by unifying their data, or, more precisely, by synchronizing it.

How it works is this: Hull has connectors for major customer-facing SaaS systems, such as Salesforce, Optimizely, HubSpot, Mailchimp, Facebook custom audiences, Slack, and Zendesk. Users connect with those systems and specify data elements or lists to synchronize. When data changes in one of customer-facing products, the change is sent to Hull which in turn sends it to other products that are tracking that data.

But, unlike data exchanges such as Zapier or Segment, Hull also keeps its own copy of the data. That’s the “persistent” bit of the CDP definition. It gives Hull a place to store data from enhancement vendors including Datanyze and Clearbit, from external processes called through Javascript, and from user-defined custom variables and summary properties, such as days since last visit. Those can be used along with other data to create triggers and define segments within Hull.  The segments can then be sent to other systems and updated as they change.

In other words, even though the external systems are not directly reading the data stored within Hull, they can still all work with consistent versions of the data.* Think of it as the martech equivalent of Einstein’s’ “spooky action at a distance”  if that clarifies things for you.

To extend its reach even further, Hull.io can also integrate with Zapier and Segment allowing it to exchange data with the hundreds of systems those products support.

Three important things have to happen inside of Hull.io to provide a unified customer view. First, it has to map data from different sources to a common data model – so that things like customer name or product ID are recognized as referring to the same entities even if they come from different places. Hull.io simplifies this as much as possible by limiting its internal data model to two entities, customers and events.  Input data, no matter how complicated, is converted to these entities by splitting each record into components that are tagged with their original meaning and relationships. The splitting and tagging are automatic, which is very important for making the system easy to deploy and maintain.  Users still need to manually tell the system which elements from different systems should map to the same element in the shared data.

The second important thing is translating stored data into the structure needed by the receiving system. This is the reverse of the data loading process, since complex records must be assembled from the simplified internal model. What’s tricky is that the output format is almost always different from the input format, so the pieces have to be reassembled in a different format.  While we’re making questionably helpful analogies, think of this as the Jive Lady translating for the sick passenger in the movie Airplane.

The third key thing is that data relating to the same customer needs to be linked. Hull will do “deterministic” matching to stitch together identities where overlapping information is available – such as, connecting an account ID to a device when someone uses that device to log into their account. Like many other CDPs, Hull doesn’t attempt “probabilistic” matching, which looks for patterns in behavior or data to associate identifiers that are likely to belong to the same person. It does use IP address to associate visitors with businesses, even if the individual is anonymous.

All told, this adds up to a respectable set of CDP features. But Hull co-founder Romain Dardour says few clients actually come to the company looking for a unified, persistent customer database. Rather, they are trying to create specific processes, such as using Slack to send notifications of support tickets from Zendesk. Hull has built a collection of these processes, which it calls recipes. Customers can use an existing recipe or design their own. Dardour said that once clients deploy a few recipes they usually recognize the broader possibilities of the system and migrate towards thinking of it as a true CDP, even if they still don’t use the term.

This is consistent with what I’ve seen elsewhere.  Big enterprises can afford to purchase a unified customer database by itself, but smaller firms often want their CDP to include a specific money-making application. That’s why my original B2B CDPs usually included applications like lead scoring and customer success, while the B2C enterprise CDPs often did not.

The other big divide between Hull and enterprise CDPs is cost. Most enterprise CDPs start somewhere between $100,000 and $250,000 per year and can easily reach seven figures. Hull starts as low as $500 per month, with a current average of about $1,000 and the largest clients topping out around $10,000. Price is based primarily on the number of system connections, with some adjustments for number of contact records, guaranteed response time, data retention period, and special features. Hull has over 1,000 clients, mostly in the U.S. but with world-wide presence. It was founded in 2013.


_________________________________________________________________________________
*You could argue that because the external systems are not reading Hull.io’s data directly, it doesn’t truly qualify as a CDP. I’d say it’s not worth the quibble – although if really massive amounts of data were involved, it might be significant. Remember that Hull.io is dealing with smaller businesses, where replicating all the relevant data is not a huge burden.

News from Krux, Demandbase, Radius: Customer Data Takes Center Stage

If Dreamforce seems a little less crowded than you expected this week, perhaps it's because I didn’t attend. But I’m still tracking the news from Salesforce and other vendors from my cave in Philadelphia. Three announcements caught my eye, all highlighting the increasing attention being paid to customer data.

Salesforce itself had the biggest news yesterday, with its agreement to purchase Krux, a data management platform that has expanded well beyond the core DMP function of assembling audiences from cookie pools. Krux now has an “intelligent marketing hub” that can also load a company’s own data from CRM, Websites, mobile apps, and offline sources, and unify customer data to build complete cross-channel profiles. Krux also allows third party data owners to sell their data through the Krux platform and offers self-service data science for exploration and predictive models. The purchase makes great strategic sense for Salesforce, providing it with a DMP to match existing components in the Oracle and Adobe marketing clouds. But beyond the standard DMP function of generating advertising audiences, Krux gives Salesforce a solid customer data foundation to support all kinds of marketing management.  In particular, it goes beyond the functions in Salesforce ExactTarget, which was previously the designated core marketing database for Salesforce Marketing Cloud. To be clear, there’s no campaign management or journey orchestration within Krux; those functions would be performed by other systems that simply draw on Krux data. Which is exactly as it should be, if marketers are to maintain maximum flexibility in their tools.

Demandbase had its own announcement yesterday: something it calls “DemandGraph,” which is basically a combination of Demandbase’s existing business database with data gathering and analytical functions the Spiderbook system that Demandbase bought in May 2016. DemandGraph isn’t exactly a product but rather a resource that Demandbase will use to power other products. It lets Demandbase more easily build detailed profiles of people and companies, including history, interests, and relationships. It can then use the information to predict future purchases and guide marketing and sales messages. There’s also a liberal sprinkling of artificial intelligence throughout DemandGraph, used mostly in Spiderbook’s processing of unstructured Web data but also in some of the predictive functions. If I’m sounding vague here it’s because, frankly, so was Demandbase. But it’s still clear that DemandGraph represents a major improvement in the power and scope of data available to business marketers.

Predictive marketing vendor Radius made its announcement last week of the Radius Customer Exchange.  This uses the Radius Business Graph database (notice a naming trend here?) to help clients identify shared customers without exposing their entire files to each other. Like Spiderbook, Radius gathers much of its data by scanning the public Web; however, Radius Business Graph also incorporates data provided Radius clients. The client data provides continuous, additional inputs that Radius says makes its data and matching much more accurate than conventional business data sources. Similarly, while there’s nothing new about using third parties to find shared customers, the Radius Customer Exchange enables sharing in near real time, gives precise revocable control over what is shared, and incorporates other information such as marketing touches and predictive models. These are subtle but significant improvements that make data-driven marketing more effective than ever. The announcement also supports a slight shift in Radius’ position from “predictive modeling” (a category that has lost some of its luster in the past year) to “business data provider”, a category that seems especially enticing after Microsoft paid $26.2 billion for LinkedIn.

Do these announcements reflect a change in industry focus from marketing applications to marketing data? I’m probably too data-centric to be an objective judge, but a case could be made. If so, I’d argue it’s a natural development as marketers look beyond the endless supply of sparkly new Martech applications to the underlying foundations needed to support them. In the long run, a solid foundation makes it easier to dance creatively along the surface: so I’d rate a new data-driven attitude as a Good Thing.

ABM Vendor Guide: What to Look for in External Data Sources

Last week’s posts introduced our new Raab Guide to ABM Vendors (buy it here) and introduced a framework four process ABM steps, six system functions, and six key sub-functions. The idea was that functions define major categories of systems, while the sub-functions differentiate systems within each category. The world isn’t really quite this simple, if only because many systems provide more than one function. But the sub-functions are still important for stack design and vendor selection.

My plan this week is to follow up with a sequence of posts that go through each sub-function in some depth.  Let’s start with the first sub-function, External Data. 

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

Vendors that support this sub-function gather account and contact information from the Internet, private, and government sources and purchase it from other vendors. They may resell the data to marketers or use it themselves to support tasks such as account scoring or ad targeting. 

(To put things in a broader context, “external data” can be contrasted with “internal data”, which comes from a company’s own systems for CRM, marketing automation, Web analytics, order processing, customer support, etc. Internal data is most important later in the sales cycle, when prospects and customers are interacting with the company directly. External data is most important at the start, when the company hasn’t identified its target accounts or established direct relationships with them.)

External data may seem like a commodity – after all, all vendors have access to pretty much the same sources. Yet there’s probably more variety among the vendors in this category than any other. Some key differentiators identified in the ABM Guide include:

• types of data provided (companies, contacts, events, intent, technology used)
• number and types of data sources (company Web pages, publisher Web pages, ad exchanges and networks, job posting sites, social networks, IP directories, financial reports, government files, industry and professional directories, news feeds, etc.  Different sources provide different data types.)
• depth of data (to measure this, get a list of data elements)
• quality of data (harder to measure: review some sample records and have the vendor explain their quality methods)
• coverage by region, company size, industry, etc. (depends heavily on data types and sources)
• coverage by language (many systems extract data using natural language technology that can only read English)
• how often data is refreshed (which involves two issues: how often are sources revisited and how quickly do changes get communicated to clients)
• on-demand updates for individual accounts or contacts (to get up-to-the minute information on a new or existing account)
• add new data sources to meet specific client needs (e.g., reports of new research contracts in the client's industry)
• custom research to supplement public information (in particular, some vendors do custom research to identify the IP addresses used by target accounts)
• custom taxonomies for intent analysis (because standard taxonomies may not be precise enough for specialized client needs)
• maturity of data management processes (how long they’ve been evolving, size of team, etc.)
• data verification methods (phone call, test for email bounces, compare against other sources, etc.)
• special methods to associate personal and business emails, attach leads to accounts, find social media handles, etc. (vendors may do different kinds of “fuzzy” matching, machine learning, or natural language processing to uncover or infer relationships when exact matches are not available)
• load client data and match against it for enhancement (most vendors will do this but some require the client to do its own matching)
• continuous updates of client data (reporting on changes as the vendor learns about them; requires uploading a list of accounts or individuals to monitor)
• provide personal identifiers on contact records (name, address, phone, email address, social media handle, etc.; not all vendors do this, especially in countries with strict privacy laws; different identifiers are also treated differently)
• provide a complete universe of all companies in a target market (some vendors only enhance records already in the client database, others provide "net new" records as well.)
• find social connections between company employees and target account employees (make sure this is done without violating the social network terms of service).
• real-time processes to identify Web site visitors, auto-fill Web forms or verify form entries, show data to sales people, support ad targeting, etc.
• add ownership relationships to accounts (headquarters/branch, parent/subsidiary, brand/franchisee, etc.) in general and to the D-U-N-S Number in particular
• fee structure (most are vendors charge per record and/or based on the data types; some are performance-based)

Which of these are important will depend on your business needs and approach to ABM. For example, if you sell to small businesses, then coverage is critical because many vendors identify companies using IP address or Web domain – things many small businesses do not have. On the other hand, if you want to target Web messages to large enterprises, your critical need will be real-time identification of Web site visitors, something only a few vendors can support.

The issue hovering over all this is data quality. If quality is poor, then nothing else matters. Quality can be a somewhat tricky concept, since it’s not just accuracy or coverage or currency.  My personal favorite definition of quality is “fitness for purpose”, which makes the point that the quality of data (or anything else) is related to how you’re going to use it. But even assuming you know exactly what you need, you can’t predict quality based on a checklist of features or attributes. The only practical approach is to get some sample data and see how it performs, whether by comparing it to known correct data, testing it directly via phone calls or surveys, or using it in a marketing program and measuring the results. Experienced data-driven marketers have known this forever, but less experienced marketers may not realize that all data isn’t as good as they’d like to assume. There’s not much I can do in the ABM Guide to solve this issue, but smart marketers can use the Guide to identify data vendors who meet their other requirements, and then test those vendors' data to ensure the quality is what they need.